From nobody Sun May 1 14:50:58 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294DB12D0DF; Sun, 1 May 2016 14:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 cACD3EDdY3wA; Sun, 1 May 2016 14:50:40 -0700 (PDT) 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 7C5A212B01C; Sun, 1 May 2016 14:50:40 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id x19so171842462oix.2; Sun, 01 May 2016 14:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4tI5hCf46fANBdJfiahM9xhPC8s+UStGqREUs9MgZCU=; b=I/XHsoVG6Qd0YrOLU/8sbdonsiYhlf65ElsDwaJkymhnDErYWFvQBUxN7lcogehAmN lmK5AqP58TNBp13L8RmXfn6rCO/qs6ac7hYo6zlCn8IVIgrr5avD0sCnGzottt8DhIIJ j3wyPA7F2yOMk4GKOWtEGQvvOrbGOn4FEoJOUKg1/tYKOr5Q0KVeRuwhiqleVMZ23HSD xke6zaIfdppBM5dHN59LyoLMgVeJ71CXoMtqoITcuLMIgpI5vtnJAuOJCi+85m7KFSw9 x2jsEkDFEBzN7RHV6rbn00iJwivltF9UwZi+Gs9CHH81GJyLZiYr9i8UUkU2x7g5fWu/ 5e/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4tI5hCf46fANBdJfiahM9xhPC8s+UStGqREUs9MgZCU=; b=BQhzVXoWq1Crn3o4W0bBIGOBYhmkur33FTrEAezU0dTqMRC52VKVB8e5LIyqAS4Ysg yRC/Gjgx++UaL3sZIlh0Oa97/v97ga8Rqo7x13mxfDkuX2XnYzEsuutGA1yExi0tqNU9 24kA0m4YkSXSqagUUhaKcLttYsK9RYBsu+iqzfciOfIhKso7+pH/0ji9mBWoiLqwZG/j 3e4uIXpfsK1srUKvIln41STG7vqUgg2QHHBb0bXtrQ7m0t/0ni5OSnaOpwj1B6kwv6DW xTHjt6CeeuVZM93pZUdEp0JWx5SKmunB3wCbdd9K5p/oh+jXDEfE03Jjqu83r0IkPxSg nm6A== X-Gm-Message-State: AOPr4FUnzW44j+WjdTuSglfI6enY+k+oeMY8HW10f7vjwn2XYHjZA476c1qT98Gl/jTV0Zgkpxaz8aT3kd9nHQ== X-Received: by 10.202.228.2 with SMTP id b2mr8558820oih.81.1462135598588; Sun, 01 May 2016 13:46:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.216 with HTTP; Sun, 1 May 2016 13:46:24 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Sun, 1 May 2016 16:46:24 -0400 Message-ID: To: Jonathan Hardwick Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: " \(rtg-ads@ietf.org\)" , "rtg-dir@ietf.org" , "trill@ietf.org" , "draft-ietf-trill-channel-tunnel@ietf.org" , "akatlas@gmail.com" Subject: Re: [RTG-DIR] Routing directorate review of draft-ietf-trill-channel-tunnel X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 21:50:45 -0000 On Thu, Apr 28, 2016 at 9:26 AM, Jonathan Hardwick wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > 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 > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing > ADs, it would be helpful if you could consider them along with any > other IETF Last Call comments that you receive, and strive to > resolve them through discussion or by updating the draft. > > Best regards > Jon > =3D=3D=3D > > Document: draft-ietf-trill-channel-tunnel > Reviewer: Jon Hardwick > Review Date: 28 April 2016 > Intended Status: Standards Track > > > Summary > > I have some concerns about this document and recommend that the > Routing ADs discuss these issues further with the authors. > > > Comments > > The draft is overall well written and the specification is quite > easy to understand, Thanks. > but I found some of the terminology and > rationale to be confusing. I would prefer to see this clarified > before the document is published as RFC. Note that this is the > first TRILL document I=E2=80=99ve reviewed, so my context comes largely f= rom > mailing list searches and the shepherd=E2=80=99s report. > > > Major Comments > > The motivations for this draft are quite obscure from the > perspective of the outsider J which makes it hard for me to evaluate > the proposed mechanism. > > I think the problems that the draft solves should be more clearly > spelled out. From the introduction: > > This document updates [RFC7178] and specifies extensions to RBridge > Channel that provide two additional facilities as follows: > > (1) A standard method to tunnel a variety of payload types by > encapsulating them in an RBridge Channel message. > > (2) A method to provide security facilities for RBridge Channel > messages. > > I think that number (1) requires more explanation because the > RBridge channel already provides a standard method for a variety of > payload types to be transmitted without needing the current draft. > What tunneling capability is this draft adding? Good point. The RBridge Channel facility does provide a "protocol number" which is, in essence, the "type" of its payload. However, there are three limitations of RBridge Channel: (1) No security; (2) No way to leverage the many existing defined Ethertypes as a payload type; and (3) RBridge Channel can only send typed messages either (3a) between RBridges in a campus and (3b) between end stations and RBridges on the same link. Earlier versions of this draft included mechanisms extensions in area 3, for example, for sending RBridge Channel messages between end stations and RBridges not on the same link; however, this added significant complexity and there appears to be no current need for such extensions so they were dropped, leaving only extensions in areas 1 and 2. How about the following change on additional facility 1 in the draft: OLD (1) A standard method to tunnel a variety of payload types by encapsulating them in an RBridge Channel message. NEW (1) A standard method to tunnel payloads whose type may be indicated by Ethertype through encapsulation in RBridge Channel messages. > A significant amount of text in the draft discusses number (2), > which secures the channel payload, presumably to cover cases where > the payload has no in-built security mechanism. This appears to be > the major purpose of the draft. The draft achieves number (2) by > adding a security shim header between the RBridge channel header and > the payload. One consideration in doing this is to remain backwards > compatible with RFC 7178, and it looks like the working group has > decided to achieve backwards compatibility by defining a new RBridge > channel protocol type called =E2=80=9Cchannel tunnel=E2=80=9D =E2=80=93 w= here this > effectively means the RBridge channel payload contains an additional > security shim which in turn contains an identifier that determines > the real payload protocol type. > > I find the term =E2=80=9Cchannel tunnel=E2=80=9D misleading, as the draft= does not > appear to add any additional tunnelling capability above and beyond > the tunnelling that can already be done using RFC 7178. The draft > actually describes an RBridge channel with enhanced security, so a > term like =E2=80=9Csecure channel=E2=80=9D would make more sense to me th= an =E2=80=9Cchannel > tunnel=E2=80=9D. OK, I understand why you think that term is misleading. While it seems quite reasonable to called the added fields a "shim", note that the facility currently called "Channel Tunnel" is quite closely integrated with the existing RFC 7178 RBridge Channel facility. For example, there is only one error reporting mechanism. Errors in the "Channel Tunnel" facility added by this draft are reported as if they were errors in the RBridge Channel messages to which the "shim" was added. I don't actually like your suggestion of "secure channel" as a new name. How about re-naming the facility being added by this draft as the "RBridge Channel Header Extension"? I believe that RFC 7783 and only that RFC that references this draft using the term "Channel Tunnel" but this is a very minor informational passing reference. There are drafts in the publication requested state that reference this draft using the term "Channel Tunnel" but it seems that it would be relatively straightforward to change the name to "RBridge Channel Header Extension" or some other new name in those drafts and even easier to change it in drafts still under the control of the TRILL WG. > Minor Comments > > Section 3.1 =E2=80=93 =E2=80=9CAny particular use of the Null Payload sho= uld specify > what VLAN or priority should be used when relevant.=E2=80=9D =E2=80=93 is= unclear > and no context for this statement is given. Should be used by what > and for what purpose? OK. How about: Any particular use of the Null Payload should specify what VLAN or FGL and what priority should be used in the inner data label of the RBridge Channel message (or in an outer VLAN tag for the native RBridge Channel message case) when those values are relevant. > Section 4.3 feels like a corollary to section 4.5 and so may be > better placed as a subsection of 4.5. The method of deriving keying material given in Section 4.3 is also used in DTLS security as mentioned in Section 4.6 so I think it should remain a separate section. > Section 4.6 =E2=80=9CThe PType indicates the nature of the > application_data.=E2=80=9D - is potentially open to misinterpretation. A= t > face value it sounds like you are leaking some potentially sensitive > information about the =E2=80=9Cnature=E2=80=9D of the encrypted payload. = I think > all you are actually saying is that it indicates whether the payload > is an Ethertype, an Ethernet frame etc. Suggest instead =E2=80=9CIn this > case, the PType value in the RBridge Channel Tunnel Protocol > Specific Data applies to the decrypted application_data.=E2=80=9D OK. > Section 5.2 =E2=80=9Cwith a payload type (PType) indicating a nested RBri= dge > Channel message=E2=80=9D =E2=80=93 strictly all the PType can indicate is= that the > payload is Ethertyped; on its own it cannot indicate a nested > RBridge Chanel message. Suggest =E2=80=9Cand it contains a nested RBridg= e > Chanel message=E2=80=9D. OK. > Section 6.2 > > =E2=80=9CSection xxx of [RFC 7178]=E2=80=9D should be =E2=80=9CSection 3.= 2 of [RFC 7178]=E2=80=9D. Right. Sorry about that. > Don=E2=80=99t you also need a new IANA registry for the =E2=80=9CRbridge = Channel > Error Subcodes=E2=80=9D listed in table 5.2? My opinion is that, for the first document in which you specify a field and some values, it is a judgment call whether you should create an IANA registry or not. If you expect multiple groups to start requesting values to multiple purposes, then creating a registry from the start is the way to go. On the other hand, if a field is internal to a particular protocol and you don't expect any new field values to be assigned until there is a significant extension of that protocol, I don't see any problem in deferring the registry creation to the second document. This is the second document assigning values for RBridge Channel Error Codes so it creates a registry for them. It does not create a registry for SubERR field values. > Nits > > Section 3.2 > > =E2=80=9Cas describe in=E2=80=9D -> =E2=80=9Cas described in=E2=80=9D OK. > Section 4 > > =E2=80=9Cnot to met=E2=80=9D -> =E2=80=9Cnot to meet=E2=80=9D OK. > 2nd paragraph =E2=80=93 this sentence is quite long and hard to parse. You're right. Looking at the sentence, it seems fairly easy to simplify and split into two sentences. How about the following replacement: The Channel Tunnel DTLS based security specified in Section 4.6 below is intended for pairwise (known unicast) use. That is, the case where the M bit in the TRILL Header is zero and any Outer.MacDA is individually addressed. > Section 4.2 & Section 5.1 > > =E2=80=9CAs show in=E2=80=9D - > =E2=80=9CAs shown in=E2=80=9D OK. > Section 4.3 > > =E2=80=9CThe use Derived Material=E2=80=9D -> =E2=80=9CThe use of the Der= ived Material=E2=80=9D OK. > Does Derived Material really need to be capitalized in this section? Well, it is capitalized in the equation. Seems to me reasonable to capitalize in both cases to indicate that a specific type of Derived Material is being talked about. > Section 4.5 > > =E2=80=9Ccan reasonable be=E2=80=9D -> =E2=80=9Ccan reasonably be=E2=80= =9D OK. > Section 4.6 > > =E2=80=9Cminimum MTU Sz=E2=80=9D -> =E2=80=9Cminimum MTU size=E2=80=9D Sz is a standard TRILL symbol widely used in TRILL documents and defined in Section 1.1 of this draft. I would prefer to make the following change in Section 4.6: "the TRILL campus wide minimum MTU Sz" -> "Sz". > =E2=80=9CActual application_data sent with Channel Tunnel=E2=80=9D -> =E2= =80=9CActual > application_data sent within the Channel Tunnel=E2=80=9D OK. > Why do you say =E2=80=9Capplication_data=E2=80=9D not =E2=80=9Capplicatio= n data=E2=80=9D? "application_data" is the name of the field type in DTLS. > Appendix Z should presumably be removed prior to IETF last call. While I'm not sure how much help it would be to IESG members or IETF participants in reviewing the draft, I don't see any reason for Appendix Z to be removed until RFC publication. But at least a notation asked the RFC Editor to delete it should be added. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Mon May 2 00:51:11 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3339812B02C; Mon, 2 May 2016 00:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.996, SPF_SOFTFAIL=0.665] 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 2INjsWm2yRc6; Mon, 2 May 2016 00:51:06 -0700 (PDT) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [161.106.1.2]) by ietfa.amsl.com (Postfix) with ESMTP id 821C112B028; Mon, 2 May 2016 00:51:05 -0700 (PDT) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 83469410270; Mon, 2 May 2016 09:51:04 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail1.rd.orange.com (Postfix) with ESMTP id 26EF641026D; Mon, 2 May 2016 09:51:04 +0200 (CEST) Received: from [10.193.71.204] (10.193.71.204) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.266.1; Mon, 2 May 2016 09:51:03 +0200 To: Mingui Zhang References: <57212222.5080904@orange.com> <4552F0907735844E9204A62BBDD325E787C858FD@NKGEML515-MBX.china.huawei.com> From: Julien Meuric Organization: Orange Message-ID: <572706E7.7050005@orange.com> Date: Mon, 2 May 2016 09:51:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <4552F0907735844E9204A62BBDD325E787C858FD@NKGEML515-MBX.china.huawei.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-trill-mtu-negotiation.all@ietf.org" , "trill@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-trill-mtu-negotiation-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 07:51:08 -0000 Hi Mingui, About the "updated RFCs" issue below, my point is: "please make sure the text and the hearder are complete". I just had a quick look at those references, you know better than me which are actually relevant. I am looking forward to the updated version. Thanks, Julien Apr. 29, 2016 - zhangmingui@huawei.com: > Hi Julien, > > Thanks for the comments! Much appreciated! > > Please see in-lines below. An updated version will soon be uploaded to resolve the comments. > > Thanks, > Mingui > >> -----Original Message----- >> From: Julien Meuric [mailto:julien.meuric@orange.com] >> Sent: Thursday, April 28, 2016 4:34 AM >> >> Hello, >> >> I have been selected as the Routing Directorate reviewer for this draft. >> The Routing Directorate seeks to review all routing or 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 >> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >> >> Although these comments are primarily for the use of the Routing ADs, it would >> be helpful if you could consider them along with any other IETF Last Call >> comments that you receive, and strive to resolve them through discussion or by >> updating the draft. >> >> Document: draft-ietf-trill-mtu-negotiation-02.txt >> Reviewer: Julien Meuric >> Review Date: April 27, 2016 >> IETF LC End Date: April 5, 2016 >> >> Intended Status: Standards Track >> >> >> *Summary:* >> I have some minor concerns about this document that I think should be resolved >> before publication. >> >> *Comments:* >> Even though it requires to browse some other TRILL (normative) documents, the >> mechanism itself is simple and well described. >> Nevertheless, the specification deserves some improvement when it comes to >> obligations and options: this was part of my expectation after I realized it was >> upgrading a short section of the base document (RFC 6325), which needs to be >> emphasized as well. > > In the abstract, it's already mentioned as "optional updates" to RFC 6325. I think "Updates: 6325 " needs to appear in the page header as well. > >> >> *Minor Issues:* >> - The document is ST and references RFC 2119. There a some "MUST" and one >> "SHOULD", many of them inherited from specifications out of the referenced >> documents. On the other side, "must" and "should" are commonly used. This >> MUST be brought up to ST expectations. > > The usage of "must" and "should" will be updated as needed. I have checked all those appearances. The changes would be editorial. > >> - The document claims to only update RFC 7177. It seems however that it also >> updates RFC 6325 (section 4.3.2), RFC 7176 and maybe even RFC 7780. > > Actually, I don't think this document updates RFC7176. It simply makes use of the MTU Sub-TLV defined in RFC 7176. > The specification about the originatingL1LSPBufferSize of an unreachable RBridge is a slight update to RFC7780. This will be emphasized. > >> That should be either acknowledged or clarified. The 4th paragraph of the >> introduction tries to tackle that topic, but it is not clear enough in defining the >> position of the document with respect to previously defined mechanisms. > > The updated to RFC 6325 will be emphasized in this paragraph. The backward compatibility will be moved to here as well. It will help the positioning. > >> - The 3rd paragraph of the introduction duplicates the beginning of the following >> section 2. A possible way to limit this repetition effect may be to summarize that >> part of the introduction. > > Yes, summarization is the proper way. > >> - Section 3 specifies an algorithm. Even if it does not rely on a formal language, >> consistency would be valuable. My mind compiler would suggest: >> * "If" is followed by "then" only once: "then" keyword to be dropped? >> * The algorithm relies on a break/stop or continue principle; as such, the >> instance of "Else" at the end should be replaced by "> break> 4) Repeat Step1"; >> * "is set to" and "<--" seem to be similar: please pick one or clarify; >> * to improve readability, I would drop the double naming introduced with X, >> X1 and X2 and rely on explicit variable names all along, as in the text: e.g., >> "linkMtuSize" instead of X, "lowerBound" for X1 and "upperBound" instead of X2. > > Sure. Explicit names will be used for the sake of readability. > >> >> *Nits:* > > The following nits will be fixed as suggested. > >> ------ >> "Updates" field in header >> --- >> - I think the "RFC" acronym should appear. >> - The list may be extended with RFC RFC 6325, RFC 7176 and maybe even RFC >> 7780. >> ------ >> Abstract >> --- >> - s/campus wide MTU feature/campus-wide MTU feature/ >> - s/campus wide capability/campus-wide capability/ >> - s/link local packets/link-local packets/ >> - s/link local MTUs/link-local MTUs/ >> - "It updates RFC..." duplicates header: either to drop or make more specific to >> point to precise sections/mechanisms. >> ------ >> Section 1. >> --- >> - s/link scope PDUs can/link-scoped PDUs can/ >> ------ >> Section 2. >> --- >> - s/campus wide Sz MTU/campus-wide Sz MTU/ >> - s/area wide scope/area-wide scope/ >> - s/domain wide scope/domain wide scope/ >> - s/L1 Circuit Scoped/L1 Circuit-Scoped/ >> - "limited to 1470 to 65,535 bytes": I cannot parse it, is it meant to be a range? >> ------ >> Section 4. >> - OLD >> "while RB1 normally ignores link state information for any IS-IS unreachable >> RBridge RB2, originatingL1LSPBufferSize is an exception." >> NEW >> "while in most cases RB1 ignores link state information for IS-IS unreachable >> RBridge RB2, originatingL1LSPBufferSize is meaningful." >> [current wording suggests it is adding an exception to a mandatory behavior, >> which AFAIU it does not] > > OK. Will update the words. > >> ------ >> Section 7. >> --- >> - "tested size can be advertised": "can" is to be addressed as part of the loose >> RFC 2119 wording comment. > > Will use the word "MAY" instead. > >> ------ >> Section 8. >> --- >> - "value [...] had been reported": "reported" puzzles me, maybe "tested" >> was meant? >> - The 3rd paragraph "For an Lz-ignorant [...] link-wide Lz." should be moved up to >> become the second paragraph, so as to clarify what an Lz-ignorant is. > > OK. It will be moved up. > >> - "The extension of TRILL MTU negociation...": this is an explicit positioning which >> should be mentioned earlier in the I-D. > > > OK. This will be moved to the introduction. > >> ------ >> Section 10. >> --- >> - RFC 7180 bis is now RFC 7780. > > Yes, this will be updated. > >> --- >> >> Regards, >> >> Julien > From nobody Mon May 2 07:04:44 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0FF612D517; Mon, 2 May 2016 07:04:40 -0700 (PDT) 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 gl_bafnnC3ki; Mon, 2 May 2016 07:04:39 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 EDE0A12B050; Mon, 2 May 2016 07:04:38 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id k142so190492568oib.1; Mon, 02 May 2016 07:04:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w+/3gI6AVLQZ7GaPe4vm9HiHvk6i2lOIS6W4vIB+pfk=; b=ced1WAwHrIfSqOhxNMNAYtjRLeAhR9HPXKqqmQ2ZHBHXPB8Iot0uJeZotNuMRxRuVE k8Em+nVn2ioUtZl2iXkWfZ8cGdQ0d6mXH6illfN0JByfwkCPfJ+ANwjhc5cG7vsDYCzd AThQALP2PGXtagSqz48fmTKmh4ISFnLvvtWt3lxTjhiFM3fH+C3zvLd2/Aa+JoWb40U8 uyXta00M3YGWU2lW/KlTok0iaurvhmO0IuNAB1MpHjCCTlXi7e3OkqpGqI4u8VDxERjo gU23eYwrPUneK8wbA6O9h6Wrdb0BuxCcRbqsczHA0HmlWOQ5Q0uaPz1PFgfoG3/mCoGX Y4RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=w+/3gI6AVLQZ7GaPe4vm9HiHvk6i2lOIS6W4vIB+pfk=; b=gKvbqXyu1iDgGbzt+NI9KpSvLWzvJBjtvaDKcCbJoAQmU1oVRx39Xst0dAZ7ck9rxS hXkGvbliwBg41uOPMRw4Zrtf4UOVCF8c8M+OojsZ+VXOh+aE0EOWxUI4YcIfHAQ+NYfO UmDsea9MRf0F2raZEJXie08iiMsdghLPuxSSxUaSANOHX5wI6Jwyy4JzwX8o5AEh6AFI +aPmOgB9BJ7YCM/4/VRXKNspFIeZJErcoBM/HF3bEzzfcKKInyIzWcZYfCnKk8YBlQb6 1uF6tepcbSAJQxl9+umXbXp+gCK7cKFeoTZjhQBAc9z4iArcf0CJACCxTW8V7hdejLCb /xxg== X-Gm-Message-State: AOPr4FW+uEVD7wOuRVJ3OYQn5fqCjlEYUn5P2iFTTnWHiRZbYwtT2JrSFSwOiPom2eyolcmf10c2VaJqitUszQ== X-Received: by 10.157.8.149 with SMTP id 21mr13834448otf.109.1462197878145; Mon, 02 May 2016 07:04:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.231.106 with HTTP; Mon, 2 May 2016 07:04:18 -0700 (PDT) In-Reply-To: <572475E5.2060009@gmail.com> References: <572475E5.2060009@gmail.com> From: "Andrew G. Malis" Date: Mon, 2 May 2016 10:04:18 -0400 Message-ID: To: Pushpasis Sarkar Content-Type: multipart/alternative; boundary=001a113f13c21e4c930531dc7953 Archived-At: Cc: "" , "rtg-dir@ietf.org" , isis-wg@ietf.org, draft-ietf-isis-node-admin-tag.all@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-isis-node-admin-tag-08.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 14:04:41 -0000 --001a113f13c21e4c930531dc7953 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pushpasis, Much appreciated, this is a really good improvement to the draft. Cheers, Andy On Sat, Apr 30, 2016 at 5:07 AM, Pushpasis Sarkar wrote: > Hi Andy, > > I have uploaded version -09. Let me know if you have any other comments. > > Thanks and Regards, > -Pushpasis > > > On Wednesday 20 April 2016 11:00 PM, Andrew G. Malis wrote: > >> Hello, >> >> I have been selected as the Routing Directorate reviewer for this draft. >> The Routing Directorate seeks to review all routing or routing-related >> drafts as they pass through IETF last call and IESG review, and sometime= s >> on special request. The purpose of the review is to provide assistance t= o >> the Routing ADs. For more information about the Routing Directorate, ple= ase >> see =E2=80=8B http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >> >> Although these comments are primarily for the use of the Routing ADs, it >> would be helpful if you could consider them along with any other IETF La= st >> Call comments that you receive, and strive to resolve them through >> discussion or by updating the draft. >> >> Document: draft-ietf-isis-node-admin-tag-08.txt >> Reviewer: Andy Malis >> Review Date: April 20, 2016 >> IETF LC End Date: April 29, 2016 >> Intended Status: Standards Track >> >> Summary: >> >> I have some minor concerns about this document that I think should be >> resolved before publication, if the AD agrees (see below for details). >> >> Comments and minor concerns: >> >> I have no technical concerns with this draft. >> >> I have noted the two comments in the AD review of this draft, and agree >> with them. >> >> Given the similarity in functionality to RFC 7777 and the overlap in >> authorship, I expected the draft to be more or less identical to the RFC= , >> except for the technical differences between OSPF and ISIS. However, the= re >> are parts of the RFC that are editorially better (easier to read or >> understand) than the equivalent text in the draft, starting with the tit= le, >> Abstract, and Introduction. In particular, the Introduction in the RFC >> looks like the result of cleanup by the RFC Editor, but which still need= s >> to be done in the draft. Why not take advantage of the work already done= by >> the RFC Editor? Also, the Introduction in the draft doesn't include the >> usual reference to RFC 2119 terms, which is in the RFC. The Abstract in = the >> RFC also includes more useful detail than the Abstract in the draft. >> >> As another example, these differences are also true in Section 4.1 of th= e >> draft, when compared to the mostly equivalent Section 2.2.1 of the RFC. = For >> example, from an editorial standpoint there is a missing "The" in the fi= rst >> line of the section, and there are other improvements as well. I also se= e >> editorial corrections in Section 3 of the RFC when compared to Section 5= in >> the draft. >> >> I would recommend an editorial pass where the text is compared with the >> RFC, and when obvious, editorially improved to take advantage of work >> already done. This will make the RFC Editor's job easier. Alternatively, >> the AD could choose to include a note to the RFC Editor, noting the >> similarity and asking the RFC Editor to take advantage of the work that >> they already did for the RFC. However, having this done by the document >> editor would take advantage of the editor's knowledge of when difference= s >> between the two are deliberate. >> >> Thanks, >> Andy >> >> > --001a113f13c21e4c930531dc7953 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Pushpasis,

Much appreciated, this is a = really good improvement to the draft.

Cheers,
Andy

On Sat, Apr 30, 2016 at 5:07 AM, Pushpasis Sarkar &l= t;pushpasis.i= etf@gmail.com> wrote:
Hi An= dy,

I have uploaded version -09. Let me know if you have any other comments.
Thanks and Regards,
-Pushpasis


On Wednesday 20 April 2016 11:00 PM, Andrew G. Malis wrote:
Hello,

I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see =E2= =80=8B http://trac.tools.ietf.org/area/rtg/trac/= wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft.

Document: draft-ietf-isis-node-admin-tag-08.txt
Reviewer: Andy Malis
Review Date: April 20, 2016
IETF LC End Date: April 29, 2016
Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I think should be resol= ved before publication, if the AD agrees (see below for details).

Comments and minor concerns:

I have no technical concerns with this draft.

I have noted the two comments in the AD review of this draft, and agree wit= h them.

Given the similarity in functionality to RFC 7777 and the overlap in author= ship, I expected the draft to be more or less identical to the RFC, except = for the technical differences between OSPF and ISIS. However, there are par= ts of the RFC that are editorially better (easier to read or understand) th= an the equivalent text in the draft, starting with the title, Abstract, and= Introduction. In particular, the Introduction in the RFC looks like the re= sult of cleanup by the RFC Editor, but which still needs to be done in the = draft. Why not take advantage of the work already done by the RFC Editor? A= lso, the Introduction in the draft doesn't include the usual reference = to RFC 2119 terms, which is in the RFC. The Abstract in the RFC also includ= es more useful detail than the Abstract in the draft.

As another example, these differences are also true in Section 4.1 of the d= raft, when compared to the mostly equivalent Section 2.2.1 of the RFC. For = example, from an editorial standpoint there is a missing "The" in= the first line of the section, and there are other improvements as well. I= also see editorial corrections in Section 3 of the RFC when compared to Se= ction 5 in the draft.

I would recommend an editorial pass where the text is compared with the RFC= , and when obvious, editorially improved to take advantage of work already = done. This will make the RFC Editor's job easier. Alternatively, the AD= could choose to include a note to the RFC Editor, noting the similarity an= d asking the RFC Editor to take advantage of the work that they already did= for the RFC. However, having this done by the document editor would take a= dvantage of the editor's knowledge of when differences between the two = are deliberate.

Thanks,
Andy



--001a113f13c21e4c930531dc7953-- From nobody Mon May 2 20:37:28 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6023212B018; Mon, 2 May 2016 20:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 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.996, 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 WlX8ulV4ieHo; Mon, 2 May 2016 20:37:21 -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 7AF1B12D13A; Mon, 2 May 2016 20:37:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CNU27584; Tue, 03 May 2016 03:37:18 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 3 May 2016 04:37:18 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Tue, 3 May 2016 11:37:10 +0800 From: Mingui Zhang To: Julien Meuric Thread-Topic: RtgDir review: draft-ietf-trill-mtu-negotiation-02 Thread-Index: AQHRoMQerp4NGV2VcEqtxnPN1zxy5p+fCHCAgAW+q4CAAdE0AA== Date: Tue, 3 May 2016 03:37:09 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E787C865EB@NKGEML515-MBX.china.huawei.com> References: <57212222.5080904@orange.com> <4552F0907735844E9204A62BBDD325E787C858FD@NKGEML515-MBX.china.huawei.com> <572706E7.7050005@orange.com> In-Reply-To: <572706E7.7050005@orange.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.146.93] 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.57281CEF.0006, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c158f6fcc470b03a621f6ad0d3ea5596 Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-trill-mtu-negotiation.all@ietf.org" , "trill@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-trill-mtu-negotiation-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 03:37:24 -0000 SGkgSnVsaWVuLA0KDQpUaGUgdXBkYXRlZCB2ZXJzaW9uIGhhcyBqdXN0IGJlZW4gdXBsb2FkZWQu DQoNClRoYW5rcywNCk1pbmd1aQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IEp1bGllbiBNZXVyaWMgW21haWx0bzpqdWxpZW4ubWV1cmljQG9yYW5nZS5jb21dDQo+IFNl bnQ6IE1vbmRheSwgTWF5IDAyLCAyMDE2IDM6NTEgUE0NCj4gVG86IE1pbmd1aSBaaGFuZw0KPiBD YzogZHJhZnQtaWV0Zi10cmlsbC1tdHUtbmVnb3RpYXRpb24uYWxsQGlldGYub3JnOyBydGctYWRz QGlldGYub3JnOyBydGctZGlyQGlldGYub3JnOw0KPiB0cmlsbEBpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi10cmlsbC1tdHUtbmVnb3RpYXRpb24tMDIN Cj4gDQo+IEhpIE1pbmd1aSwNCj4gDQo+IEFib3V0IHRoZSAidXBkYXRlZCBSRkNzIiBpc3N1ZSBi ZWxvdywgbXkgcG9pbnQgaXM6ICJwbGVhc2UgbWFrZSBzdXJlIHRoZSB0ZXh0DQo+IGFuZCB0aGUg aGVhcmRlciBhcmUgY29tcGxldGUiLiBJIGp1c3QgaGFkIGEgcXVpY2sgbG9vayBhdCB0aG9zZSBy ZWZlcmVuY2VzLCB5b3UNCj4ga25vdyBiZXR0ZXIgdGhhbiBtZSB3aGljaCBhcmUgYWN0dWFsbHkg cmVsZXZhbnQuDQo+IA0KPiBJIGFtIGxvb2tpbmcgZm9yd2FyZCB0byB0aGUgdXBkYXRlZCB2ZXJz aW9uLg0KPiANCj4gVGhhbmtzLA0KPiANCj4gSnVsaWVuDQo+IA0KPiANCj4gQXByLiAyOSwgMjAx NiAtIHpoYW5nbWluZ3VpQGh1YXdlaS5jb206DQo+ID4gSGkgSnVsaWVuLA0KPiA+DQo+ID4gVGhh bmtzIGZvciB0aGUgY29tbWVudHMhIE11Y2ggYXBwcmVjaWF0ZWQhDQo+ID4NCj4gPiBQbGVhc2Ug c2VlIGluLWxpbmVzIGJlbG93LiBBbiB1cGRhdGVkIHZlcnNpb24gd2lsbCBzb29uIGJlIHVwbG9h ZGVkIHRvIHJlc29sdmUNCj4gdGhlIGNvbW1lbnRzLg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IE1p bmd1aQ0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IEp1 bGllbiBNZXVyaWMgW21haWx0bzpqdWxpZW4ubWV1cmljQG9yYW5nZS5jb21dDQo+ID4+IFNlbnQ6 IFRodXJzZGF5LCBBcHJpbCAyOCwgMjAxNiA0OjM0IEFNDQo+ID4+DQo+ID4+IEhlbGxvLA0KPiA+ Pg0KPiA+PiBJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSBy ZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4NCj4gPj4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vl a3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yDQo+ID4+IHJvdXRpbmctcmVsYXRlZCBkcmFmdHMg YXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cNCj4gPj4gcmV2aWV3 LCBhbmQgc29tZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVzdC4gVGhlIHB1cnBvc2Ugb2YgdGhlIHJl dmlldyBpcyB0bw0KPiBwcm92aWRlIGFzc2lzdGFuY2UgdG8gdGhlIFJvdXRpbmcgQURzLg0KPiA+ PiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxl YXNlIHNlZQ0KPiA+PiBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dp a2kvUnRnRGlyDQo+ID4+DQo+ID4+IEFsdGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJp bHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURzLA0KPiA+PiBpdCB3b3VsZCBiZSBoZWxw ZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90aGVyDQo+ID4+ IElFVEYgTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8g cmVzb2x2ZSB0aGVtDQo+ID4+IHRocm91Z2ggZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUg ZHJhZnQuDQo+ID4+DQo+ID4+IERvY3VtZW50OiBkcmFmdC1pZXRmLXRyaWxsLW10dS1uZWdvdGlh dGlvbi0wMi50eHQNCj4gPj4gUmV2aWV3ZXI6IEp1bGllbiBNZXVyaWMNCj4gPj4gUmV2aWV3IERh dGU6IEFwcmlsIDI3LCAyMDE2DQo+ID4+IElFVEYgTEMgRW5kIERhdGU6IEFwcmlsIDUsIDIwMTYN Cj4gPj4NCj4gPj4gSW50ZW5kZWQgU3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sNCj4gPj4NCj4gPj4N Cj4gPj4gKlN1bW1hcnk6Kg0KPiA+PiBJIGhhdmUgc29tZSBtaW5vciBjb25jZXJucyBhYm91dCB0 aGlzIGRvY3VtZW50IHRoYXQgSSB0aGluayBzaG91bGQgYmUNCj4gPj4gcmVzb2x2ZWQgYmVmb3Jl IHB1YmxpY2F0aW9uLg0KPiA+Pg0KPiA+PiAqQ29tbWVudHM6Kg0KPiA+PiBFdmVuIHRob3VnaCBp dCByZXF1aXJlcyB0byBicm93c2Ugc29tZSBvdGhlciBUUklMTCAobm9ybWF0aXZlKQ0KPiA+PiBk b2N1bWVudHMsIHRoZSBtZWNoYW5pc20gaXRzZWxmIGlzIHNpbXBsZSBhbmQgd2VsbCBkZXNjcmli ZWQuDQo+ID4+IE5ldmVydGhlbGVzcywgdGhlIHNwZWNpZmljYXRpb24gZGVzZXJ2ZXMgc29tZSBp bXByb3ZlbWVudCB3aGVuIGl0DQo+ID4+IGNvbWVzIHRvIG9ibGlnYXRpb25zIGFuZCBvcHRpb25z OiB0aGlzIHdhcyBwYXJ0IG9mIG15IGV4cGVjdGF0aW9uDQo+ID4+IGFmdGVyIEkgcmVhbGl6ZWQg aXQgd2FzIHVwZ3JhZGluZyBhIHNob3J0IHNlY3Rpb24gb2YgdGhlIGJhc2UNCj4gPj4gZG9jdW1l bnQgKFJGQyA2MzI1KSwgd2hpY2ggbmVlZHMgdG8gYmUgZW1waGFzaXplZCBhcyB3ZWxsLg0KPiA+ DQo+ID4gSW4gdGhlIGFic3RyYWN0LCBpdCdzIGFscmVhZHkgbWVudGlvbmVkIGFzICJvcHRpb25h bCB1cGRhdGVzIiB0byBSRkMgNjMyNS4gSSB0aGluaw0KPiAiVXBkYXRlczogNjMyNSAiIG5lZWRz IHRvIGFwcGVhciBpbiB0aGUgcGFnZSBoZWFkZXIgYXMgd2VsbC4NCj4gPg0KPiA+Pg0KPiA+PiAq TWlub3IgSXNzdWVzOioNCj4gPj4gLSBUaGUgZG9jdW1lbnQgaXMgU1QgYW5kIHJlZmVyZW5jZXMg UkZDIDIxMTkuIFRoZXJlIGEgc29tZSAiTVVTVCIgYW5kDQo+ID4+IG9uZSAiU0hPVUxEIiwgbWFu eSBvZiB0aGVtIGluaGVyaXRlZCBmcm9tIHNwZWNpZmljYXRpb25zIG91dCBvZiB0aGUNCj4gPj4g cmVmZXJlbmNlZCBkb2N1bWVudHMuIE9uIHRoZSBvdGhlciBzaWRlLCAibXVzdCIgYW5kICJzaG91 bGQiIGFyZQ0KPiA+PiBjb21tb25seSB1c2VkLiBUaGlzIE1VU1QgYmUgYnJvdWdodCB1cCB0byBT VCBleHBlY3RhdGlvbnMuDQo+ID4NCj4gPiBUaGUgdXNhZ2Ugb2YgIm11c3QiIGFuZCAic2hvdWxk IiB3aWxsIGJlIHVwZGF0ZWQgYXMgbmVlZGVkLiBJIGhhdmUgY2hlY2tlZCBhbGwNCj4gdGhvc2Ug YXBwZWFyYW5jZXMuIFRoZSBjaGFuZ2VzIHdvdWxkIGJlIGVkaXRvcmlhbC4NCj4gPg0KPiA+PiAt IFRoZSBkb2N1bWVudCBjbGFpbXMgdG8gb25seSB1cGRhdGUgUkZDIDcxNzcuIEl0IHNlZW1zIGhv d2V2ZXIgdGhhdA0KPiA+PiBpdCBhbHNvIHVwZGF0ZXMgUkZDIDYzMjUgKHNlY3Rpb24gNC4zLjIp LCBSRkMgNzE3NiBhbmQgbWF5YmUgZXZlbiBSRkMgNzc4MC4NCj4gPg0KPiA+IEFjdHVhbGx5LCBJ IGRvbid0IHRoaW5rIHRoaXMgZG9jdW1lbnQgdXBkYXRlcyBSRkM3MTc2LiBJdCBzaW1wbHkgbWFr ZXMgdXNlIG9mDQo+IHRoZSBNVFUgU3ViLVRMViBkZWZpbmVkIGluIFJGQyA3MTc2Lg0KPiA+IFRo ZSBzcGVjaWZpY2F0aW9uIGFib3V0IHRoZSBvcmlnaW5hdGluZ0wxTFNQQnVmZmVyU2l6ZSBvZiBh biB1bnJlYWNoYWJsZQ0KPiBSQnJpZGdlIGlzIGEgc2xpZ2h0IHVwZGF0ZSB0byBSRkM3NzgwLiBU aGlzIHdpbGwgYmUgZW1waGFzaXplZC4NCj4gPg0KPiA+PiBUaGF0IHNob3VsZCBiZSBlaXRoZXIg YWNrbm93bGVkZ2VkIG9yIGNsYXJpZmllZC4gVGhlIDR0aCBwYXJhZ3JhcGggb2YNCj4gPj4gdGhl IGludHJvZHVjdGlvbiB0cmllcyB0byB0YWNrbGUgdGhhdCB0b3BpYywgYnV0IGl0IGlzIG5vdCBj bGVhcg0KPiA+PiBlbm91Z2ggaW4gZGVmaW5pbmcgdGhlIHBvc2l0aW9uIG9mIHRoZSBkb2N1bWVu dCB3aXRoIHJlc3BlY3QgdG8gcHJldmlvdXNseQ0KPiBkZWZpbmVkIG1lY2hhbmlzbXMuDQo+ID4N Cj4gPiBUaGUgdXBkYXRlZCB0byBSRkMgNjMyNSB3aWxsIGJlIGVtcGhhc2l6ZWQgaW4gdGhpcyBw YXJhZ3JhcGguIFRoZSBiYWNrd2FyZA0KPiBjb21wYXRpYmlsaXR5IHdpbGwgYmUgbW92ZWQgdG8g aGVyZSBhcyB3ZWxsLiBJdCB3aWxsIGhlbHAgdGhlIHBvc2l0aW9uaW5nLg0KPiA+DQo+ID4+IC0g VGhlIDNyZCBwYXJhZ3JhcGggb2YgdGhlIGludHJvZHVjdGlvbiBkdXBsaWNhdGVzIHRoZSBiZWdp bm5pbmcgb2YNCj4gPj4gdGhlIGZvbGxvd2luZyBzZWN0aW9uIDIuIEEgcG9zc2libGUgd2F5IHRv IGxpbWl0IHRoaXMgcmVwZXRpdGlvbg0KPiA+PiBlZmZlY3QgbWF5IGJlIHRvIHN1bW1hcml6ZSB0 aGF0IHBhcnQgb2YgdGhlIGludHJvZHVjdGlvbi4NCj4gPg0KPiA+IFllcywgc3VtbWFyaXphdGlv biBpcyB0aGUgcHJvcGVyIHdheS4NCj4gPg0KPiA+PiAtIFNlY3Rpb24gMyBzcGVjaWZpZXMgYW4g YWxnb3JpdGhtLiBFdmVuIGlmIGl0IGRvZXMgbm90IHJlbHkgb24gYQ0KPiA+PiBmb3JtYWwgbGFu Z3VhZ2UsIGNvbnNpc3RlbmN5IHdvdWxkIGJlIHZhbHVhYmxlLiBNeSBtaW5kIGNvbXBpbGVyIHdv dWxkDQo+IHN1Z2dlc3Q6DQo+ID4+ICAgICAgICogIklmIiBpcyBmb2xsb3dlZCBieSAidGhlbiIg b25seSBvbmNlOiAidGhlbiIga2V5d29yZCB0byBiZSBkcm9wcGVkPw0KPiA+PiAgICAgICAqIFRo ZSBhbGdvcml0aG0gcmVsaWVzIG9uIGEgYnJlYWsvc3RvcCBvciBjb250aW51ZSBwcmluY2lwbGU7 DQo+ID4+IGFzIHN1Y2gsIHRoZSBpbnN0YW5jZSBvZiAiRWxzZSIgYXQgdGhlIGVuZCBzaG91bGQg YmUgcmVwbGFjZWQgYnkNCj4gPj4gIjxsaW5lDQo+ID4+IGJyZWFrPiA0KSBSZXBlYXQgU3RlcDEi Ow0KPiA+PiAgICAgICAqICJpcyBzZXQgdG8iIGFuZCAiPC0tIiBzZWVtIHRvIGJlIHNpbWlsYXI6 IHBsZWFzZSBwaWNrIG9uZSBvciBjbGFyaWZ5Ow0KPiA+PiAgICAgICAqIHRvIGltcHJvdmUgcmVh ZGFiaWxpdHksIEkgd291bGQgZHJvcCB0aGUgZG91YmxlIG5hbWluZw0KPiA+PiBpbnRyb2R1Y2Vk IHdpdGggWCwNCj4gPj4gWDEgYW5kIFgyIGFuZCByZWx5IG9uIGV4cGxpY2l0IHZhcmlhYmxlIG5h bWVzIGFsbCBhbG9uZywgYXMgaW4gdGhlDQo+ID4+IHRleHQ6IGUuZy4sICJsaW5rTXR1U2l6ZSIg aW5zdGVhZCBvZiBYLCAibG93ZXJCb3VuZCIgZm9yIFgxIGFuZCAidXBwZXJCb3VuZCINCj4gaW5z dGVhZCBvZiBYMi4NCj4gPg0KPiA+IFN1cmUuIEV4cGxpY2l0IG5hbWVzIHdpbGwgYmUgdXNlZCBm b3IgdGhlIHNha2Ugb2YgcmVhZGFiaWxpdHkuDQo+ID4NCj4gPj4NCj4gPj4gKk5pdHM6Kg0KPiA+ DQo+ID4gVGhlIGZvbGxvd2luZyBuaXRzIHdpbGwgYmUgZml4ZWQgYXMgc3VnZ2VzdGVkLg0KPiA+ DQo+ID4+IC0tLS0tLQ0KPiA+PiAiVXBkYXRlcyIgZmllbGQgaW4gaGVhZGVyDQo+ID4+IC0tLQ0K PiA+PiAtIEkgdGhpbmsgdGhlICJSRkMiIGFjcm9ueW0gc2hvdWxkIGFwcGVhci4NCj4gPj4gLSBU aGUgbGlzdCBtYXkgYmUgZXh0ZW5kZWQgd2l0aCBSRkMgUkZDIDYzMjUsIFJGQyA3MTc2IGFuZCBt YXliZSBldmVuDQo+ID4+IFJGQyA3NzgwLg0KPiA+PiAtLS0tLS0NCj4gPj4gQWJzdHJhY3QNCj4g Pj4gLS0tDQo+ID4+IC0gcy9jYW1wdXMgd2lkZSBNVFUgZmVhdHVyZS9jYW1wdXMtd2lkZSBNVFUg ZmVhdHVyZS8NCj4gPj4gLSBzL2NhbXB1cyB3aWRlIGNhcGFiaWxpdHkvY2FtcHVzLXdpZGUgY2Fw YWJpbGl0eS8NCj4gPj4gLSBzL2xpbmsgbG9jYWwgcGFja2V0cy9saW5rLWxvY2FsIHBhY2tldHMv DQo+ID4+IC0gcy9saW5rIGxvY2FsIE1UVXMvbGluay1sb2NhbCBNVFVzLw0KPiA+PiAtICJJdCB1 cGRhdGVzIFJGQy4uLiIgZHVwbGljYXRlcyBoZWFkZXI6IGVpdGhlciB0byBkcm9wIG9yIG1ha2Ug bW9yZQ0KPiA+PiBzcGVjaWZpYyB0byBwb2ludCB0byBwcmVjaXNlIHNlY3Rpb25zL21lY2hhbmlz bXMuDQo+ID4+IC0tLS0tLQ0KPiA+PiBTZWN0aW9uIDEuDQo+ID4+IC0tLQ0KPiA+PiAtIHMvbGlu ayBzY29wZSBQRFVzIGNhbi9saW5rLXNjb3BlZCBQRFVzIGNhbi8NCj4gPj4gLS0tLS0tDQo+ID4+ IFNlY3Rpb24gMi4NCj4gPj4gLS0tDQo+ID4+IC0gcy9jYW1wdXMgd2lkZSBTeiBNVFUvY2FtcHVz LXdpZGUgU3ogTVRVLw0KPiA+PiAtIHMvYXJlYSB3aWRlIHNjb3BlL2FyZWEtd2lkZSBzY29wZS8N Cj4gPj4gLSBzL2RvbWFpbiB3aWRlIHNjb3BlL2RvbWFpbiB3aWRlIHNjb3BlLw0KPiA+PiAtIHMv TDEgQ2lyY3VpdCBTY29wZWQvTDEgQ2lyY3VpdC1TY29wZWQvDQo+ID4+IC0gImxpbWl0ZWQgdG8g MTQ3MCB0byA2NSw1MzUgYnl0ZXMiOiBJIGNhbm5vdCBwYXJzZSBpdCwgaXMgaXQgbWVhbnQgdG8g YmUgYSByYW5nZT8NCj4gPj4gLS0tLS0tDQo+ID4+IFNlY3Rpb24gNC4NCj4gPj4gLSBPTEQNCj4g Pj4gIndoaWxlIFJCMSBub3JtYWxseSBpZ25vcmVzIGxpbmsgc3RhdGUgaW5mb3JtYXRpb24gZm9y IGFueSBJUy1JUw0KPiA+PiB1bnJlYWNoYWJsZSBSQnJpZGdlIFJCMiwgb3JpZ2luYXRpbmdMMUxT UEJ1ZmZlclNpemUgaXMgYW4gZXhjZXB0aW9uLiINCj4gPj4gICAgIE5FVw0KPiA+PiAid2hpbGUg aW4gbW9zdCBjYXNlcyBSQjEgaWdub3JlcyBsaW5rIHN0YXRlIGluZm9ybWF0aW9uIGZvciBJUy1J Uw0KPiA+PiB1bnJlYWNoYWJsZSBSQnJpZGdlIFJCMiwgb3JpZ2luYXRpbmdMMUxTUEJ1ZmZlclNp emUgaXMgbWVhbmluZ2Z1bC4iDQo+ID4+IFtjdXJyZW50IHdvcmRpbmcgc3VnZ2VzdHMgaXQgaXMg YWRkaW5nIGFuIGV4Y2VwdGlvbiB0byBhIG1hbmRhdG9yeQ0KPiA+PiBiZWhhdmlvciwgd2hpY2gg QUZBSVUgaXQgZG9lcyBub3RdDQo+ID4NCj4gPiBPSy4gV2lsbCB1cGRhdGUgdGhlIHdvcmRzLg0K PiA+DQo+ID4+IC0tLS0tLQ0KPiA+PiBTZWN0aW9uIDcuDQo+ID4+IC0tLQ0KPiA+PiAtICJ0ZXN0 ZWQgc2l6ZSBjYW4gYmUgYWR2ZXJ0aXNlZCI6ICJjYW4iIGlzIHRvIGJlIGFkZHJlc3NlZCBhcyBw YXJ0DQo+ID4+IG9mIHRoZSBsb29zZSBSRkMgMjExOSB3b3JkaW5nIGNvbW1lbnQuDQo+ID4NCj4g PiBXaWxsIHVzZSB0aGUgd29yZCAiTUFZIiBpbnN0ZWFkLg0KPiA+DQo+ID4+IC0tLS0tLQ0KPiA+ PiBTZWN0aW9uIDguDQo+ID4+IC0tLQ0KPiA+PiAtICJ2YWx1ZSBbLi4uXSBoYWQgYmVlbiByZXBv cnRlZCI6ICJyZXBvcnRlZCIgcHV6emxlcyBtZSwgbWF5YmUgInRlc3RlZCINCj4gPj4gd2FzIG1l YW50Pw0KPiA+PiAtIFRoZSAzcmQgcGFyYWdyYXBoICJGb3IgYW4gTHotaWdub3JhbnQgWy4uLl0g bGluay13aWRlIEx6LiIgc2hvdWxkDQo+ID4+IGJlIG1vdmVkIHVwIHRvIGJlY29tZSB0aGUgc2Vj b25kIHBhcmFncmFwaCwgc28gYXMgdG8gY2xhcmlmeSB3aGF0IGFuDQo+IEx6LWlnbm9yYW50IGlz Lg0KPiA+DQo+ID4gT0suIEl0IHdpbGwgYmUgbW92ZWQgdXAuDQo+ID4NCj4gPj4gLSAiVGhlIGV4 dGVuc2lvbiBvZiBUUklMTCBNVFUgbmVnb2NpYXRpb24uLi4iOiB0aGlzIGlzIGFuIGV4cGxpY2l0 DQo+ID4+IHBvc2l0aW9uaW5nIHdoaWNoIHNob3VsZCBiZSBtZW50aW9uZWQgZWFybGllciBpbiB0 aGUgSS1ELg0KPiA+DQo+ID4NCj4gPiBPSy4gVGhpcyB3aWxsIGJlIG1vdmVkIHRvIHRoZSBpbnRy b2R1Y3Rpb24uDQo+ID4NCj4gPj4gLS0tLS0tDQo+ID4+IFNlY3Rpb24gMTAuDQo+ID4+IC0tLQ0K PiA+PiAtIFJGQyA3MTgwIGJpcyBpcyBub3cgUkZDIDc3ODAuDQo+ID4NCj4gPiBZZXMsIHRoaXMg d2lsbCBiZSB1cGRhdGVkLg0KPiA+DQo+ID4+IC0tLQ0KPiA+Pg0KPiA+PiBSZWdhcmRzLA0KPiA+ Pg0KPiA+PiBKdWxpZW4NCj4gPg0K From nobody Tue May 3 11:06:34 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B72D12D77D; Tue, 3 May 2016 11:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 QuHRh7ec2xcS; Tue, 3 May 2016 11:06:29 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C4912D11E; Tue, 3 May 2016 11:06:25 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u43I6Klt004640; Tue, 3 May 2016 19:06:20 +0100 Received: from 950129200 (jplon-nat11.juniper.net [193.110.55.11]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u43I6HTf004625 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 3 May 2016 19:06:18 +0100 From: "Adrian Farrel" To: "'Carlos Pignataro \(cpignata\)'" References: <069b01d1a086$46d4d470$d47e7d50$@olddog.co.uk> <094e01d1a14d$dee2e320$9ca8a960$@olddog.co.uk> <40BAEA74-73C5-4CA9-B581-FD0864DCDFF8@cisco.com> In-Reply-To: <40BAEA74-73C5-4CA9-B581-FD0864DCDFF8@cisco.com> Date: Tue, 3 May 2016 19:06:16 +0100 Message-ID: <051101d1a566$7d582170$78086450$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0512_01D1A56E.DF211D50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFw1kCCaiIwUNLtEKxshcWR2bdBZAEdXWDpAeZ8YfwCW7Rb+gM0ffgPoCR9zKA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22300.001 X-TM-AS-Result: No--27.919-10.0-31-10 X-imss-scan-details: No--27.919-10.0-31-10 X-TMASE-MatchedRID: pS5owHKhBO3FJ6ywrp0gou5xcghYf69z1kqyrcMalqVElaZ44wdr5OB8 OdeiJ2JqQ66AfpgtCSFb/YntQAmqPCh5A3bWOsipliwpJdZauweLKfr4l0eFzzCmUYns3FLTcs4 A80KaakCs1nrDbiMM4nLHqPoioImUjh97YmbtUFLhG1IOMb7PsDFFLhGUD8AWlxrbJNbm/wSmyQ VG1kMNf1YmKyHeh965kjcEZRdXvqZB1m5nja+ukRcqpH7D1rtQXru95hSuhjSUvX/ci5TjsgQyX K9eC6mUsHABAwbw/VrO/WH+Jlz/QMcxC9l7kaqpi1u/Wt2ORDrvJY9pBzgg1P/0n/rX0NETdni0 h/RUcQR1kXKt8agVAqEjdrAqXFao0H/zLeBgX2/UWdZik3yrYeiY+s2L3xQEFFn/3AEyEaz0t3k tSH728veBD01Dl6u2LSi5+Ear6Yj8BymGA9MWAoQnnAFRgjn9BdebOqawiLvMbKh5QsVRoN7EHA uRAfwU+pOmmUIxFU48QSrJjunoMZELwEFeVXChiVYleIBIrY/6e9LB8NtoJadrpTvh7T6oaUehc Y2jtkUZCegJ5M3wUKqNEi0TOKDzOXJUfyM1K02cgbKevk5shqTYf9v9flolslgQm+u5vajKooqv Q0Sk9I/1zKj4Efpl0ZQB2zwuLEbWcuaikvd2WoCOjMAO81E5CQ3xS+zL6e0g1QuRyB58YfyL40X ovS1aNtrqBJtuOX5BVgr5vOsPONLF6Y0L7R/QcFEiuPxHjsW0X0Yw27VuouQ45nVtPqmxrsFU8U w5BC6ytmB2/5InT/zxIC9LasqudG57tpB6osSeAiCmPx4NwGmRqNBHmBve1kTfEkyaZdxFGCd0S 0NCsgxrwr9aUfM2GwbyzEn0NCHzt0LjaI+ob6YL3Fz0tpLPPpCuffGH9zI= Archived-At: Cc: rtg-dir@ietf.org, 'Manav Bhatia' , rtg-ads@ietf.org, 'OSPF WG List' , draft-ietf-ospf-sbfd-discriminator.all@ietf.org, "'Acee Lindem \(acee\)'" Subject: Re: [RTG-DIR] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 18:06:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0512_01D1A56E.DF211D50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Carlos, =20 Alia asked me to confirm whether your proposed change would have caused = me to not have made this comment on review. =20 It would certainly have helped. But... =20 "quite static" is not very clear as a relative term. =20 I think the concern might be that the network is large and there are = many BFD sessions.=20 Unless have I have misunderstood, it is not just a change in = discriminator, but also a change to whether reflection is wanted or not. =20 Anyway, this is not a trap, just an encouragement to make a statement = that helps readers to know that they don't need to worry. The parameters = are: - what causes an LSA to be flooded? - how does that compare to the number of LSAs normally flooded? - the security thing about using this as a way to cause excess flooding - how much extra state info does an OSPF implementation have to hold for these LSA in the LSA DB? =20 Cheers, Adrian =20 From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]=20 Sent: 28 April 2016 17:15 To: Adrian Farrel Cc: Acee Lindem (acee); Manav Bhatia; ; = ; draft-ietf-ospf-sbfd-discriminator.all@ietf.org; = OSPF WG List Subject: Re: Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt =20 Adrian, =20 I would not oppose to making a clarification similar to the following, = if the WG things its useful: =20 The S-BFD Discriminators are expected to be quite static. S-BFD = Discriminators may change when enabling the S-BFD functionality or via = an explicit configuration event. These will result in a change in the = information advertised in the S-BFD Discriminator TLV in OSPF, but are = not expected to happen with any regularity. =20 [I expect that text needs (a lot of) wordsmithing, and might not be = useful or desired at all, but just to make the discussion more real] =20 Thanks, =20 =E2=80=94 Carlos. =20 On Apr 28, 2016, at 8:59 AM, Adrian Farrel wrote: =20 Acee has it right. =20 While (of course) stuff can be done in implementations to mitigate the = effects, the protocol extensions here increase the size of LSA and = increase the amount of flooding. Since the LSAs have to be stored (in = some form), it is reasonable to describe the amount of extra information = that reflects across a network - maybe express it as "LSA data" and = leave it up to an implementation to choose how to store it. Since the = number of LSA updates impacts the routing plane processing and bits on = the wire, it is reasonable to ask what impact that might have. =20 I am interested to hear whether turning Reflectors on and off could be a = feature that could cause LSAs to flap and so create flooding ripples in = the network. =20 Adrian =20 From: Acee Lindem (acee) [mailto:acee@cisco.com]=20 Sent: 28 April 2016 10:21 To: Manav Bhatia; Adrian Farrel Cc: ; rtg-dir@ietf.org; = draft-ietf-ospf-sbfd-discriminator.all@ietf.org; OSPF WG List Subject: Re: Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt =20 Hi Manav, =20 From: Manav Bhatia < = manav@ionosnetworks.com> Date: Thursday, April 28, 2016 at 1:31 AM To: Adrian Farrel < adrian@olddog.co.uk> Cc: "< rtg-ads@ietf.org>" < = rtg-ads@ietf.org>, Routing Directorate < = rtg-dir@ietf.org>, " = = draft-ietf-ospf-sbfd-discriminator.all@ietf.org" < = = draft-ietf-ospf-sbfd-discriminator.all@ietf.org>, OSPF WG List < = ospf@ietf.org> Subject: Re: Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt =20 Hi Adrian, =20 Thanks for the extensive review. I have a minor comment on a minor issue = that you raised. =20 Minor Issues: I should like to see some small amount of text on the scaling impact on OSPF. 1. How much additional information will implementations have to store per node/link in the network? 2. What is the expected churn in LSAs introduced by this mechanism (especially when the Reflector is turned on and off)? =20 Isnt this implementation specific? This is what will differentiate one = vendor implementation from the other.=20 =20 I am not sure how we can quantify this -- any ideas? =20 This is akin to saying that IS-IS, in contrast to OSPFv2, is more = attuned for partial SPF runs because the node information is cleanly = separated from the reachability information. However, this isnt entirely = true. While i concede that node information is mixed with prefix = information in OSPFv2, there still are ways in which clever = implementations could separate the two and do exactly what IS-IS does.=20 =20 I took this rather circuitous approach to drive home the point that = scalability, churn, overheads on the system are in many cases dependent = on the protocol implementation and by that token outside the scope of = the IETF drafts. =20 I believe what is being requested is a discussion of how often the S-BFD = TLV is likely to change, the effects on flooding, and, if required, = recommendations for any rate-limiting or other measures to prevent = churn.=20 =20 Thanks, Acee =20 =20 =20 =20 You *do* have... A change in information in the S-BFD Discriminator TLV MUST NOT trigger any SPF computation at a receiving router. ...which is a help. =20 I would be alarmed if an implementation in an absence of this pedantic = note triggered SPF runs each time an S-BFD disc changed ! I mean if you = understand the idea being discussed then you also understand that a = change in this TLV has no bearing on the reachability anywhere. And that = knowledge should be enough to prevent SPF runs in most cases !=20 =20 I know that we have added this note but if we need to explicitly spell = such things out in all standards then we clearly have bigger problems ! = :-) =20 Cheers, Manav =20 ------=_NextPart_000_0512_01D1A56E.DF211D50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Carlos,

 

Alia asked me to confirm = whether your proposed change would have caused me to not have made this = comment on review.

 

It would certainly have = helped. But...

 

"quite static" is = not very clear as a relative term.

 

I think the concern might be = that the network is large and there are many BFD sessions. =

Unless have I have = misunderstood, it is not just a change in discriminator, but also a = change to whether reflection is wanted or not.

 

Anyway, this is not a trap, = just an encouragement to make a statement that helps readers to know = that they don't need to worry. The parameters = are:

- what causes an LSA to be = flooded?

- how does that compare to the = number of LSAs normally flooded?

- the security thing about = using this as a way to cause excess flooding

- how much extra state info = does an OSPF implementation have to hold

=C2=A0=C2=A0 for these LSA in the LSA = DB?

 

Cheers,

Adrian

 

From: Carlos Pignataro = (cpignata) [mailto:cpignata@cisco.com]
Sent: 28 April 2016 = 17:15
To: Adrian Farrel
Cc: Acee Lindem (acee); = Manav Bhatia; <rtg-ads@ietf.org>; <rtg-dir@ietf.org>; = draft-ietf-ospf-sbfd-discriminator.all@ietf.org; OSPF WG = List
Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt

 

Adrian,

 

I would not oppose to making a clarification similar to the = following, if the WG things its = useful:

 

The S-BFD Discriminators are expected to be quite static. S-BFD = Discriminators may change when enabling the S-BFD functionality or via = an explicit configuration event. These will result in a change in the = information advertised in the S-BFD Discriminator TLV in OSPF, but are = not expected to happen with any = regularity.

 

[I expect that text needs (a lot of) wordsmithing, and might not = be useful or desired at all, but just to make the discussion more = real]

 

Thanks,

 

=E2=80=94 Carlos.

 

On Apr 28, 2016, at 8:59 AM, Adrian Farrel <adrian@olddog.co.uk> = wrote:

 

Acee has it = right.

 

While (of course) stuff can = be done in implementations to mitigate the effects, the protocol = extensions here increase the size of LSA and increase the amount of = flooding. Since the LSAs have to be stored (in some form), it is = reasonable to describe the amount of extra information that reflects = across a network - maybe express it as "LSA data" and leave it = up to an implementation to choose how to store it. Since the number of = LSA updates impacts the routing plane processing and bits on the wire, = it is reasonable to ask what impact that might have.

 

I am interested to hear = whether turning Reflectors on and off could be a feature that could = cause LSAs to flap and so create flooding ripples in the = network.

 

Adrian

 

From: Acee Lindem (acee) = [mailto:acee@cisco.com] 
Sent: 28 April 2016 = 10:21
To: Manav Bhatia; Adrian = Farrel
Cc: <rtg-ads@ietf.org>; rtg-dir@ietf.org; draft-iet= f-ospf-sbfd-discriminator.all@ietf.org; OSPF WG = List
Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt

 

Hi Manav,

 

From: Manav Bhatia <manav@ionosnetworks.com>
Date:=  Thursday, April 28, = 2016 at 1:31 AM
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, Routing = Directorate <rtg-dir@ietf.org>, "draft-ietf-ospf-sbfd-discriminator.all@ietf.org" <draft-ietf-ospf-sbfd-discriminator.all@ietf.org>, OSPF WG List <ospf@ietf.org>
Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt

 

Hi Adrian,

 

Thanks for the extensive review. I have a = minor comment on a minor issue that you raised.

 


Minor Issues:

I should like to = see some small amount of text on the scaling impact on
OSPF. 1. How = much additional information will implementations have to
store per = node/link in the network? 2. What is the expected churn in
LSAs = introduced by this mechanism (especially when the Reflector is
turned = on and off)?

 

Isnt this implementation specific? This = is what will differentiate one vendor implementation from the = other. 

 

I am not sure how we can quantify this -- = any ideas?

 

This is akin to saying that IS-IS, in = contrast to OSPFv2, is more attuned for partial SPF runs because the = node information is cleanly separated from the reachability information. = However, this isnt entirely true. While i concede that node information = is mixed with prefix information in OSPFv2, there still are ways in = which clever implementations could separate the two and do exactly what = IS-IS does. 

 

I took this rather circuitous approach to = drive home the point that scalability, churn, overheads on the system = are in many cases dependent on the protocol implementation and by that = token outside the scope of the IETF drafts.

<= /blockquote>

 

I believe what is being requested is a = discussion of how often the S-BFD TLV is likely to change, the effects = on flooding, and, if required, recommendations for any rate-limiting or = other measures to prevent churn. 

 

Thanks,

Acee

 

 

 

<= div>

 


You *do* have...
   A = change in information in the S-BFD Discriminator TLV MUST NOT
  =  trigger any SPF computation at a receiving router.
...which is = a help.

 

I would be alarmed if an implementation = in an absence of this pedantic note triggered SPF runs each time an = S-BFD disc changed ! I mean if you understand the idea being discussed = then you also understand that a change in this TLV has no bearing on the = reachability anywhere. And that knowledge should be enough to prevent = SPF runs in most cases ! 

 

I know that we have added this note but = if we need to explicitly spell such things out in all standards then we = clearly have bigger problems ! :-)

 

Cheers, Manav

<= /blockquote>

 

------=_NextPart_000_0512_01D1A56E.DF211D50-- From nobody Tue May 3 12:49:54 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1F212D859; Tue, 3 May 2016 12:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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.996, 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 m7qQg2vETgbE; Tue, 3 May 2016 12:49:47 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABC9C12B03A; Tue, 3 May 2016 12:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45481; q=dns/txt; s=iport; t=1462304986; x=1463514586; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LHHGsp7G1XeosZ3jpxLFgXLuPZSvJ53b/NgyRphGXvw=; b=YSgh31XEdfqi2bPXQqGVpByBXi0rT5CsZ7CbOLX2YJbWDE2Q75VqoKA4 d9dDMAijmOaHmNJjg0lY+AiJWbVsDsdSRK/fMeHCQpifZSkUxswJjRmPJ Sd1JZsW6RtH57bQ/csPxmkBhsNY5/O9NcFc5RsKRDPX2ME8/V7waV3HjG Q=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DxAgDR/yhX/5hdJa1egmxMgVAGuhsOg?= =?us-ascii?q?XWGEAKBQTgUAQEBAQEBAWUnhEEBAQEDASNWBQsCAQgRAwEBAQEgAQYDAgIyFAk?= =?us-ascii?q?IAgQOBQ6IFAircJB5AQEBAQEBAQEBAQEBAQEBAQEBAQEBDQiGIIF2CIJPhF8Wg?= =?us-ascii?q?korgi4Fh3qLKoRyAYMngWeJCY8SjzEBHgFDg2tshz1/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,573,1454976000"; d="asc'?scan'208,217";a="268374322" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2016 19:49:45 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u43JniLu030869 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 May 2016 19:49:44 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 May 2016 15:49:43 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Tue, 3 May 2016 15:49:43 -0400 From: "Carlos Pignataro (cpignata)" To: Adrian Farrel Thread-Topic: Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt Thread-Index: AQHRoQ9JJPZzPVazJE6j7eBXSSMiMJ+fX3YAgAA9NICAADaFgIAH+rkAgAAc54A= Date: Tue, 3 May 2016 19:49:43 +0000 Message-ID: References: <069b01d1a086$46d4d470$d47e7d50$@olddog.co.uk> <094e01d1a14d$dee2e320$9ca8a960$@olddog.co.uk> <40BAEA74-73C5-4CA9-B581-FD0864DCDFF8@cisco.com> <051101d1a566$7d582170$78086450$@olddog.co.uk> In-Reply-To: <051101d1a566$7d582170$78086450$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.48.199] Content-Type: multipart/signed; boundary="Apple-Mail=_D83EA809-DB89-4AE3-88B0-63D14AD204CE"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "" , Manav Bhatia , "" , OSPF WG List , "draft-ietf-ospf-sbfd-discriminator.all@ietf.org" , "Acee Lindem \(acee\)" Subject: Re: [RTG-DIR] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 19:49:51 -0000 --Apple-Mail=_D83EA809-DB89-4AE3-88B0-63D14AD204CE Content-Type: multipart/alternative; boundary="Apple-Mail=_9B96C277-716E-4C8A-8E27-72DE3C300ED7" --Apple-Mail=_9B96C277-716E-4C8A-8E27-72DE3C300ED7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Adrian, Thanks for the follow-up. As I wrote to Alia, I am hesitant to quantify this further. These are = identifiers expected to be static (think of a loopback IP address or a = hostname as identifiers), on a feature that is not toggled on-and-off = constantly. I really think that the document is saying enough for = implementors to understand and take action (we are saying how often they = change, and saying that when they do they are advertised). Plus, regarding how much extra info additionally flooded or stored, as = Alia also acknowledged, this isn=E2=80=99t a high-volume TLV, and the = format is shown. I do like helpful advice in an RFC, but it seems to me that the current = text goes as far. Perhaps I am misunderstanding the intention or the concern. In that = case, if you have specific ideas in mind, it might help if you could = provide a text proposal to compare and contrast. Thanks, =E2=80=94 Carlos. > On May 3, 2016, at 2:06 PM, Adrian Farrel wrote: >=20 > Carlos, >=20 > Alia asked me to confirm whether your proposed change would have = caused me to not have made this comment on review. >=20 > It would certainly have helped. But... >=20 > "quite static" is not very clear as a relative term. >=20 > I think the concern might be that the network is large and there are = many BFD sessions. > Unless have I have misunderstood, it is not just a change in = discriminator, but also a change to whether reflection is wanted or not. >=20 > Anyway, this is not a trap, just an encouragement to make a statement = that helps readers to know that they don't need to worry. The parameters = are: > - what causes an LSA to be flooded? > - how does that compare to the number of LSAs normally flooded? > - the security thing about using this as a way to cause excess = flooding > - how much extra state info does an OSPF implementation have to hold > for these LSA in the LSA DB? >=20 > Cheers, > Adrian >=20 > From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] > Sent: 28 April 2016 17:15 > To: Adrian Farrel > Cc: Acee Lindem (acee); Manav Bhatia; ; = ; draft-ietf-ospf-sbfd-discriminator.all@ietf.org; = OSPF WG List > Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt >=20 > Adrian, >=20 > I would not oppose to making a clarification similar to the following, = if the WG things its useful: >=20 >> The S-BFD Discriminators are expected to be quite static. S-BFD = Discriminators may change when enabling the S-BFD functionality or via = an explicit configuration event. These will result in a change in the = information advertised in the S-BFD Discriminator TLV in OSPF, but are = not expected to happen with any regularity. >=20 > [I expect that text needs (a lot of) wordsmithing, and might not be = useful or desired at all, but just to make the discussion more real] >=20 > Thanks, >=20 > =E2=80=94 Carlos. >=20 >> On Apr 28, 2016, at 8:59 AM, Adrian Farrel > wrote: >>=20 >> Acee has it right. >>=20 >> While (of course) stuff can be done in implementations to mitigate = the effects, the protocol extensions here increase the size of LSA and = increase the amount of flooding. Since the LSAs have to be stored (in = some form), it is reasonable to describe the amount of extra information = that reflects across a network - maybe express it as "LSA data" and = leave it up to an implementation to choose how to store it. Since the = number of LSA updates impacts the routing plane processing and bits on = the wire, it is reasonable to ask what impact that might have. >>=20 >> I am interested to hear whether turning Reflectors on and off could = be a feature that could cause LSAs to flap and so create flooding = ripples in the network. >>=20 >> Adrian >>=20 >> From: Acee Lindem (acee) [mailto:acee@cisco.com = ] >> Sent: 28 April 2016 10:21 >> To: Manav Bhatia; Adrian Farrel >> Cc: >; rtg-dir@ietf.org = ; = draft-ietf-ospf-sbfd-discriminator.all@ietf.org = ; OSPF WG List >> Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt >>=20 >> Hi Manav, >>=20 >> From: Manav Bhatia > >> Date: Thursday, April 28, 2016 at 1:31 AM >> To: Adrian Farrel > >> Cc: ">" >, Routing Directorate >, = "draft-ietf-ospf-sbfd-discriminator.all@ietf.org = " = >, OSPF WG List = > >> Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt >>=20 >>> Hi Adrian, >>>=20 >>> Thanks for the extensive review. I have a minor comment on a minor = issue that you raised. >>>=20 >>>>=20 >>>> Minor Issues: >>>>=20 >>>> I should like to see some small amount of text on the scaling = impact on >>>> OSPF. 1. How much additional information will implementations have = to >>>> store per node/link in the network? 2. What is the expected churn = in >>>> LSAs introduced by this mechanism (especially when the Reflector is >>>> turned on and off)? >>>=20 >>> Isnt this implementation specific? This is what will differentiate = one vendor implementation from the other. >>>=20 >>> I am not sure how we can quantify this -- any ideas? >>>=20 >>> This is akin to saying that IS-IS, in contrast to OSPFv2, is more = attuned for partial SPF runs because the node information is cleanly = separated from the reachability information. However, this isnt entirely = true. While i concede that node information is mixed with prefix = information in OSPFv2, there still are ways in which clever = implementations could separate the two and do exactly what IS-IS does. >>>=20 >>> I took this rather circuitous approach to drive home the point that = scalability, churn, overheads on the system are in many cases dependent = on the protocol implementation and by that token outside the scope of = the IETF drafts. >>=20 >> I believe what is being requested is a discussion of how often the = S-BFD TLV is likely to change, the effects on flooding, and, if = required, recommendations for any rate-limiting or other measures to = prevent churn. >>=20 >> Thanks, >> Acee >>=20 >>=20 >>=20 >>>=20 >>>>=20 >>>> You *do* have... >>>> A change in information in the S-BFD Discriminator TLV MUST NOT >>>> trigger any SPF computation at a receiving router. >>>> ...which is a help. >>>=20 >>> I would be alarmed if an implementation in an absence of this = pedantic note triggered SPF runs each time an S-BFD disc changed ! I = mean if you understand the idea being discussed then you also understand = that a change in this TLV has no bearing on the reachability anywhere. = And that knowledge should be enough to prevent SPF runs in most cases ! >>>=20 >>> I know that we have added this note but if we need to explicitly = spell such things out in all standards then we clearly have bigger = problems ! :-) >>>=20 >>> Cheers, Manav --Apple-Mail=_9B96C277-716E-4C8A-8E27-72DE3C300ED7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Adrian,

Thanks for the follow-up.

As I wrote to Alia, I am hesitant to = quantify this further. These are identifiers expected to be static = (think of a loopback IP address or a hostname as identifiers), on a = feature that is not toggled on-and-off constantly. I really think that = the document is saying enough for implementors to understand and take = action (we are saying how often they change, and saying that when they = do they are advertised). 

Plus, regarding how much extra info = additionally flooded or stored, as Alia also acknowledged, this isn=E2=80=99= t a high-volume TLV, and the format is shown.

I do like helpful advice in an RFC, but = it seems to me that the current text goes as far. 

Perhaps I am = misunderstanding the intention or the concern. In that case, if you have = specific ideas in mind, it might help if you could provide a text = proposal to compare and contrast.

Thanks,

=E2=80=94 Carlos.

On May 3, 2016, at 2:06 PM, Adrian Farrel <adrian@olddog.co.uk>= wrote:

Carlos,
 
Alia asked me to = confirm whether your proposed change would have caused me to not have = made this comment on review.
 
It would certainly have = helped. But...
 
"quite static" is not = very clear as a relative term.
 
I think the concern = might be that the network is large and there are many BFD sessions. 
Unless have I have misunderstood, it is = not just a change in discriminator, but also a change to whether = reflection is wanted or not.
 
Anyway, this is not a = trap, just an encouragement to make a statement that helps readers to = know that they don't need to worry. The parameters are:
- what causes an LSA to be flooded?
- how does that compare to the number of = LSAs normally flooded?
- = the security thing about using this as a way to cause excess = flooding
- how much extra state = info does an OSPF implementation have to hold
   for these LSA in the = LSA DB?
 
Cheers,
Adrian
 
From: Carlos Pignataro (cpignata) = [mailto:cpignata@cisco.com] 
Sent: 28 = April 2016 17:15
To: Adrian Farrel
Cc: Acee Lindem (acee); Manav = Bhatia; <rtg-ads@ietf.org>; <rtg-dir@ietf.org>; draft-ietf-ospf-sbfd-discriminator.all@ietf.org; OSPF WG = List
Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt
 
Adrian,
 
I would not oppose to = making a clarification similar to the following, if the WG things its = useful:
 
The S-BFD Discriminators are expected to be quite static. = S-BFD Discriminators may change when enabling the S-BFD functionality or = via an explicit configuration event. These will result in a change in = the information advertised in the S-BFD Discriminator TLV in OSPF, but = are not expected to happen with any regularity.
 
[I expect that text = needs (a lot of) wordsmithing, and might not be useful or desired at = all, but just to make the discussion more real]
 
Thanks,
 
=E2=80=94 Carlos.
 
On Apr 28, 2016, at 8:59 AM, Adrian Farrel <adrian@olddog.co.uk> = wrote:
 
Acee has it right.
 
While (of course) stuff = can be done in implementations to mitigate the effects, the protocol = extensions here increase the size of LSA and increase the amount of = flooding. Since the LSAs have to be stored (in some form), it is = reasonable to describe the amount of extra information that reflects = across a network - maybe express it as "LSA data" and leave it up to an = implementation to choose how to store it. Since the number of LSA = updates impacts the routing plane processing and bits on the wire, it is = reasonable to ask what impact that might have.
 
I = am interested to hear whether turning Reflectors on and off could be a = feature that could cause LSAs to flap and so create flooding ripples in = the network.
 
Adrian
 
From: Acee Lindem (acee) = [mailto:acee@cisco.com] 
Sent: 28 = April 2016 10:21
To: Manav Bhatia; Adrian = Farrel
Cc: <rtg-ads@ietf.org>; rtg-dir@ietf.org; draft-ietf-ospf-sbfd-discriminator.all@ietf.org; OSPF WG = List
Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt
 
Hi Manav,
 
From: Manav Bhatia <manav@ionosnetworks.com>
Date: Thursday, April 28, = 2016 at 1:31 AM
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, Routing Directorate <rtg-dir@ietf.org>, "draft-ietf-ospf-sbfd-discriminator.all@ietf.org" = <draft-ietf-ospf-sbfd-discriminator.all@ietf.org>,= OSPF WG List <ospf@ietf.org>
Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt
 
Hi Adrian,
 
Thanks for the extensive review. I have a minor comment on a = minor issue that you raised.
 

Minor Issues:

I = should like to see some small amount of text on the scaling impact on
OSPF. 1. How much additional information will implementations = have to
store per node/link in the network? 2. What is the = expected churn in
LSAs introduced by this mechanism = (especially when the Reflector is
turned on and = off)?
 
Isnt this implementation specific? This is what will = differentiate one vendor implementation from the = other. 
 
I am not sure how we can quantify this -- any = ideas?
 
This is akin to saying that IS-IS, in contrast to OSPFv2, is = more attuned for partial SPF runs because the node information is = cleanly separated from the reachability information. However, this isnt = entirely true. While i concede that node information is mixed with = prefix information in OSPFv2, there still are ways in which clever = implementations could separate the two and do exactly what IS-IS = does. 
 
I took this rather circuitous approach to drive home the = point that scalability, churn, overheads on the system are in many cases = dependent on the protocol implementation and by that token outside the = scope of the IETF drafts.
 
I believe what is being requested is a discussion of how = often the S-BFD TLV is likely to change, the effects on flooding, and, = if required, recommendations for any rate-limiting or other measures to = prevent churn. 
 
Thanks,
Acee
 
 
 
 

You *do* = have...
   A change in information in the S-BFD = Discriminator TLV MUST NOT
   trigger any SPF = computation at a receiving router.
...which is a = help.
 
I would be alarmed if an implementation in an absence of this = pedantic note triggered SPF runs each time an S-BFD disc changed ! I = mean if you understand the idea being discussed then you also understand = that a change in this TLV has no bearing on the reachability anywhere. = And that knowledge should be enough to prevent SPF runs in most cases = ! 
 
I know that we have added this note but if we need to = explicitly spell such things out in all standards then we clearly have = bigger problems ! :-)
 
Cheers, = Manav
<= /div>
<= br class=3D"">= --Apple-Mail=_9B96C277-716E-4C8A-8E27-72DE3C300ED7-- --Apple-Mail=_D83EA809-DB89-4AE3-88B0-63D14AD204CE 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 - http://gpgtools.org iQIcBAEBCAAGBQJXKQDXAAoJEIXgpQGOZny9JxAQAInsv1lrwyA7fWRl6WYzLZ1w 6lVb1OBqW60gwcshyUOnB6Jv0mRehzcpqeQG7oQ89Sy70+klm09AtE4KPpOqsMU3 XFPhs65Q0vKt7QiD1n8IbS9gRGx9lb50/WbFrWFTUfhVocwatxgNNdMRM/QvLc9P TY+WeSSX2cNO7FRTHIFN8BnrqgcdT0moGebLoErbBJ6JKdfyMEfG1QYGhqv/4h3Y 9G0sKpkFMq8ulukL2ZDHSWECGchzxw1sPmAcCt/vTSj3/xQL4tOH87jTQxUdpbm1 ySxygKorZHmjOLqql8sV6GMX5aOKYU1XkcJIIIFFNnKtHi6sFy1a3OYQbebqOtAj 30WT1A5Le6BTzDE3B5z3zWN8dN1JuIsghZstMbkv5Ud5Aa4Tl5uFM8ZGyo0vJ+ae qwWPAkf57IEubdalIbEpfR7vHL4B0z40g7dp6TYwWQeus3yLswiiGLptMIT9Y1sM d27cdkfBTOXEIPtL0k+4KgQCWlmhJ/ZIXvASXohjolI+UfmD1Wmrp7MxalNEVttF 2q1jaDxZ0/JxZn6zIWcoEZxkNwlwVz0h5HSEkSoXcHQURcb5o8WDhlxvgeBy0dP7 AmBgWY02+ClvsNfndshqVZkjyB5J+VZrWCZZFtFIn132NqJeVYrTpfZqxH5fW9Cm L9/8NdJ9rqZkwMEyR2OL =u+Ir -----END PGP SIGNATURE----- --Apple-Mail=_D83EA809-DB89-4AE3-88B0-63D14AD204CE-- From nobody Tue May 3 13:19:17 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4D712D0A3; Tue, 3 May 2016 13:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 3aVHiNiOgFcW; Tue, 3 May 2016 13:19:08 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65F4C12D183; Tue, 3 May 2016 13:19:07 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u43KJ1qR030245; Tue, 3 May 2016 21:19:01 +0100 Received: from 950129200 (jplon-nat11.juniper.net [193.110.55.11]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u43KInNl030092 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 3 May 2016 21:18:56 +0100 From: "Adrian Farrel" To: "'Carlos Pignataro \(cpignata\)'" References: <069b01d1a086$46d4d470$d47e7d50$@olddog.co.uk> <094e01d1a14d$dee2e320$9ca8a960$@olddog.co.uk> <40BAEA74-73C5-4CA9-B581-FD0864DCDFF8@cisco.com> <051101d1a566$7d582170$78086450$@olddog.co.uk> In-Reply-To: Date: Tue, 3 May 2016 21:18:48 +0100 Message-ID: <057401d1a579$0498e590$0dcab0b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0575_01D1A581.66667550" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFw1kCCaiIwUNLtEKxshcWR2bdBZAEdXWDpAeZ8YfwCW7Rb+gM0ffgPAY8JisMBq1EeiaAK0T+g Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22300.002 X-TM-AS-Result: No--27.464-10.0-31-10 X-imss-scan-details: No--27.464-10.0-31-10 X-TMASE-MatchedRID: pS5owHKhBO3JmaR8yBHGWKtWSWds/km2JCrNy6AbUJU4YKAM3oRt9i1l xAVVUrr2bvW8aqeo1n/Zlz8AwBLzjgkSzeMXko3JlVHM/F6YkvTNc6i32ftlfFQM54jP4h79QQ/ s9vEJJndsCEyIlk/eK5RYnhdItKOavCCmpyR752bAJnGRMfFxySseSAhqf1rR9jKBJYRpd1WDtx 8lDD0Wx0wvouS4U62BS/SrDavrFvGajZkb8TuLc1bWTTCHhOTxNNuh+5zmS68GgDV8o5u6Ewf7t X34v0pRoz8HTl+z1fZ6Nbm0VXGmc294Ipa1otxo4t2mucDkRBE0AKed0u9fBzNzZQXTq3sO8r9C VH8D1cgO1eozpdHlEuWQbb0Cu6INg+QbvWfvu8jXIwmz2YEJxTFFLhGUD8AW/Gw/uDwGV4t/7Ay 3ZInh8stjasHBa2Ue8/KQbghbCcn6Z227DrLqQ7dQIb8hCnY+e8tOW/bXHfCynk7TnYzMug+d/P hKYS9yrviYvHHdDkeOMDjZHc3LHcPlDt/vDJ7ECPKPqEbU3ZM5SAOCkuqVt33gfGZAU8fL4dLjx sRvbiIkX04GlzHMEZ7i1fZ4FYu3S5RTlYwa1oi20BbG4zmyXquvxGMwcZCYMXzBFhtQJWaZWy2Q OOrssXHDLxnhxMLIRLhdGHVxa6MUPKwcuWzcJDNKWYiz0CE6LJm8FOE9WLXgt9a0YyfLFLHaqZB ohRwhz+B9FumCXDfVbj7GXfjjmvD8WL7IHVq/B7TqRAYVohYmOHJ0aBcO1AJJmsCdNLQGrtNoTx L6qvdJlZFF2klNPrjsIvtIbWCRR1vveBQPCReeAiCmPx4NwGmRqNBHmBve1kTfEkyaZdxFGCd0S 0NCsqsWJn5Qp6QCGfUbSgrAnCbn+lRFo8pReg8bNgitPAlvCStjCuOR/hg= Archived-At: Cc: rtg-dir@ietf.org, 'Manav Bhatia' , rtg-ads@ietf.org, 'OSPF WG List' , draft-ietf-ospf-sbfd-discriminator.all@ietf.org, "'Acee Lindem \(acee\)'" Subject: Re: [RTG-DIR] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 20:19:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0575_01D1A581.66667550 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I might express the concern as one that an operator might voice. "If I = turn on this feature, what will happen to my IGP?" =20 But look, my review was for Alia to give her stuff to think about as AD. = If I really cared that much about this feature I would have reviewed the = I-D within the WG well before last call (not, as currently, well after). = So, if Alia is happy I have nothing more to say. =20 Thanks, Adrian =20 From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]=20 Sent: 03 May 2016 20:50 To: Adrian Farrel Cc: Acee Lindem (acee); Manav Bhatia; ; = ; draft-ietf-ospf-sbfd-discriminator.all@ietf.org; = OSPF WG List Subject: Re: Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt =20 Hi Adrian, =20 Thanks for the follow-up. =20 As I wrote to Alia, I am hesitant to quantify this further. These are = identifiers expected to be static (think of a loopback IP address or a = hostname as identifiers), on a feature that is not toggled on-and-off = constantly. I really think that the document is saying enough for = implementors to understand and take action (we are saying how often they = change, and saying that when they do they are advertised).=20 =20 Plus, regarding how much extra info additionally flooded or stored, as = Alia also acknowledged, this isn=E2=80=99t a high-volume TLV, and the = format is shown. =20 I do like helpful advice in an RFC, but it seems to me that the current = text goes as far.=20 =20 Perhaps I am misunderstanding the intention or the concern. In that = case, if you have specific ideas in mind, it might help if you could = provide a text proposal to compare and contrast. =20 Thanks, =20 =E2=80=94 Carlos. =20 On May 3, 2016, at 2:06 PM, Adrian Farrel wrote: =20 Carlos, =20 Alia asked me to confirm whether your proposed change would have caused = me to not have made this comment on review. =20 It would certainly have helped. But... =20 "quite static" is not very clear as a relative term. =20 I think the concern might be that the network is large and there are = many BFD sessions.=20 Unless have I have misunderstood, it is not just a change in = discriminator, but also a change to whether reflection is wanted or not. =20 Anyway, this is not a trap, just an encouragement to make a statement = that helps readers to know that they don't need to worry. The parameters = are: - what causes an LSA to be flooded? - how does that compare to the number of LSAs normally flooded? - the security thing about using this as a way to cause excess flooding - how much extra state info does an OSPF implementation have to hold for these LSA in the LSA DB? =20 Cheers, Adrian =20 From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]=20 Sent: 28 April 2016 17:15 To: Adrian Farrel Cc: Acee Lindem (acee); Manav Bhatia; ; = ; draft-ietf-ospf-sbfd-discriminator.all@ietf.org; = OSPF WG List Subject: Re: Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt =20 Adrian, =20 I would not oppose to making a clarification similar to the following, = if the WG things its useful: =20 The S-BFD Discriminators are expected to be quite static. S-BFD = Discriminators may change when enabling the S-BFD functionality or via = an explicit configuration event. These will result in a change in the = information advertised in the S-BFD Discriminator TLV in OSPF, but are = not expected to happen with any regularity. =20 [I expect that text needs (a lot of) wordsmithing, and might not be = useful or desired at all, but just to make the discussion more real] =20 Thanks, =20 =E2=80=94 Carlos. =20 On Apr 28, 2016, at 8:59 AM, Adrian Farrel < = adrian@olddog.co.uk> wrote: =20 Acee has it right. =20 While (of course) stuff can be done in implementations to mitigate the = effects, the protocol extensions here increase the size of LSA and = increase the amount of flooding. Since the LSAs have to be stored (in = some form), it is reasonable to describe the amount of extra information = that reflects across a network - maybe express it as "LSA data" and = leave it up to an implementation to choose how to store it. Since the = number of LSA updates impacts the routing plane processing and bits on = the wire, it is reasonable to ask what impact that might have. =20 I am interested to hear whether turning Reflectors on and off could be a = feature that could cause LSAs to flap and so create flooding ripples in = the network. =20 Adrian =20 From: Acee Lindem (acee) [ = mailto:acee@cisco.com]=20 Sent: 28 April 2016 10:21 To: Manav Bhatia; Adrian Farrel Cc: < rtg-ads@ietf.org>; = rtg-dir@ietf.org; = = draft-ietf-ospf-sbfd-discriminator.all@ietf.org; OSPF WG List Subject: Re: Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt =20 Hi Manav, =20 From: Manav Bhatia < = manav@ionosnetworks.com> Date: Thursday, April 28, 2016 at 1:31 AM To: Adrian Farrel < adrian@olddog.co.uk> Cc: "< rtg-ads@ietf.org>" < = rtg-ads@ietf.org>, Routing Directorate < = rtg-dir@ietf.org>, " = = draft-ietf-ospf-sbfd-discriminator.all@ietf.org" < = = draft-ietf-ospf-sbfd-discriminator.all@ietf.org>, OSPF WG List < = ospf@ietf.org> Subject: Re: Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt =20 Hi Adrian, =20 Thanks for the extensive review. I have a minor comment on a minor issue = that you raised. =20 Minor Issues: I should like to see some small amount of text on the scaling impact on OSPF. 1. How much additional information will implementations have to store per node/link in the network? 2. What is the expected churn in LSAs introduced by this mechanism (especially when the Reflector is turned on and off)? =20 Isnt this implementation specific? This is what will differentiate one = vendor implementation from the other.=20 =20 I am not sure how we can quantify this -- any ideas? =20 This is akin to saying that IS-IS, in contrast to OSPFv2, is more = attuned for partial SPF runs because the node information is cleanly = separated from the reachability information. However, this isnt entirely = true. While i concede that node information is mixed with prefix = information in OSPFv2, there still are ways in which clever = implementations could separate the two and do exactly what IS-IS does.=20 =20 I took this rather circuitous approach to drive home the point that = scalability, churn, overheads on the system are in many cases dependent = on the protocol implementation and by that token outside the scope of = the IETF drafts. =20 I believe what is being requested is a discussion of how often the S-BFD = TLV is likely to change, the effects on flooding, and, if required, = recommendations for any rate-limiting or other measures to prevent = churn.=20 =20 Thanks, Acee =20 =20 =20 =20 You *do* have... A change in information in the S-BFD Discriminator TLV MUST NOT trigger any SPF computation at a receiving router. ...which is a help. =20 I would be alarmed if an implementation in an absence of this pedantic = note triggered SPF runs each time an S-BFD disc changed ! I mean if you = understand the idea being discussed then you also understand that a = change in this TLV has no bearing on the reachability anywhere. And that = knowledge should be enough to prevent SPF runs in most cases !=20 =20 I know that we have added this note but if we need to explicitly spell = such things out in all standards then we clearly have bigger problems ! = :-) =20 Cheers, Manav =20 ------=_NextPart_000_0575_01D1A581.66667550 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I might express the concern as = one that an operator might voice. "If I turn on this feature, what = will happen to my IGP?"

 

But look, my review was for = Alia to give her stuff to think about as AD. If I really cared that much = about this feature I would have reviewed the I-D within the WG well = before last call (not, as currently, well after). So, if Alia is happy I = have nothing more to say.

 

Thanks,

Adrian

 

From: Carlos Pignataro = (cpignata) [mailto:cpignata@cisco.com]
Sent: 03 May 2016 = 20:50
To: Adrian Farrel
Cc: Acee Lindem (acee); = Manav Bhatia; <rtg-ads@ietf.org>; <rtg-dir@ietf.org>; = draft-ietf-ospf-sbfd-discriminator.all@ietf.org; OSPF WG = List
Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt

 

Hi = Adrian,

 

Thanks for the follow-up.

 

As I wrote to Alia, I am hesitant to quantify this further. = These are identifiers expected to be static (think of a loopback IP = address or a hostname as identifiers), on a feature that is not toggled = on-and-off constantly. I really think that the document is saying enough = for implementors to understand and take action (we are saying how often = they change, and saying that when they do they are = advertised). 

 

Plus, regarding how much extra info additionally flooded or = stored, as Alia also acknowledged, this isn=E2=80=99t a high-volume TLV, = and the format is shown.

 

I do like helpful advice in an RFC, but it seems to me that the = current text goes as far. 

 

Perhaps I am misunderstanding the intention or the concern. In = that case, if you have specific ideas in mind, it might help if you = could provide a text proposal to compare and = contrast.

 

Thanks,

 

=E2=80=94 Carlos.

 

On May 3, 2016, at 2:06 PM, Adrian Farrel <adrian@olddog.co.uk> = wrote:

 

Carlos,

 

Alia asked me to confirm = whether your proposed change would have caused me to not have made this = comment on review.

 

It would certainly have = helped. But...

 

"quite static" is = not very clear as a relative term.

 

I think the concern might = be that the network is large and there are many BFD sessions. 

Unless have I have = misunderstood, it is not just a change in discriminator, but also a = change to whether reflection is wanted or not.

 

Anyway, this is not a trap, = just an encouragement to make a statement that helps readers to know = that they don't need to worry. The parameters are:

- what causes an LSA to be = flooded?

- how does that compare to = the number of LSAs normally flooded?

- the security thing about = using this as a way to cause excess flooding

- how much extra state info = does an OSPF implementation have to hold

   for these LSA in the LSA = DB?

 

Cheers,

Adrian

 

From: Carlos Pignataro = (cpignata) [mailto:cpignata@cisco.com] 
Sent: 28 April 2016 = 17:15
To: Adrian = Farrel
Cc: Acee Lindem (acee); Manav = Bhatia; <rtg-ads@ietf.org>; <rtg-dir@ietf.org>; draft-iet= f-ospf-sbfd-discriminator.all@ietf.org; OSPF WG = List
Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt

 

Adrian,

 

I would not oppose to making a clarification similar to the = following, if the WG things its = useful:

 

The S-BFD = Discriminators are expected to be quite static. S-BFD Discriminators may = change when enabling the S-BFD functionality or via an explicit = configuration event. These will result in a change in the information = advertised in the S-BFD Discriminator TLV in OSPF, but are not expected = to happen with any = regularity.

 

[I expect that text needs (a lot of) wordsmithing, and might not = be useful or desired at all, but just to make the discussion more = real]

 

Thanks,

 

=E2=80=94 Carlos.

 

On Apr 28, 2016, at 8:59 AM, Adrian Farrel <adrian@olddog.co.uk> = wrote:

 

Acee has it = right.

 

While (of course) stuff can = be done in implementations to mitigate the effects, the protocol = extensions here increase the size of LSA and increase the amount of = flooding. Since the LSAs have to be stored (in some form), it is = reasonable to describe the amount of extra information that reflects = across a network - maybe express it as "LSA data" and leave it = up to an implementation to choose how to store it. Since the number of = LSA updates impacts the routing plane processing and bits on the wire, = it is reasonable to ask what impact that might have.

 

I am interested to hear = whether turning Reflectors on and off could be a feature that could = cause LSAs to flap and so create flooding ripples in the = network.

 

Adrian

 

From: Acee Lindem (acee) = [mailto:acee@cisco.com] 
Sent: 28 April 2016 = 10:21
To: Manav Bhatia; Adrian = Farrel
Cc: <rtg-ads@ietf.org>; rtg-dir@ietf.org; draft-ietf-ospf-sbfd-discriminator.all@ietf.org; OSPF WG List
Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt

 

Hi Manav,

 

From: Manav Bhatia <manav@ionosnetworks.com>
Date:=  Thursday, April 28, = 2016 at 1:31 AM
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, Routing = Directorate <rtg-dir@ietf.org>, "draft-ietf-ospf-sbfd-discriminator.all@ietf.org" <draft-ietf-ospf-sbfd-discriminator.all@ietf.org>, OSPF WG List <ospf@ietf.org>
Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt

 

<= p class=3DMsoNormal>Hi Adrian,

 

Thanks for the extensive review. I have a = minor comment on a minor issue that you raised.

 


Minor Issues:

I should like to = see some small amount of text on the scaling impact on
OSPF. 1. How = much additional information will implementations have to
store per = node/link in the network? 2. What is the expected churn in
LSAs = introduced by this mechanism (especially when the Reflector is
turned = on and off)?

 

Isnt this implementation specific? This = is what will differentiate one vendor implementation from the = other. 

 

I am not sure how we can quantify this -- = any ideas?

 

This is akin to saying that IS-IS, in = contrast to OSPFv2, is more attuned for partial SPF runs because the = node information is cleanly separated from the reachability information. = However, this isnt entirely true. While i concede that node information = is mixed with prefix information in OSPFv2, there still are ways in = which clever implementations could separate the two and do exactly what = IS-IS does. 

 

I took this rather circuitous approach to = drive home the point that scalability, churn, overheads on the system = are in many cases dependent on the protocol implementation and by that = token outside the scope of the IETF drafts.

<= /div>

 

I believe what is being requested is a = discussion of how often the S-BFD TLV is likely to change, the effects = on flooding, and, if required, recommendations for any rate-limiting or = other measures to prevent churn. 

 

Thanks,

Acee

 

 

 

<= div>

 


You *do* have...
   A = change in information in the S-BFD Discriminator TLV MUST NOT
  =  trigger any SPF computation at a receiving router.
...which is = a help.

 

I would be alarmed if an implementation = in an absence of this pedantic note triggered SPF runs each time an = S-BFD disc changed ! I mean if you understand the idea being discussed = then you also understand that a change in this TLV has no bearing on the = reachability anywhere. And that knowledge should be enough to prevent = SPF runs in most cases ! 

 

I know that we have added this note but = if we need to explicitly spell such things out in all standards then we = clearly have bigger problems ! :-)

 

Cheers, Manav

<= /div>

 

------=_NextPart_000_0575_01D1A581.66667550-- From nobody Wed May 4 03:36:08 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1E312B008; Wed, 4 May 2016 03:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.996, SPF_SOFTFAIL=0.665] 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 CsG4dLAuZWXs; Wed, 4 May 2016 03:36:03 -0700 (PDT) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [161.106.1.2]) by ietfa.amsl.com (Postfix) with ESMTP id 15E2412B02B; Wed, 4 May 2016 03:36:03 -0700 (PDT) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 32AF27CC004; Wed, 4 May 2016 12:36:02 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail1.rd.orange.com (Postfix) with ESMTP id C69557CC003; Wed, 4 May 2016 12:36:01 +0200 (CEST) Received: from [10.193.71.204] (10.193.71.204) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.266.1; Wed, 4 May 2016 12:36:01 +0200 To: Mingui Zhang References: <57212222.5080904@orange.com> <4552F0907735844E9204A62BBDD325E787C858FD@NKGEML515-MBX.china.huawei.com> <572706E7.7050005@orange.com> <4552F0907735844E9204A62BBDD325E787C865EB@NKGEML515-MBX.china.huawei.com> From: Julien Meuric Organization: Orange Message-ID: <5729D091.2040904@orange.com> Date: Wed, 4 May 2016 12:36:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <4552F0907735844E9204A62BBDD325E787C865EB@NKGEML515-MBX.china.huawei.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-trill-mtu-negotiation.all@ietf.org" , "trill@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-trill-mtu-negotiation-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 10:36:07 -0000 Hi Mingui, I have looked at the diff of your update and have noticed that several "should" have been replaced by "need[s] to": I appreciate that you acknowledge my comment on this, but none of them being RFC 2119 keyword, I still doubt this matches Standards Track expectations. I caught a nit in section 3: s/is sent to/is set to/ Regards, Julien May. 03, 2016 - zhangmingui@huawei.com: > Hi Julien, > > The updated version has just been uploaded. > > Thanks, > Mingui > >> -----Original Message----- >> From: Julien Meuric [mailto:julien.meuric@orange.com] >> Sent: Monday, May 02, 2016 3:51 PM >> >> Hi Mingui, >> >> About the "updated RFCs" issue below, my point is: "please make sure the text >> and the hearder are complete". I just had a quick look at those references, you >> know better than me which are actually relevant. >> >> I am looking forward to the updated version. >> >> Thanks, >> >> Julien >> >> >> Apr. 29, 2016 - zhangmingui@huawei.com: >>> Hi Julien, >>> >>> Thanks for the comments! Much appreciated! >>> >>> Please see in-lines below. An updated version will soon be uploaded to resolve >> the comments. >>> >>> Thanks, >>> Mingui >>> >>>> -----Original Message----- >>>> From: Julien Meuric [mailto:julien.meuric@orange.com] >>>> Sent: Thursday, April 28, 2016 4:34 AM >>>> >>>> Hello, >>>> >>>> I have been selected as the Routing Directorate reviewer for this draft. >>>> The Routing Directorate seeks to review all routing or >>>> 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 >>>> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >>>> >>>> Although these comments are primarily for the use of the Routing ADs, >>>> it would be helpful if you could consider them along with any other >>>> IETF Last Call comments that you receive, and strive to resolve them >>>> through discussion or by updating the draft. >>>> >>>> Document: draft-ietf-trill-mtu-negotiation-02.txt >>>> Reviewer: Julien Meuric >>>> Review Date: April 27, 2016 >>>> IETF LC End Date: April 5, 2016 >>>> >>>> Intended Status: Standards Track >>>> >>>> >>>> *Summary:* >>>> I have some minor concerns about this document that I think should be >>>> resolved before publication. >>>> >>>> *Comments:* >>>> Even though it requires to browse some other TRILL (normative) >>>> documents, the mechanism itself is simple and well described. >>>> Nevertheless, the specification deserves some improvement when it >>>> comes to obligations and options: this was part of my expectation >>>> after I realized it was upgrading a short section of the base >>>> document (RFC 6325), which needs to be emphasized as well. >>> >>> In the abstract, it's already mentioned as "optional updates" to RFC 6325. I think >> "Updates: 6325 " needs to appear in the page header as well. >>> >>>> >>>> *Minor Issues:* >>>> - The document is ST and references RFC 2119. There a some "MUST" and >>>> one "SHOULD", many of them inherited from specifications out of the >>>> referenced documents. On the other side, "must" and "should" are >>>> commonly used. This MUST be brought up to ST expectations. >>> >>> The usage of "must" and "should" will be updated as needed. I have checked all >> those appearances. The changes would be editorial. >>> >>>> - The document claims to only update RFC 7177. It seems however that >>>> it also updates RFC 6325 (section 4.3.2), RFC 7176 and maybe even RFC 7780. >>> >>> Actually, I don't think this document updates RFC7176. It simply makes use of >> the MTU Sub-TLV defined in RFC 7176. >>> The specification about the originatingL1LSPBufferSize of an unreachable >> RBridge is a slight update to RFC7780. This will be emphasized. >>> >>>> That should be either acknowledged or clarified. The 4th paragraph of >>>> the introduction tries to tackle that topic, but it is not clear >>>> enough in defining the position of the document with respect to previously >> defined mechanisms. >>> >>> The updated to RFC 6325 will be emphasized in this paragraph. The backward >> compatibility will be moved to here as well. It will help the positioning. >>> >>>> - The 3rd paragraph of the introduction duplicates the beginning of >>>> the following section 2. A possible way to limit this repetition >>>> effect may be to summarize that part of the introduction. >>> >>> Yes, summarization is the proper way. >>> >>>> - Section 3 specifies an algorithm. Even if it does not rely on a >>>> formal language, consistency would be valuable. My mind compiler would >> suggest: >>>> * "If" is followed by "then" only once: "then" keyword to be dropped? >>>> * The algorithm relies on a break/stop or continue principle; >>>> as such, the instance of "Else" at the end should be replaced by >>>> ">>> break> 4) Repeat Step1"; >>>> * "is set to" and "<--" seem to be similar: please pick one or clarify; >>>> * to improve readability, I would drop the double naming >>>> introduced with X, >>>> X1 and X2 and rely on explicit variable names all along, as in the >>>> text: e.g., "linkMtuSize" instead of X, "lowerBound" for X1 and "upperBound" >> instead of X2. >>> >>> Sure. Explicit names will be used for the sake of readability. >>> >>>> >>>> *Nits:* >>> >>> The following nits will be fixed as suggested. >>> >>>> ------ >>>> "Updates" field in header >>>> --- >>>> - I think the "RFC" acronym should appear. >>>> - The list may be extended with RFC RFC 6325, RFC 7176 and maybe even >>>> RFC 7780. >>>> ------ >>>> Abstract >>>> --- >>>> - s/campus wide MTU feature/campus-wide MTU feature/ >>>> - s/campus wide capability/campus-wide capability/ >>>> - s/link local packets/link-local packets/ >>>> - s/link local MTUs/link-local MTUs/ >>>> - "It updates RFC..." duplicates header: either to drop or make more >>>> specific to point to precise sections/mechanisms. >>>> ------ >>>> Section 1. >>>> --- >>>> - s/link scope PDUs can/link-scoped PDUs can/ >>>> ------ >>>> Section 2. >>>> --- >>>> - s/campus wide Sz MTU/campus-wide Sz MTU/ >>>> - s/area wide scope/area-wide scope/ >>>> - s/domain wide scope/domain wide scope/ >>>> - s/L1 Circuit Scoped/L1 Circuit-Scoped/ >>>> - "limited to 1470 to 65,535 bytes": I cannot parse it, is it meant to be a range? >>>> ------ >>>> Section 4. >>>> - OLD >>>> "while RB1 normally ignores link state information for any IS-IS >>>> unreachable RBridge RB2, originatingL1LSPBufferSize is an exception." >>>> NEW >>>> "while in most cases RB1 ignores link state information for IS-IS >>>> unreachable RBridge RB2, originatingL1LSPBufferSize is meaningful." >>>> [current wording suggests it is adding an exception to a mandatory >>>> behavior, which AFAIU it does not] >>> >>> OK. Will update the words. >>> >>>> ------ >>>> Section 7. >>>> --- >>>> - "tested size can be advertised": "can" is to be addressed as part >>>> of the loose RFC 2119 wording comment. >>> >>> Will use the word "MAY" instead. >>> >>>> ------ >>>> Section 8. >>>> --- >>>> - "value [...] had been reported": "reported" puzzles me, maybe "tested" >>>> was meant? >>>> - The 3rd paragraph "For an Lz-ignorant [...] link-wide Lz." should >>>> be moved up to become the second paragraph, so as to clarify what an >> Lz-ignorant is. >>> >>> OK. It will be moved up. >>> >>>> - "The extension of TRILL MTU negociation...": this is an explicit >>>> positioning which should be mentioned earlier in the I-D. >>> >>> >>> OK. This will be moved to the introduction. >>> >>>> ------ >>>> Section 10. >>>> --- >>>> - RFC 7180 bis is now RFC 7780. >>> >>> Yes, this will be updated. >>> >>>> --- >>>> >>>> Regards, >>>> >>>> Julien >>> From nobody Wed May 4 04:29:53 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6DB12D1E8; Wed, 4 May 2016 04:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, 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 It8-mSVrPIId; Wed, 4 May 2016 04:29:44 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0733.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0BC212D537; Wed, 4 May 2016 04:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ntlPuwlumbkqSHDztJt76uv4azRn2FpZszHruxMv7aU=; b=HQwwpz/cFXR0j3z4xuVw8u0ovOxP+2rQ8bbAjOfp+dNuy9T01W0GH4KrLRorYjBtwWq1cj2NZ4MvigbQNEPBqjYQKyCz6AKjCPFuMDyiEYvxq1RuWSFxi0J8zHcWJx1eCkEKzIfRjx8JzRy3F09M5CVBz0iIid4Hf1V7flGBuUA= Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1911.namprd02.prod.outlook.com (10.163.75.153) with Microsoft SMTP Server (TLS) id 15.1.485.9; Wed, 4 May 2016 11:29:24 +0000 Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.0485.011; Wed, 4 May 2016 11:29:23 +0000 From: Jonathan Hardwick To: Donald Eastlake Thread-Topic: Routing directorate review of draft-ietf-trill-channel-tunnel Thread-Index: AdGhTmtHFH0TbXDCR3+6jGztLdmlHwCnBrwAAIHzekA= Date: Wed, 4 May 2016 11:29:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=metaswitch.com; x-originating-ip: [2620:104:4001:73:3120:38d9:a5f3:df47] x-ms-office365-filtering-correlation-id: eb6ea4d3-e106-42ba-f1d5-08d3740f57fd x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1911; 5:171sd1MJwOauCxb4LVFnGAPge7wBp8taUflTi0OKJRlzOohLGf9mKY2NFr5wJl3Sq56NM7c9y4RiXoB49FjRoMT7DIIoJHu0aBOLnVzbImaZaihIFgSb/1FSZ6Uki9jSHFAgEmpgL9AbQPO9zYfqig==; 24:MobbYtf+HknfkOsUisV93rM5WRZH2x1rux9DazOhC2j51GvffCCiWSUwXQIRg9KsTKsn0C5/eRdjov34/4b8urkbKQv0fLSTD1sfw+Djmjg=; 7:ipQSINxdOmIHu/a7ZntCv3pGOAZ+t7AryHuTAq5ijbqyWdxLHQCSHfQ8m0cz6svkv8Dcohngy26nDgMn+fVJzVO/GVzJ4X9S0hkPC09rrK69njQCKfeT1iW/EDgXn+/CPlsZQ+O034t73sMZ5kv0S7nLjwyE6RjLwAFYjhhybEULGNxjRtM+28nDvTXk7EzX x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0201MB1911; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521098)(9101528026)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BY2PR0201MB1911; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1911; x-forefront-prvs: 093290AD39 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(30594003)(51914003)(13464003)(51444003)(5004730100002)(5003600100002)(1411001)(19580395003)(33656002)(1720100001)(9686002)(1220700001)(2906002)(74316001)(5008740100001)(86362001)(586003)(6116002)(102836003)(99286002)(189998001)(8936002)(77096005)(87936001)(5002640100001)(81166005)(15975445007)(3660700001)(2950100001)(4326007)(92566002)(76576001)(19580405001)(3280700002)(2900100001)(50986999)(10400500002)(110136002)(76176999)(54356999)(122556002)(230783001)(21314002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1911; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2016 11:29:23.7713 (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: Cc: " \(rtg-ads@ietf.org\)" , "rtg-dir@ietf.org" , "trill@ietf.org" , "draft-ietf-trill-channel-tunnel@ietf.org" , "akatlas@gmail.com" Subject: Re: [RTG-DIR] Routing directorate review of draft-ietf-trill-channel-tunnel X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 11:29:51 -0000 SGkgRG9uYWxkLA0KDQpUaGFua3MgZm9yIHRoZSByZXBsaWVzIC0gSSBhZ3JlZSB3aXRoIHRoZSBj aGFuZ2VzIHlvdSBwcm9wb3NlLiAgUGxlYXNlIHNlZSBkaXNjdXNzaW9uIGJlbG93IChsb29rIGZv ciBbSkVIXSkuDQoNCkJlc3QgcmVnYXJkcw0KSm9uDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBEb25hbGQgRWFzdGxha2UgW21haWx0bzpkM2UzZTNAZ21haWwuY29tXSANClNl bnQ6IDAxIE1heSAyMDE2IDIxOjQ2DQpUbzogSm9uYXRoYW4gSGFyZHdpY2sgPEpvbmF0aGFuLkhh cmR3aWNrQG1ldGFzd2l0Y2guY29tPg0KQ2M6IDxydGctYWRzQGlldGYub3JnPiAocnRnLWFkc0Bp ZXRmLm9yZykgPHJ0Zy1hZHNAaWV0Zi5vcmc+OyBha2F0bGFzQGdtYWlsLmNvbTsgcnRnLWRpckBp ZXRmLm9yZzsgZHJhZnQtaWV0Zi10cmlsbC1jaGFubmVsLXR1bm5lbEBpZXRmLm9yZzsgdHJpbGxA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBSb3V0aW5nIGRpcmVjdG9yYXRlIHJldmlldyBvZiBkcmFm dC1pZXRmLXRyaWxsLWNoYW5uZWwtdHVubmVsDQoNCk9uIFRodSwgQXByIDI4LCAyMDE2IGF0IDk6 MjYgQU0sIEpvbmF0aGFuIEhhcmR3aWNrIDxKb25hdGhhbi5IYXJkd2lja0BtZXRhc3dpdGNoLmNv bT4gd3JvdGU6DQo+IEhlbGxvLA0KPg0KPiBJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91 dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhpcyANCj4gZHJhZnQuIFRoZSBSb3V0aW5n IERpcmVjdG9yYXRlIHNlZWtzIHRvIHJldmlldyBhbGwgcm91dGluZyBvciANCj4gcm91dGluZy1y ZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVT RyANCj4gcmV2aWV3LCBhbmQgc29tZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVzdC4gVGhlIHB1cnBv c2Ugb2YgdGhlIHJldmlldyBpcyANCj4gdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0 aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgDQo+IHRoZSBSb3V0aW5nIERpcmVj dG9yYXRlLCBwbGVhc2Ugc2VlIA0KPiBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0 Zy90cmFjL3dpa2kvUnRnRGlyDQo+DQo+IEFsdGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmlt YXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURzLCANCj4gaXQgd291bGQgYmUgaGVs cGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciANCj4g SUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0byBy ZXNvbHZlIHRoZW0gDQo+IHRocm91Z2ggZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJh ZnQuDQo+DQo+IEJlc3QgcmVnYXJkcw0KPiBKb24NCj4gPT09DQo+DQo+IERvY3VtZW50OiBkcmFm dC1pZXRmLXRyaWxsLWNoYW5uZWwtdHVubmVsDQo+IFJldmlld2VyOiBKb24gSGFyZHdpY2sNCj4g UmV2aWV3IERhdGU6IDI4IEFwcmlsIDIwMTYNCj4gSW50ZW5kZWQgU3RhdHVzOiBTdGFuZGFyZHMg VHJhY2sNCj4NCj4NCj4gU3VtbWFyeQ0KPg0KPiBJIGhhdmUgc29tZSBjb25jZXJucyBhYm91dCB0 aGlzIGRvY3VtZW50IGFuZCByZWNvbW1lbmQgdGhhdCB0aGUgDQo+IFJvdXRpbmcgQURzIGRpc2N1 c3MgdGhlc2UgaXNzdWVzIGZ1cnRoZXIgd2l0aCB0aGUgYXV0aG9ycy4NCj4NCj4NCj4gQ29tbWVu dHMNCj4NCj4gVGhlIGRyYWZ0IGlzIG92ZXJhbGwgd2VsbCB3cml0dGVuIGFuZCB0aGUgc3BlY2lm aWNhdGlvbiBpcyBxdWl0ZSBlYXN5IA0KPiB0byB1bmRlcnN0YW5kLA0KDQpUaGFua3MuDQoNCj4g ICAgICAgICAgICAgICAgICAgICAgYnV0IEkgZm91bmQgc29tZSBvZiB0aGUgdGVybWlub2xvZ3kg YW5kIHJhdGlvbmFsZSANCj4gdG8gYmUgY29uZnVzaW5nLiAgSSB3b3VsZCBwcmVmZXIgdG8gc2Vl IHRoaXMgY2xhcmlmaWVkIGJlZm9yZSB0aGUgDQo+IGRvY3VtZW50IGlzIHB1Ymxpc2hlZCBhcyBS RkMuICBOb3RlIHRoYXQgdGhpcyBpcyB0aGUgZmlyc3QgVFJJTEwgDQo+IGRvY3VtZW50IEnigJl2 ZSByZXZpZXdlZCwgc28gbXkgY29udGV4dCBjb21lcyBsYXJnZWx5IGZyb20gbWFpbGluZyBsaXN0 IA0KPiBzZWFyY2hlcyBhbmQgdGhlIHNoZXBoZXJk4oCZcyByZXBvcnQuDQo+DQo+DQo+IE1ham9y IENvbW1lbnRzDQo+DQo+IFRoZSBtb3RpdmF0aW9ucyBmb3IgdGhpcyBkcmFmdCBhcmUgcXVpdGUg b2JzY3VyZSBmcm9tIHRoZSBwZXJzcGVjdGl2ZSANCj4gb2YgdGhlIG91dHNpZGVyIEogd2hpY2gg bWFrZXMgaXQgaGFyZCBmb3IgbWUgdG8gZXZhbHVhdGUgdGhlIHByb3Bvc2VkIA0KPiBtZWNoYW5p c20uDQo+DQo+IEkgdGhpbmsgdGhlIHByb2JsZW1zIHRoYXQgdGhlIGRyYWZ0IHNvbHZlcyBzaG91 bGQgYmUgbW9yZSBjbGVhcmx5IA0KPiBzcGVsbGVkIG91dC4gIEZyb20gdGhlIGludHJvZHVjdGlv bjoNCj4NCj4gICAgVGhpcyBkb2N1bWVudCB1cGRhdGVzIFtSRkM3MTc4XSBhbmQgc3BlY2lmaWVz IGV4dGVuc2lvbnMgdG8gUkJyaWRnZQ0KPiAgICBDaGFubmVsIHRoYXQgcHJvdmlkZSB0d28gYWRk aXRpb25hbCBmYWNpbGl0aWVzIGFzIGZvbGxvd3M6DQo+DQo+ICAgICAgICgxKSBBIHN0YW5kYXJk IG1ldGhvZCB0byB0dW5uZWwgYSB2YXJpZXR5IG9mIHBheWxvYWQgdHlwZXMgYnkNCj4gICAgICAg ICAgIGVuY2Fwc3VsYXRpbmcgdGhlbSBpbiBhbiBSQnJpZGdlIENoYW5uZWwgbWVzc2FnZS4NCj4N Cj4gICAgICAgKDIpIEEgbWV0aG9kIHRvIHByb3ZpZGUgc2VjdXJpdHkgZmFjaWxpdGllcyBmb3Ig UkJyaWRnZSBDaGFubmVsDQo+ICAgICAgICAgICBtZXNzYWdlcy4NCj4NCj4gSSB0aGluayB0aGF0 IG51bWJlciAoMSkgcmVxdWlyZXMgbW9yZSBleHBsYW5hdGlvbiBiZWNhdXNlIHRoZSBSQnJpZGdl IA0KPiBjaGFubmVsIGFscmVhZHkgcHJvdmlkZXMgYSBzdGFuZGFyZCBtZXRob2QgZm9yIGEgdmFy aWV0eSBvZiBwYXlsb2FkIA0KPiB0eXBlcyB0byBiZSB0cmFuc21pdHRlZCB3aXRob3V0IG5lZWRp bmcgdGhlIGN1cnJlbnQgZHJhZnQuDQo+IFdoYXQgdHVubmVsaW5nIGNhcGFiaWxpdHkgaXMgdGhp cyBkcmFmdCBhZGRpbmc/DQoNCkdvb2QgcG9pbnQuDQoNClRoZSBSQnJpZGdlIENoYW5uZWwgZmFj aWxpdHkgZG9lcyBwcm92aWRlIGEgInByb3RvY29sIG51bWJlciIgd2hpY2ggaXMsIGluIGVzc2Vu Y2UsIHRoZSAidHlwZSIgb2YgaXRzIHBheWxvYWQuIEhvd2V2ZXIsIHRoZXJlIGFyZSB0aHJlZSBs aW1pdGF0aW9ucyBvZiBSQnJpZGdlIENoYW5uZWw6ICgxKSBObyBzZWN1cml0eTsgKDIpIE5vIHdh eSB0byBsZXZlcmFnZSB0aGUgbWFueSBleGlzdGluZyBkZWZpbmVkIEV0aGVydHlwZXMgYXMgYSBw YXlsb2FkIHR5cGU7IGFuZA0KDQpbSkVIXSBPSywgbm93IEkgdW5kZXJzdGFuZCAoMiksIHRoYW5r IHlvdS4gIEkgdGhvdWdodCBtYXliZSB5b3UnZCBhbGxvY2F0ZSBDaGFuZWwgcHJvdG9jb2wgbnVt YmVycyB0byBtYXRjaCBFdGhlcnR5cGVzIGFzIG5lZWRlZCwgdGhvdWdoIEkgbm93IHNlZSB0aGF0 IHRoaXMgd291bGQgYmUgcXVpdGUgdGVkaW91cyBwcm9jZXNzLXdpc2UgKG5vdCB0byBtZW50aW9u IHRoYXQgRXRoZXJ0eXBlIGhhcyA0IGFkZGl0aW9uYWwgYml0cykuIFsvSkVIXQ0KDQooMykgUkJy aWRnZSBDaGFubmVsIGNhbiBvbmx5IHNlbmQgdHlwZWQgbWVzc2FnZXMgZWl0aGVyICgzYSkgYmV0 d2VlbiBSQnJpZGdlcyBpbiBhIGNhbXB1cyBhbmQgKDNiKSBiZXR3ZWVuIGVuZCBzdGF0aW9ucyBh bmQgUkJyaWRnZXMgb24gdGhlIHNhbWUgbGluay4gRWFybGllciB2ZXJzaW9ucyBvZiB0aGlzIGRy YWZ0IGluY2x1ZGVkIG1lY2hhbmlzbXMgZXh0ZW5zaW9ucyBpbiBhcmVhIDMsIGZvciBleGFtcGxl LCBmb3Igc2VuZGluZyBSQnJpZGdlIENoYW5uZWwgbWVzc2FnZXMgYmV0d2VlbiBlbmQgc3RhdGlv bnMgYW5kIFJCcmlkZ2VzIG5vdCBvbiB0aGUgc2FtZSBsaW5rOyBob3dldmVyLCB0aGlzIGFkZGVk IHNpZ25pZmljYW50IGNvbXBsZXhpdHkgYW5kIHRoZXJlIGFwcGVhcnMgdG8gYmUgbm8gY3VycmVu dCBuZWVkIGZvciBzdWNoIGV4dGVuc2lvbnMgc28gdGhleSB3ZXJlIGRyb3BwZWQsIGxlYXZpbmcg b25seSBleHRlbnNpb25zIGluIGFyZWFzIDEgYW5kIDIuDQoNCltKRUhdIE9LLiAgTnVtYmVyIDMg ZG9lcyBzb3VuZCBhIGJpdCBtb3JlIGxpa2UgdHVubmVsbGluZyB0aGFuIDEgb3IgMi4gIEhlbHBz IHRvIGhhdmUgdGhlIGhpc3RvcnksIHRoYW5rcy4gWy9KRUhdDQoNCkhvdyBhYm91dCB0aGUgZm9s bG93aW5nIGNoYW5nZSBvbiBhZGRpdGlvbmFsIGZhY2lsaXR5IDEgaW4gdGhlIGRyYWZ0Og0KDQpP TEQNCiAgICAgICgxKSBBIHN0YW5kYXJkIG1ldGhvZCB0byB0dW5uZWwgYSB2YXJpZXR5IG9mIHBh eWxvYWQgdHlwZXMgYnkNCiAgICAgICAgICBlbmNhcHN1bGF0aW5nIHRoZW0gaW4gYW4gUkJyaWRn ZSBDaGFubmVsIG1lc3NhZ2UuDQpORVcNCiAgICAgICgxKSBBIHN0YW5kYXJkIG1ldGhvZCB0byB0 dW5uZWwgcGF5bG9hZHMgd2hvc2UgdHlwZSBtYXkgYmUNCiAgICAgICAgICBpbmRpY2F0ZWQgYnkg RXRoZXJ0eXBlIHRocm91Z2ggZW5jYXBzdWxhdGlvbiBpbiBSQnJpZGdlICBDaGFubmVsIG1lc3Nh Z2VzLg0KDQpbSkVIXSBZZXMsIGxvb2tzIGdvb2QuIFsvSkVIXQ0KDQo+IEEgc2lnbmlmaWNhbnQg YW1vdW50IG9mIHRleHQgaW4gdGhlIGRyYWZ0IGRpc2N1c3NlcyBudW1iZXIgKDIpLCB3aGljaCAN Cj4gc2VjdXJlcyB0aGUgY2hhbm5lbCBwYXlsb2FkLCBwcmVzdW1hYmx5IHRvIGNvdmVyIGNhc2Vz IHdoZXJlIHRoZSANCj4gcGF5bG9hZCBoYXMgbm8gaW4tYnVpbHQgc2VjdXJpdHkgbWVjaGFuaXNt LiAgVGhpcyBhcHBlYXJzIHRvIGJlIHRoZSANCj4gbWFqb3IgcHVycG9zZSBvZiB0aGUgZHJhZnQu ICBUaGUgZHJhZnQgYWNoaWV2ZXMgbnVtYmVyICgyKSBieSBhZGRpbmcgYSANCj4gc2VjdXJpdHkg c2hpbSBoZWFkZXIgYmV0d2VlbiB0aGUgUkJyaWRnZSBjaGFubmVsIGhlYWRlciBhbmQgdGhlIA0K PiBwYXlsb2FkLiAgT25lIGNvbnNpZGVyYXRpb24gaW4gZG9pbmcgdGhpcyBpcyB0byByZW1haW4g YmFja3dhcmRzIA0KPiBjb21wYXRpYmxlIHdpdGggUkZDIDcxNzgsIGFuZCBpdCBsb29rcyBsaWtl IHRoZSB3b3JraW5nIGdyb3VwIGhhcyANCj4gZGVjaWRlZCB0byBhY2hpZXZlIGJhY2t3YXJkcyBj b21wYXRpYmlsaXR5IGJ5IGRlZmluaW5nIGEgbmV3IFJCcmlkZ2UgDQo+IGNoYW5uZWwgcHJvdG9j b2wgdHlwZSBjYWxsZWQg4oCcY2hhbm5lbCB0dW5uZWzigJ0g4oCTIHdoZXJlIHRoaXMgZWZmZWN0 aXZlbHkgDQo+IG1lYW5zIHRoZSBSQnJpZGdlIGNoYW5uZWwgcGF5bG9hZCBjb250YWlucyBhbiBh ZGRpdGlvbmFsIHNlY3VyaXR5IHNoaW0gDQo+IHdoaWNoIGluIHR1cm4gY29udGFpbnMgYW4gaWRl bnRpZmllciB0aGF0IGRldGVybWluZXMgdGhlIHJlYWwgcGF5bG9hZCANCj4gcHJvdG9jb2wgdHlw ZS4NCj4NCj4gSSBmaW5kIHRoZSB0ZXJtIOKAnGNoYW5uZWwgdHVubmVs4oCdIG1pc2xlYWRpbmcs IGFzIHRoZSBkcmFmdCBkb2VzIG5vdCANCj4gYXBwZWFyIHRvIGFkZCBhbnkgYWRkaXRpb25hbCB0 dW5uZWxsaW5nIGNhcGFiaWxpdHkgYWJvdmUgYW5kIGJleW9uZCANCj4gdGhlIHR1bm5lbGxpbmcg dGhhdCBjYW4gYWxyZWFkeSBiZSBkb25lIHVzaW5nIFJGQyA3MTc4LiAgVGhlIGRyYWZ0IA0KPiBh Y3R1YWxseSBkZXNjcmliZXMgYW4gUkJyaWRnZSBjaGFubmVsIHdpdGggZW5oYW5jZWQgc2VjdXJp dHksIHNvIGEgDQo+IHRlcm0gbGlrZSDigJxzZWN1cmUgY2hhbm5lbOKAnSB3b3VsZCBtYWtlIG1v cmUgc2Vuc2UgdG8gbWUgdGhhbiDigJxjaGFubmVsIA0KPiB0dW5uZWzigJ0uDQoNCk9LLCBJIHVu ZGVyc3RhbmQgd2h5IHlvdSB0aGluayB0aGF0IHRlcm0gaXMgbWlzbGVhZGluZy4gV2hpbGUgaXQg c2VlbXMgcXVpdGUgcmVhc29uYWJsZSB0byBjYWxsZWQgdGhlIGFkZGVkIGZpZWxkcyBhICJzaGlt Iiwgbm90ZSB0aGF0IHRoZSBmYWNpbGl0eSBjdXJyZW50bHkgY2FsbGVkICJDaGFubmVsIFR1bm5l bCIgaXMgcXVpdGUgY2xvc2VseSBpbnRlZ3JhdGVkIHdpdGggdGhlIGV4aXN0aW5nIFJGQyA3MTc4 IFJCcmlkZ2UgQ2hhbm5lbCBmYWNpbGl0eS4gRm9yIGV4YW1wbGUsIHRoZXJlIGlzIG9ubHkgb25l IGVycm9yIHJlcG9ydGluZyBtZWNoYW5pc20uIEVycm9ycyBpbiB0aGUgIkNoYW5uZWwgVHVubmVs IiBmYWNpbGl0eSBhZGRlZCBieSB0aGlzIGRyYWZ0IGFyZSByZXBvcnRlZCBhcyBpZiB0aGV5IHdl cmUgZXJyb3JzIGluIHRoZSBSQnJpZGdlIENoYW5uZWwgbWVzc2FnZXMgdG8gd2hpY2ggdGhlICJz aGltIiB3YXMgYWRkZWQuDQoNCkkgZG9uJ3QgYWN0dWFsbHkgbGlrZSB5b3VyIHN1Z2dlc3Rpb24g b2YgInNlY3VyZSBjaGFubmVsIiBhcyBhIG5ldyBuYW1lLiAgSG93IGFib3V0IHJlLW5hbWluZyB0 aGUgZmFjaWxpdHkgYmVpbmcgYWRkZWQgYnkgdGhpcyBkcmFmdCBhcyB0aGUgIlJCcmlkZ2UgQ2hh bm5lbCBIZWFkZXIgRXh0ZW5zaW9uIj8NCg0KW0pFSF0gT0ssIEkgbGlrZSBSQnJpZGdlIENoYW5u ZWwgSGVhZGVyIEV4dGVuc2lvbi4gWy9KRUhdDQoNCkkgYmVsaWV2ZSB0aGF0IFJGQyA3NzgzIGFu ZCBvbmx5IHRoYXQgUkZDIHRoYXQgcmVmZXJlbmNlcyB0aGlzIGRyYWZ0IHVzaW5nIHRoZSB0ZXJt ICJDaGFubmVsIFR1bm5lbCIgYnV0IHRoaXMgaXMgYSB2ZXJ5IG1pbm9yIGluZm9ybWF0aW9uYWwg cGFzc2luZyByZWZlcmVuY2UuIFRoZXJlIGFyZSBkcmFmdHMgaW4gdGhlIHB1YmxpY2F0aW9uIHJl cXVlc3RlZCBzdGF0ZSB0aGF0IHJlZmVyZW5jZSB0aGlzIGRyYWZ0IHVzaW5nIHRoZSB0ZXJtICJD aGFubmVsIFR1bm5lbCIgYnV0IGl0IHNlZW1zIHRoYXQgaXQgd291bGQgYmUgcmVsYXRpdmVseSBz dHJhaWdodGZvcndhcmQgdG8gY2hhbmdlIHRoZSBuYW1lIHRvICJSQnJpZGdlIENoYW5uZWwgSGVh ZGVyIEV4dGVuc2lvbiIgb3Igc29tZSBvdGhlciBuZXcgbmFtZSBpbiB0aG9zZSBkcmFmdHMgYW5k IGV2ZW4gZWFzaWVyIHRvIGNoYW5nZSBpdCBpbiBkcmFmdHMgc3RpbGwgdW5kZXIgdGhlIGNvbnRy b2wgb2YgdGhlIFRSSUxMIFdHLg0KDQpbSkVIXSBUaGFua3MsIHRoaXMgd29ya3MgZm9yIG1lLiBb L0pFSF0NCg0KPiBNaW5vciBDb21tZW50cw0KPg0KPiBTZWN0aW9uIDMuMSDigJMg4oCcQW55IHBh cnRpY3VsYXIgdXNlIG9mIHRoZSBOdWxsIFBheWxvYWQgc2hvdWxkIHNwZWNpZnkgDQo+IHdoYXQg VkxBTiBvciBwcmlvcml0eSBzaG91bGQgYmUgdXNlZCB3aGVuIHJlbGV2YW50LuKAnSDigJMgaXMg dW5jbGVhciBhbmQgDQo+IG5vIGNvbnRleHQgZm9yIHRoaXMgc3RhdGVtZW50IGlzIGdpdmVuLiAg U2hvdWxkIGJlIHVzZWQgYnkgd2hhdCBhbmQgDQo+IGZvciB3aGF0IHB1cnBvc2U/DQoNCk9LLiBI b3cgYWJvdXQ6DQoNCiAgIEFueSBwYXJ0aWN1bGFyIHVzZSBvZiB0aGUgTnVsbCBQYXlsb2FkIHNo b3VsZCBzcGVjaWZ5IHdoYXQgVkxBTiBvcg0KICAgRkdMIGFuZCB3aGF0IHByaW9yaXR5IHNob3Vs ZCBiZSB1c2VkIGluIHRoZSBpbm5lciBkYXRhIGxhYmVsIG9mIHRoZQ0KICAgUkJyaWRnZSBDaGFu bmVsIG1lc3NhZ2UgKG9yIGluIGFuIG91dGVyIFZMQU4gdGFnIGZvciB0aGUgbmF0aXZlDQogICBS QnJpZGdlIENoYW5uZWwgbWVzc2FnZSBjYXNlKSB3aGVuIHRob3NlIHZhbHVlcyBhcmUgcmVsZXZh bnQuDQoNCltKRUhdIEZpbmUgWy9KRUhdDQoNCj4gU2VjdGlvbiA0LjMgZmVlbHMgbGlrZSBhIGNv cm9sbGFyeSB0byBzZWN0aW9uIDQuNSBhbmQgc28gbWF5IGJlIGJldHRlciANCj4gcGxhY2VkIGFz IGEgc3Vic2VjdGlvbiBvZiA0LjUuDQoNClRoZSBtZXRob2Qgb2YgZGVyaXZpbmcga2V5aW5nIG1h dGVyaWFsIGdpdmVuIGluIFNlY3Rpb24gNC4zIGlzIGFsc28gdXNlZCBpbiBEVExTIHNlY3VyaXR5 IGFzIG1lbnRpb25lZCBpbiBTZWN0aW9uIDQuNiBzbyBJIHRoaW5rIGl0IHNob3VsZCByZW1haW4g YSBzZXBhcmF0ZSBzZWN0aW9uLg0KDQpbSkVIXSBPSyBbL0pFSF0NCg0KPiBTZWN0aW9uIDQuNiDi gJxUaGUgUFR5cGUgaW5kaWNhdGVzIHRoZSBuYXR1cmUgb2YgdGhlIGFwcGxpY2F0aW9uX2RhdGEu 4oCdIA0KPiAtIGlzIHBvdGVudGlhbGx5IG9wZW4gdG8gbWlzaW50ZXJwcmV0YXRpb24uICBBdCBm YWNlIHZhbHVlIGl0IHNvdW5kcyANCj4gbGlrZSB5b3UgYXJlIGxlYWtpbmcgc29tZSBwb3RlbnRp YWxseSBzZW5zaXRpdmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIA0KPiDigJxuYXR1cmXigJ0gb2Yg dGhlIGVuY3J5cHRlZCBwYXlsb2FkLiAgSSB0aGluayBhbGwgeW91IGFyZSBhY3R1YWxseSANCj4g c2F5aW5nIGlzIHRoYXQgaXQgaW5kaWNhdGVzIHdoZXRoZXIgdGhlIHBheWxvYWQgaXMgYW4gRXRo ZXJ0eXBlLCBhbiANCj4gRXRoZXJuZXQgZnJhbWUgZXRjLiAgU3VnZ2VzdCBpbnN0ZWFkIOKAnElu IHRoaXMgY2FzZSwgdGhlIFBUeXBlIHZhbHVlIGluIA0KPiB0aGUgUkJyaWRnZSBDaGFubmVsIFR1 bm5lbCBQcm90b2NvbCBTcGVjaWZpYyBEYXRhIGFwcGxpZXMgdG8gdGhlIA0KPiBkZWNyeXB0ZWQg YXBwbGljYXRpb25fZGF0YS7igJ0NCg0KT0suDQoNCj4gU2VjdGlvbiA1LjIg4oCcd2l0aCBhIHBh eWxvYWQgdHlwZSAoUFR5cGUpIGluZGljYXRpbmcgYSBuZXN0ZWQgUkJyaWRnZSANCj4gQ2hhbm5l bCBtZXNzYWdl4oCdIOKAkyBzdHJpY3RseSBhbGwgdGhlIFBUeXBlIGNhbiBpbmRpY2F0ZSBpcyB0 aGF0IHRoZSANCj4gcGF5bG9hZCBpcyBFdGhlcnR5cGVkOyBvbiBpdHMgb3duIGl0IGNhbm5vdCBp bmRpY2F0ZSBhIG5lc3RlZCBSQnJpZGdlIA0KPiBDaGFuZWwgbWVzc2FnZS4gIFN1Z2dlc3Qg4oCc YW5kIGl0IGNvbnRhaW5zIGEgbmVzdGVkIFJCcmlkZ2UgQ2hhbmVsIA0KPiBtZXNzYWdl4oCdLg0K DQpPSy4NCg0KPiBTZWN0aW9uIDYuMg0KPg0KPiDigJxTZWN0aW9uIHh4eCBvZiBbUkZDIDcxNzhd 4oCdIHNob3VsZCBiZSDigJxTZWN0aW9uIDMuMiBvZiBbUkZDIDcxNzhd4oCdLg0KDQpSaWdodC4g U29ycnkgYWJvdXQgdGhhdC4NCg0KPiBEb27igJl0IHlvdSBhbHNvIG5lZWQgYSBuZXcgSUFOQSBy ZWdpc3RyeSBmb3IgdGhlIOKAnFJicmlkZ2UgQ2hhbm5lbCBFcnJvciANCj4gU3ViY29kZXPigJ0g bGlzdGVkIGluIHRhYmxlIDUuMj8NCg0KTXkgb3BpbmlvbiBpcyB0aGF0LCBmb3IgdGhlIGZpcnN0 IGRvY3VtZW50IGluIHdoaWNoIHlvdSBzcGVjaWZ5IGEgZmllbGQgYW5kIHNvbWUgdmFsdWVzLCBp dCBpcyBhIGp1ZGdtZW50IGNhbGwgd2hldGhlciB5b3Ugc2hvdWxkIGNyZWF0ZSBhbiBJQU5BIHJl Z2lzdHJ5IG9yIG5vdC4gIElmIHlvdSBleHBlY3QgbXVsdGlwbGUgZ3JvdXBzIHRvIHN0YXJ0IHJl cXVlc3RpbmcgdmFsdWVzIHRvIG11bHRpcGxlIHB1cnBvc2VzLCB0aGVuIGNyZWF0aW5nIGEgcmVn aXN0cnkgZnJvbSB0aGUgc3RhcnQgaXMgdGhlIHdheSB0byBnby4gT24gdGhlIG90aGVyIGhhbmQs IGlmIGEgZmllbGQgaXMgaW50ZXJuYWwgdG8gYSBwYXJ0aWN1bGFyIHByb3RvY29sIGFuZCB5b3Ug ZG9uJ3QgZXhwZWN0IGFueSBuZXcgZmllbGQgdmFsdWVzIHRvIGJlIGFzc2lnbmVkIHVudGlsIHRo ZXJlIGlzIGEgc2lnbmlmaWNhbnQgZXh0ZW5zaW9uIG9mIHRoYXQgcHJvdG9jb2wsIEkgZG9uJ3Qg c2VlIGFueSBwcm9ibGVtIGluIGRlZmVycmluZyB0aGUgcmVnaXN0cnkgY3JlYXRpb24gdG8gdGhl IHNlY29uZCBkb2N1bWVudC4gVGhpcyBpcyB0aGUgc2Vjb25kIGRvY3VtZW50IGFzc2lnbmluZyB2 YWx1ZXMgZm9yIFJCcmlkZ2UgQ2hhbm5lbCBFcnJvciBDb2RlcyBzbyBpdCBjcmVhdGVzIGEgcmVn aXN0cnkgZm9yIHRoZW0uIEl0IGRvZXMgbm90IGNyZWF0ZSBhIHJlZ2lzdHJ5IGZvciBTdWJFUlIg ZmllbGQgdmFsdWVzLg0KDQpbSkVIXSBPSywganVzdCBjaGVja2luZywgYW5kIGhhcHB5IHRvIGRl ZmVyIHRvIHlvdXIganVkZ21lbnQgaGVyZS4gWy9KRUhdDQoNCj4gTml0cw0KPg0KPiBTZWN0aW9u IDMuMg0KPg0KPiDigJxhcyBkZXNjcmliZSBpbuKAnSAtPiDigJxhcyBkZXNjcmliZWQgaW7igJ0N Cg0KT0suDQoNCj4gU2VjdGlvbiA0DQo+DQo+IOKAnG5vdCB0byBtZXTigJ0gLT4g4oCcbm90IHRv IG1lZXTigJ0NCg0KT0suDQoNCj4gMm5kIHBhcmFncmFwaCDigJMgdGhpcyBzZW50ZW5jZSBpcyBx dWl0ZSBsb25nIGFuZCBoYXJkIHRvIHBhcnNlLg0KDQpZb3UncmUgcmlnaHQuIExvb2tpbmcgYXQg dGhlIHNlbnRlbmNlLCBpdCBzZWVtcyBmYWlybHkgZWFzeSB0byBzaW1wbGlmeSBhbmQgc3BsaXQg aW50byB0d28gc2VudGVuY2VzLiBIb3cgYWJvdXQgdGhlIGZvbGxvd2luZw0KcmVwbGFjZW1lbnQ6 DQoNCiAgIFRoZSBDaGFubmVsIFR1bm5lbCBEVExTIGJhc2VkIHNlY3VyaXR5IHNwZWNpZmllZCBp biBTZWN0aW9uIDQuNg0KICAgYmVsb3cgaXMgaW50ZW5kZWQgZm9yIHBhaXJ3aXNlIChrbm93biB1 bmljYXN0KSB1c2UuIFRoYXQgaXMsIHRoZQ0KICAgY2FzZSB3aGVyZSB0aGUgTSBiaXQgaW4gdGhl IFRSSUxMIEhlYWRlciBpcyB6ZXJvIGFuZCBhbnkNCiAgIE91dGVyLk1hY0RBIGlzIGluZGl2aWR1 YWxseSBhZGRyZXNzZWQuDQoNCltKRUhdIExvb2tzIGdvb2QuIFsvSkVIXQ0KDQo+IFNlY3Rpb24g NC4yICYgU2VjdGlvbiA1LjENCj4NCj4g4oCcQXMgc2hvdyBpbuKAnSAtID4g4oCcQXMgc2hvd24g aW7igJ0NCg0KT0suDQoNCj4gU2VjdGlvbiA0LjMNCj4NCj4g4oCcVGhlIHVzZSBEZXJpdmVkIE1h dGVyaWFs4oCdIC0+IOKAnFRoZSB1c2Ugb2YgdGhlIERlcml2ZWQgTWF0ZXJpYWzigJ0NCg0KT0su DQoNCj4gRG9lcyBEZXJpdmVkIE1hdGVyaWFsIHJlYWxseSBuZWVkIHRvIGJlIGNhcGl0YWxpemVk IGluIHRoaXMgc2VjdGlvbj8NCg0KV2VsbCwgaXQgaXMgY2FwaXRhbGl6ZWQgaW4gdGhlIGVxdWF0 aW9uLiBTZWVtcyB0byBtZSByZWFzb25hYmxlIHRvIGNhcGl0YWxpemUgaW4gYm90aCBjYXNlcyB0 byBpbmRpY2F0ZSB0aGF0IGEgc3BlY2lmaWMgdHlwZSBvZiBEZXJpdmVkIE1hdGVyaWFsIGlzIGJl aW5nIHRhbGtlZCBhYm91dC4NCg0KW0pFSF0gT0suIFsvSkVIXQ0KDQo+IFNlY3Rpb24gNC41DQo+ DQo+IOKAnGNhbiByZWFzb25hYmxlIGJl4oCdIC0+IOKAnGNhbiByZWFzb25hYmx5IGJl4oCdDQoN Ck9LLg0KDQo+IFNlY3Rpb24gNC42DQo+DQo+IOKAnG1pbmltdW0gTVRVIFN64oCdIC0+IOKAnG1p bmltdW0gTVRVIHNpemXigJ0NCg0KU3ogaXMgYSBzdGFuZGFyZCBUUklMTCBzeW1ib2wgd2lkZWx5 IHVzZWQgaW4gVFJJTEwgZG9jdW1lbnRzIGFuZCBkZWZpbmVkIGluIFNlY3Rpb24gMS4xIG9mIHRo aXMgZHJhZnQuIEkgd291bGQgcHJlZmVyIHRvIG1ha2UgdGhlIGZvbGxvd2luZyBjaGFuZ2UgaW4g U2VjdGlvbiA0LjY6ICJ0aGUgVFJJTEwgY2FtcHVzIHdpZGUgbWluaW11bSBNVFUgU3oiIC0+ICJT eiIuDQoNCltKRUhdIE9LIC0gc29ycnksIEkgbWlzc2VkIHRoZSBkZWZpbml0aW9uISBbL0pFSF0N Cg0KPiDigJxBY3R1YWwgYXBwbGljYXRpb25fZGF0YSBzZW50IHdpdGggQ2hhbm5lbCBUdW5uZWzi gJ0gLT4g4oCcQWN0dWFsIA0KPiBhcHBsaWNhdGlvbl9kYXRhIHNlbnQgd2l0aGluIHRoZSBDaGFu bmVsIFR1bm5lbOKAnQ0KDQpPSy4NCg0KPiBXaHkgZG8geW91IHNheSDigJxhcHBsaWNhdGlvbl9k YXRh4oCdIG5vdCDigJxhcHBsaWNhdGlvbiBkYXRh4oCdPw0KDQoiYXBwbGljYXRpb25fZGF0YSIg aXMgdGhlIG5hbWUgb2YgdGhlIGZpZWxkIHR5cGUgaW4gRFRMUy4NCg0KW0pFSF0gT0suIFsvSkVI XQ0KDQo+IEFwcGVuZGl4IFogc2hvdWxkIHByZXN1bWFibHkgYmUgcmVtb3ZlZCBwcmlvciB0byBJ RVRGIGxhc3QgY2FsbC4NCg0KV2hpbGUgSSdtIG5vdCBzdXJlIGhvdyBtdWNoIGhlbHAgaXQgd291 bGQgYmUgdG8gSUVTRyBtZW1iZXJzIG9yIElFVEYgcGFydGljaXBhbnRzIGluIHJldmlld2luZyB0 aGUgZHJhZnQsIEkgZG9uJ3Qgc2VlIGFueSByZWFzb24gZm9yIEFwcGVuZGl4IFogdG8gYmUgcmVt b3ZlZCB1bnRpbCBSRkMgcHVibGljYXRpb24uIEJ1dCBhdCBsZWFzdCBhIG5vdGF0aW9uIGFza2Vk IHRoZSBSRkMgRWRpdG9yIHRvIGRlbGV0ZSBpdCBzaG91bGQgYmUgYWRkZWQuDQoNCltKRUhdIE9L IC0gcGxlYXNlIGFkZCB0aGUgUkZDIGVkaXRvciBub3RlLiBbL0pFSF0NCg0KVGhhbmtzLA0KRG9u YWxkDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIERvbmFsZCBFLiBFYXN0bGFrZSAz cmQgICArMS01MDgtMzMzLTIyNzAgKGNlbGwpDQogMTU1IEJlYXZlciBTdHJlZXQsIE1pbGZvcmQs IE1BIDAxNzU3IFVTQSAgZDNlM2UzQGdtYWlsLmNvbQ0K From nobody Wed May 4 07:27:17 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10AF412D69C for ; Wed, 4 May 2016 07:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign-com.20150623.gappssmtp.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 g49stoGctSVy for ; Wed, 4 May 2016 07:27:13 -0700 (PDT) Received: from mail-oi0-x264.google.com (mail-oi0-x264.google.com [IPv6:2607:f8b0:4003:c06::264]) (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 0E1A812D553 for ; Wed, 4 May 2016 07:27:13 -0700 (PDT) Received: by mail-oi0-x264.google.com with SMTP id i2so4693095oib.3 for ; Wed, 04 May 2016 07:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :accept-language:content-language:user-agent:mime-version; bh=YpbJEr83lkiGzTSVhD2xu0ykYmCGwZzVwpw17AaSytU=; b=RVDueuFpO6cM3vC3zdIj5/xinAAomuCQmxjN8+wow5m5sc730I0LQRswLaUgD5gvVw DQT+Kjk1bOez4R5EbAP4mV2zvTAveR1N6KEx8BNSUT8pU7Iq3G0aMh6WxFgCss0R6qMA EvzxVaetSW+kaGZcxKsatuk34h/Tz2jHGA1Mjgo5zZuInuiaSNfDV7ZrUXzVXXvZMA8k Kt37K7UouUbgPqpg9d7aCmAqclBKnVHAJE6wur4YAluveSgUdLqsfVhlBargWnYN49kr Efoc7fDd56yfo4R9PnfTFjBVl5wvFXFHOLu6Zxb4hAQ8PggxLCVUp3DWQxsWfQ3C5RoS jqyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:accept-language:content-language:user-agent :mime-version; bh=YpbJEr83lkiGzTSVhD2xu0ykYmCGwZzVwpw17AaSytU=; b=HG7mgfY5F92CG1W9ZJJl7C0w0LojxrbeMYtJBPQtJAmcGgzlmu/LVr4ddJkpWDTmeq gB9D4kjtpxK3Pk1nTEoCYplYuCh0A0zzwULWcKxbyCqwuD9VwHeeQfmFJlWRWbLdOy1u d11H1BqwpwgygLuf/MLvJaj7cC9LgBPjcqF1YCc9gG+OTyUFyU/dkTS18SCZdLdCTG+/ Eaxs4hfK836oyraTb59h0YBLvkQ+wfgU3r+1TvRU234cc1ZXLk/io2D1ewpMVjhgo4pG QrRw3JsheydUyGwxwrhNZXPxRBEA19Dvdlk9imHpcq2z6DK0bqrJjSi6r+rSXmf5kXpc mM+Q== X-Gm-Message-State: AOPr4FVjWKsjpKXRdwxVvV8eZk5+bIwxnZMkEyYEf1MntCnf/EACJ9RUQh8jgzjku4fKHcs77F3uO3mH1O9b0FZTegsGMJzy X-Received: by 10.55.217.130 with SMTP id q2mr9215003qkl.101.1462372031659; Wed, 04 May 2016 07:27:11 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id y190sm701522qkb.3.2016.05.04.07.27.11 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 04 May 2016 07:27:11 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id u44ERBJm028028 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 May 2016 10:27:11 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 4 May 2016 10:27:10 -0400 From: "McPherson, Danny" To: "rtg-ads@ietf.org" Thread-Topic: RtgDir review: TRILL: Interface Addresses APPsub-TLV Thread-Index: AQHRphEKORUTa4BWI0iEODDXoWE46A== Date: Wed, 4 May 2016 14:27:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-originating-ip: [10.173.152.4] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3545202429_374183223" MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-trill-ia-appsubtlv@ietf.org" , "all@ietf.org" , "trill@ietf.org" Subject: [RTG-DIR] RtgDir review: TRILL: Interface Addresses APPsub-TLV X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 14:27:16 -0000 --B_3545202429_374183223 Content-type: multipart/alternative; boundary="B_3545202429_1026179878" --B_3545202429_1026179878 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts = as they pass through IETF last call and IESG review, and sometimes on specia= l request. The purpose of the review is to provide assistance to the Routing= ADs. For more information about the Routing Directorate, please see http://= trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Cal= l comments that you receive, and strive to resolve them through discussion o= r by updating the draft. Document: draft-ietf-trill-ia-appsubtlv-07.txt Reviewer: Danny McPherson Review Date: May 4, 2016 Intended Status: Proposed Standard Summary: I have some minor concerns about this document that I think should be reso= lved before publication. Comments: I believe the draft is technically sound, however, the quality and readabil= ity needs a bit more work, particularly as it relates to introduction of new= terms, and consistent application and use of all terms. There are also som= e general error handling and encoding issues that need to be given considera= tion. Major Issues: I have no =E2=80=9CMajor=E2=80=9D issues with this I-D. Minor Issues: ERROR HANDLING: There are a number of places in the document where it discu= sses the receipt of malformed, badly encoded, non-matching, or corrupt messa= ges, and the advice is to either [silently] discard or ignore the messages. = Some general guidance should be given here to enable operational diagnosis = of any issues that may result in temporal or persistent problems, where logg= ing and other actions should occur. Some aspects of this might leverage the= OAM Framework efforts, although it appears much of the TRILL work leaves th= is to the implementer. When using =E2=80=9CNickname=E2=80=9D it would be useful to define the encoding as an u= nsigned 16-bit integer, or just reference "as specified in S 3.7 of RFC6325=E2= =80=9D. The inclusion of the =E2=80=9CTLV=E2=80=9D acronym in the "APPsub-TLV=E2=80=9D TLV name seems= loose and redundant to me, as opposed to =E2=80=9CAPPsub TLV=E2=80=9D or similar. Inconsistent use of =E2=80=9CInterface Address APPsub-TLV=E2=80=9D, =E2=80=9CIA APPSub-TLV=E2=80=9D= , =E2=80=9CInterface Address APP-subTLV=E2=80=9D, and =E2=80=9CAppsubTLV=E2=80=9D makes it seem like= you=E2=80=99re talking about different things. The use of =E2=80=9Csub-sub-TLV=E2=80=9D seems a bit loose and sloppy to me as well, an= d should be cleaned up. E.g., S 5.2 =E2=80=9CIA Appsub-TLV Sub-Sub-TLVs SubRegist= ry" Only one of the =E2=80=9CFigures=E2=80=9D is labeled / captioned The use of =E2=80=9CAddress Sets=E2=80=9D and =E2=80=9CAddress Sets Ends=E2=80=9D makes it a bit ha= rd to read when used in sentences. Perhaps an acronym for each, or hyphenat= ing/underscoring them would make it more readable. S 3.4 the 2-byte =E2=80=9CType=E2=80=9D value in the diagram should be =E2=80=9CTOPOLOGY=E2=80=9D, = not =E2=80=9CDATALEN=E2=80=9D. I noticed that Radia was a co-author until the last revision, and now she d= oesn=E2=80=99t even exist in the Acknowledgements section. While no explanation i= s required here, I did find this a bit odd. IANA Considerations: Some guidance from the IANA folks on the formatting of= this section might be in order. It=E2=80=99s not as clear as it could be about w= hat their instructions are here. S 2: It=E2=80=99s unclear to me if the =E2=80=9CConfidence=E2=80=9D value of 255 =E2=80=9Cbeing tre= ated as if it was 254=E2=80=9D is inline with RFC6325 S 4.8.1 guidance? In general, I agree there appear to be no new Security Considerations here.= I do not believe Asymmetry will be an issue with the forged packet discard= issue although some consideration of this might be in order (or perhaps sim= ply a reference to SAVI or other work here). I wonder if some consideration= should be given to broader disclosure of reachable layer 2 addresses here, = but that seems a bit reaching as well. Nits: Abstract & Introduction: s/by-pass/bypass/ S.2: s/Data Label is reachable from /Data Label are reachable/ A reference for the first use of AFN would be useful, perhaps to the IANA r= egistry. Expressing TBD code points in [ ] brackets might help with readability as w= ell S 3.2 =E2=80=9Cif the Length is 0 or 1 or less=E2=80=9D =E2=80=94 not sure the =E2=80=9Cor less" is= necessary? --B_3545202429_1026179878 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

H= ello,

I have been selected as the Routing Directorate reviewer for thi= s draft. The Routing Directorate seeks to review all routing or routing-rela= ted drafts as they pass through IETF last call and IESG review, and sometime= s 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 http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although thes= e comments are primarily for the use of the Routing ADs, it would be helpful= if you could consider them along with any other IETF Last Call comments tha= t you receive, and strive to resolve them through discussion or by updating = the draft.


Document: draft-ietf-trill-ia-appsubtlv-07.txt

Reviewer: Danny McPherson

Review Date: May 4, 2016

Intended= Status: Proposed Standard


Summary:

 I have some= minor concerns about this document that I think should be resolved before p= ublication.


Comments:

I believe the draft is technica= lly sound, however, the quality and readability needs a bit more work, parti= cularly as it relates to introduction of new terms, and consistent applicati= on and use of all terms.  There are also some general error handling an= d encoding issues that need to be given consideration.


Majo= r Issues:

I have no “Major” issues with this I-D.

Minor Issues:

  1. ERROR HANDLING: There are a number of plac= es in the document where it discusses the receipt of malformed, badly encode= d, non-matching, or corrupt messages, and the advice is to either [silently]= discard or ignore the messages.  Some general guidance should be given= here to enable operational diagnosis of any issues that may result in tempo= ral or persistent problems, where logging and other actions should occur. &n= bsp;Some aspects of this might leverage the OAM Framework efforts, although = it appears much of the TRILL work leaves this to the implementer.
  2. Wh= en using “Nickname” it would be useful to define the encoding as= an unsigned 16-bit integer, or just reference "as specified in S 3.7 of RFC= 6325”.
  3. The inclusion of the “TLV” acronym in the "= APPsub-TLV” TLV name seems loose and redundant to me, as opposed to &#= 8220;APPsub TLV” or similar.
  4. Inconsistent use of “Interf= ace Address APPsub-TLV”, “IA APPSub-TLV”, “Interface= Address APP-subTLV”, and “AppsubTLV” makes it seem like y= ou’re talking about different things.
  5. The use of “sub-su= b-TLV” seems a bit loose and sloppy to me as well, and should be clean= ed up.  E.g., S 5.2 “IA Appsub-TLV Sub-Sub-TLVs SubRegistry"
    6. =
  6. Only one of the “Figures” is labeled / captioned
  7. The= use of “Address Sets” and “Address Sets Ends” makes= it a bit hard to read when used in sentences.  Perhaps an acronym for = each, or hyphenating/underscoring them would make it more readable.
  8. = S 3.4 the 2-byte “Type” value in the diagram should be “TO= POLOGY”, not “DATALEN”.
  9. I noticed that Radia was a= co-author until the last revision, and now she doesn’t even exist in = the Acknowledgements section.  While no explanation is required here, I= did find this a bit odd.
  10. IANA Considerations: Some guidance from th= e IANA folks on the formatting of this section might be in order.  It&#= 8217;s not as clear as it could be about what their instructions are here.
  11. S 2: It’s unclear to me if the “Confidence” value o= f 255 “being treated as if it was 254” is inline with RFC6325 S = 4.8.1 guidance?
  12. In general, I agree there appear to be no new Securi= ty Considerations here.  I do not believe Asymmetry will be an issue wi= th the forged packet discard issue although some consideration of this might= be in order (or perhaps simply a reference to SAVI or other work here). &nb= sp;I wonder if some consideration should be given to broader disclosure of r= eachable layer 2 addresses here, but that seems a bit reaching as well.
    13. =


Nits:

  1. Abstract & Introduction: s/b= y-pass/bypass/
  2. S.2: s/Data Label is reachable from /Data Label are r= eachable/
  3. A reference for the first use of AFN would be useful, perh= aps to the IANA registry.
  4. Expressing TBD code points in [ ] brackets= might help with readability as well
  5. S 3.2 “if the Length is 0= or 1 or less” — not sure the “or less" is necessary?
    6. =
--B_3545202429_1026179878-- --B_3545202429_374183223 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUuwYJKoZIhvcNAQcCoIIUrDCCFKgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIKMIIHhTCCBm2gAwIBAgIQFboJA3Ne3xABo4oFnBRPRzANBgkqhkiG9w0BAQsFADCB yTELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQL ExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMTUwMwYDVQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJ IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTFDMEEGA1UEAxM6U3ltYW50ZWMgQ2xhc3MgMiBT aGFyZWQgSW50ZXJtZWRpYXRlIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0xNjAzMDUwMDAw MDBaFw0xNzAzMDUyMzU5NTlaMHQxJjAkBgkqhkiG9w0BCQEWF2RtY3BoZXJzb25AdmVyaXNp Z24uY29tMRkwFwYDVQQDDBBNY1BoZXJzb24sIERhbm55MRYwFAYDVQQLDA1FTlRFUlBSSVNF IElUMRcwFQYDVQQKDA5WZXJpU2lnbiwgSW5jLjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAKcc2QTeMzwlCGKDDL0OR2xd9UTw9Y1IClTsZq65x4ud+uHa7mx08QcdI8hgxsUj EAnOIpZwid1YgY/CucX223VNKbHw+Gmgg0LfYz3i0UYe+wgJn29Nl8Q/DqQ0X0iYtBWdCDYu CsOGSHfLK3a9z7IRXyWSVXLPv0AxSTV8teIAd8ZN0xNPqRSSk3EQMh1ajwoR6MzoGBip3g3O +ZvV0zZtScAn9nBG5bF5wqMio32pobroSM6Yl5iRkF3tNJrrcpJocISBJvNa+xvTenezWUFA HGYHnkz5hmxyNqSDWZ68mJnWlfJthbRCFKEnjH79qDYBi5Dc+CmvUmtpMBRAso0CAwEAAaOC A7swggO3MAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMBYGA1UdJQEB/wQMMAoGCCsG AQUFBwMEMB0GA1UdDgQWBBRWhUpoLXEQ8H0RYqrd1avCyQi5+TBQBgNVHREESTBHgRdkbWNw aGVyc29uQHZlcmlzaWduLmNvbaAsBgorBgEEAYI3FAIDoB4MHGRtY3BoZXJzb25AdmNvcnAu YWQudnJzbi5jb20wHwYDVR0jBBgwFoAU2EgpqF8qF5Li+p57729gg/i4uNwwggFxBggrBgEF BQcBAQSCAWMwggFfMCcGCCsGAQUFBzABhhtodHRwOi8vcGtpLW9jc3Auc3ltYXV0aC5jb20w ggEyBggrBgEFBQcwAoaCASRsZGFwOi8vZGlyZWN0b3J5LnZlcmlzaWduLmNvbS9DTiUyMCUz RCUyMFN5bWFudGVjJTIwQ2xhc3MlMjAyJTIwU2hhcmVkJTIwSW50ZXJtZWRpYXRlJTIwQ2Vy dGlmaWNhdGUlMjBBdXRob3JpdHklMkNPVSUyMCUzRCUyMENsYXNzJTIwMiUyME1hbmFnZWQl MjBQS0klMjBJbmRpdmlkdWFsJTIwU3Vic2NyaWJlciUyMENBJTJDT1UlMjAlM0QlMjBTeW1h bnRlYyUyMFRydXN0JTIwTmV0d29yayUyQ08lMjAlM0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0 aW9uJTJDQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQ oE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzA3YmI3ZDY0NzdjZjRmNmJlOTZh ZjFiMzZjYWJkMzE2L0xhdGVzdENSTC5jcmwwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXAjBS MCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAc GhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTBCBgkqhkiG9w0BCQ8ENTAzMAoGCCqGSIb3 DQMHMAsGCWCGSAFlAwQBAjALBglghkgBZQMEARYwCwYJYIZIAWUDBAEqMCwGCmCGSAGG+EUB EAMEHjAcBhJghkgBhvhFARABAgIBAYvxxgkWBjI0NzY2NDA5BgpghkgBhvhFARAFBCswKQIB ABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBCwUA A4IBAQAEQBbGHfK48sDK0jQ77RK2Tp+XaQ3w3G9380i3HsbEAQzcpO6JAjqt9//Tu1Ug5ELZ DbzBNfo1M0Ba89jgahs/tZZFA9itHQnTjGhhmtjiRx4ZRV1rmW377qlZTcYibBSibxDOhhK1 PAV01vjpbUnuDhq2PjrTvg8OKGFX8HUZ/It8RL18/VoKFhHxoFU0mFqZPFHfj67FbW4SK3++ 38NfVQ5fdGr3HxUvdqCwTeIIZt2RojWVenvCGfe+SBQyxtUViEXltry0hMnpYYUsJotAfKRP GfJGl5SD2n1BuReq8iHxLz2/EF9VCcJMdpHw34CUjuswpRl/eSXmwspWCyYIMIIGYDCCBUig AwIBAgIQdoXLB6jgzA/SxU2POTWzEjANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMTEwNjA3MDAwMDAwWhcNMjEwNjA2MjM1 OTU5WjCByTELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8w HQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMTUwMwYDVQQLEyxDbGFzcyAyIE1hbmFn ZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTFDMEEGA1UEAxM6U3ltYW50ZWMgQ2xh c3MgMiBTaGFyZWQgSW50ZXJtZWRpYXRlIENlcnRpZmljYXRlIEF1dGhvcml0eTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALf4PwwrgyMghaZNSQFROtrdUDO+4wSkOj6jYWZM NMLodHB1SaW3Sezds5Kc3XkN4rn6uDk8voXjjO9teaOmtwi/nEy+PpiOrNt8mivsBSgwXykb M01E1XDoViKZpj6dQlvrI6djnS0ssC4/GPMpzRo2iYSSx1dwW3CF5jihfFDjNziIZVtryzkq BLGCqhkE/6B/P6PbkUV2ZqNr84UjXk7ZhV11p6AV98EAdODlypRCZZrCN3qLqFCsv5d0Z3fR MqevjcuTqSVCtDAadAriJRAQy3RnVQ/LFPxBUAqkfE0LC/kFqTX5Racx8YC7osk+znY54Sr/ dlDn6FEi3y3PuDMCAwEAAaOCAj8wggI7MBIGA1UdEwEB/wQIMAYBAf8CAQAwNAYDVR0fBC0w KzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi1nMy5jcmwwDgYDVR0PAQH/ BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi01NjAdBgNV HQ4EFgQU2EgpqF8qF5Li+p57729gg/i4uNwwgfAGA1UdIwSB6DCB5aGB0KSBzTCByjELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBh dXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAyIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEGFwy0mMX5hFKeewptlQW3ow NAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w bAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXAjBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5 bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3Jw YTANBgkqhkiG9w0BAQUFAAOCAQEApiqbB0DJ7P+ziOhF2jTRFw8oLbelhWcxzcHm1SmGOKzi 8FkbDOGhRc4keO9pwbBMYaJI2WhPuv51VDe6WGnqwXalNkLqnmZ4kCDZlWokeVTN3loaijuu GJVy0CXY0ka+NDCngJ7xVs4gHmxnyU1PeYeJ4i6A1p7tJmFlogPQxeLzKLkrSWmCZ+zV6TSk LtxiIqSFTUjjagKU8s395GfISbyq1cfnPN6HsRBrXQdcGeRroPRPmcvctVsMzDL5auR0wCpY N3mz+83DNG/hdt0QBwBjiwdOJxeSR5sOvt4NE4UR/KIvZX3MOqweVGtWZ8TupYciIxcrcFbD 8a53XCfBOTCCBBkwggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEBBQUAMIHKMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9y IGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGlj IFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw05OTEwMDEwMDAwMDBa Fw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZl cmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8KDcLVLNtnuS3llCfdpb7g sE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8QzicTngVHmzF6E9gf 2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCbvO/DSD5GYCCF KtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDLHMQjPR+Z/kzo FmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23SrGY/lozghNQ2 /yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEANCYVPMCN TUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDzmN+k5qQx39Mc C0bcciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfORF3UG5CYDR5C lLEALATQdKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6uuNkSLB/+zYl 2pXQ8SQUF90YgGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I54bFD4CjPt+da bBNrSbP/4xh8iYszXawz16f52jpVyVgQ+arvWrbPS0vfKjGCAnUwggJxAgEBMIHeMIHJMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5 bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJl ZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AhAVugkDc17fEAGjigWcFE9H MA0GCWCGSAFlAwQCAQUAoGkwLwYJKoZIhvcNAQkEMSIEIG+vmqE+7X9EbfPiE1+C8dSv97fR Uhm/5zDy+vXxqmg8MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTE2MDUwNDE0MjcwOVowDQYJKoZIhvcNAQEBBQAEggEADGX6tSr0zqeJ4MDOYR2WpM3k4uBH 2lnlCaKdc9RZEzdy7luuv0wRzTRNgxxsmrxLK5Jg0xQx2YM0xXgG78taV71tr2lqaLoiK+iJ 5VBUCyKHEae48JrFU1GLGNXbECcividKXGGISPZt7Y7xvVuc7iz4pHrILV/VeA2GMt5xcqB1 /27MUTyBK+Qv1iF4Go2TGUMgeHQbvlZbkg9VNUdZYG8cM0cm0fDtuwf+VE/BThWfwS4ahWBz epSt7IDzxcFy829feSLkO1HMEt7iiIsLTqNLdBLPg35HH0EDXJ76nWeIHdlsLzwoHyDn43aD AqGQ9V8zP+/hXr0Fk1s1haSAvg== --B_3545202429_374183223-- From nobody Wed May 4 09:05:47 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9C912D992; Wed, 4 May 2016 09:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-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 zUAGMgQgh7Ni; Wed, 4 May 2016 09:05:34 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::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 68CDA12DAB8; Wed, 4 May 2016 08:57:54 -0700 (PDT) Received: by mail-ob0-x229.google.com with SMTP id x1so22814505obt.0; Wed, 04 May 2016 08:57:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=68tuZO4L8Lbn/BSZPvIh1isEkH8tyl0m0DIFzHlH5MQ=; b=xn7vxPS8fnCGy6I0vloOcW89aMvFSmU4i703w+jabrOsg+yaEADkV8kcVZCZ2Tv2Sv +XM1odDrs21W0qjcWOO8iwGL2ZUPztOPL5iMvZwqrUwYRGX0Je8BbSy9/38lDS5I3Cvu /YmjkaseQFiORCeLPVyoMbE/JhZGFIQN//7VCGy4vbN4Li9QhezRzHiU5AEcnosnPZXw KhvNebAqRxsxX3xYx4bEpr9dOYmFvBRXNMwqP812I9IPDsqRzeiyktDvMMRAAJlIydC7 uSnUuKxPO5SpKEXl7Tq1bk1p4Y0QEszYowJA/c+5IFfvf64dhcJSCQ07++7r47Mg7jxB WUxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=68tuZO4L8Lbn/BSZPvIh1isEkH8tyl0m0DIFzHlH5MQ=; b=QOwH0WPzui1zGgeJI/8MMK+hOe0jmw3wINY8KTH4WwJobP+Em6N2glqTKn0jTCBLTU oOfDoPtt38TyrmBSSEnB19vowCHeOwLlY+cL79EOOFtUfQDu64cYw391fBo8UFGNmyuE urW5JUy+nYnBLUUJ6bVBnRARmpppOwBCtC9SNkbWOeyamf5oVpgNBtYi9/iXsodXoanr ilD06YUB6dzCMS/HZyBGHSdN9nB3HDuHfLtwTPTBkW4FJ5ZEIqrxQYmW1uPMHx8EyoPz O0cVH+UUV6MCeYWVXfHc7kdyi1x/3+sUEO1EZ/bLVh1LyuuAW6GK/y4QIf3gz2v20+zQ Pm3A== X-Gm-Message-State: AOPr4FWLrln6J75wpJlf/NpFaodPbfMR05UUgE0kgOfBLcf9vzjMHefYntgdoes54vwGjaMhc7OPzMhWgCiGPA== X-Received: by 10.182.162.36 with SMTP id xx4mr4455637obb.74.1462377473807; Wed, 04 May 2016 08:57:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.216 with HTTP; Wed, 4 May 2016 08:57:39 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Wed, 4 May 2016 11:57:39 -0400 Message-ID: To: Jonathan Hardwick Content-Type: multipart/alternative; boundary=e89a8f83a4fbda98cf0532064991 Archived-At: Cc: " \(rtg-ads@ietf.org\)" , "rtg-dir@ietf.org" , "trill@ietf.org" , "draft-ietf-trill-channel-tunnel@ietf.org" , "akatlas@gmail.com" Subject: Re: [RTG-DIR] Routing directorate review of draft-ietf-trill-channel-tunnel X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 16:05:40 -0000 --e89a8f83a4fbda98cf0532064991 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jonathan, Thanks for agreeing that the suggested changes resolve our comments. I think they are pretty much editorial/clarification so I'll go ahead and post a revision incorporating them. Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Wed, May 4, 2016 at 7:29 AM, Jonathan Hardwick < Jonathan.Hardwick@metaswitch.com> wrote: > Hi Donald, > > Thanks for the replies - I agree with the changes you propose. Please se= e > discussion below (look for [JEH]). > > Best regards > Jon > > -----Original Message----- > From: Donald Eastlake [mailto:d3e3e3@gmail.com] > Sent: 01 May 2016 21:46 > To: Jonathan Hardwick > Cc: (rtg-ads@ietf.org) ; > akatlas@gmail.com; rtg-dir@ietf.org; > draft-ietf-trill-channel-tunnel@ietf.org; trill@ietf.org > Subject: Re: Routing directorate review of draft-ietf-trill-channel-tunne= l > > On Thu, Apr 28, 2016 at 9:26 AM, Jonathan Hardwick < > Jonathan.Hardwick@metaswitch.com> wrote: > > Hello, > > > > I have been selected as the Routing Directorate reviewer for this > > draft. The Routing Directorate seeks to review all routing or > > 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 > > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > > > Although these comments are primarily for the use of the Routing ADs, > > it would be helpful if you could consider them along with any other > > IETF Last Call comments that you receive, and strive to resolve them > > through discussion or by updating the draft. > > > > Best regards > > Jon > > =3D=3D=3D > > > > Document: draft-ietf-trill-channel-tunnel > > Reviewer: Jon Hardwick > > Review Date: 28 April 2016 > > Intended Status: Standards Track > > > > > > Summary > > > > I have some concerns about this document and recommend that the > > Routing ADs discuss these issues further with the authors. > > > > > > Comments > > > > The draft is overall well written and the specification is quite easy > > to understand, > > Thanks. > > > but I found some of the terminology and rationale > > to be confusing. I would prefer to see this clarified before the > > document is published as RFC. Note that this is the first TRILL > > document I=E2=80=99ve reviewed, so my context comes largely from mailin= g list > > searches and the shepherd=E2=80=99s report. > > > > > > Major Comments > > > > The motivations for this draft are quite obscure from the perspective > > of the outsider J which makes it hard for me to evaluate the proposed > > mechanism. > > > > I think the problems that the draft solves should be more clearly > > spelled out. From the introduction: > > > > This document updates [RFC7178] and specifies extensions to RBridge > > Channel that provide two additional facilities as follows: > > > > (1) A standard method to tunnel a variety of payload types by > > encapsulating them in an RBridge Channel message. > > > > (2) A method to provide security facilities for RBridge Channel > > messages. > > > > I think that number (1) requires more explanation because the RBridge > > channel already provides a standard method for a variety of payload > > types to be transmitted without needing the current draft. > > What tunneling capability is this draft adding? > > Good point. > > The RBridge Channel facility does provide a "protocol number" which is, i= n > essence, the "type" of its payload. However, there are three limitations = of > RBridge Channel: (1) No security; (2) No way to leverage the many existin= g > defined Ethertypes as a payload type; and > > [JEH] OK, now I understand (2), thank you. I thought maybe you'd allocat= e > Chanel protocol numbers to match Ethertypes as needed, though I now see > that this would be quite tedious process-wise (not to mention that > Ethertype has 4 additional bits). [/JEH] > > (3) RBridge Channel can only send typed messages either (3a) between > RBridges in a campus and (3b) between end stations and RBridges on the sa= me > link. Earlier versions of this draft included mechanisms extensions in ar= ea > 3, for example, for sending RBridge Channel messages between end stations > and RBridges not on the same link; however, this added significant > complexity and there appears to be no current need for such extensions so > they were dropped, leaving only extensions in areas 1 and 2. > > [JEH] OK. Number 3 does sound a bit more like tunnelling than 1 or 2. > Helps to have the history, thanks. [/JEH] > > How about the following change on additional facility 1 in the draft: > > OLD > (1) A standard method to tunnel a variety of payload types by > encapsulating them in an RBridge Channel message. > NEW > (1) A standard method to tunnel payloads whose type may be > indicated by Ethertype through encapsulation in RBridge Channe= l > messages. > > [JEH] Yes, looks good. [/JEH] > > > A significant amount of text in the draft discusses number (2), which > > secures the channel payload, presumably to cover cases where the > > payload has no in-built security mechanism. This appears to be the > > major purpose of the draft. The draft achieves number (2) by adding a > > security shim header between the RBridge channel header and the > > payload. One consideration in doing this is to remain backwards > > compatible with RFC 7178, and it looks like the working group has > > decided to achieve backwards compatibility by defining a new RBridge > > channel protocol type called =E2=80=9Cchannel tunnel=E2=80=9D =E2=80=93= where this effectively > > means the RBridge channel payload contains an additional security shim > > which in turn contains an identifier that determines the real payload > > protocol type. > > > > I find the term =E2=80=9Cchannel tunnel=E2=80=9D misleading, as the dra= ft does not > > appear to add any additional tunnelling capability above and beyond > > the tunnelling that can already be done using RFC 7178. The draft > > actually describes an RBridge channel with enhanced security, so a > > term like =E2=80=9Csecure channel=E2=80=9D would make more sense to me = than =E2=80=9Cchannel > > tunnel=E2=80=9D. > > OK, I understand why you think that term is misleading. While it seems > quite reasonable to called the added fields a "shim", note that the > facility currently called "Channel Tunnel" is quite closely integrated wi= th > the existing RFC 7178 RBridge Channel facility. For example, there is onl= y > one error reporting mechanism. Errors in the "Channel Tunnel" facility > added by this draft are reported as if they were errors in the RBridge > Channel messages to which the "shim" was added. > > I don't actually like your suggestion of "secure channel" as a new name. > How about re-naming the facility being added by this draft as the "RBridg= e > Channel Header Extension"? > > [JEH] OK, I like RBridge Channel Header Extension. [/JEH] > > I believe that RFC 7783 and only that RFC that references this draft usin= g > the term "Channel Tunnel" but this is a very minor informational passing > reference. There are drafts in the publication requested state that > reference this draft using the term "Channel Tunnel" but it seems that it > would be relatively straightforward to change the name to "RBridge Channe= l > Header Extension" or some other new name in those drafts and even easier = to > change it in drafts still under the control of the TRILL WG. > > [JEH] Thanks, this works for me. [/JEH] > > > Minor Comments > > > > Section 3.1 =E2=80=93 =E2=80=9CAny particular use of the Null Payload s= hould specify > > what VLAN or priority should be used when relevant.=E2=80=9D =E2=80=93 = is unclear and > > no context for this statement is given. Should be used by what and > > for what purpose? > > OK. How about: > > Any particular use of the Null Payload should specify what VLAN or > FGL and what priority should be used in the inner data label of the > RBridge Channel message (or in an outer VLAN tag for the native > RBridge Channel message case) when those values are relevant. > > [JEH] Fine [/JEH] > > > Section 4.3 feels like a corollary to section 4.5 and so may be better > > placed as a subsection of 4.5. > > The method of deriving keying material given in Section 4.3 is also used > in DTLS security as mentioned in Section 4.6 so I think it should remain = a > separate section. > > [JEH] OK [/JEH] > > > Section 4.6 =E2=80=9CThe PType indicates the nature of the application_= data.=E2=80=9D > > - is potentially open to misinterpretation. At face value it sounds > > like you are leaking some potentially sensitive information about the > > =E2=80=9Cnature=E2=80=9D of the encrypted payload. I think all you are= actually > > saying is that it indicates whether the payload is an Ethertype, an > > Ethernet frame etc. Suggest instead =E2=80=9CIn this case, the PType v= alue in > > the RBridge Channel Tunnel Protocol Specific Data applies to the > > decrypted application_data.=E2=80=9D > > OK. > > > Section 5.2 =E2=80=9Cwith a payload type (PType) indicating a nested RB= ridge > > Channel message=E2=80=9D =E2=80=93 strictly all the PType can indicate = is that the > > payload is Ethertyped; on its own it cannot indicate a nested RBridge > > Chanel message. Suggest =E2=80=9Cand it contains a nested RBridge Chan= el > > message=E2=80=9D. > > OK. > > > Section 6.2 > > > > =E2=80=9CSection xxx of [RFC 7178]=E2=80=9D should be =E2=80=9CSection = 3.2 of [RFC 7178]=E2=80=9D. > > Right. Sorry about that. > > > Don=E2=80=99t you also need a new IANA registry for the =E2=80=9CRbridg= e Channel Error > > Subcodes=E2=80=9D listed in table 5.2? > > My opinion is that, for the first document in which you specify a field > and some values, it is a judgment call whether you should create an IANA > registry or not. If you expect multiple groups to start requesting value= s > to multiple purposes, then creating a registry from the start is the way = to > go. On the other hand, if a field is internal to a particular protocol an= d > you don't expect any new field values to be assigned until there is a > significant extension of that protocol, I don't see any problem in > deferring the registry creation to the second document. This is the secon= d > document assigning values for RBridge Channel Error Codes so it creates a > registry for them. It does not create a registry for SubERR field values. > > [JEH] OK, just checking, and happy to defer to your judgment here. [/JEH] > > > Nits > > > > Section 3.2 > > > > =E2=80=9Cas describe in=E2=80=9D -> =E2=80=9Cas described in=E2=80=9D > > OK. > > > Section 4 > > > > =E2=80=9Cnot to met=E2=80=9D -> =E2=80=9Cnot to meet=E2=80=9D > > OK. > > > 2nd paragraph =E2=80=93 this sentence is quite long and hard to parse. > > You're right. Looking at the sentence, it seems fairly easy to simplify > and split into two sentences. How about the following > replacement: > > The Channel Tunnel DTLS based security specified in Section 4.6 > below is intended for pairwise (known unicast) use. That is, the > case where the M bit in the TRILL Header is zero and any > Outer.MacDA is individually addressed. > > [JEH] Looks good. [/JEH] > > > Section 4.2 & Section 5.1 > > > > =E2=80=9CAs show in=E2=80=9D - > =E2=80=9CAs shown in=E2=80=9D > > OK. > > > Section 4.3 > > > > =E2=80=9CThe use Derived Material=E2=80=9D -> =E2=80=9CThe use of the D= erived Material=E2=80=9D > > OK. > > > Does Derived Material really need to be capitalized in this section? > > Well, it is capitalized in the equation. Seems to me reasonable to > capitalize in both cases to indicate that a specific type of Derived > Material is being talked about. > > [JEH] OK. [/JEH] > > > Section 4.5 > > > > =E2=80=9Ccan reasonable be=E2=80=9D -> =E2=80=9Ccan reasonably be=E2=80= =9D > > OK. > > > Section 4.6 > > > > =E2=80=9Cminimum MTU Sz=E2=80=9D -> =E2=80=9Cminimum MTU size=E2=80=9D > > Sz is a standard TRILL symbol widely used in TRILL documents and defined > in Section 1.1 of this draft. I would prefer to make the following change > in Section 4.6: "the TRILL campus wide minimum MTU Sz" -> "Sz". > > [JEH] OK - sorry, I missed the definition! [/JEH] > > > =E2=80=9CActual application_data sent with Channel Tunnel=E2=80=9D -> = =E2=80=9CActual > > application_data sent within the Channel Tunnel=E2=80=9D > > OK. > > > Why do you say =E2=80=9Capplication_data=E2=80=9D not =E2=80=9Capplicat= ion data=E2=80=9D? > > "application_data" is the name of the field type in DTLS. > > [JEH] OK. [/JEH] > > > Appendix Z should presumably be removed prior to IETF last call. > > While I'm not sure how much help it would be to IESG members or IETF > participants in reviewing the draft, I don't see any reason for Appendix = Z > to be removed until RFC publication. But at least a notation asked the RF= C > Editor to delete it should be added. > > [JEH] OK - please add the RFC editor note. [/JEH] > > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > --e89a8f83a4fbda98cf0532064991 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jonathan,

Thanks for agreeing that t= he suggested changes resolve our comments.=C2=A0 I think they are pretty mu= ch editorial/clarification so I'll go ahead and post a revision incorpo= rating them.

Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donald E. E= astlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Milfo= rd, MA 01757 USA
=C2=A0d3e3e3@gmail.com

On Wed, May 4, 2016 at 7:29 AM, Jonathan Har= dwick <Jonathan.Hardwick@metaswitch.com> wrot= e:
Hi Donald,

Thanks for the replies - I agree with the changes you propose.=C2=A0 Please= see discussion below (look for [JEH]).

Best regards
Jon

-----Original Message-----
From: Donald Eastlake [mailto:d3e3e3@gm= ail.com]
Sent: 01 May 2016 21:46
To: Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>
Cc: <rtg-ads@ietf.org> (rtg-ads@ietf.org) <rtg-ads@ietf.org>; akatlas@gmail.com; rtg-dir@ie= tf.org; dra= ft-ietf-trill-channel-tunnel@ietf.org; trill@ietf.org
Subject: Re: Routing directorate review of draft-ietf-trill-channel-tunnel<= br>
On Thu, Apr 28, 2016 at 9:26 AM, Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com> wr= ote:
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this
> draft. The Routing Directorate seeks to review all routing or
> 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
> http://trac.tools.ietf.org/area/rtg/trac/= wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs,<= br> > it would be helpful if you could consider them along with any other > IETF Last Call comments that you receive, and strive to resolve them > through discussion or by updating the draft.
>
> Best regards
> Jon
> =3D=3D=3D
>
> Document: draft-ietf-trill-channel-tunnel
> Reviewer: Jon Hardwick
> Review Date: 28 April 2016
> Intended Status: Standards Track
>
>
> Summary
>
> I have some concerns about this document and recommend that the
> Routing ADs discuss these issues further with the authors.
>
>
> Comments
>
> The draft is overall well written and the specification is quite easy<= br> > to understand,

Thanks.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 but I found some of the terminology and rationale
> to be confusing.=C2=A0 I would prefer to see this clarified before the=
> document is published as RFC.=C2=A0 Note that this is the first TRILL<= br> > document I=E2=80=99ve reviewed, so my context comes largely from maili= ng list
> searches and the shepherd=E2=80=99s report.
>
>
> Major Comments
>
> The motivations for this draft are quite obscure from the perspective<= br> > of the outsider J which makes it hard for me to evaluate the proposed<= br> > mechanism.
>
> I think the problems that the draft solves should be more clearly
> spelled out.=C2=A0 From the introduction:
>
>=C2=A0 =C2=A0 This document updates [RFC7178] and specifies extensions = to RBridge
>=C2=A0 =C2=A0 Channel that provide two additional facilities as follows= :
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(1) A standard method to tunnel a variety of= payload types by
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0encapsulating them in an RBrid= ge Channel message.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(2) A method to provide security facilities = for RBridge Channel
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0messages.
>
> I think that number (1) requires more explanation because the RBridge<= br> > channel already provides a standard method for a variety of payload > types to be transmitted without needing the current draft.
> What tunneling capability is this draft adding?

Good point.

The RBridge Channel facility does provide a "protocol number" whi= ch is, in essence, the "type" of its payload. However, there are = three limitations of RBridge Channel: (1) No security; (2) No way to levera= ge the many existing defined Ethertypes as a payload type; and

[JEH] OK, now I understand (2), thank you.=C2=A0 I thought mayb= e you'd allocate Chanel protocol numbers to match Ethertypes as needed,= though I now see that this would be quite tedious process-wise (not to men= tion that Ethertype has 4 additional bits). [/JEH]

(3) RBridge Channel can only send typed messages either (3a) between RBridg= es in a campus and (3b) between end stations and RBridges on the same link.= Earlier versions of this draft included mechanisms extensions in area 3, f= or example, for sending RBridge Channel messages between end stations and R= Bridges not on the same link; however, this added significant complexity an= d there appears to be no current need for such extensions so they were drop= ped, leaving only extensions in areas 1 and 2.

[JEH] OK.=C2=A0 Number 3 does sound a bit more like tunnelling than = 1 or 2.=C2=A0 Helps to have the history, thanks. [/JEH]

How about the following change on additional facility 1 in the draft:

OLD
=C2=A0 =C2=A0 =C2=A0 (1) A standard method to tunnel a variety of payload t= ypes by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 encapsulating them in an RBridge Channel= message.
NEW
=C2=A0 =C2=A0 =C2=A0 (1) A standard method to tunnel payloads whose type ma= y be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 indicated by Ethertype through encapsula= tion in RBridge=C2=A0 Channel messages.

[JEH] Yes, looks good. [/JEH]

> A significant amount of text in the draft discusses number (2), which<= br> > secures the channel payload, presumably to cover cases where the
> payload has no in-built security mechanism.=C2=A0 This appears to be t= he
> major purpose of the draft.=C2=A0 The draft achieves number (2) by add= ing a
> security shim header between the RBridge channel header and the
> payload.=C2=A0 One consideration in doing this is to remain backwards<= br> > compatible with RFC 7178, and it looks like the working group has
> decided to achieve backwards compatibility by defining a new RBridge > channel protocol type called =E2=80=9Cchannel tunnel=E2=80=9D =E2=80= =93 where this effectively
> means the RBridge channel payload contains an additional security shim=
> which in turn contains an identifier that determines the real payload<= br> > protocol type.
>
> I find the term =E2=80=9Cchannel tunnel=E2=80=9D misleading, as the dr= aft does not
> appear to add any additional tunnelling capability above and beyond > the tunnelling that can already be done using RFC 7178.=C2=A0 The draf= t
> actually describes an RBridge channel with enhanced security, so a
> term like =E2=80=9Csecure channel=E2=80=9D would make more sense to me= than =E2=80=9Cchannel
> tunnel=E2=80=9D.

OK, I understand why you think that term is misleading. While it seems quit= e reasonable to called the added fields a "shim", note that the f= acility currently called "Channel Tunnel" is quite closely integr= ated with the existing RFC 7178 RBridge Channel facility. For example, ther= e is only one error reporting mechanism. Errors in the "Channel Tunnel= " facility added by this draft are reported as if they were errors in = the RBridge Channel messages to which the "shim" was added.

I don't actually like your suggestion of "secure channel" as = a new name.=C2=A0 How about re-naming the facility being added by this draf= t as the "RBridge Channel Header Extension"?

[JEH] OK, I like RBridge Channel Header Extension. [/JEH]

I believe that RFC 7783 and only that RFC that references this draft using = the term "Channel Tunnel" but this is a very minor informational = passing reference. There are drafts in the publication requested state that= reference this draft using the term "Channel Tunnel" but it seem= s that it would be relatively straightforward to change the name to "R= Bridge Channel Header Extension" or some other new name in those draft= s and even easier to change it in drafts still under the control of the TRI= LL WG.

[JEH] Thanks, this works for me. [/JEH]

> Minor Comments
>
> Section 3.1 =E2=80=93 =E2=80=9CAny particular use of the Null Payload = should specify
> what VLAN or priority should be used when relevant.=E2=80=9D =E2=80=93= is unclear and
> no context for this statement is given.=C2=A0 Should be used by what a= nd
> for what purpose?

OK. How about:

=C2=A0 =C2=A0Any particular use of the Null Payload should specify what VLA= N or
=C2=A0 =C2=A0FGL and what priority should be used in the inner data label o= f the
=C2=A0 =C2=A0RBridge Channel message (or in an outer VLAN tag for the nativ= e
=C2=A0 =C2=A0RBridge Channel message case) when those values are relevant.<= br>
[JEH] Fine [/JEH]

> Section 4.3 feels like a corollary to section 4.5 and so may be better=
> placed as a subsection of 4.5.

The method of deriving keying material given in Section 4.3 is also used in= DTLS security as mentioned in Section 4.6 so I think it should remain a se= parate section.

[JEH] OK [/JEH]

> Section 4.6 =E2=80=9CThe PType indicates the nature of the application= _data.=E2=80=9D
> - is potentially open to misinterpretation.=C2=A0 At face value it sou= nds
> like you are leaking some potentially sensitive information about the<= br> > =E2=80=9Cnature=E2=80=9D of the encrypted payload.=C2=A0 I think all y= ou are actually
> saying is that it indicates whether the payload is an Ethertype, an > Ethernet frame etc.=C2=A0 Suggest instead =E2=80=9CIn this case, the P= Type value in
> the RBridge Channel Tunnel Protocol Specific Data applies to the
> decrypted application_data.=E2=80=9D

OK.

> Section 5.2 =E2=80=9Cwith a payload type (PType) indicating a nested R= Bridge
> Channel message=E2=80=9D =E2=80=93 strictly all the PType can indicate= is that the
> payload is Ethertyped; on its own it cannot indicate a nested RBridge<= br> > Chanel message.=C2=A0 Suggest =E2=80=9Cand it contains a nested RBridg= e Chanel
> message=E2=80=9D.

OK.

> Section 6.2
>
> =E2=80=9CSection xxx of [RFC 7178]=E2=80=9D should be =E2=80=9CSection= 3.2 of [RFC 7178]=E2=80=9D.

Right. Sorry about that.

> Don=E2=80=99t you also need a new IANA registry for the =E2=80=9CRbrid= ge Channel Error
> Subcodes=E2=80=9D listed in table 5.2?

My opinion is that, for the first document in which you specify a field and= some values, it is a judgment call whether you should create an IANA regis= try or not.=C2=A0 If you expect multiple groups to start requesting values = to multiple purposes, then creating a registry from the start is the way to= go. On the other hand, if a field is internal to a particular protocol and= you don't expect any new field values to be assigned until there is a = significant extension of that protocol, I don't see any problem in defe= rring the registry creation to the second document. This is the second docu= ment assigning values for RBridge Channel Error Codes so it creates a regis= try for them. It does not create a registry for SubERR field values.

[JEH] OK, just checking, and happy to defer to your judgment here. [= /JEH]

> Nits
>
> Section 3.2
>
> =E2=80=9Cas describe in=E2=80=9D -> =E2=80=9Cas described in=E2=80= =9D

OK.

> Section 4
>
> =E2=80=9Cnot to met=E2=80=9D -> =E2=80=9Cnot to meet=E2=80=9D

OK.

> 2nd paragraph =E2=80=93 this sentence is quite long and hard to parse.=

You're right. Looking at the sentence, it seems fairly easy to simplify= and split into two sentences. How about the following
replacement:

=C2=A0 =C2=A0The Channel Tunnel DTLS based security specified in Section 4.= 6
=C2=A0 =C2=A0below is intended for pairwise (known unicast) use. That is, t= he
=C2=A0 =C2=A0case where the M bit in the TRILL Header is zero and any
=C2=A0 =C2=A0Outer.MacDA is individually addressed.

[JEH] Looks good. [/JEH]

> Section 4.2 & Section 5.1
>
> =E2=80=9CAs show in=E2=80=9D - > =E2=80=9CAs shown in=E2=80=9D

OK.

> Section 4.3
>
> =E2=80=9CThe use Derived Material=E2=80=9D -> =E2=80=9CThe use of t= he Derived Material=E2=80=9D

OK.

> Does Derived Material really need to be capitalized in this section?
Well, it is capitalized in the equation. Seems to me reasonable to capitali= ze in both cases to indicate that a specific type of Derived Material is be= ing talked about.

[JEH] OK. [/JEH]

> Section 4.5
>
> =E2=80=9Ccan reasonable be=E2=80=9D -> =E2=80=9Ccan reasonably be= =E2=80=9D

OK.

> Section 4.6
>
> =E2=80=9Cminimum MTU Sz=E2=80=9D -> =E2=80=9Cminimum MTU size=E2=80= =9D

Sz is a standard TRILL symbol widely used in TRILL documents and defined in= Section 1.1 of this draft. I would prefer to make the following change in = Section 4.6: "the TRILL campus wide minimum MTU Sz" -> "S= z".

[JEH] OK - sorry, I missed the definition! [/JEH]

> =E2=80=9CActual application_data sent with Channel Tunnel=E2=80=9D -&g= t; =E2=80=9CActual
> application_data sent within the Channel Tunnel=E2=80=9D

OK.

> Why do you say =E2=80=9Capplication_data=E2=80=9D not =E2=80=9Capplica= tion data=E2=80=9D?

"application_data" is the name of the field type in DTLS.

[JEH] OK. [/JEH]

> Appendix Z should presumably be removed prior to IETF last call.

While I'm not sure how much help it would be to IESG members or IETF pa= rticipants in reviewing the draft, I don't see any reason for Appendix = Z to be removed until RFC publication. But at least a notation asked the RF= C Editor to delete it should be added.

[JEH] OK - please add the RFC editor note. [/JEH]

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd=C2=A0 =C2=A0+1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Milford, MA 01757 USA=C2=A0 d3e3e3@gmail.com

--e89a8f83a4fbda98cf0532064991-- From nobody Wed May 4 16:25:27 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5152D12D87C; Wed, 4 May 2016 16:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 YhOyLDyQHlND; Wed, 4 May 2016 16:24:55 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9511A12D956; Wed, 4 May 2016 16:24:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10351; q=dns/txt; s=iport; t=1462404294; x=1463613894; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HmksQ4TU7UouNx5MsQyoOVPGNU5tuVs3Rz0BEyiLfYM=; b=Rx5Goz+FPiG1PE3RVVWnYmZ2zbymkL/UfDFn82rcd7Dz0Jv1Ecs2XgQb 6cTLbovoNIDJtPxCmFW2X4zv/0j4pW64XiDf72De0uBwM5qWTH64Tqxnv ovOCiXIrlAVYnOcMPJiOVaPnpzEKHeEKiG4ScjHGfFj9Bfk1eSwIXIdOE 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BCAwBvgypX/4oNJK1WAQeDOFN9AQW5Z?= =?us-ascii?q?QENgXYihW4CgTc4FAEBAQEBAQFlJ4RBAQEBAwE6LQsCBQULAgEIFAEPAREQMiU?= =?us-ascii?q?CBA4DCgyIDggOvgIBAQEBAQEBAQEBAQEBAQEBAQEBF4Ygg0mBA4QbAg+FbAWTJ?= =?us-ascii?q?IR1AYV7iBWBb06Df4hehiaJDQEeAQFCg2s/LocbAh4DBBh/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,579,1454976000"; d="scan'208";a="104676224" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 May 2016 23:24:53 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u44NOrY2028136 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 May 2016 23:24:53 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 May 2016 19:24:51 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1104.009; Wed, 4 May 2016 19:24:52 -0400 From: "Eric Voit (evoit)" To: Dan Frost Thread-Topic: RtgDir review: draft-ietf-i2rs-pub-sub-requirements-06 Thread-Index: AQHRnwwwp5NeJzUz10S3mqOVd9uHg5+pN74g Date: Wed, 4 May 2016 23:24:51 +0000 Message-ID: <97eeb138efbf4b86b05065391fd0a71f@XCH-RTP-013.cisco.com> References: <1461600259.1868989.588979393.728AD1A2@webmail.messagingengine.com> In-Reply-To: <1461600259.1868989.588979393.728AD1A2@webmail.messagingengine.com> 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.118.56.228] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-i2rs-pub-sub-requirements.all@ietf.org" , "i2rs@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-i2rs-pub-sub-requirements-06 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 23:24:58 -0000 Hi Dan, Thanks for the excellent comments. In-line below are what has been done f= or each of these... > From: Dan Frost, April 25, 2016 12:04 PM >=20 > Hello, >=20 > I have been selected as the Routing Directorate reviewer for this draft. = The > Routing Directorate seeks to review all routing or routing-related drafts= as they > pass through IETF last call and IESG review, and sometimes on special req= uest. > The purpose of the review is to provide assistance to the Routing ADs. Fo= r more > information about the Routing Directorate, please see > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >=20 > Although these comments are primarily for the use of the Routing ADs, it = would > be helpful if you could consider them along with any other IETF Last Call > comments that you receive, and strive to resolve them through discussion = or by > updating the draft. >=20 > Document: draft-ietf-i2rs-pub-sub-requirements-06 > Reviewer: Dan Frost > Review Date: 2016-04-25 > IETF LC End Date: 2016-04-29 > Intended Status: Informational (?) >=20 > Summary: >=20 > I have significant concerns about this document and recommend that the > Routing ADs discuss these issues further with the authors. >=20 > Comments: >=20 > Overall this is a clear and consistent requirements document that address= es an > important real-world problem domain, and is nearly ready for publication. > However, because this work may lead to significant changes in the mechani= cs of > network management and control, some extra care in the review stage is > warranted. I've marked some issues as major to indicate that they may de= serve > extra consideration by the ADs and/or the wider Internet community. >=20 >=20 > Major Issues: >=20 > 1. There seems to be some confusion as to the intended status of the docu= ment. > The draft itself lists its intended status as Informational, which is usu= ally > appropriate for a requirements document. On the other hand, the draft wa= s > submitted to the IESG with an Intended Status of Proposed Standard. > Furthermore, a quick check of other I2RS WG requirements docs shows them > split between Informational and Proposed Standard, so the confusion may > extend beyond this draft. I'd suggest the ADs and chairs agree on a cons= istent > policy. Fixed=20 > 2. The document concerns requirements for a publish/subscribe interface t= o, > among other things, real-time operational data. The text in Section > 2.3 indicates an awareness of the need to support potentially large numbe= rs of > subscribers and high volumes of data. However, the document doesn't seem= to > discuss the global network impact of continuously pushing a lot of data t= o many > subscribers. > > As the introduction of such a push system could lead to a qualitative shi= ft in the > total volume of management/control traffic, it seems important to begin > addressing this issue at the requirements stage. > > A possible resolution would be to add a brief section on network impact u= nder > large-scale conditions, and/or a set of requirements for minimizing this = impact. > Some of the listed requirements are germane to this, e.g. subscription fi= lters. > bundling, and dampening. Issues that are not addressed include support f= or > encoding formats that are efficient for high-volume transport and process= ing > (XML and JSON are usually considered not to be); appropriate selection of > transport protocols and features according to scale/use-case; and support= for > mechanisms to determine or restrict the bandwidth cost of a proposed or > ongoing subscription. Good point. We do have some relevant requirements as there are mechanisms = to: - Allow/deny/negotiate subscriptions so as not to overwhelm resources. Thi= s could include negotiation of the encoding and filters. See Section 4.2.2 - Notify subscribers that push updates are being suspended/resumed But there could be more. For example, there should be the ability of prior= itize some subscriptions over others for de-queuing towards recipients Therefore the new draft version '07' adds a Relative Prioritization section= 4.2.6.8 and requirements to ensure limited bandwidth environments are addr= essed. > 3. This work is being carried out in the I2RS WG, but the first sentence = of Section > 2.2 states that this document is intended to cover requirements beyond I2= RS. A > general question for the editors/chairs/ADs is whether it has received an= y review > by interested/affected parties outside I2RS? >=20 > 4. The Security Requirements make no mention of data integrity or > confidentiality. This is a potentially serious omission in today's netwo= rk > environment. I would expect at the least that subscribers have the abili= ty to > request a secure (authenticated, integrity-verified, > confidential) session, that publishers likewise have the ability to refus= e non- > secure sessions, and that the security status of a session is explicitly = signaled and > checked by both parties during negotiation. With subscriptions signaled in-band, any pushed updates will rely on the un= derlying transport layer protocols to ensure integrity and confidentiality.= This provides the same level of security as a traditional "GET". =20 >=20 > Minor Issues: >=20 > 1. The requirements in this document ought to be numbered for ease of > reference. Hoping to avoid this :-) =20 > 2. Section 3: > As this is a requirements doc, the RFC 2119 language paragraph could use = a > clarification sentence along the lines of the one in Section 1.1 of RFC 5= 654. Added=20 =20 > 3. Section 3: > It's not obvious to me from the text in this section what the distinction= and > intended relationship is between Receivers and Subscribers. Perhaps this= can be > clarified with an example? Also the statement "In general, the Receiver = and > Subscriber will be the same entity" doesn't sound right -- maybe you mean= t that > in general they can be different, but usually they will be the same? That is what is meant. =20 > 4. Section 3, last sentence: > What is the difference between the terms "previous Push" and "last Update= " > used in this sentence? Agree this was confusing. In fact it included a requirement in the definiti= on. Extracted this text in the -07 version, and added a reworded requireme= nt to section 4.2.7. > 5. Section 4.2.3, last paragraph: > This paragraph would be more useful if it explained what a persistence/re= play > capability was and how it might work. Updated text =20 > 6. Can a definition or reference be provided for the term "object propert= y" as > used in Sections 3 and 4.2.7? This terminology seems slightly different = from that > used in RFC 6020. I can see where people might get confused. I tweaked the text to better m= atch what can be seen with RFC6241 filtering. =20 > 7. Section 4.2.4: > What is the purpose of stating that a subscription service should support > "different" transports and encodings? This sounds too vague to be useful= . > Choice of transport and encoding are of great practical importance, but t= he > document has almost nothing to say on these topics. > Can the authors not provide a summary of options and some definite guidan= ce > here? This is tough. There are proposals for transports of NETCONF, RESTCONF, HT= TP, and HTTP2 in technology drafts. Other people have suggested COAP and = IPFIX. Some people want non-IETF transports like gRPC. We really don't w= ant to take a position. =20 > 8. Section 4.2.5, third paragraph: > Can you spell out in the document exactly what "Versioning" means here? Updated =20 > 9. When the underlying transport provides some form of security, should t= here > not be a requirement for alignment between transport security and pub/sub > protocol security? Can, for example, TLS certificate validation fulfil t= he pub/sub > authentication requirement? These requirements explore the security requirements for control plane mess= aging, anticipating that the data plane will be locked down as would a trad= itional "GET" for the same information. This is why in the Security requir= ements talk about filtering based on whatever mechanisms would in place for= a "GET" using that specific transport. I.e., we are attempting equivalenc= e for "GET" rather than new incremental mechanisms with perhaps different b= ehavior. > 10. An important use-case for such a pub/sub update service is a subscrib= er that > wants to maintain an up-to-date local copy of a datastore residing on the > publisher. This requires the ability to correlate the version of the dat= astore > obtained via an out-of-band full download with the version reflected by e= ach > published update. Do the authors intend to allow for this case, and have= they > considered the associated requirements? Yes. In summary, you can get deltas via on-change. And when you want to = ensure you haven't lost something, you can do a GET against any objects whe= re the remote datastore houses the primary copy. =20 >=20 > Nits: >=20 > Section 2.2, first paragraph: > - s/Switches and Routers/switches and routers/ > - s/past subscriptions includes/past subscription mechanisms includes/ Fixed =20 > Section 2.2, last paragraph: > - s/NETCONF should the/NETCONF should be the/ > - s/support Multicast and Broadcast/support for multicast and broadcast/ Fixed =20 > Section 3, 8th paragraph: > - s/referred in/referred to in/ > Section 3, 9th paragraph: > - s/which have been made/that have been made/ Section 3, last paragraph: > - s/propert(ies)/properties/ Fixed > - s/different that/different than that/ Couldn't find that one =20 > Section 4, first paragraph: > - s/morphed/adapted/ fixed =20 > Section 4.1, last paragraph: > - s/lease a Subscription/lease of a Subscription/ Fixed > Section 4.2.1, second and third paragraphs: > These two requirements seem to make more sense if "one or more" is replac= ed > by "multiple". Fixed > Section 4.2.8, third paragraph: > - s/us a failure/is a failure/ Fixed Eric >=20 > Cheers, > -d From nobody Thu May 5 03:03:48 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6DB12D579; Thu, 5 May 2016 03:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] 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 E8NZBYf4wjyR; Thu, 5 May 2016 03:03:44 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 0654912D570; Thu, 5 May 2016 03:03:43 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.238; From: "Susan Hares" To: "'Eric Voit \(evoit\)'" , "'Dan Frost'" References: <1461600259.1868989.588979393.728AD1A2@webmail.messagingengine.com> <97eeb138efbf4b86b05065391fd0a71f@XCH-RTP-013.cisco.com> In-Reply-To: <97eeb138efbf4b86b05065391fd0a71f@XCH-RTP-013.cisco.com> Date: Thu, 5 May 2016 06:03:47 -0400 Message-ID: <06fc01d1a6b5$6b417b80$41c47280$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGlXuo2JX8PXEdKa+QuqVobYuqg+AJ3++tfn+7rVBA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, draft-ietf-i2rs-pub-sub-requirements.all@ietf.org, i2rs@ietf.org Subject: Re: [RTG-DIR] [i2rs] RtgDir review: draft-ietf-i2rs-pub-sub-requirements-06 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 10:03:46 -0000 Dan: Regarding your major comments: Comment on #1 - The ADs agreed on informational after WG LC did standards. It is fixed to informational now. Comment on #2 - Has Eric's comment addressed your questions? Comment on #3 - NETCONF has adopted push mechanism. What other parties are you concerned about? Comment on #4 - Please see the security requirements for the I2RS protocol: https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requireme nts https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment-reqs/ These documents provide requirement for data integrity, confidentiality, protection against replay attacks, and DDoS. Do you feel you major comments have been addressed? Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Eric Voit (evoit) Sent: Wednesday, May 04, 2016 7:25 PM To: Dan Frost Cc: rtg-ads@ietf.org; rtg-dir@ietf.org; draft-ietf-i2rs-pub-sub-requirements.all@ietf.org; i2rs@ietf.org Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-pub-sub-requirements-06 Hi Dan, Thanks for the excellent comments. In-line below are what has been done for each of these... > From: Dan Frost, April 25, 2016 12:04 PM > > Hello, > > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > 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 > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, > it would be helpful if you could consider them along with any other > IETF Last Call comments that you receive, and strive to resolve them > through discussion or by updating the draft. > > Document: draft-ietf-i2rs-pub-sub-requirements-06 > Reviewer: Dan Frost > Review Date: 2016-04-25 > IETF LC End Date: 2016-04-29 > Intended Status: Informational (?) > > Summary: > > I have significant concerns about this document and recommend that the > Routing ADs discuss these issues further with the authors. > > Comments: > > Overall this is a clear and consistent requirements document that > addresses an important real-world problem domain, and is nearly ready for publication. > However, because this work may lead to significant changes in the > mechanics of network management and control, some extra care in the > review stage is warranted. I've marked some issues as major to > indicate that they may deserve extra consideration by the ADs and/or the wider Internet community. > > > Major Issues: > > 1. There seems to be some confusion as to the intended status of the document. > The draft itself lists its intended status as Informational, which is > usually appropriate for a requirements document. On the other hand, > the draft was submitted to the IESG with an Intended Status of Proposed Standard. > Furthermore, a quick check of other I2RS WG requirements docs shows > them split between Informational and Proposed Standard, so the > confusion may extend beyond this draft. I'd suggest the ADs and > chairs agree on a consistent policy. Fixed > 2. The document concerns requirements for a publish/subscribe > interface to, among other things, real-time operational data. The > text in Section > 2.3 indicates an awareness of the need to support potentially large > numbers of subscribers and high volumes of data. However, the > document doesn't seem to discuss the global network impact of > continuously pushing a lot of data to many subscribers. > > As the introduction of such a push system could lead to a qualitative > shift in the total volume of management/control traffic, it seems > important to begin addressing this issue at the requirements stage. > > A possible resolution would be to add a brief section on network > impact under large-scale conditions, and/or a set of requirements for minimizing this impact. > Some of the listed requirements are germane to this, e.g. subscription filters. > bundling, and dampening. Issues that are not addressed include > support for encoding formats that are efficient for high-volume > transport and processing (XML and JSON are usually considered not to > be); appropriate selection of transport protocols and features > according to scale/use-case; and support for mechanisms to determine > or restrict the bandwidth cost of a proposed or ongoing subscription. Good point. We do have some relevant requirements as there are mechanisms to: - Allow/deny/negotiate subscriptions so as not to overwhelm resources. This could include negotiation of the encoding and filters. See Section 4.2.2 - Notify subscribers that push updates are being suspended/resumed But there could be more. For example, there should be the ability of prioritize some subscriptions over others for de-queuing towards recipients Therefore the new draft version '07' adds a Relative Prioritization section 4.2.6.8 and requirements to ensure limited bandwidth environments are addressed. > 3. This work is being carried out in the I2RS WG, but the first > sentence of Section > 2.2 states that this document is intended to cover requirements beyond > I2RS. A general question for the editors/chairs/ADs is whether it has > received any review by interested/affected parties outside I2RS? > > 4. The Security Requirements make no mention of data integrity or > confidentiality. This is a potentially serious omission in today's > network environment. I would expect at the least that subscribers > have the ability to request a secure (authenticated, > integrity-verified, > confidential) session, that publishers likewise have the ability to > refuse non- secure sessions, and that the security status of a session > is explicitly signaled and checked by both parties during negotiation. With subscriptions signaled in-band, any pushed updates will rely on the underlying transport layer protocols to ensure integrity and confidentiality. This provides the same level of security as a traditional "GET". > > Minor Issues: > > 1. The requirements in this document ought to be numbered for ease of > reference. Hoping to avoid this :-) > 2. Section 3: > As this is a requirements doc, the RFC 2119 language paragraph could > use a clarification sentence along the lines of the one in Section 1.1 of RFC 5654. Added > 3. Section 3: > It's not obvious to me from the text in this section what the > distinction and intended relationship is between Receivers and > Subscribers. Perhaps this can be clarified with an example? Also the > statement "In general, the Receiver and Subscriber will be the same > entity" doesn't sound right -- maybe you meant that in general they can be different, but usually they will be the same? That is what is meant. > 4. Section 3, last sentence: > What is the difference between the terms "previous Push" and "last Update" > used in this sentence? Agree this was confusing. In fact it included a requirement in the definition. Extracted this text in the -07 version, and added a reworded requirement to section 4.2.7. > 5. Section 4.2.3, last paragraph: > This paragraph would be more useful if it explained what a > persistence/replay capability was and how it might work. Updated text > 6. Can a definition or reference be provided for the term "object > property" as used in Sections 3 and 4.2.7? This terminology seems > slightly different from that used in RFC 6020. I can see where people might get confused. I tweaked the text to better match what can be seen with RFC6241 filtering. > 7. Section 4.2.4: > What is the purpose of stating that a subscription service should > support "different" transports and encodings? This sounds too vague to be useful. > Choice of transport and encoding are of great practical importance, > but the document has almost nothing to say on these topics. > Can the authors not provide a summary of options and some definite > guidance here? This is tough. There are proposals for transports of NETCONF, RESTCONF, HTTP, and HTTP2 in technology drafts. Other people have suggested COAP and IPFIX. Some people want non-IETF transports like gRPC. We really don't want to take a position. > 8. Section 4.2.5, third paragraph: > Can you spell out in the document exactly what "Versioning" means here? Updated > 9. When the underlying transport provides some form of security, > should there not be a requirement for alignment between transport > security and pub/sub protocol security? Can, for example, TLS > certificate validation fulfil the pub/sub authentication requirement? These requirements explore the security requirements for control plane messaging, anticipating that the data plane will be locked down as would a traditional "GET" for the same information. This is why in the Security requirements talk about filtering based on whatever mechanisms would in place for a "GET" using that specific transport. I.e., we are attempting equivalence for "GET" rather than new incremental mechanisms with perhaps different behavior. > 10. An important use-case for such a pub/sub update service is a > subscriber that wants to maintain an up-to-date local copy of a > datastore residing on the publisher. This requires the ability to > correlate the version of the datastore obtained via an out-of-band > full download with the version reflected by each published update. Do > the authors intend to allow for this case, and have they considered the associated requirements? Yes. In summary, you can get deltas via on-change. And when you want to ensure you haven't lost something, you can do a GET against any objects where the remote datastore houses the primary copy. > > Nits: > > Section 2.2, first paragraph: > - s/Switches and Routers/switches and routers/ > - s/past subscriptions includes/past subscription mechanisms includes/ Fixed > Section 2.2, last paragraph: > - s/NETCONF should the/NETCONF should be the/ > - s/support Multicast and Broadcast/support for multicast and > broadcast/ Fixed > Section 3, 8th paragraph: > - s/referred in/referred to in/ > Section 3, 9th paragraph: > - s/which have been made/that have been made/ Section 3, last paragraph: > - s/propert(ies)/properties/ Fixed > - s/different that/different than that/ Couldn't find that one > Section 4, first paragraph: > - s/morphed/adapted/ fixed > Section 4.1, last paragraph: > - s/lease a Subscription/lease of a Subscription/ Fixed > Section 4.2.1, second and third paragraphs: > These two requirements seem to make more sense if "one or more" is > replaced by "multiple". Fixed > Section 4.2.8, third paragraph: > - s/us a failure/is a failure/ Fixed Eric > > Cheers, > -d _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu May 5 04:11:38 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8122612D106; Thu, 5 May 2016 04:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 p6sHOItPmyzM; Thu, 5 May 2016 04:11:34 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1FEE12B05A; Thu, 5 May 2016 04:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28484; q=dns/txt; s=iport; t=1462446693; x=1463656293; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TYROZvg8I/sDb8opqTTvrGytf55BdBtlFVEuCWyvH5Q=; b=lJZKRVETu9F///digXbBVgve2r3LUa72zKP028oDAvhW0ENPBLxceIUD CYWP+93/l1LjJ+HKfGLo4x2PjiTF43tXycDnl7vSlUj3xWyv7Doz9nhVI DQoXFNQKpoUPLRdssDPJB84QdyeVywmrwynVHmNe6BuroS9ePN5fMqKyh Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAgAfKitX/40NJK1egzhTfQa5KgENg?= =?us-ascii?q?XYmhWoCHIESOBQBAQEBAQEBZSeEQQEBAQIBARgLETMNBQULAgEIFAQCAiYCAgI?= =?us-ascii?q?wFRACBAENBRsEiAMIDq1vkQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEVfIUkgXaCV?= =?us-ascii?q?oQ/FxWCVCuCLgWHdg2FVoEyhBqEdQGFe4IzhWqBaE6Df4hehiaJDQEeAQFCggU?= =?us-ascii?q?bgUtsAQGHGiQbfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,581,1454976000"; d="scan'208";a="104835873" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 May 2016 11:11:20 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u45BBJhv010796 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 May 2016 11:11:20 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 5 May 2016 07:11:19 -0400 Received: from xch-rtp-019.cisco.com ([64.101.220.159]) by XCH-RTP-019.cisco.com ([64.101.220.159]) with mapi id 15.00.1104.009; Thu, 5 May 2016 07:11:18 -0400 From: "Giles Heron (giheron)" To: "adrian@olddog.co.uk" , "Luca Martini (lmartini)" Thread-Topic: Routing Directorate review of draft-ietf-pals-rfc4447bis Thread-Index: AQHRpr7ZKQjnfm/AQE6igwCcD/YpWw== Date: Thu, 5 May 2016 11:11:18 +0000 Message-ID: <41025DD4-8D96-4FCC-A9B9-00CD2DA71236@cisco.com> References: <035501d16cba$d1e22270$75a66750$@olddog.co.uk> In-Reply-To: <035501d16cba$d1e22270$75a66750$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.60.143.152] Content-Type: text/plain; charset="utf-8" Content-ID: <534479EECB785F4791869AB365FB4C01@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-pals-rfc4447bis.all@ietf.org" Subject: Re: [RTG-DIR] Routing Directorate review of draft-ietf-pals-rfc4447bis X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 11:11:37 -0000 SGkgQWRyaWFuL0x1Y2EsDQoNCnNvcnJ5IGZvciB0aGUgc2xvdyByZXNwb25zZSBvbiB0aGlzLg0K DQpXZSBtYXkgbmVlZCB0byBpdGVyYXRlIG9uZSBtb3JlIHRpbWUgdG9vIDooDQoNCj4gT24gMjEg RmViIDIwMTYsIGF0IDE1OjE2LCBBZHJpYW4gRmFycmVsIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPiB3 cm90ZToNCj4gDQo+IEhlbGxvLCANCj4gDQo+IEkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBS b3V0aW5nIERpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBE aXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVk IGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZp ZXcuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRv IHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcg RGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUg4oCLaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJl YS9ydGcvdHJhYy93aWtpL1J0Z0RpciANCj4gDQo+IEFsdGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFy ZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURzLCBpdCB3b3VsZCBiZSBo ZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFzIHRoZSBkcmFmdCBhZHZhbmNlcywg YW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0 aW5nIHRoZSBkcmFmdC4gDQo+IA0KPiBUaGFua3MsDQo+IEFkcmlhbg0KPiANCj4gPT09DQo+IA0K PiBEb2N1bWVudDogZHJhZnQtaWV0Zi1wYWxzLXJmYzQ0NDdiaXMtMDMudHh0IA0KPiBSZXZpZXdl cjogQWRyaWFuIEZhcnJlbA0KPiBSZXZpZXcgRGF0ZTogMjEgRmVicnVhcnkgMjAxNg0KPiBJRVRG IExDIEVuZCBEYXRlOiBOb3QgeWV0IHN0YXJ0ZWQNCj4gSW50ZW5kZWQgU3RhdHVzOiBJbnRlcm5l dCBTdGFuZGFyZA0KPiANCj4gPSBTdW1tYXJ5ID0NCj4gDQo+IEkgaGF2ZSBzb21lIG1pbm9yIGNv bmNlcm5zIGFib3V0IHRoaXMgZG9jdW1lbnQgdGhhdCBJIHRoaW5rIHNob3VsZCBiZSByZXNvbHZl ZCBiZWZvcmUgcHVibGljYXRpb24uIA0KPiANCj4gPSBDb21tZW50cyA9DQo+IA0KPiBJJ20gT0sg dG8gc2VlIDQ0NDcgYmVpbmcgYWR2YW5jZWQgdG8gZnVsbCBzdGFuZGFyZCwgYWx0aG91Z2ggSSdt IGFsc28gYSBsaXR0bGUgc3VycHJpc2VkIHRoYXQgdGhlcmUgd2FzIGVuZXJneSB0byBkbyBpdC4N Cj4gDQo+IFRoZSB3b3JrIGlzIGxhcmdlbHkgbWVjaGFuaWNhbC4gTXkgY29tbWVudHMgYXJlIGEg bWl4IG9mIG1pbm9yIHByb2Nlc3MgY29uY2VybnMgKHRoYXQgeW91ciBBRCBzaG91bGQgYmUgYWJs ZSB0byByZXNvbHZlKSwgbWlub3IgdGV4dCBjbGFyaWZpY2F0aW9ucywgYW5kIG5pdHMuDQo+IA0K PiBJdCdzIGJlZW4gYSB3aGlsZSBzaW5jZSBJIHdhcyBjb25jZXJuZWQgd2l0aCBMRFAsIGJ1dCBJ IGhhdmUgbm8gcmVhc29uIHRvIGRvdWJ0IHRoZSBpbnRlZ3JpdHkgb2YgdGhpcyBkb2N1bWVudC4N Cj4gDQo+ID0gTWFqb3IgSXNzdWVzID0NCj4gDQo+IE5vIG1ham9yIGlzc3VlcyBmb3VuZC4gDQo+ IA0KPiA9IE1pbm9yIElzc3VlcyA9DQo+IA0KPiBJIGJlbGlldmUgdGhhdCB0aGlzIGRvY3VtZW50 IHNob3VsZCBiZSBtYXJrZWQgYXMgb2Jzb2xldGluZyA0NDQ3IGFuZCANCj4gNjcyMy4gSXQgd2ls bCByZXN1bHQgaW4gYSBuZXcgUkZDIHdpdGggYSBuZXcgbnVtYmVyLCBzbyA0NDQ3IHdpbGwgbm8N Cj4gbG9uZ2VyIGJlIHJlbGV2YW50LiBBbmQsIGFzIFNlY3Rpb24gMSBzYXlzOiBhIG5ldyBzZWN0 aW9uICg2LjMpIG9uIA0KPiBjb250cm9sLXdvcmQgcmVuZWdvdGlhdGlvbiBieSBsYWJlbCByZXF1 ZXN0IG1lc3NhZ2UgaGFzIGJlZW4gYWRkZWQsDQo+IG9ic29sZXRpbmcgUkZDIDY3MjMuDQoNCml0 IGlzIG1hcmtlZCB0aGF0IHdheS4gIGJ1dCBpdOKAmXMgb25seSB3aGVuIGl0IGdvZXMgdG8gUkZD IHRoYXQgdGhhdCBnZXRzIGludG8gdGhlIHRleHQ/DQoNCj4gQnkgdGhlIHdheSwgaXQgaXMgc2Vj dGlvbiA3LjMgKG5vdCA2LjMpIHRoYXQgeW91IGhhdmUgYWRkZWQhDQoNCnRoYW5rcyEgIHdpbGwg Zml4IDopDQoNCj4gW05COiBRMTYgb2YgdGhlIFNoZXBoZXJkIHdyaXRlLXVwIHNlZW1zIGEgYml0 IGdhcmJsZWQgb24gdGhpcyBmcm9udC4NCj4gRXNwZWNpYWxseSAiV2lsbCBwdWJsaWNhdGlvbiBv ZiB0aGlzIGRvY3VtZW50IGNoYW5nZSB0aGUgc3RhdHVzIG9mIGFueQ0KPiBleGlzdGluZyBSRkNz PyIgc2VlbXMgdG8gbmVlZCBhIG11Y2ggY2xlYXJlciBhbnN3ZXIhXQ0KDQo6KQ0KDQo+IC0tLQ0K PiANCj4gSSdtIG5vdCB1cCB0byBzcGVlZCBvbiB0aGUgbmV3IHByb2Nlc3MgZm9yIGFkdmFuY2lu ZyBhIHNwZWNpZmljYXRpb24gdG8NCj4gSW50ZXJuZXQtU3RhbmRhcmQgd2hlbiBpdCBoYXMgbm9y bWF0aXZlIHJlZmVyZW5jZXMgdGhhdCBhcmUgbm90IA0KPiBzaW1pbGFybHkgYWR2YW5jZWQvYWR2 YW5jaW5nLiBJIGRvIGtub3cgdGhhdCB0aGUgcHJvY2VzcyBjaGFuZ2VkDQo+IHJlY2VudGx5IGFu ZCBJIGFtIHN1cmUgdGhhdCB5b3VyIEFEIGNhbiBsb29rIGl0IHVwLg0KDQpJIHdhaXQgd2l0aCBi YXRlZCBicmVhdGggOykNCg0KPiAtLS0NCj4gDQo+IEl0IG1pZ2h0IGJlIGEgcmVhc29uYWJsZSBx dWVzdGlvbiB0byBhc2sgd2h5IHNvbWUgb2YgdGhlDQo+IChpbmZvcm1hdGl2ZWx5KSByZWZlcmVu Y2VkIHJlbGF0ZWQgUFcgUkZDcyAoc3VjaCBhcyBlbmNhcHN1bGF0aW9ucykNCj4gYXJlIG5vdCBi ZWluZyBhZHZhbmNlZCBhdCB0aGUgc2FtZSB0aW1lLCBlc3BlY2lhbGx5IHRob3NlIHRoYXQgYXJl DQo+IGRlc2NyaWJlZCBhcyAiY29tcGFuaW9uIGRvY3VtZW50c+KAnS4NCg0KUkZDNDQ0Ny1iaXMg aXMgYmVpbmcgZG9uZSBiZWNhdXNlIHRoZXJlIHdlcmUgdG9vIG1hbnkgZXJyYXRhIG9uIDQ0NDcu ICAgVGhlcmUgd29u4oCZdCBhcyBtYW55IG9uIHRoZSBvdGhlcnMuICBJIHRoaW5rIHRoZSBwcm9t b3Rpb24gdG8gSW50ZXJuZXQgU3RhbmRhcmQgaGFwcGVuZWQgYXMgcGFydCBvZiB0aGF0Pw0KIA0K PiAtLS0NCj4gDQo+IEl0IHNlZW1zIHVubmVjZXNzYXJ5IHBldHR5LWZvZ2dpbmcgcHJvY2Vzcywg YnV0IHRoZSBpbmNsdXNpb24gb2YNCj4gc2VjdGlvbiA3LjMgc2VlbXMgdG8gbWUgdG8gZGVmZWF0 IHRoZSBzdGFiaWxpdHkgcmVxdWlyZW1lbnQgZm9yDQo+IGFkdmFuY2VtZW50IHRvIEludGVybmV0 IFN0YW5kYXJkIHVubGVzcyB5b3VyIGNsYWltIGhlcmUgaXMgdGhhdCB5b3UNCj4gYXJlIGFkdmFu Y2luZyA0NDQ3IGFuZCA2NzIzIHRvZ2V0aGVyIGluIHRoaXMgc2luZ2xlIGRvY3VtZW50LiBUaGF0 DQo+IG1pZ2h0IGJlIGZpbmUuDQoNCnRoZSBpc3N1ZSBpcyB0aGF0IDQ0NDcgZmFpbGVkIHRvIGNv dmVyIGEgY29ybmVyLWNhc2UgdGhhdCB3YXMgZG9jdW1lbnRlZCBpbiA2NzIzLiAgIFNvIDY3MjMg Y291bGQgYmUgc2VlbiBhcyBhIHN1cGVyLWVycmF0dW0gb24gNDQ0Ny4gIDQ0NDdiaXMgbWVyZ2Vz IGl0IGluIGFzIGEgc2luZ2xlIGRvY3VtZW50Lg0KDQo+IC0tLQ0KPiANCj4gVGhlIEVycmF0YSB0 aGF0IGhhdmUgYmVlbiBkZWxpYmVyYXRlbHkgZGlzcmVnYXJkZWQgbmVlZCB0byBiZSBtYXJrZWQg YXMNCj4gUmVqZWN0ZWQuIEkgdGhpbmsgdGhlIG9uZXMgdGhhdCBoYXZlIGJlZW4gYWN0aW9uZWQg Y291bGQgdXNlZnVsbHkgYmUgDQo+IG1hcmtlZCBhcyBWZXJpZmllZCBvciBoYXZlIGEgbm90ZSBh ZGRlZCBzYXlpbmcgImZpeGVkIGluIFJGQ2FiY2QiLg0KPiANCj4gQXMgZmFyIGFzIEkgY2FuIHRl bGw6DQo+IA0KPiAzNTU0IHdhcyBub3QgYWN0aW9uZWQNCg0KaXQgd2FzIGFjdGlvbmVkLCBidXQg d2l0aCBiZXR0ZXIgd29yZGluZyAoSU1PKSB0aGFuIHRoZSBlcnJhdHVtDQoNCj4gOTM4IHdhcyBk b25lDQo+IDg2IHdhcyBkb25lDQo+IDM1NTUgd2FzIGRvbmUNCj4gMzExNSBubyBsb25nZXIgYXBw bGllcw0KPiAzMTE0IHdhcyBkb25lDQo+IDMxMTIgd2FzIGRvbmUNCj4gMTUzMCB3YXMgZG9uZQ0K DQp5dXAuDQoNCj4gLS0tDQo+IA0KPiBCZWNhdXNlIHlvdSAoaW5jb3JyZWN0bHkpIHNhaWQgdGhh dCBzZWN0aW9uIDYuMyB3YXMgbmV3IHRleHQsIEkgZ2F2ZSBpdA0KPiBjYXJlZnVsIHJldmlldy4g SSB0aGluayB0aGUgdGV4dCBpcyBpbiByYXRoZXIgcG9vciBzdGF0ZToNCj4gDQo+IEZvciBleGFt cGxlLCBpbiA2LjMuMS4uLg0KPiANCj4gICBVc2luZyB0aGUgcHJvY2VkdXJlcw0KPiAgIG91dGxp bmVkIGluIHRoaXMgc2VjdGlvbiwgYSBzaW1wbGUgbGFiZWwgd2l0aGRyYXcgbWV0aG9kIE1BWSBh bHNvIGJlDQo+ICAgc3VwcG9ydGVkIGFzIGEgbGVnYWN5IG1lYW5zIG9mIHNpZ25hbGluZyBQVyBz dGF0dXMgYW5kIEFDIHN0YXR1cy4NCj4gDQo+IC4uLlNpbmNlIHRoaXMgaXMgKnRoZSogc3BlY2lm aWNhdGlvbiBub3csIHdoYXQgZG9lcyAibGVnYWN5IiBtZWFuPw0KDQppdCBtZWFucyBmb3IgaW50 ZXJvcCB3aXRoIGV4dHJlbWVseSBvbGQgaW1wbGVtZW50YXRpb25zIChpbXBsZW1lbnRhdGlvbnMg dGhhdCB3ZXJlIHByZSB0aGUgNDQ0NyBzdGFuZGFyZCkuDQoNCj4gSW5kZWVkLCB5b3UgZW5kIDYu My4xIHdpdGguLi4NCj4gICBUaGUgUFcgc3RhdHVzDQo+ICAgc2lnbmFsaW5nIHByb2NlZHVyZXMg ZGVzY3JpYmVkIGluIHRoaXMgc2VjdGlvbiBNVVNUIGJlIGZ1bGx5DQo+ICAgaW1wbGVtZW50ZWQu DQo+IC4uLndoaWNoIGtpbmQgb2YgaW1wbGllcyAuLi4gaG1tLg0KDQp5ZXMgLSB0aGV5IG11c3Qg YmUgaW1wbGVtZW50ZWQuICBCdXQgeW91IGNhbiBpbnRlcndvcmsgd2l0aCDigJxsZWdhY3nigJ0u DQoNCj4gSSB0aGluayB5b3UgY291bGQgcmV3b3JrIDYuMy4xIHRvIGhhbmRsZSB0aGlzIG1vcmUg Z3JhY2VmdWxseSBhbmQgYXZvaWQNCj4gdGhlICJjbHVuayIgb2YgdGhlIDJuZCBwYXJhLi4uDQo+ IA0KPiAgIE9uY2UgdGhlIFBXIHN0YXR1cyBuZWdvdGlhdGlvbiBwcm9jZWR1cmVzIGFyZSBjb21w bGV0ZWQgYW5kIGlmIHRoZXkNCj4gDQo+IC4uLndoZXJlIHdlIGFyZSBzdXJwcmlzZWQgdG8gaGVh ciBhYm91dCBzdGF0dXMgbmVnb3RpYXRpb24uDQo+IA0KPiBGb3IgZXhhbXBsZToNCj4gDQo+IE9M RA0KPiAgIFRoZSBQRXMgTVVTVCBzZW5kIExhYmVsIE1hcHBpbmcgTWVzc2FnZXMgdG8gdGhlaXIg cGVlcnMgYXMgc29vbiBhcw0KPiAgIHRoZSBQVyBpcyBjb25maWd1cmVkIGFuZCBhZG1pbmlzdHJh dGl2ZWx5IGVuYWJsZWQsIHJlZ2FyZGxlc3Mgb2YgdGhlDQo+ICAgYXR0YWNobWVudCBjaXJjdWl0 IHN0YXRlLiAgVGhlIFBXIGxhYmVsIHNob3VsZCBub3QgYmUgd2l0aGRyYXduDQo+ICAgdW5sZXNz IHRoZSBvcGVyYXRvciBhZG1pbmlzdHJhdGl2ZWx5IGNvbmZpZ3VyZXMgdGhlIHBzZXVkb3dpcmUg ZG93bg0KPiAgIChvciB0aGUgUFcgY29uZmlndXJhdGlvbiBpcyBkZWxldGVkIGVudGlyZWx5KS4g IFVzaW5nIHRoZSBwcm9jZWR1cmVzDQo+ICAgb3V0bGluZWQgaW4gdGhpcyBzZWN0aW9uLCBhIHNp bXBsZSBsYWJlbCB3aXRoZHJhdyBtZXRob2QgTUFZIGFsc28gYmUNCj4gICBzdXBwb3J0ZWQgYXMg YSBsZWdhY3kgbWVhbnMgb2Ygc2lnbmFsaW5nIFBXIHN0YXR1cyBhbmQgQUMgc3RhdHVzLiAgSW4N Cj4gICBhbnkgY2FzZSwgaWYgdGhlIGxhYmVsLXRvLVBXIGJpbmRpbmcgaXMgbm90IGF2YWlsYWJs ZSB0aGUgUFcgTVVTVCBiZQ0KPiAgIGNvbnNpZGVyZWQgaW4gdGhlIGRvd24gc3RhdGUuDQo+IA0K PiAgIE9uY2UgdGhlIFBXIHN0YXR1cyBuZWdvdGlhdGlvbiBwcm9jZWR1cmVzIGFyZSBjb21wbGV0 ZWQgYW5kIGlmIHRoZXkNCj4gICByZXN1bHQgaW4gdGhlIHVzZSBvZiB0aGUgbGFiZWwgd2l0aGRy YXcgbWV0aG9kIGZvciBQVyBzdGF0dXMNCj4gICBjb21tdW5pY2F0aW9uLCBhbmQgdGhpcyBtZXRo b2QgaXMgbm90IHN1cHBvcnRlZCBieSBvbmUgb2YgdGhlIFBFcywNCj4gICB0aGVuIHRoYXQgUEUg bXVzdCBzZW5kIGEgTGFiZWwgUmVsZWFzZSBNZXNzYWdlIHRvIGl0cyBwZWVyIHdpdGggdGhlDQo+ ICAgZm9sbG93aW5nIGVycm9yOg0KPiANCj4gICAiTGFiZWwgV2l0aGRyYXcgUFcgU3RhdHVzIE1l dGhvZCBOb3QgU3VwcG9ydGVkIg0KPiANCj4gICBJZiB0aGUgbGFiZWwgd2l0aGRyYXcgbWV0aG9k IGZvciBQVyBzdGF0dXMgY29tbXVuaWNhdGlvbiBpcyBzZWxlY3RlZA0KPiAgIGZvciB0aGUgUFcs IGl0IHdpbGwgcmVzdWx0IGluIHRoZSBMYWJlbCBNYXBwaW5nIE1lc3NhZ2UgYmVpbmcNCj4gICBh ZHZlcnRpc2VkIG9ubHkgaWYgdGhlIGF0dGFjaG1lbnQgY2lyY3VpdCBpcyBhY3RpdmUuICBUaGUg UFcgc3RhdHVzDQo+ICAgc2lnbmFsaW5nIHByb2NlZHVyZXMgZGVzY3JpYmVkIGluIHRoaXMgc2Vj dGlvbiBNVVNUIGJlIGZ1bGx5DQo+ICAgaW1wbGVtZW50ZWQuDQo+IE5FVw0KPiAgIFRoZSBQRXMg TVVTVCBzZW5kIExhYmVsIE1hcHBpbmcgTWVzc2FnZXMgdG8gdGhlaXIgcGVlcnMgYXMgc29vbiBh cw0KPiAgIHRoZSBQVyBpcyBjb25maWd1cmVkIGFuZCBhZG1pbmlzdHJhdGl2ZWx5IGVuYWJsZWQs IHJlZ2FyZGxlc3Mgb2YgdGhlDQo+ICAgYXR0YWNobWVudCBjaXJjdWl0IHN0YXRlLiAgVGhlIFBX IGxhYmVsIHNob3VsZCBub3QgYmUgd2l0aGRyYXduDQo+ICAgdW5sZXNzIHRoZSBvcGVyYXRvciBh ZG1pbmlzdHJhdGl2ZWx5IGNvbmZpZ3VyZXMgdGhlIHBzZXVkb3dpcmUgZG93bg0KPiAgIChvciB0 aGUgUFcgY29uZmlndXJhdGlvbiBpcyBkZWxldGVkIGVudGlyZWx5KS4gDQo+IA0KPiAgIFNlY3Rp b24gNi4zLjIgZGVzY3JpYmVzIGEgbWVjaGFuaXNtIGZvciBzaWduYWxpbmcgdGhlIHN0YXR1cyBv ZiB0aGUgDQo+ICAgUFcgYW5kIEFDLiAgQWRkaXRpb25hbGx5LCBhIHNpbXBsZSBsYWJlbCB3aXRo ZHJhdyBtZXRob2QgTUFZIGJlIHVzZWQgDQo+ICAgdG8gc2lnbmFsIHRoZSBQVyBzdGF0dXMgYW5k IEFDIHN0YXR1cy4gIEluIGFueSBjYXNlLCBpZiB0aGUgbGFiZWwtdG8tDQo+ICAgUFcgYmluZGlu ZyBpcyBub3QgYXZhaWxhYmxlIHRoZSBQVyBNVVNUIGJlIGNvbnNpZGVyZWQgdG8gYmUgaW4gdGhl IA0KPiAgIGRvd24gc3RhdGUuDQo+IA0KPiAgIFRoZSBQRXMgbmVnb3RpYXRlIHdoaWNoIFBXIGFu ZCBBQyBzdGF0dXMgc2lnbmFsaW5nIG1lY2hhbmlzbSB0byB1c2UNCj4gICBieSBmb2xsb3dpbmcg dGhlIHByb2NlZHVyZXMgaW4gU2VjdGlvbiA2LjMuMy4gIElmIHRoZSBQVyBuZWdvdGlhdGlvbg0K PiAgIHByb2NlZHVyZXMgYXJlIGNvbXBsZXRlZCBhbmQgaWYgdGhleSByZXN1bHQgaW4gdGhlIHVz ZSBvZiB0aGUgc2ltcGxlIA0KPiAgIGxhYmVsIHdpdGhkcmF3IG1ldGhvZCBmb3IgUFcgc3RhdHVz IGNvbW11bmljYXRpb24sIGFuZCBpZiB0aGlzIG1ldGhvZA0KPiAgIGlzIG5vdCBzdXBwb3J0ZWQg Ynkgb25lIG9mIHRoZSBQRXMgdGhlbiB0aGF0IFBFIG11c3Qgc2VuZCBhIExhYmVsDQo+ICAgUmVs ZWFzZSBNZXNzYWdlIHRvIGl0cyBwZWVyIHdpdGggdGhlIGZvbGxvd2luZyBlcnJvcjoNCj4gDQo+ ICAgIkxhYmVsIFdpdGhkcmF3IFBXIFN0YXR1cyBNZXRob2QgTm90IFN1cHBvcnRlZCINCj4gDQo+ ICAgSWYgdGhlIGxhYmVsIHdpdGhkcmF3IG1ldGhvZCBmb3IgUFcgc3RhdHVzIGNvbW11bmljYXRp b24gaXMgc2VsZWN0ZWQNCj4gICBmb3IgdGhlIFBXLCBpdCB3aWxsIHJlc3VsdCBpbiB0aGUgTGFi ZWwgTWFwcGluZyBNZXNzYWdlIGJlaW5nDQo+ICAgYWR2ZXJ0aXNlZCBvbmx5IGlmIHRoZSBBQyBp cyBhY3RpdmUuDQo+IA0KPiAgIFRoZSBQVyBzdGF0dXMgc2lnbmFsaW5nIHByb2NlZHVyZXMgZGVz Y3JpYmVkIGluIFNlY3Rpb24gNi4zLjIgTVVTVCBiZQ0KPiAgIGZ1bGx5IGltcGxlbWVudGVkLg0K PiBFTkQNCg0KSeKAmW0gbm90IHN1cmUgd2Ugd2FudCB0byBtYWtlIGJpZyB0ZXh0IGNoYW5nZXMg YXQgdGhpcyBzdGFnZSBmb3IgbWFyZ2luYWwgYmVuZWZpdD8NCg0KPiAtLS0NCj4gDQo+IFNlY3Rp b24gNi4zLjIgYWNoaWV2ZXMgYW1iaWd1aXR5IGJ5IHN0YXRpbmcuLi4NCj4gICBUaGUgZ2VuZXJh bCBmb3JtYXQgb2YgdGhlIE5vdGlmaWNhdGlvbiBNZXNzYWdlIGlzOg0KPiAuLi5hbmQgdGhlbiBz aG93aW5nIHRoZSBzcGVjaWZpYyBjYXNlIG9mICJQVyBzdGF0dXMiLg0KPiANCj4gWW91IGNhbiBm aXggdGhpcyBieSByZS1vcmRlcmluZyBhbmQgdHdlYWtpbmcgc2xpZ2h0bHksIGFzIGZvbGxvd3Mu DQo+IA0KPiBOb3RlIHRoYXQgdGhlIG9sZCB0ZXh0IHNheXM6DQo+ICAgU2luY2UgdGhpcyBub3Rp ZmljYXRpb24gZG9lcyBub3QNCj4gICByZWZlciB0byBhbnkgcGFydGljdWxhciBtZXNzYWdlLCB0 aGUgTWVzc2FnZSBJZCBhbmQgTWVzc2FnZSBUeXBlDQo+ICAgZmllbGRzIGFyZSBzZXQgdG8gMC4N Cj4gLi4uYnV0IEkgdGhpbmsgdGhlIE1lc3NhZ2UgVHlwZSBpcyBzZXQgdG8gMHgwMDAxIDotKQ0K PiANCj4gDQo+IE9MRA0KPiAgIFRoZSBTdGF0dXMgVExWIGlzIHRyYW5zcG9ydGVkIHRvIHRoZSBy ZW1vdGUgUFcgcGVlciB2aWEgdGhlIExEUA0KPiAgIE5vdGlmaWNhdGlvbiBtZXNzYWdlLiAgVGhl IGdlbmVyYWwgZm9ybWF0IG9mIHRoZSBOb3RpZmljYXRpb24gTWVzc2FnZQ0KPiAgIGlzOg0KPiAN Cj4gICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAg ICAgICAgICAgMw0KPiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCj4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgIHwwfCAgIE5vdGlmaWNh dGlvbiAoMHgwMDAxKSAgICAgfCAgICAgIE1lc3NhZ2UgTGVuZ3RoICAgICAgICAgICB8DQo+ICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCj4gICB8ICAgICAgICAgICAgICAgICAgICAgICBNZXNzYWdlIElEICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ICAgfCAgICAgICAgICAgICAg ICAgICAgICAgU3RhdHVzIChUTFYpICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KPiAgIHwgICAgICAgICAgICAgICAgICAgICAgUFcgU3RhdHVzIFRMViAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8DQo+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICB8ICAgICAgICAgICBQV0lk IEZFQyBUTFYgb3IgR2VuZXJhbGl6ZWQgSUQgRkVDIFRMViAgICAgICAgICAgICAgfA0KPiAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQo+ICAgfCAgICAgICAgICAgICAgIFBXIEdyb3VwaW5nIElEIFRMViAoT3B0aW9uYWwp ICAgICAgICAgICAgICAgICAgIHwNCj4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiANCj4gDQo+IA0KPiAgIFRoZSBT dGF0dXMgVExWIHN0YXR1cyBjb2RlIGlzIHNldCB0byAweDAwMDAwMDI4LCAiUFcgc3RhdHVzIiwg dG8NCj4gICBpbmRpY2F0ZSB0aGF0IFBXIHN0YXR1cyBmb2xsb3dzLiAgU2luY2UgdGhpcyBub3Rp ZmljYXRpb24gZG9lcyBub3QNCj4gICByZWZlciB0byBhbnkgcGFydGljdWxhciBtZXNzYWdlLCB0 aGUgTWVzc2FnZSBJZCBhbmQgTWVzc2FnZSBUeXBlDQo+ICAgZmllbGRzIGFyZSBzZXQgdG8gMC4N Cj4gTkVXDQo+ICAgVGhlIFN0YXR1cyBUTFYgaXMgdHJhbnNwb3J0ZWQgdG8gdGhlIHJlbW90ZSBQ VyBwZWVyIHZpYSB0aGUgTERQDQo+ICAgTm90aWZpY2F0aW9uIG1lc3NhZ2UgYXMgZGVzY3JpYmVk IGluIFtSRkM1MDM2XS4NCj4gDQo+ICAgVGhlIFN0YXR1cyBUTFYgc3RhdHVzIGNvZGUgaXMgc2V0 IHRvIDB4MDAwMDAwMjgsICJQVyBzdGF0dXMiLCB0bw0KPiAgIGluZGljYXRlIHRoYXQgUFcgc3Rh dHVzIGZvbGxvd3MuICBUaGUgZm9ybWF0IG9mIHRoZSBOb3RpZmljYXRpb24NCj4gICBNZXNzYWdl IGZvciBjYXJyeWluZyB0aGUgUFcgU3RhdHVzIGlzIGFzIGZvbGxvd3M6DQo+IA0KPiANCj4gICAg MCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAg ICAgMw0KPiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIg MyA0IDUgNiA3IDggOSAwIDENCj4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgIHwwfCAgIE5vdGlmaWNhdGlvbiAo MHgwMDAxKSAgICAgfCAgICAgIE1lc3NhZ2UgTGVuZ3RoICAgICAgICAgICB8DQo+ICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCj4gICB8ICAgICAgICAgICAgICAgICAgICAgICBNZXNzYWdlIElEICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfA0KPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ICAgfCAgICAgICAgICAgICAgICAgICAg ICAgU3RhdHVzIChUTFYpICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KPiAgIHwgICAgICAgICAgICAgICAgICAgICAgUFcgU3RhdHVzIFRMViAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8DQo+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICB8ICAgICAgICAgICBQV0lkIEZFQyBU TFYgb3IgR2VuZXJhbGl6ZWQgSUQgRkVDIFRMViAgICAgICAgICAgICAgfA0KPiAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r DQo+ICAgfCAgICAgICAgICAgICAgIFBXIEdyb3VwaW5nIElEIFRMViAoT3B0aW9uYWwpICAgICAg ICAgICAgICAgICAgIHwNCj4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiANCj4gDQo+ICAgU2luY2UgdGhpcyBub3Rp ZmljYXRpb24gZG9lcyBub3QgcmVmZXIgdG8gYW55IHBhcnRpY3VsYXIgbWVzc2FnZSwNCj4gICB0 aGUgTWVzc2FnZSBJZCBmaWVsZCBpcyBzZXQgdG8gMC4NCj4gRU5EDQoNCg0KYWdhaW4gSeKAmW0g bm90IHN1cmUgSeKAmWQgd2FudCB0byBtYWtlIG1ham9yIGNoYW5nZXMgdG8gdGhlIHRleHQgaWYg d2UgY2FuIGF2b2lkIGl0Lg0KDQo+IC0tLQ0KPiANCj4gU2VjdGlvbiA4IGNvdWxkIGJlIHRpZGll ZCBhIGxpdHRsZS4NCj4gDQo+IFRoZSB1c2Ugb2YgImluIGdlbmVyYWwiIGdpdmVzIHRoZSBJQU5B IG5vIHdheSB0byBrbm93IHdoZXRoZXIgdGhleQ0KPiBzaG91bGQgb3Igc2hvdWxkIG5vdCB1cGRh dGUgYSByZWZlcmVuY2UuIA0KDQpJIHRoaW5rIG1heWJlIHdlIGp1c3QgbmVlZCBhIG5vdGUgYXNr aW5nIElBTkEgdG8gcmVtb3ZlIHRoaXMgc2VjdGlvbiBvbmNlIHRoZSBSRkMgaXMgcHVibGlzaGVk LCBhbmQgdG8gdXBkYXRlIGFsbCB0aGUgcmVnaXN0cmllcyB3aXRoIHRoZSBuZXcgbnVtYmVyIG9m IHRoaXMgUkZDPw0KDQo+IEFyZSB5b3Ugc3VyZSB0aGF0IHlvdSB3YW50IHRvIHJlbW92ZSB0aGUg bmljZSwgY29uY2lzZSBsaXN0aW5nIG9mIGNvZGUNCj4gcG9pbnRzIHRoYXQgYXJlIHByZXNlbnQg aW4gUkZDIDQ0NDc/DQoNCnllYWggLSBJIHRoaW5rIHdlIHJlbW92ZWQgdGhlbSB0byBhdm9pZCBy aXNrIG9mIGNvbnRyYWRpY3RpbmcgdGhlIHJlZ2lzdHJ5Lg0KDQo+IDguMSwgOC4yLCBhbmQgOC4z IGFsbCBzYXkgIm5ldyIuIEkgc3VnZ2VzdCBkZWxldGluZyB0aGF0IHdvcmQuDQoNCm9rIC0gd2Xi gJlsbCByZWx5IG9uIElBTkEgdG8gZG8gdGhpcyA6KQ0KDQo+IEFuZCBsYXN0bHksICJJQU5BIG5l ZWRzIHRvLi4uIiBpcyBub3Qgd2hhdCB3ZSBzYXkgOi0pICJJQU5BIGlzIHJlcXVlc3RlZA0KPiB0 by4uLiIgaXMgbmljZXIuDQoNCmhvcGVmdWxseSBteSBuZXcgd29yZGluZyBmb3Igc2VjdGlvbiA4 IHdpbGwgYmUgbmljZXIgOikNCg0KPiBbTkI6IFRoZSBTaGVwaGVyZCB3cml0ZS11cCBzZWVtcyB0 byByZXBvcnQgYWxsIHRoaXMgd3JvbmdseSBhdCBRMTddDQo+IA0KPiAtLS0NCj4gDQo+IFNob3Vs ZG4ndCB0aGUgd2hvbGUgb2YgU2VjdGlvbiAxMCBiZSBtb3ZlZCB0byBhbiBpbnRlcm9wIHJlcG9y dA0KPiBzb21ld2hlcmU/IEl0J3MgcHJlc2VuY2Ugd2l0aGluIHRoZSBkb2N1bWVudCBzZWVtcyBz b21ld2hhdCB0ZW1wb3JhbGx5DQo+IHVuc3RhYmxlLiBJIHVuZGVyc3RhbmQgdGhhdCB5b3Ugd2Fu dCB0byB3cml0ZSBpdCBkb3duIGFuZCByZWNvcmQgaXQNCj4gc29tZXdoZXJlLCBhbHNvIHRoYXQg eW91IHByb2JhYmx5IGRldmVsb3BlZCBpdCBpbiB0aGUgSS1EIGFzIGEgdXNlZnVsIA0KPiBwbGFj ZSBmb3Igd29ya2luZyB0ZXh0LiBGb3IgYWR2aWNlIGFib3V0IGhvdyBhbmQgd2hlcmUgdG8gZG8g dGhpcyB5b3UNCj4gY2FuIGxvb2sgYXQgUkZDIDU2NTcuDQoNClRoZSBBRCBhc2tlZCB1cyB0byBw dXQgdGhpcyBpbiB0byBwcm92aWRlIGV2aWRlbmNlIGZvciBtb3ZpbmcgdG8gSW50ZXJuZXQgU3Rh bmRhcmQuICBIYXBweSB0byByZW1vdmUgaXQgYWdhaW4gb2YgY291cnNlIGlmIHRoZSBBRCByZXF1 ZXN0cyA6KQ0KDQo+IFlvdSBzZWVtIHRvIGhhdmUgYW5zd2VyZWQgdGhlIGZvdXIgcG9pbnRzIGZy b20gNjQxMCwgYnV0IG1heSBiZSBtaXNzaW5nDQo+IGEgbGl0dGxlIGNvcnJvYm9yYXRpb24uIA0K PiANCj4+IFRoZSBwc2V1ZG93aXJlIHRlY2hub2xvZ3kgd2FzIGZpcnN0IGRlcGxveWVkIGluIDIw MDEgYW5kIGhhcyBiZWVuDQo+PiB3aWRlbHkgZGVwbG95ZWQgYnkgbWFueSBjYXJyaWVycy4gW1JG QzcwNzldIGRvY3VtZW50cyB0aGUgcmVzdWx0cyBvZg0KPj4gYSBzdXJ2ZXkgb2YgUFcgaW1wbGVt ZW50YXRpb25zLCB3aXRoIHNwZWNpZmljIGVtcGhhc2lzIG9uIENvbnRyb2wNCj4+IFdvcmQgdXNh Z2UuICBbRUFOVENdIGRvY3VtZW50cyBhIHB1YmxpYyBtdWx0aS12ZW5kb3IgaW50ZXJvcGVyYWJp bGl0eQ0KPj4gdGVzdCBvZiBNUExTIGFuZCBDYXJyaWVyIEV0aGVybmV0IGVxdWlwbWVudCwgd2hp Y2ggaW5jbHVkZWQgdGVzdGluZw0KPj4gb2YgRXRoZXJuZXQsIEFUTSBhbmQgVERNIHBzZXVkb3dp cmVzLg0KPiANCj4gNzA3OSBpcyBhIHNsaWdodGx5IHJlbGF0ZWQgcGllY2Ugb2Ygc3VydmV5IHdv cmssIGJ1dCB0aGUgb25seSBtZW50aW9uIG9mIA0KPiBMRFAgKHdoaWNoIGlzIHRoZSBzdWJqZWN0 IG9mICp0aGlzKiBkb2N1bWVudCkgaXMgdG8gcG9pbnQgb3V0IGFuIGlzc3VlDQo+IHdpdGggbm9u LWltcGxlbWVudGF0aW9uLg0KDQp1bmRlcnN0b29kLiAgV2Ugd2VyZSBqdXN0IHRyeWluZyB0byBz aG93IHRoYXQgUFcgd2FzIHdpZGVseSBpbXBsZW1lbnRlZC4NCg0KPiBUaGUgRUFOVEMgcmVmZXJl bmNlIHJlYWxseSBuZWVkcyBzb21ldGhpbmcgdGhhdCBoZWxwcyB1cyBmaW5kIHRoZSByZXBvcnQN Cj4gb2YgdGhlIGludGVyb3AgZXZlbnQuIFBvc3NpYmx5IHRoaXMgaXMNCj4gaHR0cDovL3d3dy5l YW50Yy5kZS9maWxlYWRtaW4vZWFudGMvZG93bmxvYWRzL2V2ZW50cy8yMDA3LTIwMTAvTVBMU0VX QzA5L0VBTlRDLU1QTFNFV0MyMDA5LVdoaXRlUGFwZXItdjEuMC5wZGYNCj4gTG9va2luZyBhdCB0 aGF0IHBhcGVyLCBpdCBkZWZpbml0ZWx5IHN1cHBvcnRzIHRoZSBjbGFpbSBvZiBtdWx0aXBsZQ0K PiBpbnRlcm9wZXJhdGluZyBpbXBsZW1lbnRhdGlvbnMgb2YgNDQ0Ny4NCg0KY2FuIHdlIHB1dCBV UkxzIGludG8gcmVmZXJlbmNlcz8gIEFuZCBjYW4gdGhleSBiZSB0aGF0IGxvbmc/IDspDQoNCj4g V2UgbGFjaywgaG93ZXZlciwgYW55IHN0YXRlbWVudHMgYWJvdXQgIndpZGVzcHJlYWQgZGVwbG95 bWVudCBhbmQgDQo+IHN1Y2Nlc3NmdWwgb3BlcmF0aW9uYWwgZXhwZXJpZW5jZS7igJ0NCg0KSSBw dXQ6ICAiVGhlIHBzZXVkb3dpcmUgdGVjaG5vbG9neSB3YXMgZmlyc3QgZGVwbG95ZWQgaW4gMjAw MSBhbmQgaGFzIGJlZW4gd2lkZWx5IGRlcGxveWVkIGJ5IG1hbnkgY2FycmllcnMu4oCdICBJ4oCZ bSBub3Qgc3VyZSB3aGF0IG1vcmUgd2UgY2FuIGRvLiAgIFByb3ZpZGUgbGlzdHMgb2YgY2Fycmll cnMgb2ZmZXJpbmcgc2VydmljZXMgYmFzZWQgb24gcHNldWRvd2lyZXM/ICBUaGF04oCZZCBiZSAq dmVyeSogdGVtcG9yYXJsbHkgdW5zdGFibGUgOykNCg0KPj4gVGhlIGVycmF0YSBhZ2FpbnN0IFtS RkM0NDQ3XSBhcmUgYWxsIGVkaXRvcmlhbCBpbiBuYXR1cmUgYW5kIGhhdmUNCj4+IGJlZW4gYWRk cmVzc2VkIGluIHRoaXMgZG9jdW1lbnQuDQo+IA0KPiBHb29kIChleGNlcHQgZm9yIHRob3NlIG5v dCBhZGRyZXNzZWQgYXMgYWJvdmUsIGFuZCBleGNlcHQgdGhhdCBzb21lIG9mDQo+IHRob3NlIGVy cmF0YSBhcmUgaW5jb3JyZWN0bHkgbWFya2VkIGFzICJUZWNobmljYWzigJ0pLg0KDQpzbyB0aGV5 4oCZcmUgYWxsIGFkZHJlc3NlZCBhcyBub3RlZCBhYm92ZS4gIEFuZCB3ZSBjYW4gc2F5IOKAnG1v c3RseSBlZGl0b3JpYWzigJ0/DQoNCj4+IEFsbCBmZWF0dXJlcyBpbiB0aGlzIHNwZWNpZmljYXRp b24gaGF2ZSBiZWVuIGltcGxlbWVudGVkIGJ5IG11bHRpcGxlDQo+PiB2ZW5kb3JzLg0KPiANCj4g SG93IGRvIHdlIGtub3cgdGhpcz8NCg0KSeKAmW0gcmVhbGx5IG5vdCBzdXJlIGhvdyB3ZSBwcm92 ZSB0aGF0Lg0KDQo+IEZ1cnRoZXIsIGFyZSBhbGwgdGhlIGZlYXR1cmVzIHVzZWQ/IE9uZSBwb2lu dCBvZiB0aGlzIHN0ZXAgaW4gdGhlIA0KPiBwcm9jZXNzIGlzIHRvIHBydW5lIG91dCBmZWF0dXJl cyB0aGF0IGFyZSB1bm5lY2Vzc2FyeSAoYW5kIHNvIGNvbXBsaWNhdGUNCj4gaW1wbGVtZW50YXRp b24gYW5kIG9wZXJhdGlvbiwgYW5kIGNvc3QgbW9uZXkpLg0KDQpyaWdodCAtIHNvIGFzIGZhciBh cyB3ZSBrbm93IGFsbCB0aGUgZmVhdHVyZXMgYXJlIGluIHVzZSBieSBtdWx0aXBsZSB2ZW5kb3Jz LiAgSeKAmXZlIGFza2VkIGFyb3VuZCBpbnNpZGUgQ2lzY28gdG8gY2hlY2sgb3VyIGltcGxlbWVu dGF0aW9ucywgYnV0IEnigJltIHZlcnkgaGFwcHkgZm9yIHNvbWVvbmUgZWxzZSB0byBjaGVjayB3 aXRoIG91ciBjb21wZXRpdG9ycy4NCg0KPj4gVGhlcmUgaXMgbm8gSVBSIGZpbGVkIGFnYWluc3Qg dGhpcyBkb2N1bWVudCBvciBpdHMgcHJlZGVjZXNzb3IuDQo+IA0KPiBUaGlzIG1heSBiZSBvdmVy bHkgdmFndWUgKHlvdSBwcm9iYWJseSBtZWFuICJObyBJUFIgZGlzY2xvc3VyZXMgaGF2ZQ0KPiBi ZWVuIG1hZGUgdG8gdGhlIElFVEYgcmVsYXRlZCB0byB0aGlzIGRvY3VtZW50LCB0byBSRkMgNDQ0 NyBvciBSRkMgNjcyMywNCj4gb3IgdG8gdGhlIEludGVybmV0LURyYWZ0cyB0aGF0IHJlc3VsdGVk IGluIFJGQyA0NDQ3IGFuZCBSRkMgNjcyMy7igJ0pLg0KDQpvayAtIHdpbGwgY2hhbmdlLg0KDQo+ IC0tLQ0KPiANCj4gPSBOaXRzID0NCj4gDQo+IEluIHRoZSBBYnN0cmFjdCwgcHJvYmFibHkuLi4N Cj4gDQo+IE9MRA0KPiAgIFRoaXMgZG9jdW1lbnQgaGFzIGJlZW4gd3JpdHRlbiB0byBhZGRyZXNz IGVycmF0YSBpbiBhIHByZXZpb3VzDQo+ICAgdmVyc2lvbiBvZiB0aGlzIHN0YW5kYXJkLg0KPiBO RVcNCj4gICBUaGlzIGRvY3VtZW50IGhhcyBiZWVuIHdyaXR0ZW4gdG8gYWRkcmVzcyBlcnJhdGEg aW4gYSBwcmV2aW91cw0KPiAgIHZlcnNpb24gb2YgdGhpcyBzcGVjaWZpY2F0aW9uLg0KPiBFTkQN Cj4gDQo+IEJ1dCwgYWN0dWFsbHksIEkgdGhpbmsgeW91IGFyZSBtaXNzaW5nIHRoZSBtYWluIHB1 cnBvc2Ugd2hpY2ggaXMgdG8NCj4gYWR2YW5jZSB0aGUgc3BlYyB0byBmdWxsIHN0YW5kYXJkLg0K DQpBcyBub3RlZCBhYm92ZSBJIHRoaW5rIHRoZSBrZXkgd2FzIGZpeGluZyBlcnJhdGEuICBUaGUg c3RhbmRhcmQgdGhpbmcgY2FtZSBhZnRlciB0aGF0IC0gYnV0IHRoYXQgbWF5IGJlIG1lIGFuZCBM dWNhIG1pcy1yZW1lbWJlcmluZyB0aGUgaGlzdG9yeS4NCg0KPiBPbiByZWZsZWN0aW9uLCBJIHRo aW5rIHRoYXQgdGhpcyBwYXJhZ3JhcGggcHJvYmFibHkgc2VydmVkIHdlbGwgaW4gdGhlDQo+IGRy YWZ0IGFzIGl0IHdhcyBiZWluZyBwcm9jZXNzZWQsIGJ1dCBjYW4gYmUgcmVtb3ZlZCBub3cuIFRo ZSBlcXVpdmFsZW50IA0KPiB0ZXh0IG9idmlvdXNseSBuZWVkcyB0byBiZSBpbiB0aGUgc2hlcGhl cmQgd3JpdGUtdXAuDQoNCm9rIC0gdGhhdCBtYWtlcyBzZW5zZS4NCg0KPiBbZGl0dG8gdGhlIHBh cmFncmFwaCBpbiB0aGUgaW50cm9kdWN0aW9uXQ0KDQpkaXR0by4NCg0KPiAtLS0NCj4gDQo+IFRo YW5rIHlvdSBmb3IgaW5jbHVkaW5nIFNlY3Rpb24gMS4gSXQncyBpbXBvcnRhbnQgYW5kIGhlbHBm dWwuDQo+IA0KPiBUaHJlZSB0aW55IHBvaW50czoNCj4gDQo+IFNlY29uZCBwYXJhIHNob3VsZCBw cm9iYWJseSBzL0hvd2V2ZXIvQWRkaXRpb25hbGx5Lw0KDQp3aWxsIGZpeC4NCg0KPiBUaGUgUkZD IEVkaXRvciByZXF1aXJlcyB0aGF0IHNlY3Rpb24gMSBpcyB0aGUgSW50cm9kdWN0aW9uLiBBIHNp bXBsZQ0KPiBzb2x1dGlvbiBpcyB0byBzd2FwIHNlY3Rpb25zIDEgYW5kIDIsIG9yIHRvIG1vdmUg dGhlIGN1cnJlbnQgc2VjdGlvbiAyDQo+IHRvIGJlIHRoZSBuZXcgc2VjdGlvbiAxIGFuZCB0aGUg Y3VycmVudCBzZWN0aW9uIDEgdG8gYmUgc2VjdGlvbiAxLjEuDQoNCmFnYWluIC0gdGhhdCBtYWtl cyBzZW5zZS4NCg0KPiBUaGUgdGV4dCBzYXlzICJBIG5vdGUgd2FzIGFkZGVkIHRvIGNsYXJpZnkg dGhhdCB0aGUgQy1iaXQgaXMgcGFydCBvZiANCj4gdGhlIEZFQy4iIEkgdGhpbmsgeW91IHNob3Vs ZCBzL3dhcy9oYXMgYmVlbi8gYW5kIHlvdSBjb3VsZCBhbHNvIHVzZWZ1bGx5DQo+IGdpdmUgYSBs aXR0bGUgaGludCBhcyB0byB3aGVyZSB0aGUgbm90ZSB3YXMgYWRkZWQuDQoNCm9rLg0KDQo+IC0t LQ0KPiANCj4gU2hvdWxkbid0IHlvdSBtZW50aW9uIHRoZSBpbmNsdXNpb24gb2YgdGV4dCByZWZl cmVuY2luZyA3MzU4PyBUaGlzIGlzDQo+IGNsZWFybHkgYSBjaGFuZ2UgdG8gdGhlIG9yaWdpbmFs IHRleHQuIEkgd29uZGVyLCBob3dldmVyLCB3aGV0aGVyIHdoYXQNCj4gcmVhbGx5IHdhbnQgdG8g ZG8gaXMgdGFrZSB0aGF0IHBhcnQgb2YgNzM1OCB0aGF0IHVwZGF0ZWQgNDQ0NyBhbmQgc2ltcGx5 DQo+IHdyaXRlIGl0IGhlcmUgc28gdGhhdCB0aGlzIHNwZWMgaGFzIG5vIG5lZWQgb2YgdGhhdCBy ZWZlcmVuY2UuDQoNCnByZXN1bWFibHkgYmV0dGVyIHRvIHJlZmVyZW5jZSA3MzU4IHNvIHdlIGRv buKAmXQgZHVwbGljYXRlIHRleHQ/DQoNCj4gRWl0aGVyIHdheSwgeW91IGFsc28gbmVlZCB0byB0 YWtlIGNhcmUgYWJvdXQgdGhlIHN0YWJpbGl0eSByZXF1aXJlbWVudCANCj4gZm9yIGFkdmFuY2Vt ZW50Lg0KDQp5b3UgbWVhbiBzdGFuZGFyZHMgdHJhY2sgdnMgaW5mb3JtYXRpb25hbCBldGMuPw0K DQotLS0NCj4gDQo+IEluIDYuMi4yLjENCj4gcGxlYXNlIG5vdGUgdGhhdCBJQU5BIGhhcyAiUFcg SW50ZXJmYWNlIFBhcmFtZXRlcnMgVExWIiBub3QgIkludGVyZmFjZQ0KPiBQYXJhbWV0ZXJzIFRM ViIuDQo+IA0KPiBUaGUgaXMgYSBnb29kIGNoYW5jZSB0byBtYWtlIHRoaXMgY29uc2lzdGVudC4N Cg0Kb2sNCg0KPiAtLS0NCj4gDQo+IEluIDYuMi4yLjIgYW5kIHRoZSByZXN0IG9mIHRoZSBkb2N1 bWVudCwgcGxlYXNlIG5vdGUgdGhhdCB0aGUgSUFOQSBoYXMNCj4gIlBXIEdyb3VwIElEIFRMViIg bm90ICJQVyBHcm91cGluZyBJRCBUTFYiLg0KPiANCj4gVGhlIGlzIGEgZ29vZCBjaGFuY2UgdG8g bWFrZSB0aGlzIGNvbnNpc3RlbnQuDQoNCm9rDQoNCj4gLS0tDQo+IA0KPiA2LjMuMiBoYXMgYSBm aWd1cmUgd2hpY2ggY2xhaW1zIHRvIGluY2x1ZGUgYSAiUFdJZCBGRUMgVExWIiBvciBhDQo+ICJH ZW5lcmFsaXplZCBJRCBGRUMgVExWIi4gSG93ZXZlciwgNi4xIGFuZCA2LjIgZGVzY3JpYmUgdGhl c2UgYXMNCj4gImVsZW1lbnRzIiBub3QgVExWcyBhbmQgdGhleSBzaG93IHVwIGluIHRoZSBGb3J3 YXJkaW5nIEVxdWl2YWxlbmNlIENsYXNzDQo+IChGRUMpIFR5cGUgTmFtZSBTcGFjZS4NCj4gDQo+ IEkgdGhpbmsgeW91IGNhbiBjbGFyaWZ5IDYuMy4yIGJ5IGV4cGxhaW5pbmcgdGhhdCB3aGF0IGlz IGluY2x1ZGVkIGhlcmUNCj4gaXMgImEgRkVDIFRMViBjb250YWluaW5nIGVpdGhlciBhIFBXSWQg RkVDIGVsZW1lbnQgb3IgYSBHZW5lcmFsaXplZCBGRUMNCj4gZWxlbWVudC4NCj4gDQo+IFRoZW4s IGp1c3QgYWZ0ZXIgdGhlIGZpZ3VyZSB5b3UgaGF2ZSAiVGhlIFBXIEZFQyBUTFYiIGJ1dCBpdCBp cyBqdXN0IGENCj4gIkZFQyBUTFbigJ0NCg0Kb2sNCg0KPiAtLS0NCj4gDQo+IEluIDcuMyB5b3Ug aGF2ZSAicmUtcHJvdmlzaW9uZWQiLiBJIHdvbmRlciB3aGV0aGVyIHlvdSBtZWFuDQo+ICJyZS1j b25maWd1cmVkIi4gIlByb3Zpc2lvbmluZyIgaGFzIGEgY29udGV4dCBpbml0aWFsIHNldC11cCwg c28gcmUtDQo+IHByb3Zpc2lvbmluZyBzdWdnZXN0cyAodG8gbWU/KSByZS1pbml0aWFsaXphdGlv bi4NCg0Kb2sNCg0KPiAtLS0NCj4gDQo+IEluIHRoZSBmaXJzdCBwYXJhIG9mIDcuMyB5b3UgaGF2 ZSAiUFcgQy1iaXQgbmVnb3RpYXRpb24gcHJvY2VkdXJlIiBhbmQNCj4gIkNvbnRyb2wtV29yZCBu ZWdvdGlhdGlvbiBwcm9jZWR1cmVzIi4NCj4gDQo+IENvdWxkIHlvdSBkZWNpZGUgb24gYSBzaW5n bGUgbmFtZSwgYW5kIG9uIHdoZXRoZXIgaXQgaXMgc2luZ3VsYXIgb3INCj4gcGx1cmFsLg0KPiAN Cg0Kb2sNCg0KPiAtLS0NCj4gDQo+IDcuMw0KPiBPTEQNCj4gICAgICAgIC1pLiBJZiBsb2NhbCBQ RSBoYXMgcHJldmlvdXNseSBzZW50IGEgTGFiZWwgTWFwcGluZyBtZXNzYWdlLCBpdA0KPiAgICAg ICAgICAgIE1VU1Qgc2VuZCBhIExhYmVsIFdpdGhkcmF3IG1lc3NhZ2UgdG8gcmVtb3RlIFBFIGFu ZCB3YWl0DQo+IE5FVw0KPiAgICAgICAgLWkuIElmIHRoZSBsb2NhbCBQRSBoYXMgcHJldmlvdXNs eSBzZW50IGEgTGFiZWwgTWFwcGluZyBtZXNzYWdlLCBpdA0KPiAgICAgICAgICAgIE1VU1Qgc2Vu ZCBhIExhYmVsIFdpdGhkcmF3IG1lc3NhZ2UgdG8gdGhlIHJlbW90ZSBQRSBhbmQgd2FpdA0KPiBF TkQNCg0Kb2sNCg0KPiAtLS0NCj4gDQo+IDcuMw0KPiBPTEQNCj4gICAgICAgLWlpLiB0aGUgbG9j YWwgUEUgTVVTVCBzZW5kIGEgbGFiZWwgcmVsZWFzZSBtZXNzYWdlIHRvIHRoZSByZW1vdGUNCj4g TkVXDQo+ICAgICAgIC1paS4gVGhlIGxvY2FsIFBFIE1VU1Qgc2VuZCBhIExhYmVsIFJlbGVhc2Ug bWVzc2FnZSB0byB0aGUgcmVtb3RlDQo+IEVORA0KDQpvaw0KDQo+IC0tLQ0KPiANCj4gNy4zDQo+ IHMvbmVnb3RhaWF0aW9uL25lZ290aWF0aW9uLw0KPiBzL3JlbmVnb3RhdGlvbi9yZW5lZ290aWF0 aW9uLw0KDQpvaw0KDQo+IC0tLQ0KPiANCj4gNy4zDQo+IA0KPiAgIFRoZSBhYm92ZSBDLWJpdCBy ZW5lZ290aWF0aW9uIHByb2Nlc3MgU0hPVUxEIE5PVCBiZSBpbnRlcnJ1cHRlZCB1bnRpbA0KPiAg IGl0IGlzIGNvbXBsZXRlZCwgb3IgdW5wcmVkaWN0YWJsZSByZXN1bHRzIG1pZ2h0IG9jY3VyLg0K PiANCj4gVGhpcyBpcyBhIGJpdCBvZGQuIE5vcm1hbGx5IHRoZSAib3IiIHRoYXQgZm9sbG93cyBh ICJTSE9VTEQiIG9yICJTSE9VTEQNCj4gTk9UIiBleHBsYWlucyB0aGUgY29uZGl0aW9ucyB1bmRl ciB3aGljaCB5b3UgbWlnaHQgd2FudCB0byB2YXJ5IHRoZSANCj4gIlNIT1VMRCIuIA0KPiANCj4g QnV0IEknbSBzdHJ1Z2dsaW5nOiBpbnRlcnJ1cHRlZCBieSB3aG9tIGFuZCBieSBkb2luZyB3aGF0 Pw0KDQpJ4oCZbGwgaGF2ZSB0byBkZWZlciB0byBMdWNhIGhlcmUuDQoNCj4gDQo+IC0tLSANCj4g DQo+IFNvbWUgb2YgdGhlIGZvcm1hdHRpbmcgaW4gdGhlIHJlZmVyZW5jZXMgc2VlbXMgdG8gaGF2 ZSBiZWVuIGhpdCB3aXRoIGENCj4gZ2xvYmFsIGNoYW5nZSBvZiAvLiAvLiAgLyBZb3UgbWlnaHQg d2FudCB0byBwb2xpc2guDQoNCndpbGwgZG8NCg0KPiAtLS0NCj4gDQo+IFRoZSBsYXRlc3QgdmVy c2lvbiBvZiBHLjcwNyBpcyBkYXRlZCBKYW51YXJ5IDIwMDcuIElzIHRoZXJlIGFueSByZWFzb24N Cj4gdG8gbm90IHVwZGF0ZSB0aGUgcmVmZXJlbmNlPw0KDQpwcm9iYWJseSBqdXN0IHRoYXQgd2Ug bmV2ZXIgcmV2aXNpdGVkIGl0Lg0KDQo+IC0tLQ0KPiANCj4gSGF2ZSBhIGxvb2sgYXQgU2VjdGlv biA4IG9mIFJGQyA1MDM2IGZvciBhbiBleGFtcGxlIG9mIGEgbmljZSB3YXkgdG8NCj4gaGFuZGxl ICJsZWdhY3kgYXV0aG9ycyIgYW5kIGNyZWRpdHMgZm9yIHBhc3Qgd29yay4NCj4gDQo+IEluIGFu eSBjYXNlLCB0aGUgUkZDIEVkaXRvciB3aWxsIHJlcXVpcmUgdGhhdCBTZWN0aW9uIDE1IGlzIHJl bmFtZWQgDQo+ICJDb250cmlidXRvcnPigJ0uDQoNCm9rDQoNCj4gLS0tDQo+IA0KPiBUaGVyZSBh cmUgdHdvIHRyaXZpYWwgbml0cyBmcm9tIGlkbml0cy4NCj4gDQoNCndpbGwgdGFrZSBhIGxvb2sN Cg0KR2lsZXM= From nobody Thu May 5 07:17:52 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9A812DA41; Thu, 5 May 2016 07:17:51 -0700 (PDT) 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 RhTTI-xfjlW0; Thu, 5 May 2016 07:17:43 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 8C36412DA56; Thu, 5 May 2016 07:12:18 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id a17so30043770wme.0; Thu, 05 May 2016 07:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=YVtYk46LqzOOh6Ghg9BxMy0sgzLxNAfvVRf7aP9bAWs=; b=HHf51fxnJ6u0D7ylXioXGzxBXSXDiiFIUFU0cxbQIOgXnehx1CUqxQY1M1e03P88Yc 3oPvP2Piep/oMa16lkZ0bfCJbD2IMX6jJrX1kNRT+drv1YcIC/sS95i9A9aAIJ4cQQx1 UtuyKWmjrhPoY5kH1ZLR+AiSfJnuV+YW5xpZFtT7azdvcPc1QL2RWrJdtrPXxSujwxaW I32zptNReu11VdEnUiM8VDjhNpMN3Jq02qE+lneswyAFk6S5IDlcvfDLIOL7Dmqc0Jgf OVKFIDpgog0C4dMIHEbs6x5D1nr6dQHwFOIzhJSLX7qHam9vnwCrx8xKoumbFsMeSs4W Gz2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=YVtYk46LqzOOh6Ghg9BxMy0sgzLxNAfvVRf7aP9bAWs=; b=AsAczJg95SCze7Dchx5KvEnXNVpMn45Bnkb192S1QY/DuDtNfZ3IaUASL6vGzqX822 1x1+ce/CDuXW7+AyeXLsU03gKHJdLBstNadMR7FQWbKKsmV4Cdrjq66JLGMcHyWrOx0P xWUj7DHP2gUqffW5HbAlLm1QAO6ycjXpmBJNnr4mdi+nbHo8FMzU8C+p9SPS1wrq0vun 3+U5GxnKUq5fjXzwnOoZnx/GN9PbvzJ6726i+zLqRIUAkvQQufGcQOwn+56OU6XcWR/6 Q/JUtHsR0PgWIDAViYppieaFLz/CuRFPEd9Xlfb1Dky1TMu75vQFxO9GKLaWiVISGdyX b1+w== X-Gm-Message-State: AOPr4FV9JXqUHoRuXRKgMdc7FKzZyF4FX++hibWiX4WGZzysnLUXwI0blyLLWVvd+2nWQA== X-Received: by 10.194.94.229 with SMTP id df5mr14538030wjb.176.1462457536894; Thu, 05 May 2016 07:12:16 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id cf6sm9952097wjc.12.2016.05.05.07.12.14 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 May 2016 07:12:15 -0700 (PDT) To: "Giles Heron (giheron)" , "adrian@olddog.co.uk" , "Luca Martini (lmartini)" References: <035501d16cba$d1e22270$75a66750$@olddog.co.uk> <41025DD4-8D96-4FCC-A9B9-00CD2DA71236@cisco.com> From: Stewart Bryant Message-ID: <572B54BD.1090101@gmail.com> Date: Thu, 5 May 2016 15:12:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <41025DD4-8D96-4FCC-A9B9-00CD2DA71236@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-pals-rfc4447bis.all@ietf.org" , "pals-chairs@tools.ietf.org" Subject: Re: [RTG-DIR] Routing Directorate review of draft-ietf-pals-rfc4447bis X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 14:17:51 -0000 Please see SB> On 05/05/2016 12:11, Giles Heron (giheron) wrote: > Hi Adrian/Luca, > > sorry for the slow response on this. > > We may need to iterate one more time too :( > >> On 21 Feb 2016, at 15:16, Adrian Farrel wrote: >> >> Hello, >> >> I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >> >> Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them as the draft advances, and strive to resolve them through discussion or by updating the draft. >> >> Thanks, >> Adrian >> >> === >> >> Document: draft-ietf-pals-rfc4447bis-03.txt >> Reviewer: Adrian Farrel >> Review Date: 21 February 2016 >> IETF LC End Date: Not yet started >> Intended Status: Internet Standard >> >> = Summary = >> >> I have some minor concerns about this document that I think should be resolved before publication. >> >> = Comments = >> >> I'm OK to see 4447 being advanced to full standard, although I'm also a little surprised that there was energy to do it. >> >> The work is largely mechanical. My comments are a mix of minor process concerns (that your AD should be able to resolve), minor text clarifications, and nits. >> >> It's been a while since I was concerned with LDP, but I have no reason to doubt the integrity of this document. >> >> = Major Issues = >> >> No major issues found. >> >> = Minor Issues = >> >> I believe that this document should be marked as obsoleting 4447 and >> 6723. It will result in a new RFC with a new number, so 4447 will no >> longer be relevant. And, as Section 1 says: a new section (6.3) on >> control-word renegotiation by label request message has been added, >> obsoleting RFC 6723. > it is marked that way. but it’s only when it goes to RFC that that gets into the text? SB> No, Giles, Adrian is correct. The Top Left corner of the front page should have a list of RFCs being obsoleted. SB> Thus after "Intended status: Internet Standard" there should be a line saying SB> Obsoletes: RFC4447, RFC6723 SB> We also need replace the last para in the Abstract with something like. SB> This document has been published to address RFC4447 errata. It replaces SB> RFC4447 and incorporates the correction published in RFC6723. In doing SB> so it obsoletes RFC4447 and RFC6723. SB> At the end of Section 1, you need something like: SB> This document replaces and thus obsoletes RFC4447 and RFC6723. > >> By the way, it is section 7.3 (not 6.3) that you have added! > thanks! will fix :) > >> [NB: Q16 of the Shepherd write-up seems a bit garbled on this front. >> Especially "Will publication of this document change the status of any >> existing RFCs?" seems to need a much clearer answer!] > :) SB> I will update the Shepherds report when the new version of RFC4447bis is uploaded >> --- >> >> I'm not up to speed on the new process for advancing a specification to >> Internet-Standard when it has normative references that are not >> similarly advanced/advancing. I do know that the process changed >> recently and I am sure that your AD can look it up. > I wait with bated breath ;) > >> --- >> >> It might be a reasonable question to ask why some of the >> (informatively) referenced related PW RFCs (such as encapsulations) >> are not being advanced at the same time, especially those that are >> described as "companion documents”. > RFC4447-bis is being done because there were too many errata on 4447. There won’t as many on the others. I think the promotion to Internet Standard happened as part of that? SB> Promotion to standard seemed the right thing given the wide deployment of this signalling scheme. SB> If we all feel that we need to jump through too many hoops, we could just leave it as PS, although all of the issues we are discussing here will need to be addressed either way. > >> --- >> >> It seems unnecessary petty-fogging process, but the inclusion of >> section 7.3 seems to me to defeat the stability requirement for >> advancement to Internet Standard unless your claim here is that you >> are advancing 4447 and 6723 together in this single document. That >> might be fine. > the issue is that 4447 failed to cover a corner-case that was documented in 6723. So 6723 could be seen as a super-erratum on 4447. 4447bis merges it in as a single document. > >> --- >> >> The Errata that have been deliberately disregarded need to be marked as >> Rejected. I think the ones that have been actioned could usefully be >> marked as Verified or have a note added saying "fixed in RFCabcd". >> >> As far as I can tell: >> >> 3554 was not actioned > it was actioned, but with better wording (IMO) than the erratum > >> 938 was done >> 86 was done >> 3555 was done >> 3115 no longer applies >> 3114 was done >> 3112 was done >> 1530 was done > yup. > >> --- >> >> Because you (incorrectly) said that section 6.3 was new text, I gave it >> careful review. I think the text is in rather poor state: >> >> For example, in 6.3.1... >> >> Using the procedures >> outlined in this section, a simple label withdraw method MAY also be >> supported as a legacy means of signaling PW status and AC status. >> >> ...Since this is *the* specification now, what does "legacy" mean? > it means for interop with extremely old implementations (implementations that were pre the 4447 standard). > >> Indeed, you end 6.3.1 with... >> The PW status >> signaling procedures described in this section MUST be fully >> implemented. >> ...which kind of implies ... hmm. > yes - they must be implemented. But you can interwork with “legacy”. > >> I think you could rework 6.3.1 to handle this more gracefully and avoid >> the "clunk" of the 2nd para... >> >> Once the PW status negotiation procedures are completed and if they >> >> ...where we are surprised to hear about status negotiation. >> >> For example: >> >> OLD >> The PEs MUST send Label Mapping Messages to their peers as soon as >> the PW is configured and administratively enabled, regardless of the >> attachment circuit state. The PW label should not be withdrawn >> unless the operator administratively configures the pseudowire down >> (or the PW configuration is deleted entirely). Using the procedures >> outlined in this section, a simple label withdraw method MAY also be >> supported as a legacy means of signaling PW status and AC status. In >> any case, if the label-to-PW binding is not available the PW MUST be >> considered in the down state. >> >> Once the PW status negotiation procedures are completed and if they >> result in the use of the label withdraw method for PW status >> communication, and this method is not supported by one of the PEs, >> then that PE must send a Label Release Message to its peer with the >> following error: >> >> "Label Withdraw PW Status Method Not Supported" >> >> If the label withdraw method for PW status communication is selected >> for the PW, it will result in the Label Mapping Message being >> advertised only if the attachment circuit is active. The PW status >> signaling procedures described in this section MUST be fully >> implemented. >> NEW >> The PEs MUST send Label Mapping Messages to their peers as soon as >> the PW is configured and administratively enabled, regardless of the >> attachment circuit state. The PW label should not be withdrawn >> unless the operator administratively configures the pseudowire down >> (or the PW configuration is deleted entirely). >> >> Section 6.3.2 describes a mechanism for signaling the status of the >> PW and AC. Additionally, a simple label withdraw method MAY be used >> to signal the PW status and AC status. In any case, if the label-to- >> PW binding is not available the PW MUST be considered to be in the >> down state. >> >> The PEs negotiate which PW and AC status signaling mechanism to use >> by following the procedures in Section 6.3.3. If the PW negotiation >> procedures are completed and if they result in the use of the simple >> label withdraw method for PW status communication, and if this method >> is not supported by one of the PEs then that PE must send a Label >> Release Message to its peer with the following error: >> >> "Label Withdraw PW Status Method Not Supported" >> >> If the label withdraw method for PW status communication is selected >> for the PW, it will result in the Label Mapping Message being >> advertised only if the AC is active. >> >> The PW status signaling procedures described in Section 6.3.2 MUST be >> fully implemented. >> END > I’m not sure we want to make big text changes at this stage for marginal benefit? > >> --- >> >> Section 6.3.2 achieves ambiguity by stating... >> The general format of the Notification Message is: >> ...and then showing the specific case of "PW status". >> >> You can fix this by re-ordering and tweaking slightly, as follows. >> >> Note that the old text says: >> Since this notification does not >> refer to any particular message, the Message Id and Message Type >> fields are set to 0. >> ...but I think the Message Type is set to 0x0001 :-) >> >> >> OLD >> The Status TLV is transported to the remote PW peer via the LDP >> Notification message. The general format of the Notification Message >> is: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| Notification (0x0001) | Message Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Message ID | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Status (TLV) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | PW Status TLV | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | PWId FEC TLV or Generalized ID FEC TLV | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | PW Grouping ID TLV (Optional) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> >> The Status TLV status code is set to 0x00000028, "PW status", to >> indicate that PW status follows. Since this notification does not >> refer to any particular message, the Message Id and Message Type >> fields are set to 0. >> NEW >> The Status TLV is transported to the remote PW peer via the LDP >> Notification message as described in [RFC5036]. >> >> The Status TLV status code is set to 0x00000028, "PW status", to >> indicate that PW status follows. The format of the Notification >> Message for carrying the PW Status is as follows: >> >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| Notification (0x0001) | Message Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Message ID | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Status (TLV) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | PW Status TLV | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | PWId FEC TLV or Generalized ID FEC TLV | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | PW Grouping ID TLV (Optional) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> Since this notification does not refer to any particular message, >> the Message Id field is set to 0. >> END > > again I’m not sure I’d want to make major changes to the text if we can avoid it. > >> --- >> >> Section 8 could be tidied a little. >> >> The use of "in general" gives the IANA no way to know whether they >> should or should not update a reference. > I think maybe we just need a note asking IANA to remove this section once the RFC is published, and to update all the registries with the new number of this RFC? SB> I think the point that Adrian is making is that you should strike "in general". SB> All of the IANA entries that point to RFC4447 should be replaced. > >> Are you sure that you want to remove the nice, concise listing of code >> points that are present in RFC 4447? > yeah - I think we removed them to avoid risk of contradicting the registry. > >> 8.1, 8.2, and 8.3 all say "new". I suggest deleting that word. > ok - we’ll rely on IANA to do this :) > >> And lastly, "IANA needs to..." is not what we say :-) "IANA is requested >> to..." is nicer. > hopefully my new wording for section 8 will be nicer :) > >> [NB: The Shepherd write-up seems to report all this wrongly at Q17] SB> I have corrected the Shepherd's writeup. >> --- >> >> Shouldn't the whole of Section 10 be moved to an interop report >> somewhere? It's presence within the document seems somewhat temporally >> unstable. I understand that you want to write it down and record it >> somewhere, also that you probably developed it in the I-D as a useful >> place for working text. For advice about how and where to do this you >> can look at RFC 5657. > The AD asked us to put this in to provide evidence for moving to Internet Standard. Happy to remove it again of course if the AD requests :) > >> You seem to have answered the four points from 6410, but may be missing >> a little corroboration. >> >>> The pseudowire technology was first deployed in 2001 and has been >>> widely deployed by many carriers. [RFC7079] documents the results of >>> a survey of PW implementations, with specific emphasis on Control >>> Word usage. [EANTC] documents a public multi-vendor interoperability >>> test of MPLS and Carrier Ethernet equipment, which included testing >>> of Ethernet, ATM and TDM pseudowires. >> 7079 is a slightly related piece of survey work, but the only mention of >> LDP (which is the subject of *this* document) is to point out an issue >> with non-implementation. > understood. We were just trying to show that PW was widely implemented. > >> The EANTC reference really needs something that helps us find the report >> of the interop event. Possibly this is >> http://www.eantc.de/fileadmin/eantc/downloads/events/2007-2010/MPLSEWC09/EANTC-MPLSEWC2009-WhitePaper-v1.0.pdf >> Looking at that paper, it definitely supports the claim of multiple >> interoperating implementations of 4447. > can we put URLs into references? And can they be that long? ;) SB> Yes, and Yes > >> We lack, however, any statements about "widespread deployment and >> successful operational experience.” > I put: "The pseudowire technology was first deployed in 2001 and has been widely deployed by many carriers.” I’m not sure what more we can do. Provide lists of carriers offering services based on pseudowires? That’d be *very* temporarlly unstable ;) > >>> The errata against [RFC4447] are all editorial in nature and have >>> been addressed in this document. >> Good (except for those not addressed as above, and except that some of >> those errata are incorrectly marked as "Technical”). > so they’re all addressed as noted above. And we can say “mostly editorial”? > >>> All features in this specification have been implemented by multiple >>> vendors. >> How do we know this? > I’m really not sure how we prove that. > >> Further, are all the features used? One point of this step in the >> process is to prune out features that are unnecessary (and so complicate >> implementation and operation, and cost money). > right - so as far as we know all the features are in use by multiple vendors. I’ve asked around inside Cisco to check our implementations, but I’m very happy for someone else to check with our competitors. > >>> There is no IPR filed against this document or its predecessor. >> This may be overly vague (you probably mean "No IPR disclosures have >> been made to the IETF related to this document, to RFC 4447 or RFC 6723, >> or to the Internet-Drafts that resulted in RFC 4447 and RFC 6723.”). > ok - will change. > >> --- >> >> = Nits = >> >> In the Abstract, probably... >> >> OLD >> This document has been written to address errata in a previous >> version of this standard. >> NEW >> This document has been written to address errata in a previous >> version of this specification. >> END >> >> But, actually, I think you are missing the main purpose which is to >> advance the spec to full standard. > As noted above I think the key was fixing errata. The standard thing came after that - but that may be me and Luca mis-remembering the history. SB> I am fairly sure that the Chairs suggested moving to Full Std. As I said earlier if it is too many hoops perhaps we should just publish as PS, although that says something about the IETF process given how widely this is implemented. > >> On reflection, I think that this paragraph probably served well in the >> draft as it was being processed, but can be removed now. The equivalent >> text obviously needs to be in the shepherd write-up. > ok - that makes sense. > >> [ditto the paragraph in the introduction] > ditto. > >> --- >> >> Thank you for including Section 1. It's important and helpful. >> >> Three tiny points: >> >> Second para should probably s/However/Additionally/ > will fix. > >> The RFC Editor requires that section 1 is the Introduction. A simple >> solution is to swap sections 1 and 2, or to move the current section 2 >> to be the new section 1 and the current section 1 to be section 1.1. > again - that makes sense. > >> The text says "A note was added to clarify that the C-bit is part of >> the FEC." I think you should s/was/has been/ and you could also usefully >> give a little hint as to where the note was added. > ok. > >> --- >> >> Shouldn't you mention the inclusion of text referencing 7358? This is >> clearly a change to the original text. I wonder, however, whether what >> really want to do is take that part of 7358 that updated 4447 and simply >> write it here so that this spec has no need of that reference. > presumably better to reference 7358 so we don’t duplicate text? > >> Either way, you also need to take care about the stability requirement >> for advancement. > you mean standards track vs informational etc.? > > --- >> In 6.2.2.1 >> please note that IANA has "PW Interface Parameters TLV" not "Interface >> Parameters TLV". >> >> The is a good chance to make this consistent. > ok > >> --- >> >> In 6.2.2.2 and the rest of the document, please note that the IANA has >> "PW Group ID TLV" not "PW Grouping ID TLV". >> >> The is a good chance to make this consistent. > ok > >> --- >> >> 6.3.2 has a figure which claims to include a "PWId FEC TLV" or a >> "Generalized ID FEC TLV". However, 6.1 and 6.2 describe these as >> "elements" not TLVs and they show up in the Forwarding Equivalence Class >> (FEC) Type Name Space. >> >> I think you can clarify 6.3.2 by explaining that what is included here >> is "a FEC TLV containing either a PWId FEC element or a Generalized FEC >> element. >> >> Then, just after the figure you have "The PW FEC TLV" but it is just a >> "FEC TLV” > ok > >> --- >> >> In 7.3 you have "re-provisioned". I wonder whether you mean >> "re-configured". "Provisioning" has a context initial set-up, so re- >> provisioning suggests (to me?) re-initialization. > ok > >> --- >> >> In the first para of 7.3 you have "PW C-bit negotiation procedure" and >> "Control-Word negotiation procedures". >> >> Could you decide on a single name, and on whether it is singular or >> plural. >> > ok > >> --- >> >> 7.3 >> OLD >> -i. If local PE has previously sent a Label Mapping message, it >> MUST send a Label Withdraw message to remote PE and wait >> NEW >> -i. If the local PE has previously sent a Label Mapping message, it >> MUST send a Label Withdraw message to the remote PE and wait >> END > ok > >> --- >> >> 7.3 >> OLD >> -ii. the local PE MUST send a label release message to the remote >> NEW >> -ii. The local PE MUST send a Label Release message to the remote >> END > ok > >> --- >> >> 7.3 >> s/negotaiation/negotiation/ >> s/renegotation/renegotiation/ > ok > >> --- >> >> 7.3 >> >> The above C-bit renegotiation process SHOULD NOT be interrupted until >> it is completed, or unpredictable results might occur. >> >> This is a bit odd. Normally the "or" that follows a "SHOULD" or "SHOULD >> NOT" explains the conditions under which you might want to vary the >> "SHOULD". >> >> But I'm struggling: interrupted by whom and by doing what? > I’ll have to defer to Luca here. > >> --- >> >> Some of the formatting in the references seems to have been hit with a >> global change of /. /. / You might want to polish. > will do > >> --- >> >> The latest version of G.707 is dated January 2007. Is there any reason >> to not update the reference? > probably just that we never revisited it. > >> --- >> >> Have a look at Section 8 of RFC 5036 for an example of a nice way to >> handle "legacy authors" and credits for past work. >> >> In any case, the RFC Editor will require that Section 15 is renamed >> "Contributors”. > ok > >> --- >> >> There are two trivial nits from idnits. >> > will take a look > > Giles From nobody Thu May 5 09:02:36 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AEF12D6B9; Thu, 5 May 2016 09:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 buM3K5MEYCZd; Thu, 5 May 2016 09:02:31 -0700 (PDT) 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 1165312D707; Thu, 5 May 2016 09:02:30 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id x201so107685676oif.3; Thu, 05 May 2016 09:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZZ+WlFYzt3COcRftrRd9y3jPH7N4kIOapkv7JklQay0=; b=xaxb6iXjhz4ZteTu2Jbf5KB30pZ8BfTAlL6Omzg/8mvoZ2BmnS9/s077OLNb6XW8cP 0gx9aIBh2sfq7Jkcm5Pa9XHcxxD2tMcYVPv/YCOvQWVKIFm4A4cXIeT9IqHob5waO/zi exc+c7kQXzpgV5joAEHDOhj8Tu4Pnj8HpZk3HzbP5I/kyKL/1vJ+Zau/h74Tkp+4tFfd Glh4fsO3QfbWx9i6OhBDFygc1Mwbt3dH8yKNENiKoKNBz8A6PaCaxHDqAnJclayA4xda 8DPROCM7CdQNyBrp+DWDKOS+HhSkniKX6HRVjKrXa0/Aw+nlrdLehi1OdPoGlNDyHpwm s0TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZZ+WlFYzt3COcRftrRd9y3jPH7N4kIOapkv7JklQay0=; b=GC/SeWLIf1C8oppMAN9zgiHBtiTF9abk3F+ve1GYqrzpqWeMxIvuXYWsxUiPWJAgGO JpcPnGz42s//7wbpssiQTS7dNmgJRSp9e5N5uJ+nYs8AD1jgRYwaMkLtiGeOXGUht4S1 xewoxPh/YnGDbStnALq+IdKSZxwd8si54avD0BRbN3cCyATXxYlGssJ9V5P2/BNv78MJ AfKhpgncHAD5WV5i485GOTzoOgkQRTTr9RlK/YlhzuvAwgx+EgT9BwY5fpqUZzAgTKom NlUiDkiPOGf29QULOKghFfRc/bwvf/lIGzk1FmEaCgpbKFq5ms9zJOumD4Z/Snj3gejq CmEA== X-Gm-Message-State: AOPr4FXo5YUcL6ZOCkZJ0n849r04g2iMqJr+5D40Aq6qREhArh45sxZdpAp4+JmTr6z4n9fIqv4+FJqvzMenKQ== X-Received: by 10.202.85.2 with SMTP id j2mr6550711oib.6.1462464150220; Thu, 05 May 2016 09:02:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.216 with HTTP; Thu, 5 May 2016 09:02:15 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Thu, 5 May 2016 12:02:15 -0400 Message-ID: To: "McPherson, Danny" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-trill-ia-appsubtlv@ietf.org" , "all@ietf.org" , "trill@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: TRILL: Interface Addresses APPsub-TLV X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 16:02:33 -0000 Hi Danny, Thanks for your comments. See below. On Wed, May 4, 2016 at 10:27 AM, McPherson, Danny wrote: > > Hello, > > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > 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 > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing > ADs, it would be helpful if you could consider them along with any > other IETF Last Call comments that you receive, and strive to > resolve them through discussion or by updating the draft. > > Document: draft-ietf-trill-ia-appsubtlv-07.txt > Reviewer: Danny McPherson > Review Date: May 4, 2016 > Intended Status: Proposed Standard > > > Summary: > > I have some minor concerns about this document that I think should > be resolved before publication. > > > Comments: > > I believe the draft is technically sound, however, the quality and > readability needs a bit more work, particularly as it relates to > introduction of new terms, and consistent application and use of all > terms. There are also some general error handling and encoding > issues that need to be given consideration. > > > Major Issues: > > I have no =E2=80=9CMajor=E2=80=9D issues with this I-D. Thanks. > Minor Issues: > > 1. ERROR HANDLING: There are a number of places in the document > where it discusses the receipt of malformed, badly encoded, > non-matching, or corrupt messages, and the advice is to either > [silently] discard or ignore the messages. Some general guidance > should be given here to enable operational diagnosis of any issues > that may result in temporal or persistent problems, where logging > and other actions should occur. Some aspects of this might leverage > the OAM Framework efforts, although it appears much of the TRILL > work leaves this to the implementer. In the IETF context "silently discard" means that there is no on-the-wire message sent. It says nothing about whether or not counters are kept of such condition or errors are logged. A suggestion to log such events and/or keep such counters can be added. > 2. When using =E2=80=9CNickname=E2=80=9D it would be useful to define the= encoding > as an unsigned 16-bit integer, or just reference "as specified in S > 3.7 of RFC6325=E2=80=9D. OK. Will add the reference. > 3. The inclusion of the =E2=80=9CTLV=E2=80=9D acronym in the "APPsub-TLV= =E2=80=9D TLV name > seems loose and redundant to me, as opposed to =E2=80=9CAPPsub TLV=E2=80= =9D or > similar. This comes from RFC 6823, Section 3.2, which says that sub-TLVs that go inside the GENAPP TLV "are refrred to as APPsub-TLVs". > 4. Inconsistent use of =E2=80=9CInterface Address APPsub-TLV=E2=80=9D, = =E2=80=9CIA > APPSub-TLV=E2=80=9D, =E2=80=9CInterface Address APP-subTLV=E2=80=9D, and = =E2=80=9CAppsubTLV=E2=80=9D makes > it seem like you=E2=80=99re talking about different things. OK - that should be made more consistent, probably standardizing on "IA APPsub-TLV". > 5. The use of =E2=80=9Csub-sub-TLV=E2=80=9D seems a bit loose and sloppy = to me as > well, and should be cleaned up. E.g., S 5.2 =E2=80=9CIA Appsub-TLV > Sub-Sub-TLVs SubRegistry" You don't like "sub-sub-TLV"? Seems like, strictly speaking, you have IS-IS PDUs which contain TLVs. Then some TLVs can contain sub-TLVs. (The GENAPP TLV is the only one that occurs to me with a special name for its sub-TLVs, namely APPsub-TLVs.) and some sub-TLVs can contain a further nested level, which it seems to me to be precise and logical to call sub-sub-TLVs. (I am not aware of any requirement for any more deeper nesting in a use of IS-IS.) So, would you prefer that what are called sub-sub-TLVs in this document just be called "sub-TLVs" (which I agree they are) resulting in two different levels with the same name? While there might be some errors in their use in this draft, the mere use of APPsub-TLV and sub-sub-TLV for the two levels does not seem "loose and sloppy" to me... > 6. Only one of the =E2=80=9CFigures=E2=80=9D is labeled / captioned OK. All the principal figures should be labeled. (I don't think cases where there is a small, indented figure that just expands part of a principal figure and appears shortly after the principal figure need to be captioned.) So, the initial figures in Sections 3.1, 3.2, 3.3, and 3.4 would have Figures numbers and captions added. > 7. The use of =E2=80=9CAddress Sets=E2=80=9D and =E2=80=9CAddress Sets En= ds=E2=80=9D makes it a bit > hard to read when used in sentences. Perhaps an acronym for each, > or hyphenating/underscoring them would make it more readable. OK - I'll see what I can do. > 8. S 3.4 the 2-byte =E2=80=9CType=E2=80=9D value in the diagram should be > =E2=80=9CTOPOLOGY=E2=80=9D, not =E2=80=9CDATALEN=E2=80=9D. Thanks for noticing this error. > 9. I noticed that Radia was a co-author until the last revision, and > now she doesn=E2=80=99t even exist in the Acknowledgements section. Whil= e > no explanation is required here, I did find this a bit odd. I think her listing as an author was in error. > 10. IANA Considerations: Some guidance from the IANA folks on the > formatting of this section might be in order. It=E2=80=99s not as clear = as > it could be about what their instructions are here. There are some improvements that could be made. In inverse order, Section 5.3 looks fine. In Section 5.2, "Available" should be changed to "Unassigned" as that is the preferred IANA term. Section 5.1 is talking about assignments that have already happened and looks OK as far as the table of values goes; however, the material after the first sentence after that table seems inappropriate in an "IANA Considerations" section and should, perhpas, be in a new "Processing Address Sets" section. > 11. S 2: It=E2=80=99s unclear to me if the =E2=80=9CConfidence=E2=80=9D v= alue of 255 =E2=80=9Cbeing > treated as if it was 254=E2=80=9D is inline with RFC6325 S 4.8.1 guidance= ? The idea is that local configuration or learning should be able to override address reachability received through network messages. Thus such information, when manually configured, defaults to have confidence 255. RFC 6325 Section 4.8.1 just says that information learned via ESADI will have a confidence of from 0 to 254 but don't actually say what to do if it is recreived as 255. This is updated by Section 6.2 RFC 7357, 1st paragraph, that makes it clear that a received value of 255 is just treated as if it was 254. Thus it is consistent with these prior RFCs to the IA APPsub-TLV draft to give this rule for handling the value 255 in the Confidence field of IP APPsub-TLVs. > 12. In general, I agree there appear to be no new Security > Considerations here. I do not believe Asymmetry will be an issue > with the forged packet discard issue although some consideration of > this might be in order (or perhaps simply a reference to SAVI or > other work here). I wonder if some consideration should be given to > broader disclosure of reachable layer 2 addresses here, but that > seems a bit reaching as well. > > > Nits: > > 1. Abstract & Introduction: s/by-pass/bypass/ OK. > 2. S.2: s/Data Label is reachable from /Data Label are reachable/ "... inteface ... is reachable ...", so I think "is" is correct but I'll see if I can re-word this sentence. > 3. A reference for the first use of AFN would be useful, perhaps to > the IANA registry. OK. > 4. Expressing TBD code points in [ ] brackets might help with > readability as well OK. > 5. S 3.2 =E2=80=9Cif the Length is 0 or 1 or less=E2=80=9D =E2=80=94 not = sure the =E2=80=9Cor less" > is necessary? OK, the "or less" should be removed. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Thu May 5 10:21:01 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514BD12D70A; Thu, 5 May 2016 10:20:59 -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_H4=-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 NCHt8sqNSB5n; Thu, 5 May 2016 10:20:56 -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 1369812D55E; Thu, 5 May 2016 10:20:54 -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 u45HKm42004816; Thu, 5 May 2016 18:20:48 +0100 Received: from 950129200 ([79.141.128.249]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u45HKjR6004753 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 5 May 2016 18:20:47 +0100 From: "Adrian Farrel" To: "'Stewart Bryant'" , "'Giles Heron \(giheron\)'" , "'Luca Martini \(lmartini\)'" References: <035501d16cba$d1e22270$75a66750$@olddog.co.uk> <41025DD4-8D96-4FCC-A9B9-00CD2DA71236@cisco.com> <572B54BD.1090101@gmail.com> In-Reply-To: <572B54BD.1090101@gmail.com> Date: Thu, 5 May 2016 18:20:42 +0100 Message-ID: <0ae301d1a6f2$756b5580$60420080$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGSd87YOfQiy969xmYfDEp2McHSGwIYAGERAme5Or2gBN+/8A== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22304.001 X-TM-AS-Result: No--14.187-10.0-31-10 X-imss-scan-details: No--14.187-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtE4HKI/yaqRm521GZGE81yGwx0jRRxcQfNY/2pi7PK0Er2U 9rkMF467oICjo9XRtmiycHJa2DktdIjQo/Iw2s1SmlaAItiONP24ml4cZGFcsUiO8DX9hL7ReP3 Zqt12BCySyAjRu6HqdtycgMKVtVy3Sr6L0atbOCyxOCMwQanpye8lj2kHOCDUN15VVRl9DpE+5v PA46mwB0NBiULvP93O8/m5n1VrRDLF8mOMzX07Ry/MZ1E/Ptpxk9chTaAgTrFXPwnnY5XL5ALyt DvV39h+gnSboVgI/abRR8x1Rs/IL54JPQewVPBv/bxP0FQ1eSGB2Ejud0204A2G3vz8l/IESl8p dB8xPzoWD5/PBB/OYpOFISpATtc43M/5tYlXywAD2WXLXdz+AV4GhfqhwUCy2Fq6de/aaIbQYQ2 xEnBjXPD770H84ApaUcYlGdKZ66w13IIF3ou0Vy4uTw19Klh6d0/IMHz0evkWnuSeJfGi8yzEhI i4UXuxf60/JilEiKTuHDnQiTpv2YDVR1zNwvHusyNb+yeIRAqAfODDLypXmqwgydzPLF7nidMoK S5QldA9KlurZE/oHNvmJcriAEaJmPnR7BD/zBXzh2yKdnl7WFZWFBQa1+Nf47ndse0z1bf0/WAk 5AfCS+TNoFDwCjWstmCgZGtEQyrqy2TyqbUcVGivjLE8DPtZOFrEjYh/1F6GisL/BZ/9PcB25Cd wiNdGWhZ7HebQga2rBcSSr/LTczurH0qx1kBYRqd7O4ywqbvx7plxxm1SPEklF5L0lQHcrildDD opgNvXI8pFTsC6AI9u3Nun6VJRpffDv4oDZL6eAiCmPx4NwFkMvWAuahr8ylNXFsiN4FpJKW4mD lJsMSAHAopEd76vgUjQ2feKYFonvWwvBkXZ0jOVrNZhUzMTL38WktyeJbzKCcpBg3VHng== Archived-At: Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, draft-ietf-pals-rfc4447bis.all@ietf.org, pals-chairs@tools.ietf.org Subject: Re: [RTG-DIR] Routing Directorate review of draft-ietf-pals-rfc4447bis X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 17:20:59 -0000 Stewart beat me to the draw on a couple of points. I agree with him, so = I've cut down to other issues. > >> I'm not up to speed on the new process for advancing a = specification to > >> Internet-Standard when it has normative references that are not > >> similarly advanced/advancing. I do know that the process changed > >> recently and I am sure that your AD can look it up. > > > > I wait with bated breath ;) Indeed! > >> It might be a reasonable question to ask why some of the > >> (informatively) referenced related PW RFCs (such as encapsulations) > >> are not being advanced at the same time, especially those that are > >> described as "companion documents=E2=80=9D. > > > > RFC4447-bis is being done because there were too many errata on = 4447. There > > won=E2=80=99t as many on the others. I think the promotion to = Internet Standard > > happened as part of that? >=20 > SB> Promotion to standard seemed the right thing given the wide > deployment of this signalling scheme. >=20 > SB> If we all feel that we need to jump through too many hoops, we = could > just leave it as PS, although all of the issues we are discussing here > will need to be addressed either way. So I'm not demanding anything, just asking the question that your AD = might also ask. I think promotion to standard is a fine idea for this document. I also = appreciate the desire to not ingest more work. However, I think some = (all?) of the other documents might advance with just a last call. Anyway. Whatever. > >> It seems unnecessary petty-fogging process, but the inclusion of > >> section 7.3 seems to me to defeat the stability requirement for > >> advancement to Internet Standard unless your claim here is that you > >> are advancing 4447 and 6723 together in this single document. That > >> might be fine. > > the issue is that 4447 failed to cover a corner-case that was = documented in > > 6723. So 6723 could be seen as a super-erratum on 4447. 4447bis = merges it in as > > a single document. Right. And Stewart's fixes for "obsoletes..." handle this. > >> Because you (incorrectly) said that section 6.3 was new text, I = gave it > >> careful review. I think the text is in rather poor state: > >> > >> For example, in 6.3.1... > >> > >> Using the procedures > >> outlined in this section, a simple label withdraw method MAY = also be > >> supported as a legacy means of signaling PW status and AC = status. > >> > >> ...Since this is *the* specification now, what does "legacy" mean? > > > > it means for interop with extremely old implementations = (implementations > > that were pre the 4447 standard). OK. Do we need that? Still? > >> Indeed, you end 6.3.1 with... > >> The PW status > >> signaling procedures described in this section MUST be fully > >> implemented. > >> ...which kind of implies ... hmm. > > > > yes - they must be implemented. But you can interwork with = =E2=80=9Clegacy=E2=80=9D. > > > >> I think you could rework 6.3.1 to handle this more gracefully and = avoid > >> the "clunk" of the 2nd para... > >> > >> Once the PW status negotiation procedures are completed and if = they > >> > >> ...where we are surprised to hear about status negotiation. > >> > >> For example: > >> > >> OLD > >> The PEs MUST send Label Mapping Messages to their peers as soon = as > >> the PW is configured and administratively enabled, regardless of = the > >> attachment circuit state. The PW label should not be withdrawn > >> unless the operator administratively configures the pseudowire = down > >> (or the PW configuration is deleted entirely). Using the = procedures > >> outlined in this section, a simple label withdraw method MAY = also be > >> supported as a legacy means of signaling PW status and AC = status. In > >> any case, if the label-to-PW binding is not available the PW = MUST be > >> considered in the down state. > >> > >> Once the PW status negotiation procedures are completed and if = they > >> result in the use of the label withdraw method for PW status > >> communication, and this method is not supported by one of the = PEs, > >> then that PE must send a Label Release Message to its peer with = the > >> following error: > >> > >> "Label Withdraw PW Status Method Not Supported" > >> > >> If the label withdraw method for PW status communication is = selected > >> for the PW, it will result in the Label Mapping Message being > >> advertised only if the attachment circuit is active. The PW = status > >> signaling procedures described in this section MUST be fully > >> implemented. > >> NEW > >> The PEs MUST send Label Mapping Messages to their peers as soon = as > >> the PW is configured and administratively enabled, regardless of = the > >> attachment circuit state. The PW label should not be withdrawn > >> unless the operator administratively configures the pseudowire = down > >> (or the PW configuration is deleted entirely). > >> > >> Section 6.3.2 describes a mechanism for signaling the status of = the > >> PW and AC. Additionally, a simple label withdraw method MAY be = used > >> to signal the PW status and AC status. In any case, if the = label-to- > >> PW binding is not available the PW MUST be considered to be in = the > >> down state. > >> > >> The PEs negotiate which PW and AC status signaling mechanism to = use > >> by following the procedures in Section 6.3.3. If the PW = negotiation > >> procedures are completed and if they result in the use of the = simple > >> label withdraw method for PW status communication, and if this = method > >> is not supported by one of the PEs then that PE must send a = Label > >> Release Message to its peer with the following error: > >> > >> "Label Withdraw PW Status Method Not Supported" > >> > >> If the label withdraw method for PW status communication is = selected > >> for the PW, it will result in the Label Mapping Message being > >> advertised only if the AC is active. > >> > >> The PW status signaling procedures described in Section 6.3.2 = MUST be > >> fully implemented. > >> END > > I=E2=80=99m not sure we want to make big text changes at this stage = for marginal > > benefit? It isn't a big technical change. It's just words. But if you are concerned then this needs to be a negotiation with the AD = "at this stage". Personally, I like specs that are easy to read :-) > >> Section 6.3.2 achieves ambiguity by stating... > >> The general format of the Notification Message is: > >> ...and then showing the specific case of "PW status". > >> > >> You can fix this by re-ordering and tweaking slightly, as follows. > >> > >> Note that the old text says: > >> Since this notification does not > >> refer to any particular message, the Message Id and Message Type > >> fields are set to 0. > >> ...but I think the Message Type is set to 0x0001 :-) > >> > >> > >> OLD > >> The Status TLV is transported to the remote PW peer via the LDP > >> Notification message. The general format of the Notification = Message > >> is: > >> > >> 0 1 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> |0| Notification (0x0001) | Message Length = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Message ID = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Status (TLV) = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | PW Status TLV = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | PWId FEC TLV or Generalized ID FEC TLV = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | PW Grouping ID TLV (Optional) = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> > >> > >> The Status TLV status code is set to 0x00000028, "PW status", to > >> indicate that PW status follows. Since this notification does = not > >> refer to any particular message, the Message Id and Message Type > >> fields are set to 0. > >> NEW > >> The Status TLV is transported to the remote PW peer via the LDP > >> Notification message as described in [RFC5036]. > >> > >> The Status TLV status code is set to 0x00000028, "PW status", to > >> indicate that PW status follows. The format of the Notification > >> Message for carrying the PW Status is as follows: > >> > >> > >> 0 1 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> |0| Notification (0x0001) | Message Length = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Message ID = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Status (TLV) = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | PW Status TLV = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | PWId FEC TLV or Generalized ID FEC TLV = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | PW Grouping ID TLV (Optional) = | > >> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> > >> Since this notification does not refer to any particular = message, > >> the Message Id field is set to 0. > >> END > > > > again I=E2=80=99m not sure I=E2=80=99d want to make major changes to = the text if we can avoid it. Ditto. > >> Section 8 could be tidied a little. > >> > >> The use of "in general" gives the IANA no way to know whether they > >> should or should not update a reference. > > > > I think maybe we just need a note asking IANA to remove this section = once the > > RFC is published, and to update all the registries with the new = number of this > > RFC? >=20 > SB> I think the point that Adrian is making is that you should strike > "in general". >=20 > SB> All of the IANA entries that point to RFC4447 should be replaced. Yeah, the section is needed and so are the instructions. But "in = general" is unnecessary. > >> Are you sure that you want to remove the nice, concise listing of = code > >> points that are present in RFC 4447? > > yeah - I think we removed them to avoid risk of contradicting the = registry. > > > >> 8.1, 8.2, and 8.3 all say "new". I suggest deleting that word. > > ok - we=E2=80=99ll rely on IANA to do this :) How so? IANA *do* supply a statement of their actions to the RFC Editor, = but they do not "in general" edit the text. > >> And lastly, "IANA needs to..." is not what we say :-) "IANA is = requested > >> to..." is nicer. > > hopefully my new wording for section 8 will be nicer :) > > > >> [NB: The Shepherd write-up seems to report all this wrongly at Q17] > SB> I have corrected the Shepherd's writeup. >=20 > >> --- > >> > >> Shouldn't the whole of Section 10 be moved to an interop report > >> somewhere? It's presence within the document seems somewhat = temporally > >> unstable. I understand that you want to write it down and record it > >> somewhere, also that you probably developed it in the I-D as a = useful > >> place for working text. For advice about how and where to do this = you > >> can look at RFC 5657. > > The AD asked us to put this in to provide evidence for moving to = Internet > > Standard. Happy to remove it again of course if the AD requests :) OK. That's between you and the IESG. > >> You seem to have answered the four points from 6410, but may be = missing > >> a little corroboration. > >> > >>> The pseudowire technology was first deployed in 2001 and has been > >>> widely deployed by many carriers. [RFC7079] documents the results = of > >>> a survey of PW implementations, with specific emphasis on Control > >>> Word usage. [EANTC] documents a public multi-vendor = interoperability > >>> test of MPLS and Carrier Ethernet equipment, which included = testing > >>> of Ethernet, ATM and TDM pseudowires. > >> 7079 is a slightly related piece of survey work, but the only = mention of > >> LDP (which is the subject of *this* document) is to point out an = issue > >> with non-implementation. > > understood. We were just trying to show that PW was widely = implemented. Fine, you certainly achieved on your intention. > >> The EANTC reference really needs something that helps us find the = report > >> of the interop event. Possibly this is > >> http://www.eantc.de/fileadmin/eantc/downloads/events/2007- > >> 2010/MPLSEWC09/EANTC-MPLSEWC2009-WhitePaper-v1.0.pdf > >> Looking at that paper, it definitely supports the claim of multiple > >> interoperating implementations of 4447. > > can we put URLs into references? And can they be that long? ;) >=20 > SB> Yes, and Yes >=20 > >> We lack, however, any statements about "widespread deployment and > >> successful operational experience.=E2=80=9D > > I put: "The pseudowire technology was first deployed in 2001 and = has been > widely deployed by many carriers.=E2=80=9D I=E2=80=99m not sure what = more we can do. Provide > lists of carriers offering services based on pseudowires? = That=E2=80=99d be *very* > temporarlly unstable ;) That's why implementation surveys are done the way they are. And, again, we're looking at 4447 implementation and deployment, not at = PWs in general. For what it is worth, I don't doubt that this is widely implemented and = deployed, but I'm not on the IESG and it is them who you have to = convince. > >>> The errata against [RFC4447] are all editorial in nature and have > >>> been addressed in this document. > >> Good (except for those not addressed as above, and except that some = of > >> those errata are incorrectly marked as "Technical=E2=80=9D). > > so they=E2=80=99re all addressed as noted above. And we can say = =E2=80=9Cmostly editorial=E2=80=9D? Actually, you can leave this. They were addressed in an editorial way. > >>> All features in this specification have been implemented by = multiple > >>> vendors. > >> How do we know this? > > I=E2=80=99m really not sure how we prove that. It is the implementation report's job to collect this information. Maybe the IESG don't care anymore and will take your word for it. > >> Further, are all the features used? One point of this step in the > >> process is to prune out features that are unnecessary (and so = complicate > >> implementation and operation, and cost money). > > right - so as far as we know all the features are in use by multiple = vendors. I=E2=80=99ve > asked around inside Cisco to check our implementations, but = I=E2=80=99m very happy for > someone else to check with our competitors. Well, that's OK then. Just checking. > >>> There is no IPR filed against this document or its predecessor. > >> This may be overly vague (you probably mean "No IPR disclosures = have > >> been made to the IETF related to this document, to RFC 4447 or RFC = 6723, > >> or to the Internet-Drafts that resulted in RFC 4447 and RFC = 6723.=E2=80=9D). > > ok - will change. Cheers, Adrian From nobody Thu May 5 11:01:11 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE7412D0E6; Thu, 5 May 2016 11:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] 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 w8sgltaXMihZ; Thu, 5 May 2016 11:01:06 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFF1C12B049; Thu, 5 May 2016 11:01:05 -0700 (PDT) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.14.7/8.14.7) with ESMTP id u45I11Y6010211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 5 May 2016 12:01:01 -0600 (MDT) To: Stewart Bryant , "Giles Heron (giheron)" , "adrian@olddog.co.uk" References: <035501d16cba$d1e22270$75a66750$@olddog.co.uk> <41025DD4-8D96-4FCC-A9B9-00CD2DA71236@cisco.com> <572B54BD.1090101@gmail.com> From: Luca Martini Message-ID: <572B8A58.2090002@cisco.com> Date: Thu, 5 May 2016 12:00:56 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <572B54BD.1090101@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-pals-rfc4447bis.all@ietf.org" , "pals-chairs@tools.ietf.org" Subject: Re: [RTG-DIR] Routing Directorate review of draft-ietf-pals-rfc4447bis X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 18:01:10 -0000 Giles/Adrian, I added more comments below: LM> On 05/05/16 08:12, Stewart Bryant wrote: > Please see SB> > > On 05/05/2016 12:11, Giles Heron (giheron) wrote: >> Hi Adrian/Luca, >> >> sorry for the slow response on this. >> >> We may need to iterate one more time too :( >> >>> On 21 Feb 2016, at 15:16, Adrian Farrel wrote: >>> >>> Hello, >>> >>> I have been selected as the Routing Directorate reviewer for this >>> draft. The Routing Directorate seeks to review all routing or >>> routing-related drafts as they pass through IETF last call and IESG >>> review. The purpose of the review is to provide assistance to the >>> Routing ADs. For more information about the Routing Directorate, >>> please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >>> >>> Although these comments are primarily for the use of the Routing >>> ADs, it would be helpful if you could consider them as the draft >>> advances, and strive to resolve them through discussion or by >>> updating the draft. >>> >>> Thanks, >>> Adrian >>> >>> === >>> >>> Document: draft-ietf-pals-rfc4447bis-03.txt >>> Reviewer: Adrian Farrel >>> Review Date: 21 February 2016 >>> IETF LC End Date: Not yet started >>> Intended Status: Internet Standard >>> >>> = Summary = >>> >>> I have some minor concerns about this document that I think should >>> be resolved before publication. >>> >>> = Comments = >>> >>> I'm OK to see 4447 being advanced to full standard, although I'm >>> also a little surprised that there was energy to do it. >>> >>> The work is largely mechanical. My comments are a mix of minor >>> process concerns (that your AD should be able to resolve), minor >>> text clarifications, and nits. >>> >>> It's been a while since I was concerned with LDP, but I have no >>> reason to doubt the integrity of this document. >>> >>> = Major Issues = >>> >>> No major issues found. >>> >>> = Minor Issues = >>> >>> I believe that this document should be marked as obsoleting 4447 and >>> 6723. It will result in a new RFC with a new number, so 4447 will no >>> longer be relevant. And, as Section 1 says: a new section (6.3) on >>> control-word renegotiation by label request message has been added, >>> obsoleting RFC 6723. >> it is marked that way. but it’s only when it goes to RFC that that >> gets into the text? > > SB> No, Giles, Adrian is correct. The Top Left corner of the front > page should have a list of RFCs being obsoleted. > > SB> Thus after "Intended status: Internet Standard" there should be a > line saying > SB> Obsoletes: RFC4447, RFC6723 > > SB> We also need replace the last para in the Abstract with something > like. > > SB> This document has been published to address RFC4447 errata. It > replaces > SB> RFC4447 and incorporates the correction published in RFC6723. In > doing > SB> so it obsoletes RFC4447 and RFC6723. > > SB> At the end of Section 1, you need something like: > > SB> This document replaces and thus obsoletes RFC4447 and RFC6723. > LM> Yes , there is a bug in the script that generates the text, I have never fixed it since there is not enough incentive to ;-) Let's just remember to manually edit the text before submission. >> >>> By the way, it is section 7.3 (not 6.3) that you have added! >> thanks! will fix :) >> >>> [NB: Q16 of the Shepherd write-up seems a bit garbled on this front. >>> Especially "Will publication of this document change the status of any >>> existing RFCs?" seems to need a much clearer answer!] >> :) > SB> I will update the Shepherds report when the new version of > RFC4447bis is uploaded > >>> --- >>> >>> I'm not up to speed on the new process for advancing a specification to >>> Internet-Standard when it has normative references that are not >>> similarly advanced/advancing. I do know that the process changed >>> recently and I am sure that your AD can look it up. >> I wait with bated breath ;) >> >>> --- >>> >>> It might be a reasonable question to ask why some of the >>> (informatively) referenced related PW RFCs (such as encapsulations) >>> are not being advanced at the same time, especially those that are >>> described as "companion documents”. >> RFC4447-bis is being done because there were too many errata on >> 4447. There won’t as many on the others. I think the promotion >> to Internet Standard happened as part of that? > > SB> Promotion to standard seemed the right thing given the wide > deployment of this signalling scheme. > > SB> If we all feel that we need to jump through too many hoops, we > could just leave it as PS, although all of the issues we are > discussing here will need to be addressed either way. > >> >>> --- >>> >>> It seems unnecessary petty-fogging process, but the inclusion of >>> section 7.3 seems to me to defeat the stability requirement for >>> advancement to Internet Standard unless your claim here is that you >>> are advancing 4447 and 6723 together in this single document. That >>> might be fine. >> the issue is that 4447 failed to cover a corner-case that was >> documented in 6723. So 6723 could be seen as a super-erratum on >> 4447. 4447bis merges it in as a single document. >> >>> --- >>> >>> The Errata that have been deliberately disregarded need to be marked as >>> Rejected. I think the ones that have been actioned could usefully be >>> marked as Verified or have a note added saying "fixed in RFCabcd". >>> >>> As far as I can tell: >>> >>> 3554 was not actioned >> it was actioned, but with better wording (IMO) than the erratum >> >>> 938 was done >>> 86 was done >>> 3555 was done >>> 3115 no longer applies >>> 3114 was done >>> 3112 was done >>> 1530 was done >> yup. >> >>> --- >>> >>> Because you (incorrectly) said that section 6.3 was new text, I gave it >>> careful review. I think the text is in rather poor state: >>> >>> For example, in 6.3.1... >>> >>> Using the procedures >>> outlined in this section, a simple label withdraw method MAY also be >>> supported as a legacy means of signaling PW status and AC status. >>> >>> ...Since this is *the* specification now, what does "legacy" mean? >> it means for interop with extremely old implementations >> (implementations that were pre the 4447 standard). >> >>> Indeed, you end 6.3.1 with... >>> The PW status >>> signaling procedures described in this section MUST be fully >>> implemented. >>> ...which kind of implies ... hmm. >> yes - they must be implemented. But you can interwork with >> “legacy”. >> >>> I think you could rework 6.3.1 to handle this more gracefully and avoid >>> the "clunk" of the 2nd para... >>> >>> Once the PW status negotiation procedures are completed and if they >>> >>> ...where we are surprised to hear about status negotiation. >>> >>> For example: >>> >>> OLD >>> The PEs MUST send Label Mapping Messages to their peers as soon as >>> the PW is configured and administratively enabled, regardless of the >>> attachment circuit state. The PW label should not be withdrawn >>> unless the operator administratively configures the pseudowire down >>> (or the PW configuration is deleted entirely). Using the procedures >>> outlined in this section, a simple label withdraw method MAY also be >>> supported as a legacy means of signaling PW status and AC >>> status. In >>> any case, if the label-to-PW binding is not available the PW MUST be >>> considered in the down state. >>> >>> Once the PW status negotiation procedures are completed and if they >>> result in the use of the label withdraw method for PW status >>> communication, and this method is not supported by one of the PEs, >>> then that PE must send a Label Release Message to its peer with the >>> following error: >>> >>> "Label Withdraw PW Status Method Not Supported" >>> >>> If the label withdraw method for PW status communication is selected >>> for the PW, it will result in the Label Mapping Message being >>> advertised only if the attachment circuit is active. The PW status >>> signaling procedures described in this section MUST be fully >>> implemented. >>> NEW >>> The PEs MUST send Label Mapping Messages to their peers as soon as >>> the PW is configured and administratively enabled, regardless of the >>> attachment circuit state. The PW label should not be withdrawn >>> unless the operator administratively configures the pseudowire down >>> (or the PW configuration is deleted entirely). >>> >>> Section 6.3.2 describes a mechanism for signaling the status of the >>> PW and AC. Additionally, a simple label withdraw method MAY be used >>> to signal the PW status and AC status. In any case, if the >>> label-to- >>> PW binding is not available the PW MUST be considered to be in the >>> down state. >>> >>> The PEs negotiate which PW and AC status signaling mechanism to use >>> by following the procedures in Section 6.3.3. If the PW negotiation >>> procedures are completed and if they result in the use of the simple >>> label withdraw method for PW status communication, and if this >>> method >>> is not supported by one of the PEs then that PE must send a Label >>> Release Message to its peer with the following error: >>> >>> "Label Withdraw PW Status Method Not Supported" >>> >>> If the label withdraw method for PW status communication is selected >>> for the PW, it will result in the Label Mapping Message being >>> advertised only if the AC is active. >>> >>> The PW status signaling procedures described in Section 6.3.2 >>> MUST be >>> fully implemented. >>> END >> I’m not sure we want to make big text changes at this stage for >> marginal benefit? >> LM> Andrian, we cannot change the specification in this stage. So the word "legacy" above needs to stay to discourage future implementation from being lazy and not implementing section 6.3.2. So if we work in the original meaning I'm fine with your clarified text. We are just shaming implementations into compliance ;-) >>> --- >>> >>> Section 6.3.2 achieves ambiguity by stating... >>> The general format of the Notification Message is: >>> ...and then showing the specific case of "PW status". >>> >>> You can fix this by re-ordering and tweaking slightly, as follows. >>> >>> Note that the old text says: >>> Since this notification does not >>> refer to any particular message, the Message Id and Message Type >>> fields are set to 0. >>> ...but I think the Message Type is set to 0x0001 :-) >>> >>> >>> OLD >>> The Status TLV is transported to the remote PW peer via the LDP >>> Notification message. The general format of the Notification >>> Message >>> is: >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| Notification (0x0001) | Message Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Message ID | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Status (TLV) | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | PW Status TLV | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | PWId FEC TLV or Generalized ID FEC TLV | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | PW Grouping ID TLV (Optional) | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> >>> >>> The Status TLV status code is set to 0x00000028, "PW status", to >>> indicate that PW status follows. Since this notification does not >>> refer to any particular message, the Message Id and Message Type >>> fields are set to 0. >>> NEW >>> The Status TLV is transported to the remote PW peer via the LDP >>> Notification message as described in [RFC5036]. >>> >>> The Status TLV status code is set to 0x00000028, "PW status", to >>> indicate that PW status follows. The format of the Notification >>> Message for carrying the PW Status is as follows: >>> >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| Notification (0x0001) | Message Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Message ID | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Status (TLV) | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | PW Status TLV | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | PWId FEC TLV or Generalized ID FEC TLV | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | PW Grouping ID TLV (Optional) | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> >>> Since this notification does not refer to any particular message, >>> the Message Id field is set to 0. >>> END >> >> again I’m not sure I’d want to make major changes to the text if >> we can avoid it. >> LM> On this I agree with Adrian. It's a nit , but he is correct , we can make this change. Clearly the message type is not 0 , and that was a mistake in the original text. >>> --- >>> >>> Section 8 could be tidied a little. >>> >>> The use of "in general" gives the IANA no way to know whether they >>> should or should not update a reference. >> I think maybe we just need a note asking IANA to remove this section >> once the RFC is published, and to update all the registries with the >> new number of this RFC? > > SB> I think the point that Adrian is making is that you should strike > "in general". > > SB> All of the IANA entries that point to RFC4447 should be replaced. > LM> I agree , but doen't IANA do this automatically when you obsolete an RFC ? Let's just get IANA to do the right thing. >> >>> Are you sure that you want to remove the nice, concise listing of code >>> points that are present in RFC 4447? >> yeah - I think we removed them to avoid risk of contradicting the >> registry. >> >>> 8.1, 8.2, and 8.3 all say "new". I suggest deleting that word. >> ok - we’ll rely on IANA to do this :) >> >>> And lastly, "IANA needs to..." is not what we say :-) "IANA is >>> requested >>> to..." is nicer. >> hopefully my new wording for section 8 will be nicer :) >> >>> [NB: The Shepherd write-up seems to report all this wrongly at Q17] > SB> I have corrected the Shepherd's writeup. > >>> --- >>> >>> Shouldn't the whole of Section 10 be moved to an interop report >>> somewhere? It's presence within the document seems somewhat temporally >>> unstable. I understand that you want to write it down and record it >>> somewhere, also that you probably developed it in the I-D as a useful >>> place for working text. For advice about how and where to do this you >>> can look at RFC 5657. >> The AD asked us to put this in to provide evidence for moving to >> Internet Standard. Happy to remove it again of course if the AD >> requests :) >> LM> As Giles pointed out , THe AD requested it. And the have an RFC with an interop report of sorts, just focused on the C-Bit. >>> You seem to have answered the four points from 6410, but may be missing >>> a little corroboration. >>> >>>> The pseudowire technology was first deployed in 2001 and has been >>>> widely deployed by many carriers. [RFC7079] documents the results of >>>> a survey of PW implementations, with specific emphasis on Control >>>> Word usage. [EANTC] documents a public multi-vendor interoperability >>>> test of MPLS and Carrier Ethernet equipment, which included testing >>>> of Ethernet, ATM and TDM pseudowires. >>> 7079 is a slightly related piece of survey work, but the only >>> mention of >>> LDP (which is the subject of *this* document) is to point out an issue >>> with non-implementation. >> understood. We were just trying to show that PW was widely implemented. >> >>> The EANTC reference really needs something that helps us find the >>> report >>> of the interop event. Possibly this is >>> http://www.eantc.de/fileadmin/eantc/downloads/events/2007-2010/MPLSEWC09/EANTC-MPLSEWC2009-WhitePaper-v1.0.pdf >>> >>> Looking at that paper, it definitely supports the claim of multiple >>> interoperating implementations of 4447. >> can we put URLs into references? And can they be that long? ;) > > SB> Yes, and Yes > >> >>> We lack, however, any statements about "widespread deployment and >>> successful operational experience.” >> I put: "The pseudowire technology was first deployed in 2001 and has >> been widely deployed by many carriers.” I’m not sure what more >> we can do. Provide lists of carriers offering services based on >> pseudowires? That’d be *very* temporarlly unstable ;) >> >>>> The errata against [RFC4447] are all editorial in nature and have >>>> been addressed in this document. >>> Good (except for those not addressed as above, and except that some of >>> those errata are incorrectly marked as "Technical”). >> so they’re all addressed as noted above. And we can say >> “mostly editorial”? >> >>>> All features in this specification have been implemented by multiple >>>> vendors. >>> How do we know this? >> I’m really not sure how we prove that. >> >>> Further, are all the features used? One point of this step in the >>> process is to prune out features that are unnecessary (and so >>> complicate >>> implementation and operation, and cost money). >> right - so as far as we know all the features are in use by multiple >> vendors. I’ve asked around inside Cisco to check our >> implementations, but I’m very happy for someone else to check with >> our competitors. >> >>>> There is no IPR filed against this document or its predecessor. >>> This may be overly vague (you probably mean "No IPR disclosures have >>> been made to the IETF related to this document, to RFC 4447 or RFC >>> 6723, >>> or to the Internet-Drafts that resulted in RFC 4447 and RFC 6723.”). >> ok - will change. >> >>> --- >>> >>> = Nits = >>> >>> In the Abstract, probably... >>> >>> OLD >>> This document has been written to address errata in a previous >>> version of this standard. >>> NEW >>> This document has been written to address errata in a previous >>> version of this specification. >>> END >>> >>> But, actually, I think you are missing the main purpose which is to >>> advance the spec to full standard. >> As noted above I think the key was fixing errata. The standard thing >> came after that - but that may be me and Luca mis-remembering the >> history. > > SB> I am fairly sure that the Chairs suggested moving to Full Std. As > I said earlier if it is too many hoops perhaps we should just publish > as PS, although that says something about the IETF process given how > widely this is implemented. > >> >>> On reflection, I think that this paragraph probably served well in the >>> draft as it was being processed, but can be removed now. The equivalent >>> text obviously needs to be in the shepherd write-up. >> ok - that makes sense. >> >>> [ditto the paragraph in the introduction] >> ditto. >> >>> --- >>> >>> Thank you for including Section 1. It's important and helpful. >>> >>> Three tiny points: >>> >>> Second para should probably s/However/Additionally/ >> will fix. >> >>> The RFC Editor requires that section 1 is the Introduction. A simple >>> solution is to swap sections 1 and 2, or to move the current section 2 >>> to be the new section 1 and the current section 1 to be section 1.1. >> again - that makes sense. >> >>> The text says "A note was added to clarify that the C-bit is part of >>> the FEC." I think you should s/was/has been/ and you could also >>> usefully >>> give a little hint as to where the note was added. >> ok. >> >>> --- >>> >>> Shouldn't you mention the inclusion of text referencing 7358? This is >>> clearly a change to the original text. I wonder, however, whether what >>> really want to do is take that part of 7358 that updated 4447 and >>> simply >>> write it here so that this spec has no need of that reference. >> presumably better to reference 7358 so we don’t duplicate text? >> >>> Either way, you also need to take care about the stability requirement >>> for advancement. >> you mean standards track vs informational etc.? >> >> --- >>> In 6.2.2.1 >>> please note that IANA has "PW Interface Parameters TLV" not "Interface >>> Parameters TLV". >>> >>> The is a good chance to make this consistent. >> ok >> >>> --- >>> >>> In 6.2.2.2 and the rest of the document, please note that the IANA has >>> "PW Group ID TLV" not "PW Grouping ID TLV". >>> >>> The is a good chance to make this consistent. >> ok >> >>> --- >>> >>> 6.3.2 has a figure which claims to include a "PWId FEC TLV" or a >>> "Generalized ID FEC TLV". However, 6.1 and 6.2 describe these as >>> "elements" not TLVs and they show up in the Forwarding Equivalence >>> Class >>> (FEC) Type Name Space. >>> >>> I think you can clarify 6.3.2 by explaining that what is included here >>> is "a FEC TLV containing either a PWId FEC element or a Generalized FEC >>> element. >>> >>> Then, just after the figure you have "The PW FEC TLV" but it is just a >>> "FEC TLV” >> ok >> >>> --- >>> >>> In 7.3 you have "re-provisioned". I wonder whether you mean >>> "re-configured". "Provisioning" has a context initial set-up, so re- >>> provisioning suggests (to me?) re-initialization. >> ok >> >>> --- >>> >>> In the first para of 7.3 you have "PW C-bit negotiation procedure" and >>> "Control-Word negotiation procedures". >>> >>> Could you decide on a single name, and on whether it is singular or >>> plural. >>> >> ok >> >>> --- >>> >>> 7.3 >>> OLD >>> -i. If local PE has previously sent a Label Mapping message, it >>> MUST send a Label Withdraw message to remote PE and wait >>> NEW >>> -i. If the local PE has previously sent a Label Mapping >>> message, it >>> MUST send a Label Withdraw message to the remote PE and >>> wait >>> END >> ok >> >>> --- >>> >>> 7.3 >>> OLD >>> -ii. the local PE MUST send a label release message to the >>> remote >>> NEW >>> -ii. The local PE MUST send a Label Release message to the >>> remote >>> END >> ok >> >>> --- >>> >>> 7.3 >>> s/negotaiation/negotiation/ >>> s/renegotation/renegotiation/ >> ok >> >>> --- >>> >>> 7.3 >>> >>> The above C-bit renegotiation process SHOULD NOT be interrupted >>> until >>> it is completed, or unpredictable results might occur. >>> >>> This is a bit odd. Normally the "or" that follows a "SHOULD" or "SHOULD >>> NOT" explains the conditions under which you might want to vary the >>> "SHOULD". >>> >>> But I'm struggling: interrupted by whom and by doing what? >> I’ll have to defer to Luca here. >> LM> This was in reference that in the original spec we had no "reset" button for this negotiation. So i wanted to make sure that if someone changed the provisioning in the middle of the negotiation, the system would finish the state machine, then initiate a new procedure. It's just attempting to protect against very bad coding. The reason it is a should is that if we have a label withdraw in the middle of it it's ok , as all state is erased at that point. >>> --- >>> >>> Some of the formatting in the references seems to have been hit with a >>> global change of /. /. / You might want to polish. >> will do >> >>> --- >>> >>> The latest version of G.707 is dated January 2007. Is there any reason >>> to not update the reference? >> probably just that we never revisited it. >> >>> --- >>> >>> Have a look at Section 8 of RFC 5036 for an example of a nice way to >>> handle "legacy authors" and credits for past work. >>> >>> In any case, the RFC Editor will require that Section 15 is renamed >>> "Contributors”. >> ok >> >>> --- >>> >>> There are two trivial nits from idnits. >>> >> will take a look >> >> Giles > From nobody Thu May 5 11:41:19 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166B712D7F2 for ; Thu, 5 May 2016 11:41:17 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign-com.20150623.gappssmtp.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 u-L6CFcetK85 for ; Thu, 5 May 2016 11:41:15 -0700 (PDT) Received: from mail-qg0-x264.google.com (mail-qg0-x264.google.com [IPv6:2607:f8b0:400d:c04::264]) (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 3000612D7E9 for ; Thu, 5 May 2016 11:41:10 -0700 (PDT) Received: by mail-qg0-x264.google.com with SMTP id g48so7434643qge.2 for ; Thu, 05 May 2016 11:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language:user-agent :mime-version; bh=s22192yVOBvQNhUUIfs/sq986FqXPnjJcK0Vd/K1mcQ=; b=Mi2TIKQg/6RpwIZkXNWCoo2Wi/H946C9Y2AnzSdWNGKV/JXyHXrG2XOy48BaU+kjBA NVDzpE/AI5jpplj2MugoswGyuk8vPUPdaYbkfvbvVMNOnG2elDzvqUwJNFUvR+pEFkzp y29TIsMoQe7Y2juHc0k66qx95CBHvMjx1OD89puM14CtCBtPdsrpbnFNq4Sh6VU9+olx itU9f+fZ0fZSp6oom1e8ztc2HqBc0J7AdxY48MRRJ3AgLYgjxiCenxnuuGPgiNObr04+ eF+zj+3JxF7F5w/URmHxxbCjk07HRzHkJNuJUg7bQpJGM38JqR5cb0duMRf1ad8EJS+h tahA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:user-agent:mime-version; bh=s22192yVOBvQNhUUIfs/sq986FqXPnjJcK0Vd/K1mcQ=; b=g9YUi0bGCM5SLYbTpIImYa7KHLy2j8Chxv/0iYPp7SuBHi4e4xjgCKOWhactJKOxeF XyWPz4EpQ89W3TP3hM4jG+mcDjiRT091gdr8wItskJxGdy52E5ev7ZWamqZDDpJF3SS7 kyltiEq+hTfhuGSyZTdNHsTozX7iaWq8scJY9vlf9l/gEcc1x3i1thSqQdazEnm6zJVA INjfC9jX56NIAZUQIg9KAnujaJ0HuLyCkhV3+yjFF0l5rUnuV5p67bj+WB4v71gtOj/+ aLoASxQuRpaMGNq0ZMK2IwPI423YB+hIOdAFOMUfU6zsKbOcE2oXc5B0h95ifTeXT737 X/hg== X-Gm-Message-State: AOPr4FVP/+2BmY8yVERdfhLqygGTRNsgsAQV/KZZwYHiPAP5J5VmYFHlFhlw6rgORJKeUFf4Zl5Zc9kbdwMcpwttQgVmdV/x X-Received: by 10.55.102.215 with SMTP id a206mr11079175qkc.69.1462473669131; Thu, 05 May 2016 11:41:09 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id g133sm1649853qkb.1.2016.05.05.11.41.08 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 05 May 2016 11:41:09 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id u45If8IT029865 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 May 2016 14:41:08 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 5 May 2016 14:41:08 -0400 From: "McPherson, Danny" To: Donald Eastlake Thread-Topic: RtgDir review: TRILL: Interface Addresses APPsub-TLV Thread-Index: AQHRphEKORUTa4BWI0iEODDXoWE46J+qxeeA///pWIA= Date: Thu, 5 May 2016 18:41:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-originating-ip: [10.173.152.4] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3545304069_2060181664" MIME-Version: 1.0 Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-trill-ia-appsubtlv@ietf.org" , "all@ietf.org" , "trill@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: TRILL: Interface Addresses APPsub-TLV X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 18:41:17 -0000 --B_3545304069_2060181664 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I=E2=80=99m comfortable with your stated intentions here Donald. Thanks for the prompt response, =20 -danny On 5/5/16, 12:02 PM, "Donald Eastlake" wrote: >Hi Danny, > >Thanks for your comments. See below. > >On Wed, May 4, 2016 at 10:27 AM, McPherson, Danny > wrote: >> >> Hello, >> >> I have been selected as the Routing Directorate reviewer for this >> draft. The Routing Directorate seeks to review all routing or >> 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 >> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >> >> Although these comments are primarily for the use of the Routing >> ADs, it would be helpful if you could consider them along with any >> other IETF Last Call comments that you receive, and strive to >> resolve them through discussion or by updating the draft. >> >> Document: draft-ietf-trill-ia-appsubtlv-07.txt >> Reviewer: Danny McPherson >> Review Date: May 4, 2016 >> Intended Status: Proposed Standard >> >> >> Summary: >> >> I have some minor concerns about this document that I think should >> be resolved before publication. >> >> >> Comments: >> >> I believe the draft is technically sound, however, the quality and >> readability needs a bit more work, particularly as it relates to >> introduction of new terms, and consistent application and use of all >> terms. There are also some general error handling and encoding >> issues that need to be given consideration. >> >> >> Major Issues: >> >> I have no =E2=80=9CMajor=E2=80=9D issues with this I-D. > >Thanks. > >> Minor Issues: >> >> 1. ERROR HANDLING: There are a number of places in the document >> where it discusses the receipt of malformed, badly encoded, >> non-matching, or corrupt messages, and the advice is to either >> [silently] discard or ignore the messages. Some general guidance >> should be given here to enable operational diagnosis of any issues >> that may result in temporal or persistent problems, where logging >> and other actions should occur. Some aspects of this might leverage >> the OAM Framework efforts, although it appears much of the TRILL >> work leaves this to the implementer. > >In the IETF context "silently discard" means that there is no >on-the-wire message sent. It says nothing about whether or not >counters are kept of such condition or errors are logged. A suggestion >to log such events and/or keep such counters can be added. > >> 2. When using =E2=80=9CNickname=E2=80=9D it would be useful to define the encoding >> as an unsigned 16-bit integer, or just reference "as specified in S >> 3.7 of RFC6325=E2=80=9D. > >OK. Will add the reference. > >> 3. The inclusion of the =E2=80=9CTLV=E2=80=9D acronym in the "APPsub-TLV=E2=80=9D TLV name >> seems loose and redundant to me, as opposed to =E2=80=9CAPPsub TLV=E2=80=9D or >> similar. > >This comes from RFC 6823, Section 3.2, which says that sub-TLVs that >go inside the GENAPP TLV "are refrred to as APPsub-TLVs". > >> 4. Inconsistent use of =E2=80=9CInterface Address APPsub-TLV=E2=80=9D, =E2=80=9CIA >> APPSub-TLV=E2=80=9D, =E2=80=9CInterface Address APP-subTLV=E2=80=9D, and =E2=80=9CAppsubTLV=E2=80=9D m= akes >> it seem like you=E2=80=99re talking about different things. > >OK - that should be made more consistent, probably standardizing on >"IA APPsub-TLV". > >> 5. The use of =E2=80=9Csub-sub-TLV=E2=80=9D seems a bit loose and sloppy to me as >> well, and should be cleaned up. E.g., S 5.2 =E2=80=9CIA Appsub-TLV >> Sub-Sub-TLVs SubRegistry" > >You don't like "sub-sub-TLV"? > >Seems like, strictly speaking, you have IS-IS PDUs which contain >TLVs. Then some TLVs can contain sub-TLVs. (The GENAPP TLV is the only >one that occurs to me with a special name for its sub-TLVs, namely >APPsub-TLVs.) and some sub-TLVs can contain a further nested level, >which it seems to me to be precise and logical to call sub-sub-TLVs. >(I am not aware of any requirement for any more deeper nesting in a >use of IS-IS.) So, would you prefer that what are called sub-sub-TLVs >in this document just be called "sub-TLVs" (which I agree they are) >resulting in two different levels with the same name? While there >might be some errors in their use in this draft, the mere use of >APPsub-TLV and sub-sub-TLV for the two levels does not seem "loose and >sloppy" to me... > >> 6. Only one of the =E2=80=9CFigures=E2=80=9D is labeled / captioned > >OK. All the principal figures should be labeled. (I don't think cases >where there is a small, indented figure that just expands part of a >principal figure and appears shortly after the principal figure need >to be captioned.) So, the initial figures in Sections 3.1, 3.2, 3.3, >and 3.4 would have Figures numbers and captions added. > >> 7. The use of =E2=80=9CAddress Sets=E2=80=9D and =E2=80=9CAddress Sets Ends=E2=80=9D makes it a = bit >> hard to read when used in sentences. Perhaps an acronym for each, >> or hyphenating/underscoring them would make it more readable. > >OK - I'll see what I can do. > >> 8. S 3.4 the 2-byte =E2=80=9CType=E2=80=9D value in the diagram should be >> =E2=80=9CTOPOLOGY=E2=80=9D, not =E2=80=9CDATALEN=E2=80=9D. > >Thanks for noticing this error. > >> 9. I noticed that Radia was a co-author until the last revision, and >> now she doesn=E2=80=99t even exist in the Acknowledgements section. While >> no explanation is required here, I did find this a bit odd. > >I think her listing as an author was in error. > >> 10. IANA Considerations: Some guidance from the IANA folks on the >> formatting of this section might be in order. It=E2=80=99s not as clear as >> it could be about what their instructions are here. > >There are some improvements that could be made. In inverse order, >Section 5.3 looks fine. In Section 5.2, "Available" should be changed >to "Unassigned" as that is the preferred IANA term. Section 5.1 is >talking about assignments that have already happened and looks OK as >far as the table of values goes; however, the material after the first >sentence after that table seems inappropriate in an "IANA >Considerations" section and should, perhpas, be in a new "Processing >Address Sets" section. > >> 11. S 2: It=E2=80=99s unclear to me if the =E2=80=9CConfidence=E2=80=9D value of 255 =E2=80=9Cbe= ing >> treated as if it was 254=E2=80=9D is inline with RFC6325 S 4.8.1 guidance? > >The idea is that local configuration or learning should be able to >override address reachability received through network messages. Thus >such information, when manually configured, defaults to have confidence >255. > >RFC 6325 Section 4.8.1 just says that information learned via ESADI >will have a confidence of from 0 to 254 but don't actually say what to >do if it is recreived as 255. This is updated by Section 6.2 RFC 7357, >1st paragraph, that makes it clear that a received value of 255 is >just treated as if it was 254. Thus it is consistent with these prior >RFCs to the IA APPsub-TLV draft to give this rule for handling the >value 255 in the Confidence field of IP APPsub-TLVs. > >> 12. In general, I agree there appear to be no new Security >> Considerations here. I do not believe Asymmetry will be an issue >> with the forged packet discard issue although some consideration of >> this might be in order (or perhaps simply a reference to SAVI or >> other work here). I wonder if some consideration should be given to >> broader disclosure of reachable layer 2 addresses here, but that >> seems a bit reaching as well. >> >> >> Nits: >> >> 1. Abstract & Introduction: s/by-pass/bypass/ > >OK. > >> 2. S.2: s/Data Label is reachable from /Data Label are reachable/ > >"... inteface ... is reachable ...", so I think "is" is correct but >I'll see if I can re-word this sentence. > >> 3. A reference for the first use of AFN would be useful, perhaps to >> the IANA registry. > >OK. > >> 4. Expressing TBD code points in [ ] brackets might help with >> readability as well > >OK. > >> 5. S 3.2 =E2=80=9Cif the Length is 0 or 1 or less=E2=80=9D =E2=80=94 not sure the =E2=80=9Cor le= ss" >> is necessary? > >OK, the "or less" should be removed. > >Thanks, >Donald >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com --B_3545304069_2060181664 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUuwYJKoZIhvcNAQcCoIIUrDCCFKgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIKMIIHhTCCBm2gAwIBAgIQFboJA3Ne3xABo4oFnBRPRzANBgkqhkiG9w0BAQsFADCB yTELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQL ExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMTUwMwYDVQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJ IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTFDMEEGA1UEAxM6U3ltYW50ZWMgQ2xhc3MgMiBT aGFyZWQgSW50ZXJtZWRpYXRlIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0xNjAzMDUwMDAw MDBaFw0xNzAzMDUyMzU5NTlaMHQxJjAkBgkqhkiG9w0BCQEWF2RtY3BoZXJzb25AdmVyaXNp Z24uY29tMRkwFwYDVQQDDBBNY1BoZXJzb24sIERhbm55MRYwFAYDVQQLDA1FTlRFUlBSSVNF IElUMRcwFQYDVQQKDA5WZXJpU2lnbiwgSW5jLjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAKcc2QTeMzwlCGKDDL0OR2xd9UTw9Y1IClTsZq65x4ud+uHa7mx08QcdI8hgxsUj EAnOIpZwid1YgY/CucX223VNKbHw+Gmgg0LfYz3i0UYe+wgJn29Nl8Q/DqQ0X0iYtBWdCDYu CsOGSHfLK3a9z7IRXyWSVXLPv0AxSTV8teIAd8ZN0xNPqRSSk3EQMh1ajwoR6MzoGBip3g3O +ZvV0zZtScAn9nBG5bF5wqMio32pobroSM6Yl5iRkF3tNJrrcpJocISBJvNa+xvTenezWUFA HGYHnkz5hmxyNqSDWZ68mJnWlfJthbRCFKEnjH79qDYBi5Dc+CmvUmtpMBRAso0CAwEAAaOC A7swggO3MAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMBYGA1UdJQEB/wQMMAoGCCsG AQUFBwMEMB0GA1UdDgQWBBRWhUpoLXEQ8H0RYqrd1avCyQi5+TBQBgNVHREESTBHgRdkbWNw aGVyc29uQHZlcmlzaWduLmNvbaAsBgorBgEEAYI3FAIDoB4MHGRtY3BoZXJzb25AdmNvcnAu YWQudnJzbi5jb20wHwYDVR0jBBgwFoAU2EgpqF8qF5Li+p57729gg/i4uNwwggFxBggrBgEF BQcBAQSCAWMwggFfMCcGCCsGAQUFBzABhhtodHRwOi8vcGtpLW9jc3Auc3ltYXV0aC5jb20w ggEyBggrBgEFBQcwAoaCASRsZGFwOi8vZGlyZWN0b3J5LnZlcmlzaWduLmNvbS9DTiUyMCUz RCUyMFN5bWFudGVjJTIwQ2xhc3MlMjAyJTIwU2hhcmVkJTIwSW50ZXJtZWRpYXRlJTIwQ2Vy dGlmaWNhdGUlMjBBdXRob3JpdHklMkNPVSUyMCUzRCUyMENsYXNzJTIwMiUyME1hbmFnZWQl MjBQS0klMjBJbmRpdmlkdWFsJTIwU3Vic2NyaWJlciUyMENBJTJDT1UlMjAlM0QlMjBTeW1h bnRlYyUyMFRydXN0JTIwTmV0d29yayUyQ08lMjAlM0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0 aW9uJTJDQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQ oE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzA3YmI3ZDY0NzdjZjRmNmJlOTZh ZjFiMzZjYWJkMzE2L0xhdGVzdENSTC5jcmwwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXAjBS MCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAc GhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTBCBgkqhkiG9w0BCQ8ENTAzMAoGCCqGSIb3 DQMHMAsGCWCGSAFlAwQBAjALBglghkgBZQMEARYwCwYJYIZIAWUDBAEqMCwGCmCGSAGG+EUB EAMEHjAcBhJghkgBhvhFARABAgIBAYvxxgkWBjI0NzY2NDA5BgpghkgBhvhFARAFBCswKQIB ABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBCwUA A4IBAQAEQBbGHfK48sDK0jQ77RK2Tp+XaQ3w3G9380i3HsbEAQzcpO6JAjqt9//Tu1Ug5ELZ DbzBNfo1M0Ba89jgahs/tZZFA9itHQnTjGhhmtjiRx4ZRV1rmW377qlZTcYibBSibxDOhhK1 PAV01vjpbUnuDhq2PjrTvg8OKGFX8HUZ/It8RL18/VoKFhHxoFU0mFqZPFHfj67FbW4SK3++ 38NfVQ5fdGr3HxUvdqCwTeIIZt2RojWVenvCGfe+SBQyxtUViEXltry0hMnpYYUsJotAfKRP GfJGl5SD2n1BuReq8iHxLz2/EF9VCcJMdpHw34CUjuswpRl/eSXmwspWCyYIMIIGYDCCBUig AwIBAgIQdoXLB6jgzA/SxU2POTWzEjANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMTEwNjA3MDAwMDAwWhcNMjEwNjA2MjM1 OTU5WjCByTELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8w HQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMTUwMwYDVQQLEyxDbGFzcyAyIE1hbmFn ZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTFDMEEGA1UEAxM6U3ltYW50ZWMgQ2xh c3MgMiBTaGFyZWQgSW50ZXJtZWRpYXRlIENlcnRpZmljYXRlIEF1dGhvcml0eTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALf4PwwrgyMghaZNSQFROtrdUDO+4wSkOj6jYWZM NMLodHB1SaW3Sezds5Kc3XkN4rn6uDk8voXjjO9teaOmtwi/nEy+PpiOrNt8mivsBSgwXykb M01E1XDoViKZpj6dQlvrI6djnS0ssC4/GPMpzRo2iYSSx1dwW3CF5jihfFDjNziIZVtryzkq BLGCqhkE/6B/P6PbkUV2ZqNr84UjXk7ZhV11p6AV98EAdODlypRCZZrCN3qLqFCsv5d0Z3fR MqevjcuTqSVCtDAadAriJRAQy3RnVQ/LFPxBUAqkfE0LC/kFqTX5Racx8YC7osk+znY54Sr/ dlDn6FEi3y3PuDMCAwEAAaOCAj8wggI7MBIGA1UdEwEB/wQIMAYBAf8CAQAwNAYDVR0fBC0w KzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi1nMy5jcmwwDgYDVR0PAQH/ BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi01NjAdBgNV HQ4EFgQU2EgpqF8qF5Li+p57729gg/i4uNwwgfAGA1UdIwSB6DCB5aGB0KSBzTCByjELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBh dXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAyIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEGFwy0mMX5hFKeewptlQW3ow NAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w bAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXAjBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5 bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3Jw YTANBgkqhkiG9w0BAQUFAAOCAQEApiqbB0DJ7P+ziOhF2jTRFw8oLbelhWcxzcHm1SmGOKzi 8FkbDOGhRc4keO9pwbBMYaJI2WhPuv51VDe6WGnqwXalNkLqnmZ4kCDZlWokeVTN3loaijuu GJVy0CXY0ka+NDCngJ7xVs4gHmxnyU1PeYeJ4i6A1p7tJmFlogPQxeLzKLkrSWmCZ+zV6TSk LtxiIqSFTUjjagKU8s395GfISbyq1cfnPN6HsRBrXQdcGeRroPRPmcvctVsMzDL5auR0wCpY N3mz+83DNG/hdt0QBwBjiwdOJxeSR5sOvt4NE4UR/KIvZX3MOqweVGtWZ8TupYciIxcrcFbD 8a53XCfBOTCCBBkwggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEBBQUAMIHKMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9y IGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGlj IFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw05OTEwMDEwMDAwMDBa Fw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZl cmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg LSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8KDcLVLNtnuS3llCfdpb7g sE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8QzicTngVHmzF6E9gf 2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCbvO/DSD5GYCCF KtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDLHMQjPR+Z/kzo FmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23SrGY/lozghNQ2 /yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEANCYVPMCN TUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDzmN+k5qQx39Mc C0bcciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfORF3UG5CYDR5C lLEALATQdKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6uuNkSLB/+zYl 2pXQ8SQUF90YgGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I54bFD4CjPt+da bBNrSbP/4xh8iYszXawz16f52jpVyVgQ+arvWrbPS0vfKjGCAnUwggJxAgEBMIHeMIHJMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5 bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJl ZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AhAVugkDc17fEAGjigWcFE9H MA0GCWCGSAFlAwQCAQUAoGkwLwYJKoZIhvcNAQkEMSIEIDxutiPNm88vejLnlcoib/T/dxNH mi8aQvonZ+9Zi85UMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTE2MDUwNTE4NDEwOVowDQYJKoZIhvcNAQEBBQAEggEAD9k+iPuthcE5EuSVbjoRue1+q/vg BUbkwvpUZreNozLDskSvSqqqUpds+NmMLCuGIrjBooQjPP0K7wfM1Bywqg2TI+M/aOAlhd0T IUvHA5KEHcu7IQVFjE/dw2Bu8z1M8D4VY3YFG2vOc3qNYod8mh53U8N0NSMzDFhtzT/E9TRn dc18a92nnc/qbqeUVyd38e8GwrfvF2yNVeAMztUy+PtBUcvI/mQsQY/RrJAKexRV40QOFW4N jEo/4uzpZMJUS9kr7NEyh3ZqdZyst20E5rlWdHX/uP8V/6lh8yflJjYz20b4TgnXH9+CWtE7 wfbL5d/gJk/HpMbKBXh9vYOGkg== --B_3545304069_2060181664-- From nobody Thu May 5 14:10:14 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1020112D4FB; Thu, 5 May 2016 14:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 2IyPfCthbQ_y; Thu, 5 May 2016 14:10:11 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 725B812D133; Thu, 5 May 2016 14:10:11 -0700 (PDT) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.11/8.16.0.11) with SMTP id u45JTPfH009021; Thu, 5 May 2016 15:29:51 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0048589.ppops.net-00191d01. with ESMTP id 22rbufahmv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 May 2016 15:29:50 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u45JTnIu000434; Thu, 5 May 2016 15:29:49 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u45JTdjv032624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 May 2016 15:29:43 -0400 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 5 May 2016 19:29:25 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.44]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0294.000; Thu, 5 May 2016 15:29:25 -0400 From: "BRUNGARD, DEBORAH A" To: "adrian@olddog.co.uk" , "'Stewart Bryant'" , "'Giles Heron (giheron)'" , "'Luca Martini (lmartini)'" Thread-Topic: Routing Directorate review of draft-ietf-pals-rfc4447bis Thread-Index: AQHRpr7oUjEvQqjsSka8cQJh3XI9jp+qpc2AgAA0qgD//9kXsA== Date: Thu, 5 May 2016 19:29:24 +0000 Message-ID: References: <035501d16cba$d1e22270$75a66750$@olddog.co.uk> <41025DD4-8D96-4FCC-A9B9-00CD2DA71236@cisco.com> <572B54BD.1090101@gmail.com> <0ae301d1a6f2$756b5580$60420080$@olddog.co.uk> In-Reply-To: <0ae301d1a6f2$756b5580$60420080$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.199.146] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-05_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1605050273 Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-pals-rfc4447bis.all@ietf.org" , "pals-chairs@tools.ietf.org" Subject: Re: [RTG-DIR] Routing Directorate review of draft-ietf-pals-rfc4447bis X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 21:10:13 -0000 SSBhbnN3ZXJlZCB0aGlzIGZpcnN0IHF1ZXN0aW9uIG9uIDEwLzI2LzIwMTUgZm9yIFN0ZXdhcnQg KGNjJ2QgYXV0aG9ycyBhbmQgY2hhaXJzKS4gKG15IG1lbW9yeSBpcyBzdGlsbCBnb29kOi0pKQ0K DQpJdCdzIHN0aWxsIHRoZSBzYW1lIGFuc3dlciwgYnV0IGNvbnNpZGVyaW5nIHRoaXMgZG9jdW1l bnQncyByZXZpc2lvbiB0aW1lLCBtYXliZSBpdCB3aWxsIGNoYW5nZS4gSSBkaWRuJ3QgcmVhbGl6 ZSBhbGwgb2YgeW91IHdlcmUgaG9sZGluZyB5b3VyIGJyZWF0aCBmb3IgdGhlIGFuc3dlcjotKQ0K DQpBbnN3ZXI6IFdlIG5lZWQgdG8gZG8gImRvd253YXJkIHJlZmVyZW5jZXMiLiBJIGhhZCBzZW50 IGxpbmtzIGluIG15IHByZXZpb3VzIGVtYWlsIHRvIHJlY2VudCBJUyBkb2N1bWVudHMgYXMgZXhh bXBsZXMsIGUuZy46DQpodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjNzY4MC50eHQN CihoYXMgbm9ybWF0aXZlIHJlZmVyZW5jZXMgaW5jbHVkaW5nIFBTLCBCQ1ApDQoNCkhvdyB0byBk bzoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjL3JmYzQ4OTcudHh0DQoNCiANCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFkcmlhbiBGYXJyZWwgW21haWx0bzphZHJpYW5A b2xkZG9nLmNvLnVrXSANClNlbnQ6IFRodXJzZGF5LCBNYXkgMDUsIDIwMTYgMToyMSBQTQ0KVG86 ICdTdGV3YXJ0IEJyeWFudCcgPHN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbT47ICdHaWxlcyBIZXJv biAoZ2loZXJvbiknIDxnaWhlcm9uQGNpc2NvLmNvbT47ICdMdWNhIE1hcnRpbmkgKGxtYXJ0aW5p KScgPGxtYXJ0aW5pQGNpc2NvLmNvbT4NCkNjOiBydGctYWRzQGlldGYub3JnOyBydGctZGlyQGll dGYub3JnOyBkcmFmdC1pZXRmLXBhbHMtcmZjNDQ0N2Jpcy5hbGxAaWV0Zi5vcmc7IHBhbHMtY2hh aXJzQHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBSRTogUm91dGluZyBEaXJlY3RvcmF0ZSByZXZp ZXcgb2YgZHJhZnQtaWV0Zi1wYWxzLXJmYzQ0NDdiaXMNCg0KU3Rld2FydCBiZWF0IG1lIHRvIHRo ZSBkcmF3IG9uIGEgY291cGxlIG9mIHBvaW50cy4gSSBhZ3JlZSB3aXRoIGhpbSwgc28gSSd2ZSBj dXQgZG93biB0byBvdGhlciBpc3N1ZXMuDQoNCj4gPj4gSSdtIG5vdCB1cCB0byBzcGVlZCBvbiB0 aGUgbmV3IHByb2Nlc3MgZm9yIGFkdmFuY2luZyBhIHNwZWNpZmljYXRpb24gdG8NCj4gPj4gSW50 ZXJuZXQtU3RhbmRhcmQgd2hlbiBpdCBoYXMgbm9ybWF0aXZlIHJlZmVyZW5jZXMgdGhhdCBhcmUg bm90DQo+ID4+IHNpbWlsYXJseSBhZHZhbmNlZC9hZHZhbmNpbmcuIEkgZG8ga25vdyB0aGF0IHRo ZSBwcm9jZXNzIGNoYW5nZWQNCj4gPj4gcmVjZW50bHkgYW5kIEkgYW0gc3VyZSB0aGF0IHlvdXIg QUQgY2FuIGxvb2sgaXQgdXAuDQo+ID4NCj4gPiBJIHdhaXQgd2l0aCBiYXRlZCBicmVhdGggOykN Cg0KSW5kZWVkIQ0KPHNuaXA+DQo= From nobody Fri May 6 15:09:15 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241D712D133 for ; Fri, 6 May 2016 15:09:14 -0700 (PDT) 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 rB-TUFtVU6Ck for ; Fri, 6 May 2016 15:09:11 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::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 B0ED112D12A for ; Fri, 6 May 2016 15:09:11 -0700 (PDT) Received: by mail-ig0-x22a.google.com with SMTP id u10so58408733igr.1 for ; Fri, 06 May 2016 15:09:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ooFOo/AVlNSWRWCVA3R5jq5dgiEJu/EGHjQug4wsiQ8=; b=hSFL6+M2JS8UKhTqzpl7XDwBJru6VrB8/xx3D1quFzDn2tivrUrX2/D7iskMW2rTqs jt4tsc0AaqzXkKbPrxMUoL1/QMwnIybjZv79Oy1yXDa+kK6EmivqiDdvbCtw9ZaQcOCJ F3s70C0WeGHINgqWDKMtL0UeCU2KZN7rtKsBCKW8yQ0kAwhTn6yfCRHiqFXoCnmoIMlA oMKnpbUjAjhihuEq2oYPg+DykkDB6VyKvqHSVTRLQaW3OwoPXmW7jiX9AqxAlXhO33Hd D7G1GmTMrPeuuiYAgd6oXJ61XPm4myq7npUvzrnTKA7daa0nPYgNXjvsLajRK1yvLOF2 ZNPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ooFOo/AVlNSWRWCVA3R5jq5dgiEJu/EGHjQug4wsiQ8=; b=EtCqqsoMuEnKcWkkI0kHcGepFJDAu5cqHTPyn31e1AzkZoEL2rCwvxYNkIEl3psXR4 uZbN9voMHQ867uOkE/N9jCxlo51i96P48eZbTQPnutAklq5b9tFhMfpVObImDq3vdEWv SkkAdOWClxwGXP0X2Q6V9UyjkwYXOCrQFXyu00D+WUVplfK/cLfFFotIju9Q4xvAas2i 6rONxSGjt1iCZH0DRJfir/lEaPZcJIqfZs0u0CZ7SnKBOlM6m57cBdfrRL1d7u2BVcqx sWUJuqt95JfbTR17R7Wc/CUY9+CO1LC1rj5gAAydSK7JkfUhD1Put07uIShHNj3QhVJi sT5Q== X-Gm-Message-State: AOPr4FX7ECRnDtmVmSf/cUfHYjfJcP4vdU3EQ1iRljhuQMolurgmqjOJLB1hyj30+cWU/ryBMUjku9vJ0SVa/g== X-Received: by 10.50.29.45 with SMTP id g13mr13137215igh.93.1462572550957; Fri, 06 May 2016 15:09:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.15.93 with HTTP; Fri, 6 May 2016 15:08:31 -0700 (PDT) In-Reply-To: References: From: Tony Przygienda Date: Fri, 6 May 2016 15:08:31 -0700 Message-ID: To: Jonathan Hardwick , Jon Hudson , Susan Hares , zhang.xian@huawei.com Content-Type: multipart/alternative; boundary=047d7bd7528c5bb099053233b5d7 Archived-At: Cc: rtg-dir@ietf.org Subject: Re: [RTG-DIR] Routing directorate QA review of draft-ietf-i2rs-yang-l3-topology X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 22:09:14 -0000 --047d7bd7528c5bb099053233b5d7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I was requested as part of the routing directorate to provide a QA review for draft-ietf-i2rs-yang-l3-topology-01. I give my input assuming the wider angle of the complete yang-topology work in i2rs first since this specific draft is just an extension of it. I follow this up by examples of detailed technical concerns/work items I found. To start off with a wider angle: Overall, the draft seems a bit hard to follow as far as the use-case correlation goes in several aspects (I admit there are valid use-cases for this draft but between the i2rs-usecase and l3-topology drafts they are not easy to detect/understand). In more detail: i) draft-ietf-i2rs-usecase-reqs-summary-02 provides no clear, hard rationale for having an l3-topology draft in i2rs in this form IMO. There are some requirements about =E2=80=9CIGP node failure for faster detection= =E2=80=9D but l3-topology draft does not cover any clear use-cases in section 6 as claimed, neither in e.g. Section 6.1 (VC) nor 6.3 (where e.g. Topo-REQ-01 seems to have been miswritten?). Further, the model does not include IGP low level elements like LSAs, statistics or any of the things required for the PCE/SFC use cases (such as protection types, prefixes, admin groups) or ultimately things desired in section 4 of draft-ietf-i2rs-usecase-reqs-summary-02. The draft omits so much information that it can be used to maybe =E2=80=98high-level share=E2=80=99= topology info but not for computations relating to detailed IGP IGP forwarding computation decisions (e.g. overload bits or capabilities are omitted). A clear, detailed use example introduced in the draft could go a long way to improve things. In comparison, when looking @ the i2rs drafts related to it, I cannot clearly delineate WHICH type of information is supposed to be contained in the topology draft and which in auto drafts. To give a specific example the draft teas-te-topology seems to be in an excellent shape and have a clear purpose in life, draft-i2rs-yang-l3 and draft-i2rs-yang-l2 leave the impression of being unclear in scope and intended use-cases. ii) it would be beneficial to mention that BGP-LS is providing the superset of the information contained in this draft (albeit not as a =E2=80=9Cmodel=E2=80=9D) in a standardized fashion already. RFC 7752 has be= en published on standards track and is being deployed @ a quick rate. IMO the l3-topology draft could do a better job delineating the use-cases it will serve from the ones covered by BGP-LS already or describes the expected overlap. iii) For the suggested models to work well a strong support for Yang push is needed. The network topology draft is mentioning Yang push and obviously restconf exists but both were not seeing the necessary amount of contributions in IETF or implementations IMO. Smaller angle (examples of detailed technical concerns): I see tons of information missing in the draft which IGPs carry and need to be conveyed to understand WHAT IGPs actually do and I don=E2=80=99t see a c= lear indications whether it=E2=80=99s intentional or will be remedied and to whi= ch extent (again, without a clear use case correlation it=E2=80=99s hard to de= cide WHAT needs to be in). To give couple random examples: i) Prefix metrics: where is I/E which is very important, otherwise the metrics are not comparable? I know that =E2=80=9Cflags=E2=80=9D can be= claimed to cover everything in the future but the flags need to be described for the implementations to interoperate. ii) I do not find things like overload bits, capabilities & so on that determine how the information is being used and whether e.g. the node/link even participates in control and/or data plane. iii) A node can be ABR (in multiple areas) and ASBR @ same time while it can be only one of 1 or 2 or 1-2 in ISIS (historically expressed like this while it could be considered as a logical combination of both as well). The model does not capture that as far I saw. Both things look the same while ISIS node type should be an enum probably. iv) Multi-topology ID in ISIS is 12 bits. v) Overload/colors/admin tags/ TE metrics and many other things are missing while e.g. topology ID is included. Again, the delineation between TE draft and topology drafts does not seem clear to me. Overall, I do think that a l3 topology draft is necessary but its purpose is not explained clearly enough. With that it is non-obvious which topology/node/link information it needs to ultimately carry. I would encourage the WG/authors to correlate the draft clearly with use cases and even better, usage examples and explain why/when BGP-LS will not meet those use-cases. It will be then necessary to subject the draft to the scrutiny of OSPF/ISIS experts which will make sure that it contains a set of information that allows the client of such a model the derivation of conclusions to meet the intended use cases. If these models are to progress successfully and enjoy wide acceptance I recommend a stronger focus at area director level given to the yang push model work. thanks -- tony --047d7bd7528c5bb099053233b5d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I was requested as part of the r= outing directorate to provide a QA review for=C2=A0 draft-ietf-i2rs-yang-l3= -topology-01. I give my input assuming the wider angle of the complete yang= -topology work in i2rs first=C2=A0since this specific draft is just an e= xtension of it. I follow this up by examples of detailed technical concerns= /work items I found.


To start off with a wider angle:

=C2=A0

Overall, the draft seems a bit hard to follow as fa= r as the use-case correlation goes in several aspects (I admit there are va= lid use-cases for this draft but between the i2rs-usecase and l3-topology d= rafts they are not easy to detect/understand). In more detail:=C2=A0=

= i)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-ietf-i2rs-usecase-reqs-summary-02 pr= ovides no clear, hard rationale for having an l3-topology draft in i2rs in = this form IMO. There are some requirements about =E2=80=9CIGP node failure = for faster detection=E2=80=9D but l3-topology draft does not cover any clea= r use-cases in section 6 as claimed, neither in e.g. Section 6.1 (VC) nor 6= .3 (where e.g. Topo-REQ-01 seems to have been miswritten?). Further, the mo= del does not include IGP low level elements like LSAs, statistics or any of= the things required for the PCE/SFC use cases (such as protection types, p= refixes, admin groups) or ultimately things desired in section 4 of draft-i= etf-i2rs-usecase-reqs-summary-02. The draft=C2=A0 omits so much information= that it can be used to maybe =E2=80=98high-level share=E2=80=99 topology i= nfo but not for computations relating to detailed IGP IGP forwarding comput= ation decisions (e.g. overload bits or capabilities are omitted). A clear, = detailed use example introduced in the draft could go a long way to improve= things.=C2=A0 In comparison, when looking @ the i2rs drafts related to it,= I cannot clearly delineate WHICH type of information is supposed to be con= tained in the topology draft and which in auto drafts. To give a specific e= xample the draft teas-te-topology seems to be in an excellent shape and hav= e a clear purpose in life, draft-i2rs-yang-l3 and draft-i2rs-yang-l2 leave = the impression of being unclear in scope and intended use-cases.

= ii)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0it would be beneficial to mention that BGP= -LS is providing the superset of the information contained in this draft (a= lbeit not as a =E2=80=9Cmodel=E2=80=9D) in a standardized fashion already. = RFC 7752 has been published on standards track and is being deployed @ a qu= ick rate. IMO the l3-topology draft could do a better job delineating the u= se-cases it will serve from the ones covered by BGP-LS already or describes= the expected overlap.=C2=A0

= iii)=C2=A0 For the sugge= sted models to work well a strong support for Yang push is needed. The netw= ork topology draft is mentioning Yang push and obviously restconf exists bu= t both were not seeing the necessary amount of contributions in IETF or imp= lementations IMO.=C2=A0


Smaller angle (examples of detailed technical conce= rns):


I see tons of information missing in the draft whic= h IGPs carry and need to be conveyed to understand WHAT IGPs actually do an= d I don=E2=80=99t see a clear indications whether it=E2=80=99s intentional = or will be remedied and to which extent (again, without a clear use case co= rrelation it=E2=80=99s hard to decide WHAT needs to be in). To give couple = random examples:

i)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 P= refix metrics: where is I/E which is very important, otherwise the metrics = are not comparable?=C2=A0 I know that =E2=80=9Cflags=E2=80=9D can be claime= d to cover everything in the future but the flags need to be described for = the implementations to interoperate.=C2=A0

ii)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I do n= ot find things like overload bits, capabilities & so on that determine = how the information is being used and whether e.g. the node/link even parti= cipates in control and/or data plane.=C2=A0

iii)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A nod= e can be ABR (in multiple areas) and ASBR @ same time while it can be only = one of 1 or 2 or 1-2 in ISIS (historically expressed like this while it cou= ld be considered as a logical combination of both as well). The model does = not capture that as far I saw. Both things look the same while ISIS node ty= pe should be an enum probably.

iv)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Multi-topology ID in ISIS is 12 bits. =C2=A0

v)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 O= verload/colors/admin tags/ TE metrics and many other things are missing whi= le e.g. topology ID is included. Again, the delineation between TE draft an= d topology drafts does not seem clear to me.=C2=A0

=C2=A0

Overall, I do think that a l3 topology draft is nec= essary but its purpose is not explained clearly enough. With that it is non= -obvious which topology/node/link information it needs to ultimately carry.= I would encourage the WG/authors to correlate the draft clearly with use c= ases and even better, usage examples and explain why/when BGP-LS will not m= eet those use-cases. It will be then necessary to subject the draft to the = scrutiny of OSPF/ISIS experts which will make sure that it contains a set o= f information that allows the client of such a model the derivation of conc= lusions to meet the=C2=A0 intended use cases. If these models are to progre= ss successfully and enjoy wide acceptance I recommend a stronger focus at a= rea director level given to the yang push model work.

=C2=A0

thanks=C2=A0

-- tony= =C2=A0
--047d7bd7528c5bb099053233b5d7-- From nobody Sun May 8 19:17:16 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A53A12D197; Sun, 8 May 2016 19:17:15 -0700 (PDT) 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=googlemail.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 buGQZOsummpf; Sun, 8 May 2016 19:17:13 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 33EC212D18D; Sun, 8 May 2016 19:17:10 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id f66so50171681vkh.2; Sun, 08 May 2016 19:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=kJwUVmztqHgDad3+5ENFC9e4+3UHElC3yqkwbDXnbTQ=; b=xWrhDsxYF11lCCjeY8S8+CLvjHmnFy7vs4eiDX948kh1+Qm58dUcuDzXbUXLXFdPTe cfFZGmuCt3nzAHjTdc95l9M7VqqOgbVCuHYn+KXbD3j8E1gpPLmxBEcggorZaSAKLByt t6nL8TfHvGrxxJL3ma+Xaov1BC50w7OsV0f8arfjkIQIhHsP+ZtTNdY3hUt6ra8jj0vd hJ/D8LJ36fh3V+Xch4LSCBQ5yHvR60KtMEDhn7Cr+ePj8zNhEWPWWSuWn/eZoiis0tt2 sqQrZiZhiXyjLzO5hd8wcD6ovIiEXX/yj8FIgWWg20eieVIx7nreTopNtFGzvRbivk3+ 6Z8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=kJwUVmztqHgDad3+5ENFC9e4+3UHElC3yqkwbDXnbTQ=; b=HMvSvSTgue78CX6RPLZdN/TIupJkGdfWfNUTX7v550XL907chiqzZvNIqErk0CxxYT dZbbeS8j+vnk2l/4CRZtWS9ZnPd9iwnZyRdnaT8XRhCHEw6V21zDpbCP/og5cvYAgZCN 1C6akv/LyXMtWZfX2r2LD+5o2rXnZJCf2ENSe1CdGJBjU6H3QDQuc+v5UFo7vqw3PMt+ M3nh8bATfBbUlzvTqbRZvzgDXX7Bibh2HzcRL6po3LmLPYXn7wTflCdewKwMEd4ibVL4 +JtmBTciAo7jk0qSKPTnx5xA61N/34gZ+JjhlRCwNR4YAMS8uEOocP+33wIv7Dwgd1gh Tj4w== X-Gm-Message-State: AOPr4FW3Dd/oOsPxhNQ/Nsig2yqLFDvqzAsY2bAm56RkgWITnuT/AhEynUi7dv0hsiJZyOYSpBG7hTFbCH9v+w== MIME-Version: 1.0 X-Received: by 10.159.55.207 with SMTP id q73mr18922343uaq.71.1462760229149; Sun, 08 May 2016 19:17:09 -0700 (PDT) Received: by 10.176.69.211 with HTTP; Sun, 8 May 2016 19:17:09 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 May 2016 05:17:09 +0300 Message-ID: From: Ines Robles To: i2rs@ietf.org, draft-ietf-i2rs-yang-network-topo@ietf.org Content-Type: multipart/alternative; boundary=94eb2c03fa6ad9a34805325f670a Archived-At: Cc: Jonathan Hardwick , "rtg-dir@ietf.org" , "Zhangxian \(Xian\)" , Susan Hares , Jon Hudson Subject: Re: [RTG-DIR] Routing directorate QA review of draft-ietf-i2rs-yang-network-topo X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 02:17:15 -0000 --94eb2c03fa6ad9a34805325f670a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, QA review related to Data Model for Network Topologies I-D: Document: draft-ietf-i2rs-yang-network-topo-02.txt Reviewer: Ines Robles Review Date: May 9, 2016 Intended Status: Standards Track Summary: I have some minor concerns about this document that should be resolved before publication. Comments: I believe the draft is technically good. Thinking how it could be extended for constrained topology networks, e.g. RPL build a DODAG (Destination-Oriented Directed Acyclic Graph) and I like that the links are point-to-point and unidirectional, and like "One common requirement concerns the ability to represent that the same device can be part of multiple networks and topologies." a RPL node can participate in several DODAGs and in each one can have different role. Major Issues: I have no =E2=80=9CMajor=E2=80=9D issues with this I-D. Minor Issues and Nits: 1- Section 1, following Figure 2: 1.1- " X1 and X2 - mapping onto... ", I think it would be "X1 and X3 mapping onto..." 1.2- " a single L3 network element", I would add in this case [Y2] "a single L3 [Y2] network element", the same for "The figure shows a single "L3" network element mapped onto multiple "Optical" network elements.", I would add "The figure shows a single "L3" [Y2] network element mapped onto multiple "Optical" network elements [Z] and [Z1]." 2- Section 2: 2.1- I would add a reference to RFC 6020, since the document uses terminology e.g container, augment, etc. which are defined in 6020. Even if this RFC is mentioned in the normative reference, still I would add it here as well. 2.2- In terminology you mention ReST, for this I would add the reference for further information. "Fielding, Roy Thomas. "Architectural styles and the design of network-based software architectures." PhD diss., University of California, Irvine, 2000.". ReST is mentioned here but not in the rest of the draft, is it correct? 3- Section 5: What about add the security considerations mentioned in 6020? 4- In general: I would mention as related work and the relation with this draft: draft-ietf-i2rs-yang-l2-network-topology-02, draft-ietf-i2rs-yang-l3-topology-01 and draft-contreras-supa-yang-network-topo-03 (this one is expired) Thank you, Ines. --94eb2c03fa6ad9a34805325f670a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,<= /div>

QA rev= iew related to Data Model for Network Topologies I-D:


Document: draft-ietf-i2rs-yang-network-topo-02.txt

Reviewer: Ines Roble= s

Revi= ew Date: May 9, 2016

Intended Status: Standards Track



Summary:

=C2=A0I have some minor conce= rns about this document that should be resolved before publication.


Comments:

I believe the draft is technically good. Thinki= ng how it could be extended for constrained topology networks, e.g. RPL bui= ld a DODAG (Destination-Oriented Directed Acyclic Graph) and I like that th= e links =C2=A0are point-to-point and unidirectional, and like "One com= mon requirement concerns the ability to represent that the same device can = be part of multiple networks and topologies." a RPL node can participa= te in several DODAGs and in each one can have different role.


Major Issues:

<= div class=3D"gmail_extra">I have no =E2=80=9CMajor=E2=80=9D issues with thi= s I-D.

Minor Issues and Nits:

1- Section 1, following Figure 2:

=C2=A01.1- " X1 and X2 -= mapping onto... ", =C2=A0I think it would be "X1 and X3 mapping = onto..."
=C2=A01.2- " a single L3= network element", I would add in this case [Y2] "a single L3 [Y2= ] network element", the same for "The figure shows a single "= ;L3" network element mapped onto multiple "Optical" network = elements.", I would add "The figure shows a single "L3"= [Y2] network element mapped onto multiple "Optical" network elem= ents [Z] and [Z1]."

2- Section 2:

=
=C2=A02.1- I would add a reference to RFC 6020, = since the document uses terminology e.g container, augment, etc. which are = defined in 6020. Even if this RFC is mentioned in the normative reference, = still I would add it here as well.=C2=A0
=C2=A02.2- In terminology you mention Re= ST, for this I would add the reference for further information. "Field= ing, Roy Thomas. "Architectural styles and the design of network-based= software architectures." PhD diss., University of California, Irvine,= 2000.".=C2=A0
ReST is mentioned here = but not in the rest of the draft, is it correct?


3- Section 5: What about add the security considerations mentioned in = 6020?

=
4- In general: I would mention as rela= ted work and the relation with this draft: draft-ietf-i2rs-yang-l2-network-= topology-02, draft-ietf-i2rs-yang-l3-topology-01 and draft-contreras-supa-y= ang-network-topo-03 (this one is expired)
<= br>

Th= ank you,

Ines.
--94eb2c03fa6ad9a34805325f670a-- From nobody Mon May 9 09:20:15 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B1112D09D; Mon, 9 May 2016 09:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] 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 LtYUBXcnoujF; Mon, 9 May 2016 09:20:12 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 D6A3512D535; Mon, 9 May 2016 09:20:11 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.238; From: "Susan Hares" To: "'Ines Robles'" , , References: In-Reply-To: Date: Mon, 9 May 2016 12:20:01 -0400 Message-ID: <016901d1aa0e$a3a48fb0$eaedaf10$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_016A_01D1A9ED.1C95FCF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKvZPF3zDxstev4wPdQHgNIenot2gJu0abhAgTMek0BNJ8aeAF+C2MbAq41G2adpq9T0A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jonathan Hardwick' , rtg-dir@ietf.org, "'Zhangxian \(Xian\)'" , 'Jon Hudson' Subject: Re: [RTG-DIR] [i2rs] Routing directorate QA review of draft-ietf-i2rs-yang-network-topo X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 16:20:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_016A_01D1A9ED.1C95FCF0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ines:=20 =20 Thank you for the excellent review. We appreciate your hard work.=20 =20 Sue=20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Ines Robles Sent: Sunday, May 08, 2016 10:17 PM To: i2rs@ietf.org; draft-ietf-i2rs-yang-network-topo@ietf.org Cc: Jonathan Hardwick; rtg-dir@ietf.org; Zhangxian (Xian); Susan Hares; = Jon Hudson Subject: Re: [i2rs] Routing directorate QA review of = draft-ietf-i2rs-yang-network-topo =20 Hi, =20 QA review related to Data Model for Network Topologies I-D: =20 =20 Document: draft-ietf-i2rs-yang-network-topo-02.txt =20 Reviewer: Ines Robles =20 Review Date: May 9, 2016 =20 Intended Status: Standards Track =20 =20 =20 Summary: =20 I have some minor concerns about this document that should be resolved = before publication. =20 =20 Comments: =20 I believe the draft is technically good. Thinking how it could be = extended for constrained topology networks, e.g. RPL build a DODAG = (Destination-Oriented Directed Acyclic Graph) and I like that the links = are point-to-point and unidirectional, and like "One common requirement = concerns the ability to represent that the same device can be part of = multiple networks and topologies." a RPL node can participate in several = DODAGs and in each one can have different role. =20 =20 Major Issues: =20 I have no =E2=80=9CMajor=E2=80=9D issues with this I-D. =20 Minor Issues and Nits: =20 1- Section 1, following Figure 2: =20 1.1- " X1 and X2 - mapping onto... ", I think it would be "X1 and X3 = mapping onto..." 1.2- " a single L3 network element", I would add in this case [Y2] "a = single L3 [Y2] network element", the same for "The figure shows a single = "L3" network element mapped onto multiple "Optical" network elements.", = I would add "The figure shows a single "L3" [Y2] network element mapped = onto multiple "Optical" network elements [Z] and [Z1]." =20 2- Section 2: =20 2.1- I would add a reference to RFC 6020, since the document uses = terminology e.g container, augment, etc. which are defined in 6020. Even = if this RFC is mentioned in the normative reference, still I would add = it here as well.=20 =20 2.2- In terminology you mention ReST, for this I would add the = reference for further information. "Fielding, Roy Thomas. "Architectural = styles and the design of network-based software architectures." PhD = diss., University of California, Irvine, 2000.".=20 ReST is mentioned here but not in the rest of the draft, is it correct? =20 =20 3- Section 5: What about add the security considerations mentioned in = 6020? =20 =20 4- In general: I would mention as related work and the relation with = this draft: draft-ietf-i2rs-yang-l2-network-topology-02, = draft-ietf-i2rs-yang-l3-topology-01 and = draft-contreras-supa-yang-network-topo-03 (this one is expired) =20 =20 Thank you, =20 Ines. ------=_NextPart_000_016A_01D1A9ED.1C95FCF0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Ines:

 

Thank you for the excellent review.=C2=A0 We appreciate your hard = work.

 

Sue

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Ines = Robles
Sent: Sunday, May 08, 2016 10:17 PM
To: = i2rs@ietf.org; draft-ietf-i2rs-yang-network-topo@ietf.org
Cc: = Jonathan Hardwick; rtg-dir@ietf.org; Zhangxian (Xian); Susan Hares; Jon = Hudson
Subject: Re: [i2rs] Routing directorate QA review of = draft-ietf-i2rs-yang-network-topo

 

Hi,

 

QA review related to Data Model for Network Topologies = I-D:

 

 

Document: = draft-ietf-i2rs-yang-network-topo-02.txt

 

Reviewer: Ines Robles

 

Review Date: May 9, 2016

 

Intended Status: Standards = Track

 

 

 

Summary:

 

 I have some minor concerns about this document = that should be resolved before publication.

 

 

Comments:

 

I = believe the draft is technically good. Thinking how it could be extended = for constrained topology networks, e.g. RPL build a DODAG = (Destination-Oriented Directed Acyclic Graph) and I like that the links =  are point-to-point and unidirectional, and like "One common = requirement concerns the ability to represent that the same device can = be part of multiple networks and topologies." a RPL node can = participate in several DODAGs and in each one can have different = role.

 

 

Major Issues:

 

I = have no =E2=80=9CMajor=E2=80=9D issues with this = I-D.

 

Minor Issues and Nits:

 

1- Section 1, following Figure = 2:

 

 1.1- " X1 and X2 - mapping onto... ", =  I think it would be "X1 and X3 mapping = onto..."

 1.2- = " a single L3 network element", I would add in this case [Y2] = "a single L3 [Y2] network element", the same for "The = figure shows a single "L3" network element mapped onto = multiple "Optical" network elements.", I would add = "The figure shows a single "L3" [Y2] network element = mapped onto multiple "Optical" network elements [Z] and = [Z1]."

 

2- Section 2:

 

 2.1- I would add a reference to RFC 6020, since = the document uses terminology e.g container, augment, etc. which are = defined in 6020. Even if this RFC is mentioned in the normative = reference, still I would add it here as = well. 

 

 2.2- In terminology you mention ReST, for this I = would add the reference for further information. "Fielding, Roy = Thomas. "Architectural styles and the design of network-based = software architectures." PhD diss., University of California, = Irvine, 2000.". 

ReST is mentioned here but not in the rest of the = draft, is it correct?

 

 

3- Section 5: What about add the security = considerations mentioned in 6020?

 

 

4- In general: I would mention as related work and the = relation with this draft: draft-ietf-i2rs-yang-l2-network-topology-02, = draft-ietf-i2rs-yang-l3-topology-01 and = draft-contreras-supa-yang-network-topo-03 (this one is = expired)

 

 

Thank you,

 

Ines.

------=_NextPart_000_016A_01D1A9ED.1C95FCF0-- From nobody Mon May 9 19:35:53 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A09712D0A1; Mon, 9 May 2016 19:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 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.996, 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 ht3xyM3BJvX3; Mon, 9 May 2016 19:35:49 -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 E806712B052; Mon, 9 May 2016 19:35:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id COI36165; Tue, 10 May 2016 02:35:45 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 10 May 2016 03:35:44 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Tue, 10 May 2016 10:35:37 +0800 From: Mingui Zhang To: Julien Meuric Thread-Topic: RtgDir review: draft-ietf-trill-mtu-negotiation-02 Thread-Index: AQHRoMQerp4NGV2VcEqtxnPN1zxy5p+fCHCAgAW+q4CAAdE0AIABgY2AgAltlPA= Date: Tue, 10 May 2016 02:35:37 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E787C889B1@NKGEML515-MBX.china.huawei.com> References: <57212222.5080904@orange.com> <4552F0907735844E9204A62BBDD325E787C858FD@NKGEML515-MBX.china.huawei.com> <572706E7.7050005@orange.com> <4552F0907735844E9204A62BBDD325E787C865EB@NKGEML515-MBX.china.huawei.com> <5729D091.2040904@orange.com> In-Reply-To: <5729D091.2040904@orange.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.146.93] 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.0A020204.57314902.0048, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c158f6fcc470b03a621f6ad0d3ea5596 Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-trill-mtu-negotiation.all@ietf.org" , "trill@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-trill-mtu-negotiation-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 02:35:52 -0000 SGkgSnVsaWVuLA0KDQpJIGhhdmUgdXBsb2FkZWQgdGhlIDA0IHZlcnNpb24uIFBsZWFzZSB0YWtl IGEgbG9vay4NCg0KVGhhbmtzLA0KTWluZ3VpDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogSnVsaWVuIE1ldXJpYyBbbWFpbHRvOmp1bGllbi5tZXVyaWNAb3JhbmdlLmNv bV0NCj4gU2VudDogV2VkbmVzZGF5LCBNYXkgMDQsIDIwMTYgNjozNiBQTQ0KPiBUbzogTWluZ3Vp IFpoYW5nDQo+IENjOiBkcmFmdC1pZXRmLXRyaWxsLW10dS1uZWdvdGlhdGlvbi5hbGxAaWV0Zi5v cmc7IHJ0Zy1hZHNAaWV0Zi5vcmc7IHJ0Zy1kaXJAaWV0Zi5vcmc7DQo+IHRyaWxsQGlldGYub3Jn DQo+IFN1YmplY3Q6IFJlOiBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLXRyaWxsLW10dS1uZWdv dGlhdGlvbi0wMg0KPiANCj4gSGkgTWluZ3VpLA0KPiANCj4gSSBoYXZlIGxvb2tlZCBhdCB0aGUg ZGlmZiBvZiB5b3VyIHVwZGF0ZSBhbmQgaGF2ZSBub3RpY2VkIHRoYXQgc2V2ZXJhbCAic2hvdWxk Ig0KPiBoYXZlIGJlZW4gcmVwbGFjZWQgYnkgIm5lZWRbc10gdG8iOiBJIGFwcHJlY2lhdGUgdGhh dCB5b3UgYWNrbm93bGVkZ2UgbXkNCj4gY29tbWVudCBvbiB0aGlzLCBidXQgbm9uZSBvZiB0aGVt IGJlaW5nIFJGQyAyMTE5IGtleXdvcmQsIEkgc3RpbGwgZG91YnQgdGhpcw0KPiBtYXRjaGVzIFN0 YW5kYXJkcyBUcmFjayBleHBlY3RhdGlvbnMuDQo+IA0KPiBJIGNhdWdodCBhIG5pdCBpbiBzZWN0 aW9uIDM6IHMvaXMgc2VudCB0by9pcyBzZXQgdG8vDQo+IA0KPiBSZWdhcmRzLA0KPiANCj4gSnVs aWVuDQo+IA0KPiANCj4gTWF5LiAwMywgMjAxNiAtIHpoYW5nbWluZ3VpQGh1YXdlaS5jb206DQo+ ID4gSGkgSnVsaWVuLA0KPiA+DQo+ID4gVGhlIHVwZGF0ZWQgdmVyc2lvbiBoYXMganVzdCBiZWVu IHVwbG9hZGVkLg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IE1pbmd1aQ0KPiA+DQo+ID4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IEp1bGllbiBNZXVyaWMgW21haWx0bzpq dWxpZW4ubWV1cmljQG9yYW5nZS5jb21dDQo+ID4+IFNlbnQ6IE1vbmRheSwgTWF5IDAyLCAyMDE2 IDM6NTEgUE0NCj4gPj4NCj4gPj4gSGkgTWluZ3VpLA0KPiA+Pg0KPiA+PiBBYm91dCB0aGUgInVw ZGF0ZWQgUkZDcyIgaXNzdWUgYmVsb3csIG15IHBvaW50IGlzOiAicGxlYXNlIG1ha2Ugc3VyZQ0K PiA+PiB0aGUgdGV4dCBhbmQgdGhlIGhlYXJkZXIgYXJlIGNvbXBsZXRlIi4gSSBqdXN0IGhhZCBh IHF1aWNrIGxvb2sgYXQNCj4gPj4gdGhvc2UgcmVmZXJlbmNlcywgeW91IGtub3cgYmV0dGVyIHRo YW4gbWUgd2hpY2ggYXJlIGFjdHVhbGx5IHJlbGV2YW50Lg0KPiA+Pg0KPiA+PiBJIGFtIGxvb2tp bmcgZm9yd2FyZCB0byB0aGUgdXBkYXRlZCB2ZXJzaW9uLg0KPiA+Pg0KPiA+PiBUaGFua3MsDQo+ ID4+DQo+ID4+IEp1bGllbg0KPiA+Pg0KPiA+Pg0KPiA+PiBBcHIuIDI5LCAyMDE2IC0gemhhbmdt aW5ndWlAaHVhd2VpLmNvbToNCj4gPj4+IEhpIEp1bGllbiwNCj4gPj4+DQo+ID4+PiBUaGFua3Mg Zm9yIHRoZSBjb21tZW50cyEgTXVjaCBhcHByZWNpYXRlZCENCj4gPj4+DQo+ID4+PiBQbGVhc2Ug c2VlIGluLWxpbmVzIGJlbG93LiBBbiB1cGRhdGVkIHZlcnNpb24gd2lsbCBzb29uIGJlIHVwbG9h ZGVkDQo+ID4+PiB0byByZXNvbHZlDQo+ID4+IHRoZSBjb21tZW50cy4NCj4gPj4+DQo+ID4+PiBU aGFua3MsDQo+ID4+PiBNaW5ndWkNCj4gPj4+DQo+ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPj4+PiBGcm9tOiBKdWxpZW4gTWV1cmljIFttYWlsdG86anVsaWVuLm1ldXJpY0Bv cmFuZ2UuY29tXQ0KPiA+Pj4+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAyOCwgMjAxNiA0OjM0IEFN DQo+ID4+Pj4NCj4gPj4+PiBIZWxsbywNCj4gPj4+Pg0KPiA+Pj4+IEkgaGF2ZSBiZWVuIHNlbGVj dGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0Lg0K PiA+Pj4+IFRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtzIHRvIHJldmlldyBhbGwgcm91dGlu ZyBvcg0KPiA+Pj4+IHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2gg SUVURiBsYXN0IGNhbGwgYW5kIElFU0cNCj4gPj4+PiByZXZpZXcsIGFuZCBzb21ldGltZXMgb24g c3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3DQo+ID4+Pj4gaXMgdG8N Cj4gPj4gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4NCj4gPj4+PiBGb3Ig bW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNl ZQ0KPiA+Pj4+IGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9S dGdEaXINCj4gPj4+Pg0KPiA+Pj4+IEFsdGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJp bHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcNCj4gPj4+PiBBRHMsIGl0IHdvdWxkIGJlIGhl bHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkNCj4gPj4+PiBv dGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZl IHRvDQo+ID4+Pj4gcmVzb2x2ZSB0aGVtIHRocm91Z2ggZGlzY3Vzc2lvbiBvciBieSB1cGRhdGlu ZyB0aGUgZHJhZnQuDQo+ID4+Pj4NCj4gPj4+PiBEb2N1bWVudDogZHJhZnQtaWV0Zi10cmlsbC1t dHUtbmVnb3RpYXRpb24tMDIudHh0DQo+ID4+Pj4gUmV2aWV3ZXI6IEp1bGllbiBNZXVyaWMNCj4g Pj4+PiBSZXZpZXcgRGF0ZTogQXByaWwgMjcsIDIwMTYNCj4gPj4+PiBJRVRGIExDIEVuZCBEYXRl OiBBcHJpbCA1LCAyMDE2DQo+ID4+Pj4NCj4gPj4+PiBJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJk cyBUcmFjaw0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiAqU3VtbWFyeToqDQo+ID4+Pj4gSSBoYXZl IHNvbWUgbWlub3IgY29uY2VybnMgYWJvdXQgdGhpcyBkb2N1bWVudCB0aGF0IEkgdGhpbmsgc2hv dWxkDQo+ID4+Pj4gYmUgcmVzb2x2ZWQgYmVmb3JlIHB1YmxpY2F0aW9uLg0KPiA+Pj4+DQo+ID4+ Pj4gKkNvbW1lbnRzOioNCj4gPj4+PiBFdmVuIHRob3VnaCBpdCByZXF1aXJlcyB0byBicm93c2Ug c29tZSBvdGhlciBUUklMTCAobm9ybWF0aXZlKQ0KPiA+Pj4+IGRvY3VtZW50cywgdGhlIG1lY2hh bmlzbSBpdHNlbGYgaXMgc2ltcGxlIGFuZCB3ZWxsIGRlc2NyaWJlZC4NCj4gPj4+PiBOZXZlcnRo ZWxlc3MsIHRoZSBzcGVjaWZpY2F0aW9uIGRlc2VydmVzIHNvbWUgaW1wcm92ZW1lbnQgd2hlbiBp dA0KPiA+Pj4+IGNvbWVzIHRvIG9ibGlnYXRpb25zIGFuZCBvcHRpb25zOiB0aGlzIHdhcyBwYXJ0 IG9mIG15IGV4cGVjdGF0aW9uDQo+ID4+Pj4gYWZ0ZXIgSSByZWFsaXplZCBpdCB3YXMgdXBncmFk aW5nIGEgc2hvcnQgc2VjdGlvbiBvZiB0aGUgYmFzZQ0KPiA+Pj4+IGRvY3VtZW50IChSRkMgNjMy NSksIHdoaWNoIG5lZWRzIHRvIGJlIGVtcGhhc2l6ZWQgYXMgd2VsbC4NCj4gPj4+DQo+ID4+PiBJ biB0aGUgYWJzdHJhY3QsIGl0J3MgYWxyZWFkeSBtZW50aW9uZWQgYXMgIm9wdGlvbmFsIHVwZGF0 ZXMiIHRvIFJGQw0KPiA+Pj4gNjMyNS4gSSB0aGluaw0KPiA+PiAiVXBkYXRlczogNjMyNSAiIG5l ZWRzIHRvIGFwcGVhciBpbiB0aGUgcGFnZSBoZWFkZXIgYXMgd2VsbC4NCj4gPj4+DQo+ID4+Pj4N Cj4gPj4+PiAqTWlub3IgSXNzdWVzOioNCj4gPj4+PiAtIFRoZSBkb2N1bWVudCBpcyBTVCBhbmQg cmVmZXJlbmNlcyBSRkMgMjExOS4gVGhlcmUgYSBzb21lICJNVVNUIg0KPiA+Pj4+IGFuZCBvbmUg IlNIT1VMRCIsIG1hbnkgb2YgdGhlbSBpbmhlcml0ZWQgZnJvbSBzcGVjaWZpY2F0aW9ucyBvdXQg b2YNCj4gPj4+PiB0aGUgcmVmZXJlbmNlZCBkb2N1bWVudHMuIE9uIHRoZSBvdGhlciBzaWRlLCAi bXVzdCIgYW5kICJzaG91bGQiDQo+ID4+Pj4gYXJlIGNvbW1vbmx5IHVzZWQuIFRoaXMgTVVTVCBi ZSBicm91Z2h0IHVwIHRvIFNUIGV4cGVjdGF0aW9ucy4NCj4gPj4+DQo+ID4+PiBUaGUgdXNhZ2Ug b2YgIm11c3QiIGFuZCAic2hvdWxkIiB3aWxsIGJlIHVwZGF0ZWQgYXMgbmVlZGVkLiBJIGhhdmUN Cj4gPj4+IGNoZWNrZWQgYWxsDQo+ID4+IHRob3NlIGFwcGVhcmFuY2VzLiBUaGUgY2hhbmdlcyB3 b3VsZCBiZSBlZGl0b3JpYWwuDQo+ID4+Pg0KPiA+Pj4+IC0gVGhlIGRvY3VtZW50IGNsYWltcyB0 byBvbmx5IHVwZGF0ZSBSRkMgNzE3Ny4gSXQgc2VlbXMgaG93ZXZlcg0KPiA+Pj4+IHRoYXQgaXQg YWxzbyB1cGRhdGVzIFJGQyA2MzI1IChzZWN0aW9uIDQuMy4yKSwgUkZDIDcxNzYgYW5kIG1heWJl IGV2ZW4gUkZDDQo+IDc3ODAuDQo+ID4+Pg0KPiA+Pj4gQWN0dWFsbHksIEkgZG9uJ3QgdGhpbmsg dGhpcyBkb2N1bWVudCB1cGRhdGVzIFJGQzcxNzYuIEl0IHNpbXBseQ0KPiA+Pj4gbWFrZXMgdXNl IG9mDQo+ID4+IHRoZSBNVFUgU3ViLVRMViBkZWZpbmVkIGluIFJGQyA3MTc2Lg0KPiA+Pj4gVGhl IHNwZWNpZmljYXRpb24gYWJvdXQgdGhlIG9yaWdpbmF0aW5nTDFMU1BCdWZmZXJTaXplIG9mIGFu DQo+ID4+PiB1bnJlYWNoYWJsZQ0KPiA+PiBSQnJpZGdlIGlzIGEgc2xpZ2h0IHVwZGF0ZSB0byBS RkM3NzgwLiBUaGlzIHdpbGwgYmUgZW1waGFzaXplZC4NCj4gPj4+DQo+ID4+Pj4gVGhhdCBzaG91 bGQgYmUgZWl0aGVyIGFja25vd2xlZGdlZCBvciBjbGFyaWZpZWQuIFRoZSA0dGggcGFyYWdyYXBo DQo+ID4+Pj4gb2YgdGhlIGludHJvZHVjdGlvbiB0cmllcyB0byB0YWNrbGUgdGhhdCB0b3BpYywg YnV0IGl0IGlzIG5vdCBjbGVhcg0KPiA+Pj4+IGVub3VnaCBpbiBkZWZpbmluZyB0aGUgcG9zaXRp b24gb2YgdGhlIGRvY3VtZW50IHdpdGggcmVzcGVjdCB0bw0KPiA+Pj4+IHByZXZpb3VzbHkNCj4g Pj4gZGVmaW5lZCBtZWNoYW5pc21zLg0KPiA+Pj4NCj4gPj4+IFRoZSB1cGRhdGVkIHRvIFJGQyA2 MzI1IHdpbGwgYmUgZW1waGFzaXplZCBpbiB0aGlzIHBhcmFncmFwaC4gVGhlDQo+ID4+PiBiYWNr d2FyZA0KPiA+PiBjb21wYXRpYmlsaXR5IHdpbGwgYmUgbW92ZWQgdG8gaGVyZSBhcyB3ZWxsLiBJ dCB3aWxsIGhlbHAgdGhlIHBvc2l0aW9uaW5nLg0KPiA+Pj4NCj4gPj4+PiAtIFRoZSAzcmQgcGFy YWdyYXBoIG9mIHRoZSBpbnRyb2R1Y3Rpb24gZHVwbGljYXRlcyB0aGUgYmVnaW5uaW5nIG9mDQo+ ID4+Pj4gdGhlIGZvbGxvd2luZyBzZWN0aW9uIDIuIEEgcG9zc2libGUgd2F5IHRvIGxpbWl0IHRo aXMgcmVwZXRpdGlvbg0KPiA+Pj4+IGVmZmVjdCBtYXkgYmUgdG8gc3VtbWFyaXplIHRoYXQgcGFy dCBvZiB0aGUgaW50cm9kdWN0aW9uLg0KPiA+Pj4NCj4gPj4+IFllcywgc3VtbWFyaXphdGlvbiBp cyB0aGUgcHJvcGVyIHdheS4NCj4gPj4+DQo+ID4+Pj4gLSBTZWN0aW9uIDMgc3BlY2lmaWVzIGFu IGFsZ29yaXRobS4gRXZlbiBpZiBpdCBkb2VzIG5vdCByZWx5IG9uIGENCj4gPj4+PiBmb3JtYWwg bGFuZ3VhZ2UsIGNvbnNpc3RlbmN5IHdvdWxkIGJlIHZhbHVhYmxlLiBNeSBtaW5kIGNvbXBpbGVy DQo+ID4+Pj4gd291bGQNCj4gPj4gc3VnZ2VzdDoNCj4gPj4+PiAgICAgICAgKiAiSWYiIGlzIGZv bGxvd2VkIGJ5ICJ0aGVuIiBvbmx5IG9uY2U6ICJ0aGVuIiBrZXl3b3JkIHRvIGJlDQo+IGRyb3Bw ZWQ/DQo+ID4+Pj4gICAgICAgICogVGhlIGFsZ29yaXRobSByZWxpZXMgb24gYSBicmVhay9zdG9w IG9yIGNvbnRpbnVlDQo+ID4+Pj4gcHJpbmNpcGxlOyBhcyBzdWNoLCB0aGUgaW5zdGFuY2Ugb2Yg IkVsc2UiIGF0IHRoZSBlbmQgc2hvdWxkIGJlDQo+ID4+Pj4gcmVwbGFjZWQgYnkgIjxsaW5lDQo+ ID4+Pj4gYnJlYWs+IDQpIFJlcGVhdCBTdGVwMSI7DQo+ID4+Pj4gICAgICAgICogImlzIHNldCB0 byIgYW5kICI8LS0iIHNlZW0gdG8gYmUgc2ltaWxhcjogcGxlYXNlIHBpY2sgb25lIG9yIGNsYXJp Znk7DQo+ID4+Pj4gICAgICAgICogdG8gaW1wcm92ZSByZWFkYWJpbGl0eSwgSSB3b3VsZCBkcm9w IHRoZSBkb3VibGUgbmFtaW5nDQo+ID4+Pj4gaW50cm9kdWNlZCB3aXRoIFgsDQo+ID4+Pj4gWDEg YW5kIFgyIGFuZCByZWx5IG9uIGV4cGxpY2l0IHZhcmlhYmxlIG5hbWVzIGFsbCBhbG9uZywgYXMg aW4gdGhlDQo+ID4+Pj4gdGV4dDogZS5nLiwgImxpbmtNdHVTaXplIiBpbnN0ZWFkIG9mIFgsICJs b3dlckJvdW5kIiBmb3IgWDEgYW5kDQo+ICJ1cHBlckJvdW5kIg0KPiA+PiBpbnN0ZWFkIG9mIFgy Lg0KPiA+Pj4NCj4gPj4+IFN1cmUuIEV4cGxpY2l0IG5hbWVzIHdpbGwgYmUgdXNlZCBmb3IgdGhl IHNha2Ugb2YgcmVhZGFiaWxpdHkuDQo+ID4+Pg0KPiA+Pj4+DQo+ID4+Pj4gKk5pdHM6Kg0KPiA+ Pj4NCj4gPj4+IFRoZSBmb2xsb3dpbmcgbml0cyB3aWxsIGJlIGZpeGVkIGFzIHN1Z2dlc3RlZC4N Cj4gPj4+DQo+ID4+Pj4gLS0tLS0tDQo+ID4+Pj4gIlVwZGF0ZXMiIGZpZWxkIGluIGhlYWRlcg0K PiA+Pj4+IC0tLQ0KPiA+Pj4+IC0gSSB0aGluayB0aGUgIlJGQyIgYWNyb255bSBzaG91bGQgYXBw ZWFyLg0KPiA+Pj4+IC0gVGhlIGxpc3QgbWF5IGJlIGV4dGVuZGVkIHdpdGggUkZDIFJGQyA2MzI1 LCBSRkMgNzE3NiBhbmQgbWF5YmUNCj4gPj4+PiBldmVuIFJGQyA3NzgwLg0KPiA+Pj4+IC0tLS0t LQ0KPiA+Pj4+IEFic3RyYWN0DQo+ID4+Pj4gLS0tDQo+ID4+Pj4gLSBzL2NhbXB1cyB3aWRlIE1U VSBmZWF0dXJlL2NhbXB1cy13aWRlIE1UVSBmZWF0dXJlLw0KPiA+Pj4+IC0gcy9jYW1wdXMgd2lk ZSBjYXBhYmlsaXR5L2NhbXB1cy13aWRlIGNhcGFiaWxpdHkvDQo+ID4+Pj4gLSBzL2xpbmsgbG9j YWwgcGFja2V0cy9saW5rLWxvY2FsIHBhY2tldHMvDQo+ID4+Pj4gLSBzL2xpbmsgbG9jYWwgTVRV cy9saW5rLWxvY2FsIE1UVXMvDQo+ID4+Pj4gLSAiSXQgdXBkYXRlcyBSRkMuLi4iIGR1cGxpY2F0 ZXMgaGVhZGVyOiBlaXRoZXIgdG8gZHJvcCBvciBtYWtlDQo+ID4+Pj4gbW9yZSBzcGVjaWZpYyB0 byBwb2ludCB0byBwcmVjaXNlIHNlY3Rpb25zL21lY2hhbmlzbXMuDQo+ID4+Pj4gLS0tLS0tDQo+ ID4+Pj4gU2VjdGlvbiAxLg0KPiA+Pj4+IC0tLQ0KPiA+Pj4+IC0gcy9saW5rIHNjb3BlIFBEVXMg Y2FuL2xpbmstc2NvcGVkIFBEVXMgY2FuLw0KPiA+Pj4+IC0tLS0tLQ0KPiA+Pj4+IFNlY3Rpb24g Mi4NCj4gPj4+PiAtLS0NCj4gPj4+PiAtIHMvY2FtcHVzIHdpZGUgU3ogTVRVL2NhbXB1cy13aWRl IFN6IE1UVS8NCj4gPj4+PiAtIHMvYXJlYSB3aWRlIHNjb3BlL2FyZWEtd2lkZSBzY29wZS8NCj4g Pj4+PiAtIHMvZG9tYWluIHdpZGUgc2NvcGUvZG9tYWluIHdpZGUgc2NvcGUvDQo+ID4+Pj4gLSBz L0wxIENpcmN1aXQgU2NvcGVkL0wxIENpcmN1aXQtU2NvcGVkLw0KPiA+Pj4+IC0gImxpbWl0ZWQg dG8gMTQ3MCB0byA2NSw1MzUgYnl0ZXMiOiBJIGNhbm5vdCBwYXJzZSBpdCwgaXMgaXQgbWVhbnQg dG8gYmUgYQ0KPiByYW5nZT8NCj4gPj4+PiAtLS0tLS0NCj4gPj4+PiBTZWN0aW9uIDQuDQo+ID4+ Pj4gLSBPTEQNCj4gPj4+PiAid2hpbGUgUkIxIG5vcm1hbGx5IGlnbm9yZXMgbGluayBzdGF0ZSBp bmZvcm1hdGlvbiBmb3IgYW55IElTLUlTDQo+ID4+Pj4gdW5yZWFjaGFibGUgUkJyaWRnZSBSQjIs IG9yaWdpbmF0aW5nTDFMU1BCdWZmZXJTaXplIGlzIGFuIGV4Y2VwdGlvbi4iDQo+ID4+Pj4gICAg ICBORVcNCj4gPj4+PiAid2hpbGUgaW4gbW9zdCBjYXNlcyBSQjEgaWdub3JlcyBsaW5rIHN0YXRl IGluZm9ybWF0aW9uIGZvciBJUy1JUw0KPiA+Pj4+IHVucmVhY2hhYmxlIFJCcmlkZ2UgUkIyLCBv cmlnaW5hdGluZ0wxTFNQQnVmZmVyU2l6ZSBpcyBtZWFuaW5nZnVsLiINCj4gPj4+PiBbY3VycmVu dCB3b3JkaW5nIHN1Z2dlc3RzIGl0IGlzIGFkZGluZyBhbiBleGNlcHRpb24gdG8gYSBtYW5kYXRv cnkNCj4gPj4+PiBiZWhhdmlvciwgd2hpY2ggQUZBSVUgaXQgZG9lcyBub3RdDQo+ID4+Pg0KPiA+ Pj4gT0suIFdpbGwgdXBkYXRlIHRoZSB3b3Jkcy4NCj4gPj4+DQo+ID4+Pj4gLS0tLS0tDQo+ID4+ Pj4gU2VjdGlvbiA3Lg0KPiA+Pj4+IC0tLQ0KPiA+Pj4+IC0gInRlc3RlZCBzaXplIGNhbiBiZSBh ZHZlcnRpc2VkIjogImNhbiIgaXMgdG8gYmUgYWRkcmVzc2VkIGFzIHBhcnQNCj4gPj4+PiBvZiB0 aGUgbG9vc2UgUkZDIDIxMTkgd29yZGluZyBjb21tZW50Lg0KPiA+Pj4NCj4gPj4+IFdpbGwgdXNl IHRoZSB3b3JkICJNQVkiIGluc3RlYWQuDQo+ID4+Pg0KPiA+Pj4+IC0tLS0tLQ0KPiA+Pj4+IFNl Y3Rpb24gOC4NCj4gPj4+PiAtLS0NCj4gPj4+PiAtICJ2YWx1ZSBbLi4uXSBoYWQgYmVlbiByZXBv cnRlZCI6ICJyZXBvcnRlZCIgcHV6emxlcyBtZSwgbWF5YmUgInRlc3RlZCINCj4gPj4+PiB3YXMg bWVhbnQ/DQo+ID4+Pj4gLSBUaGUgM3JkIHBhcmFncmFwaCAiRm9yIGFuIEx6LWlnbm9yYW50IFsu Li5dIGxpbmstd2lkZSBMei4iIHNob3VsZA0KPiA+Pj4+IGJlIG1vdmVkIHVwIHRvIGJlY29tZSB0 aGUgc2Vjb25kIHBhcmFncmFwaCwgc28gYXMgdG8gY2xhcmlmeSB3aGF0DQo+ID4+Pj4gYW4NCj4g Pj4gTHotaWdub3JhbnQgaXMuDQo+ID4+Pg0KPiA+Pj4gT0suIEl0IHdpbGwgYmUgbW92ZWQgdXAu DQo+ID4+Pg0KPiA+Pj4+IC0gIlRoZSBleHRlbnNpb24gb2YgVFJJTEwgTVRVIG5lZ29jaWF0aW9u Li4uIjogdGhpcyBpcyBhbiBleHBsaWNpdA0KPiA+Pj4+IHBvc2l0aW9uaW5nIHdoaWNoIHNob3Vs ZCBiZSBtZW50aW9uZWQgZWFybGllciBpbiB0aGUgSS1ELg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBP Sy4gVGhpcyB3aWxsIGJlIG1vdmVkIHRvIHRoZSBpbnRyb2R1Y3Rpb24uDQo+ID4+Pg0KPiA+Pj4+ IC0tLS0tLQ0KPiA+Pj4+IFNlY3Rpb24gMTAuDQo+ID4+Pj4gLS0tDQo+ID4+Pj4gLSBSRkMgNzE4 MCBiaXMgaXMgbm93IFJGQyA3NzgwLg0KPiA+Pj4NCj4gPj4+IFllcywgdGhpcyB3aWxsIGJlIHVw ZGF0ZWQuDQo+ID4+Pg0KPiA+Pj4+IC0tLQ0KPiA+Pj4+DQo+ID4+Pj4gUmVnYXJkcywNCj4gPj4+ Pg0KPiA+Pj4+IEp1bGllbg0KPiA+Pj4NCg== From nobody Tue May 10 01:33:54 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1E812D584; Tue, 10 May 2016 01:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.55 X-Spam-Level: X-Spam-Status: No, score=-4.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_SOFTFAIL=0.665] 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 FsFDzne4k8fa; Tue, 10 May 2016 01:33:46 -0700 (PDT) Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id E92AF12D56E; Tue, 10 May 2016 01:33:45 -0700 (PDT) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BE5E4A4418F; Tue, 10 May 2016 10:33:44 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail1.rd.orange.com (Postfix) with ESMTP id A764EA44182; Tue, 10 May 2016 10:33:44 +0200 (CEST) Received: from [10.193.71.204] (10.193.71.204) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.266.1; Tue, 10 May 2016 10:33:44 +0200 To: Mingui Zhang References: <57212222.5080904@orange.com> <4552F0907735844E9204A62BBDD325E787C858FD@NKGEML515-MBX.china.huawei.com> <572706E7.7050005@orange.com> <4552F0907735844E9204A62BBDD325E787C865EB@NKGEML515-MBX.china.huawei.com> <5729D091.2040904@orange.com> <4552F0907735844E9204A62BBDD325E787C889B1@NKGEML515-MBX.china.huawei.com> From: Julien Meuric Organization: Orange Message-ID: <57319CE8.9020300@orange.com> Date: Tue, 10 May 2016 10:33:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <4552F0907735844E9204A62BBDD325E787C889B1@NKGEML515-MBX.china.huawei.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-trill-mtu-negotiation.all@ietf.org" , "trill@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-trill-mtu-negotiation-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 08:33:50 -0000 Hi Mingui, This version seems to address my comment. Please note a new typo on page 8: s/any LPS/any LSP/ Thanks, Julien May. 10, 2016 - zhangmingui@huawei.com: > Hi Julien, > > I have uploaded the 04 version. Please take a look. > > Thanks, > Mingui > >> -----Original Message----- >> From: Julien Meuric [mailto:julien.meuric@orange.com] >> Sent: Wednesday, May 04, 2016 6:36 PM >> >> Hi Mingui, >> >> I have looked at the diff of your update and have noticed that several "should" >> have been replaced by "need[s] to": I appreciate that you acknowledge my >> comment on this, but none of them being RFC 2119 keyword, I still doubt this >> matches Standards Track expectations. >> >> I caught a nit in section 3: s/is sent to/is set to/ >> >> Regards, >> >> Julien >> >> >> May. 03, 2016 - zhangmingui@huawei.com: >>> Hi Julien, >>> >>> The updated version has just been uploaded. >>> >>> Thanks, >>> Mingui >>> >>>> -----Original Message----- >>>> From: Julien Meuric [mailto:julien.meuric@orange.com] >>>> Sent: Monday, May 02, 2016 3:51 PM >>>> >>>> Hi Mingui, >>>> >>>> About the "updated RFCs" issue below, my point is: "please make sure >>>> the text and the hearder are complete". I just had a quick look at >>>> those references, you know better than me which are actually relevant. >>>> >>>> I am looking forward to the updated version. >>>> >>>> Thanks, >>>> >>>> Julien >>>> >>>> >>>> Apr. 29, 2016 - zhangmingui@huawei.com: >>>>> Hi Julien, >>>>> >>>>> Thanks for the comments! Much appreciated! >>>>> >>>>> Please see in-lines below. An updated version will soon be uploaded >>>>> to resolve >>>> the comments. >>>>> >>>>> Thanks, >>>>> Mingui >>>>> >>>>>> -----Original Message----- >>>>>> From: Julien Meuric [mailto:julien.meuric@orange.com] >>>>>> Sent: Thursday, April 28, 2016 4:34 AM >>>>>> >>>>>> Hello, >>>>>> >>>>>> I have been selected as the Routing Directorate reviewer for this draft. >>>>>> The Routing Directorate seeks to review all routing or >>>>>> 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 >>>>>> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >>>>>> >>>>>> Although these comments are primarily for the use of the Routing >>>>>> ADs, it would be helpful if you could consider them along with any >>>>>> other IETF Last Call comments that you receive, and strive to >>>>>> resolve them through discussion or by updating the draft. >>>>>> >>>>>> Document: draft-ietf-trill-mtu-negotiation-02.txt >>>>>> Reviewer: Julien Meuric >>>>>> Review Date: April 27, 2016 >>>>>> IETF LC End Date: April 5, 2016 >>>>>> >>>>>> Intended Status: Standards Track >>>>>> >>>>>> >>>>>> *Summary:* >>>>>> I have some minor concerns about this document that I think should >>>>>> be resolved before publication. >>>>>> >>>>>> *Comments:* >>>>>> Even though it requires to browse some other TRILL (normative) >>>>>> documents, the mechanism itself is simple and well described. >>>>>> Nevertheless, the specification deserves some improvement when it >>>>>> comes to obligations and options: this was part of my expectation >>>>>> after I realized it was upgrading a short section of the base >>>>>> document (RFC 6325), which needs to be emphasized as well. >>>>> >>>>> In the abstract, it's already mentioned as "optional updates" to RFC >>>>> 6325. I think >>>> "Updates: 6325 " needs to appear in the page header as well. >>>>> >>>>>> >>>>>> *Minor Issues:* >>>>>> - The document is ST and references RFC 2119. There a some "MUST" >>>>>> and one "SHOULD", many of them inherited from specifications out of >>>>>> the referenced documents. On the other side, "must" and "should" >>>>>> are commonly used. This MUST be brought up to ST expectations. >>>>> >>>>> The usage of "must" and "should" will be updated as needed. I have >>>>> checked all >>>> those appearances. The changes would be editorial. >>>>> >>>>>> - The document claims to only update RFC 7177. It seems however >>>>>> that it also updates RFC 6325 (section 4.3.2), RFC 7176 and maybe even RFC >> 7780. >>>>> >>>>> Actually, I don't think this document updates RFC7176. It simply >>>>> makes use of >>>> the MTU Sub-TLV defined in RFC 7176. >>>>> The specification about the originatingL1LSPBufferSize of an >>>>> unreachable >>>> RBridge is a slight update to RFC7780. This will be emphasized. >>>>> >>>>>> That should be either acknowledged or clarified. The 4th paragraph >>>>>> of the introduction tries to tackle that topic, but it is not clear >>>>>> enough in defining the position of the document with respect to >>>>>> previously >>>> defined mechanisms. >>>>> >>>>> The updated to RFC 6325 will be emphasized in this paragraph. The >>>>> backward >>>> compatibility will be moved to here as well. It will help the positioning. >>>>> >>>>>> - The 3rd paragraph of the introduction duplicates the beginning of >>>>>> the following section 2. A possible way to limit this repetition >>>>>> effect may be to summarize that part of the introduction. >>>>> >>>>> Yes, summarization is the proper way. >>>>> >>>>>> - Section 3 specifies an algorithm. Even if it does not rely on a >>>>>> formal language, consistency would be valuable. My mind compiler >>>>>> would >>>> suggest: >>>>>> * "If" is followed by "then" only once: "then" keyword to be >> dropped? >>>>>> * The algorithm relies on a break/stop or continue >>>>>> principle; as such, the instance of "Else" at the end should be >>>>>> replaced by ">>>>> break> 4) Repeat Step1"; >>>>>> * "is set to" and "<--" seem to be similar: please pick one or clarify; >>>>>> * to improve readability, I would drop the double naming >>>>>> introduced with X, >>>>>> X1 and X2 and rely on explicit variable names all along, as in the >>>>>> text: e.g., "linkMtuSize" instead of X, "lowerBound" for X1 and >> "upperBound" >>>> instead of X2. >>>>> >>>>> Sure. Explicit names will be used for the sake of readability. >>>>> >>>>>> >>>>>> *Nits:* >>>>> >>>>> The following nits will be fixed as suggested. >>>>> >>>>>> ------ >>>>>> "Updates" field in header >>>>>> --- >>>>>> - I think the "RFC" acronym should appear. >>>>>> - The list may be extended with RFC RFC 6325, RFC 7176 and maybe >>>>>> even RFC 7780. >>>>>> ------ >>>>>> Abstract >>>>>> --- >>>>>> - s/campus wide MTU feature/campus-wide MTU feature/ >>>>>> - s/campus wide capability/campus-wide capability/ >>>>>> - s/link local packets/link-local packets/ >>>>>> - s/link local MTUs/link-local MTUs/ >>>>>> - "It updates RFC..." duplicates header: either to drop or make >>>>>> more specific to point to precise sections/mechanisms. >>>>>> ------ >>>>>> Section 1. >>>>>> --- >>>>>> - s/link scope PDUs can/link-scoped PDUs can/ >>>>>> ------ >>>>>> Section 2. >>>>>> --- >>>>>> - s/campus wide Sz MTU/campus-wide Sz MTU/ >>>>>> - s/area wide scope/area-wide scope/ >>>>>> - s/domain wide scope/domain wide scope/ >>>>>> - s/L1 Circuit Scoped/L1 Circuit-Scoped/ >>>>>> - "limited to 1470 to 65,535 bytes": I cannot parse it, is it meant to be a >> range? >>>>>> ------ >>>>>> Section 4. >>>>>> - OLD >>>>>> "while RB1 normally ignores link state information for any IS-IS >>>>>> unreachable RBridge RB2, originatingL1LSPBufferSize is an exception." >>>>>> NEW >>>>>> "while in most cases RB1 ignores link state information for IS-IS >>>>>> unreachable RBridge RB2, originatingL1LSPBufferSize is meaningful." >>>>>> [current wording suggests it is adding an exception to a mandatory >>>>>> behavior, which AFAIU it does not] >>>>> >>>>> OK. Will update the words. >>>>> >>>>>> ------ >>>>>> Section 7. >>>>>> --- >>>>>> - "tested size can be advertised": "can" is to be addressed as part >>>>>> of the loose RFC 2119 wording comment. >>>>> >>>>> Will use the word "MAY" instead. >>>>> >>>>>> ------ >>>>>> Section 8. >>>>>> --- >>>>>> - "value [...] had been reported": "reported" puzzles me, maybe "tested" >>>>>> was meant? >>>>>> - The 3rd paragraph "For an Lz-ignorant [...] link-wide Lz." should >>>>>> be moved up to become the second paragraph, so as to clarify what >>>>>> an >>>> Lz-ignorant is. >>>>> >>>>> OK. It will be moved up. >>>>> >>>>>> - "The extension of TRILL MTU negociation...": this is an explicit >>>>>> positioning which should be mentioned earlier in the I-D. >>>>> >>>>> >>>>> OK. This will be moved to the introduction. >>>>> >>>>>> ------ >>>>>> Section 10. >>>>>> --- >>>>>> - RFC 7180 bis is now RFC 7780. >>>>> >>>>> Yes, this will be updated. >>>>> >>>>>> --- >>>>>> >>>>>> Regards, >>>>>> >>>>>> Julien >>>>> From nobody Tue May 10 04:17:03 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49B412D0FD; Tue, 10 May 2016 04:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 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.996, 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 SGKz_6IgAsde; Tue, 10 May 2016 04:16:58 -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 84AD812D0FB; Tue, 10 May 2016 04:16:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJP09409; Tue, 10 May 2016 11:16:53 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 10 May 2016 12:16:52 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Tue, 10 May 2016 19:16:42 +0800 From: Mingui Zhang To: Julien Meuric Thread-Topic: RtgDir review: draft-ietf-trill-mtu-negotiation-02 Thread-Index: AQHRoMQerp4NGV2VcEqtxnPN1zxy5p+fCHCAgAW+q4CAAdE0AIABgY2AgAltlPD//94+AIAAsSRw Date: Tue, 10 May 2016 11:16:41 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E787C88C39@NKGEML515-MBX.china.huawei.com> References: <57212222.5080904@orange.com> <4552F0907735844E9204A62BBDD325E787C858FD@NKGEML515-MBX.china.huawei.com> <572706E7.7050005@orange.com> <4552F0907735844E9204A62BBDD325E787C865EB@NKGEML515-MBX.china.huawei.com> <5729D091.2040904@orange.com> <4552F0907735844E9204A62BBDD325E787C889B1@NKGEML515-MBX.china.huawei.com> <57319CE8.9020300@orange.com> In-Reply-To: <57319CE8.9020300@orange.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.146.93] 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.0A020205.5731C326.016E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 93b6faea5066089566f2c565c9c5650f Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-trill-mtu-negotiation.all@ietf.org" , "trill@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-trill-mtu-negotiation-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 11:17:02 -0000 SGkgSnVsaWVuLCANCg0KVGhhbmtzIGZvciBwb2ludGluZyBpdCBvdXQuIFRoYXQgdHlwbyB3aWxs IGJlIGZpeGVkIHRvZ2V0aGVyIHdpdGggb3RoZXIgY29tbWVudHMgd2Ugd291bGQgcmVjZWl2ZS4N Cg0KVGhhbmtzLA0KTWluZ3VpDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogSnVsaWVuIE1ldXJpYyBbbWFpbHRvOmp1bGllbi5tZXVyaWNAb3JhbmdlLmNvbV0NCj4gU2Vu dDogVHVlc2RheSwgTWF5IDEwLCAyMDE2IDQ6MzQgUE0NCj4gVG86IE1pbmd1aSBaaGFuZw0KPiBD YzogZHJhZnQtaWV0Zi10cmlsbC1tdHUtbmVnb3RpYXRpb24uYWxsQGlldGYub3JnOyBydGctYWRz QGlldGYub3JnOyBydGctZGlyQGlldGYub3JnOw0KPiB0cmlsbEBpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi10cmlsbC1tdHUtbmVnb3RpYXRpb24tMDIN Cj4gDQo+IEhpIE1pbmd1aSwNCj4gDQo+IFRoaXMgdmVyc2lvbiBzZWVtcyB0byBhZGRyZXNzIG15 IGNvbW1lbnQuDQo+IA0KPiBQbGVhc2Ugbm90ZSBhIG5ldyB0eXBvIG9uIHBhZ2UgODogcy9hbnkg TFBTL2FueSBMU1AvDQo+IA0KPiBUaGFua3MsDQo+IA0KPiBKdWxpZW4NCj4gDQo+IA0KPiBNYXku IDEwLCAyMDE2IC0gemhhbmdtaW5ndWlAaHVhd2VpLmNvbToNCj4gPiBIaSBKdWxpZW4sDQo+ID4N Cj4gPiBJIGhhdmUgdXBsb2FkZWQgdGhlIDA0IHZlcnNpb24uIFBsZWFzZSB0YWtlIGEgbG9vay4N Cj4gPg0KPiA+IFRoYW5rcywNCj4gPiBNaW5ndWkNCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBKdWxpZW4gTWV1cmljIFttYWlsdG86anVsaWVuLm1ldXJp Y0BvcmFuZ2UuY29tXQ0KPiA+PiBTZW50OiBXZWRuZXNkYXksIE1heSAwNCwgMjAxNiA2OjM2IFBN DQo+ID4+DQo+ID4+IEhpIE1pbmd1aSwNCj4gPj4NCj4gPj4gSSBoYXZlIGxvb2tlZCBhdCB0aGUg ZGlmZiBvZiB5b3VyIHVwZGF0ZSBhbmQgaGF2ZSBub3RpY2VkIHRoYXQgc2V2ZXJhbA0KPiAic2hv dWxkIg0KPiA+PiBoYXZlIGJlZW4gcmVwbGFjZWQgYnkgIm5lZWRbc10gdG8iOiBJIGFwcHJlY2lh dGUgdGhhdCB5b3UgYWNrbm93bGVkZ2UNCj4gPj4gbXkgY29tbWVudCBvbiB0aGlzLCBidXQgbm9u ZSBvZiB0aGVtIGJlaW5nIFJGQyAyMTE5IGtleXdvcmQsIEkgc3RpbGwNCj4gPj4gZG91YnQgdGhp cyBtYXRjaGVzIFN0YW5kYXJkcyBUcmFjayBleHBlY3RhdGlvbnMuDQo+ID4+DQo+ID4+IEkgY2F1 Z2h0IGEgbml0IGluIHNlY3Rpb24gMzogcy9pcyBzZW50IHRvL2lzIHNldCB0by8NCj4gPj4NCj4g Pj4gUmVnYXJkcywNCj4gPj4NCj4gPj4gSnVsaWVuDQo+ID4+DQo+ID4+DQo+ID4+IE1heS4gMDMs IDIwMTYgLSB6aGFuZ21pbmd1aUBodWF3ZWkuY29tOg0KPiA+Pj4gSGkgSnVsaWVuLA0KPiA+Pj4N Cj4gPj4+IFRoZSB1cGRhdGVkIHZlcnNpb24gaGFzIGp1c3QgYmVlbiB1cGxvYWRlZC4NCj4gPj4+ DQo+ID4+PiBUaGFua3MsDQo+ID4+PiBNaW5ndWkNCj4gPj4+DQo+ID4+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPj4+PiBGcm9tOiBKdWxpZW4gTWV1cmljIFttYWlsdG86anVsaWVu Lm1ldXJpY0BvcmFuZ2UuY29tXQ0KPiA+Pj4+IFNlbnQ6IE1vbmRheSwgTWF5IDAyLCAyMDE2IDM6 NTEgUE0NCj4gPj4+Pg0KPiA+Pj4+IEhpIE1pbmd1aSwNCj4gPj4+Pg0KPiA+Pj4+IEFib3V0IHRo ZSAidXBkYXRlZCBSRkNzIiBpc3N1ZSBiZWxvdywgbXkgcG9pbnQgaXM6ICJwbGVhc2UgbWFrZQ0K PiA+Pj4+IHN1cmUgdGhlIHRleHQgYW5kIHRoZSBoZWFyZGVyIGFyZSBjb21wbGV0ZSIuIEkganVz dCBoYWQgYSBxdWljaw0KPiA+Pj4+IGxvb2sgYXQgdGhvc2UgcmVmZXJlbmNlcywgeW91IGtub3cg YmV0dGVyIHRoYW4gbWUgd2hpY2ggYXJlIGFjdHVhbGx5DQo+IHJlbGV2YW50Lg0KPiA+Pj4+DQo+ ID4+Pj4gSSBhbSBsb29raW5nIGZvcndhcmQgdG8gdGhlIHVwZGF0ZWQgdmVyc2lvbi4NCj4gPj4+ Pg0KPiA+Pj4+IFRoYW5rcywNCj4gPj4+Pg0KPiA+Pj4+IEp1bGllbg0KPiA+Pj4+DQo+ID4+Pj4N Cj4gPj4+PiBBcHIuIDI5LCAyMDE2IC0gemhhbmdtaW5ndWlAaHVhd2VpLmNvbToNCj4gPj4+Pj4g SGkgSnVsaWVuLA0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGFua3MgZm9yIHRoZSBjb21tZW50cyEgTXVj aCBhcHByZWNpYXRlZCENCj4gPj4+Pj4NCj4gPj4+Pj4gUGxlYXNlIHNlZSBpbi1saW5lcyBiZWxv dy4gQW4gdXBkYXRlZCB2ZXJzaW9uIHdpbGwgc29vbiBiZQ0KPiA+Pj4+PiB1cGxvYWRlZCB0byBy ZXNvbHZlDQo+ID4+Pj4gdGhlIGNvbW1lbnRzLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGFua3MsDQo+ ID4+Pj4+IE1pbmd1aQ0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gPj4+Pj4+IEZyb206IEp1bGllbiBNZXVyaWMgW21haWx0bzpqdWxpZW4ubWV1cmljQG9y YW5nZS5jb21dDQo+ID4+Pj4+PiBTZW50OiBUaHVyc2RheSwgQXByaWwgMjgsIDIwMTYgNDozNCBB TQ0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEhlbGxvLA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEkgaGF2ZSBi ZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlz IGRyYWZ0Lg0KPiA+Pj4+Pj4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3 IGFsbCByb3V0aW5nIG9yDQo+ID4+Pj4+PiByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkg cGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZA0KPiA+Pj4+Pj4gSUVTRyByZXZpZXcsIGFu ZCBzb21ldGltZXMgb24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUNCj4gPj4+ Pj4+IHJldmlldyBpcyB0bw0KPiA+Pj4+IHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGlu ZyBBRHMuDQo+ID4+Pj4+PiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUm91dGluZyBE aXJlY3RvcmF0ZSwgcGxlYXNlIHNlZQ0KPiA+Pj4+Pj4gaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5v cmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0Rpcg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEFsdGhvdWdo IHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcN Cj4gPj4+Pj4+IEFEcywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIg dGhlbSBhbG9uZyB3aXRoDQo+ID4+Pj4+PiBhbnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVu dHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0bw0KPiA+Pj4+Pj4gcmVzb2x2ZSB0aGVt IHRocm91Z2ggZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuDQo+ID4+Pj4+Pg0K PiA+Pj4+Pj4gRG9jdW1lbnQ6IGRyYWZ0LWlldGYtdHJpbGwtbXR1LW5lZ290aWF0aW9uLTAyLnR4 dA0KPiA+Pj4+Pj4gUmV2aWV3ZXI6IEp1bGllbiBNZXVyaWMNCj4gPj4+Pj4+IFJldmlldyBEYXRl OiBBcHJpbCAyNywgMjAxNg0KPiA+Pj4+Pj4gSUVURiBMQyBFbmQgRGF0ZTogQXByaWwgNSwgMjAx Ng0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIFRyYWNrDQo+ ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICpTdW1tYXJ5OioNCj4gPj4+Pj4+IEkgaGF2ZSBz b21lIG1pbm9yIGNvbmNlcm5zIGFib3V0IHRoaXMgZG9jdW1lbnQgdGhhdCBJIHRoaW5rDQo+ID4+ Pj4+PiBzaG91bGQgYmUgcmVzb2x2ZWQgYmVmb3JlIHB1YmxpY2F0aW9uLg0KPiA+Pj4+Pj4NCj4g Pj4+Pj4+ICpDb21tZW50czoqDQo+ID4+Pj4+PiBFdmVuIHRob3VnaCBpdCByZXF1aXJlcyB0byBi cm93c2Ugc29tZSBvdGhlciBUUklMTCAobm9ybWF0aXZlKQ0KPiA+Pj4+Pj4gZG9jdW1lbnRzLCB0 aGUgbWVjaGFuaXNtIGl0c2VsZiBpcyBzaW1wbGUgYW5kIHdlbGwgZGVzY3JpYmVkLg0KPiA+Pj4+ Pj4gTmV2ZXJ0aGVsZXNzLCB0aGUgc3BlY2lmaWNhdGlvbiBkZXNlcnZlcyBzb21lIGltcHJvdmVt ZW50IHdoZW4gaXQNCj4gPj4+Pj4+IGNvbWVzIHRvIG9ibGlnYXRpb25zIGFuZCBvcHRpb25zOiB0 aGlzIHdhcyBwYXJ0IG9mIG15IGV4cGVjdGF0aW9uDQo+ID4+Pj4+PiBhZnRlciBJIHJlYWxpemVk IGl0IHdhcyB1cGdyYWRpbmcgYSBzaG9ydCBzZWN0aW9uIG9mIHRoZSBiYXNlDQo+ID4+Pj4+PiBk b2N1bWVudCAoUkZDIDYzMjUpLCB3aGljaCBuZWVkcyB0byBiZSBlbXBoYXNpemVkIGFzIHdlbGwu DQo+ID4+Pj4+DQo+ID4+Pj4+IEluIHRoZSBhYnN0cmFjdCwgaXQncyBhbHJlYWR5IG1lbnRpb25l ZCBhcyAib3B0aW9uYWwgdXBkYXRlcyIgdG8NCj4gPj4+Pj4gUkZDIDYzMjUuIEkgdGhpbmsNCj4g Pj4+PiAiVXBkYXRlczogNjMyNSAiIG5lZWRzIHRvIGFwcGVhciBpbiB0aGUgcGFnZSBoZWFkZXIg YXMgd2VsbC4NCj4gPj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiAqTWlub3IgSXNzdWVzOioNCj4g Pj4+Pj4+IC0gVGhlIGRvY3VtZW50IGlzIFNUIGFuZCByZWZlcmVuY2VzIFJGQyAyMTE5LiBUaGVy ZSBhIHNvbWUgIk1VU1QiDQo+ID4+Pj4+PiBhbmQgb25lICJTSE9VTEQiLCBtYW55IG9mIHRoZW0g aW5oZXJpdGVkIGZyb20gc3BlY2lmaWNhdGlvbnMgb3V0DQo+ID4+Pj4+PiBvZiB0aGUgcmVmZXJl bmNlZCBkb2N1bWVudHMuIE9uIHRoZSBvdGhlciBzaWRlLCAibXVzdCIgYW5kICJzaG91bGQiDQo+ ID4+Pj4+PiBhcmUgY29tbW9ubHkgdXNlZC4gVGhpcyBNVVNUIGJlIGJyb3VnaHQgdXAgdG8gU1Qg ZXhwZWN0YXRpb25zLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGUgdXNhZ2Ugb2YgIm11c3QiIGFuZCAi c2hvdWxkIiB3aWxsIGJlIHVwZGF0ZWQgYXMgbmVlZGVkLiBJIGhhdmUNCj4gPj4+Pj4gY2hlY2tl ZCBhbGwNCj4gPj4+PiB0aG9zZSBhcHBlYXJhbmNlcy4gVGhlIGNoYW5nZXMgd291bGQgYmUgZWRp dG9yaWFsLg0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gLSBUaGUgZG9jdW1lbnQgY2xhaW1zIHRvIG9ubHkg dXBkYXRlIFJGQyA3MTc3LiBJdCBzZWVtcyBob3dldmVyDQo+ID4+Pj4+PiB0aGF0IGl0IGFsc28g dXBkYXRlcyBSRkMgNjMyNSAoc2VjdGlvbiA0LjMuMiksIFJGQyA3MTc2IGFuZCBtYXliZQ0KPiA+ Pj4+Pj4gZXZlbiBSRkMNCj4gPj4gNzc4MC4NCj4gPj4+Pj4NCj4gPj4+Pj4gQWN0dWFsbHksIEkg ZG9uJ3QgdGhpbmsgdGhpcyBkb2N1bWVudCB1cGRhdGVzIFJGQzcxNzYuIEl0IHNpbXBseQ0KPiA+ Pj4+PiBtYWtlcyB1c2Ugb2YNCj4gPj4+PiB0aGUgTVRVIFN1Yi1UTFYgZGVmaW5lZCBpbiBSRkMg NzE3Ni4NCj4gPj4+Pj4gVGhlIHNwZWNpZmljYXRpb24gYWJvdXQgdGhlIG9yaWdpbmF0aW5nTDFM U1BCdWZmZXJTaXplIG9mIGFuDQo+ID4+Pj4+IHVucmVhY2hhYmxlDQo+ID4+Pj4gUkJyaWRnZSBp cyBhIHNsaWdodCB1cGRhdGUgdG8gUkZDNzc4MC4gVGhpcyB3aWxsIGJlIGVtcGhhc2l6ZWQuDQo+ ID4+Pj4+DQo+ID4+Pj4+PiBUaGF0IHNob3VsZCBiZSBlaXRoZXIgYWNrbm93bGVkZ2VkIG9yIGNs YXJpZmllZC4gVGhlIDR0aA0KPiA+Pj4+Pj4gcGFyYWdyYXBoIG9mIHRoZSBpbnRyb2R1Y3Rpb24g dHJpZXMgdG8gdGFja2xlIHRoYXQgdG9waWMsIGJ1dCBpdA0KPiA+Pj4+Pj4gaXMgbm90IGNsZWFy IGVub3VnaCBpbiBkZWZpbmluZyB0aGUgcG9zaXRpb24gb2YgdGhlIGRvY3VtZW50IHdpdGgNCj4g Pj4+Pj4+IHJlc3BlY3QgdG8gcHJldmlvdXNseQ0KPiA+Pj4+IGRlZmluZWQgbWVjaGFuaXNtcy4N Cj4gPj4+Pj4NCj4gPj4+Pj4gVGhlIHVwZGF0ZWQgdG8gUkZDIDYzMjUgd2lsbCBiZSBlbXBoYXNp emVkIGluIHRoaXMgcGFyYWdyYXBoLiBUaGUNCj4gPj4+Pj4gYmFja3dhcmQNCj4gPj4+PiBjb21w YXRpYmlsaXR5IHdpbGwgYmUgbW92ZWQgdG8gaGVyZSBhcyB3ZWxsLiBJdCB3aWxsIGhlbHAgdGhl IHBvc2l0aW9uaW5nLg0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gLSBUaGUgM3JkIHBhcmFncmFwaCBvZiB0 aGUgaW50cm9kdWN0aW9uIGR1cGxpY2F0ZXMgdGhlIGJlZ2lubmluZw0KPiA+Pj4+Pj4gb2YgdGhl IGZvbGxvd2luZyBzZWN0aW9uIDIuIEEgcG9zc2libGUgd2F5IHRvIGxpbWl0IHRoaXMNCj4gPj4+ Pj4+IHJlcGV0aXRpb24gZWZmZWN0IG1heSBiZSB0byBzdW1tYXJpemUgdGhhdCBwYXJ0IG9mIHRo ZSBpbnRyb2R1Y3Rpb24uDQo+ID4+Pj4+DQo+ID4+Pj4+IFllcywgc3VtbWFyaXphdGlvbiBpcyB0 aGUgcHJvcGVyIHdheS4NCj4gPj4+Pj4NCj4gPj4+Pj4+IC0gU2VjdGlvbiAzIHNwZWNpZmllcyBh biBhbGdvcml0aG0uIEV2ZW4gaWYgaXQgZG9lcyBub3QgcmVseSBvbiBhDQo+ID4+Pj4+PiBmb3Jt YWwgbGFuZ3VhZ2UsIGNvbnNpc3RlbmN5IHdvdWxkIGJlIHZhbHVhYmxlLiBNeSBtaW5kIGNvbXBp bGVyDQo+ID4+Pj4+PiB3b3VsZA0KPiA+Pj4+IHN1Z2dlc3Q6DQo+ID4+Pj4+PiAgICAgICAgICog IklmIiBpcyBmb2xsb3dlZCBieSAidGhlbiIgb25seSBvbmNlOiAidGhlbiIga2V5d29yZCB0bw0K PiA+Pj4+Pj4gYmUNCj4gPj4gZHJvcHBlZD8NCj4gPj4+Pj4+ICAgICAgICAgKiBUaGUgYWxnb3Jp dGhtIHJlbGllcyBvbiBhIGJyZWFrL3N0b3Agb3IgY29udGludWUNCj4gPj4+Pj4+IHByaW5jaXBs ZTsgYXMgc3VjaCwgdGhlIGluc3RhbmNlIG9mICJFbHNlIiBhdCB0aGUgZW5kIHNob3VsZCBiZQ0K PiA+Pj4+Pj4gcmVwbGFjZWQgYnkgIjxsaW5lDQo+ID4+Pj4+PiBicmVhaz4gNCkgUmVwZWF0IFN0 ZXAxIjsNCj4gPj4+Pj4+ICAgICAgICAgKiAiaXMgc2V0IHRvIiBhbmQgIjwtLSIgc2VlbSB0byBi ZSBzaW1pbGFyOiBwbGVhc2UgcGljayBvbmUgb3INCj4gY2xhcmlmeTsNCj4gPj4+Pj4+ICAgICAg ICAgKiB0byBpbXByb3ZlIHJlYWRhYmlsaXR5LCBJIHdvdWxkIGRyb3AgdGhlIGRvdWJsZSBuYW1p bmcNCj4gPj4+Pj4+IGludHJvZHVjZWQgd2l0aCBYLA0KPiA+Pj4+Pj4gWDEgYW5kIFgyIGFuZCBy ZWx5IG9uIGV4cGxpY2l0IHZhcmlhYmxlIG5hbWVzIGFsbCBhbG9uZywgYXMgaW4NCj4gPj4+Pj4+ IHRoZQ0KPiA+Pj4+Pj4gdGV4dDogZS5nLiwgImxpbmtNdHVTaXplIiBpbnN0ZWFkIG9mIFgsICJs b3dlckJvdW5kIiBmb3IgWDEgYW5kDQo+ID4+ICJ1cHBlckJvdW5kIg0KPiA+Pj4+IGluc3RlYWQg b2YgWDIuDQo+ID4+Pj4+DQo+ID4+Pj4+IFN1cmUuIEV4cGxpY2l0IG5hbWVzIHdpbGwgYmUgdXNl ZCBmb3IgdGhlIHNha2Ugb2YgcmVhZGFiaWxpdHkuDQo+ID4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+ Pj4gKk5pdHM6Kg0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGUgZm9sbG93aW5nIG5pdHMgd2lsbCBiZSBm aXhlZCBhcyBzdWdnZXN0ZWQuDQo+ID4+Pj4+DQo+ID4+Pj4+PiAtLS0tLS0NCj4gPj4+Pj4+ICJV cGRhdGVzIiBmaWVsZCBpbiBoZWFkZXINCj4gPj4+Pj4+IC0tLQ0KPiA+Pj4+Pj4gLSBJIHRoaW5r IHRoZSAiUkZDIiBhY3JvbnltIHNob3VsZCBhcHBlYXIuDQo+ID4+Pj4+PiAtIFRoZSBsaXN0IG1h eSBiZSBleHRlbmRlZCB3aXRoIFJGQyBSRkMgNjMyNSwgUkZDIDcxNzYgYW5kIG1heWJlDQo+ID4+ Pj4+PiBldmVuIFJGQyA3NzgwLg0KPiA+Pj4+Pj4gLS0tLS0tDQo+ID4+Pj4+PiBBYnN0cmFjdA0K PiA+Pj4+Pj4gLS0tDQo+ID4+Pj4+PiAtIHMvY2FtcHVzIHdpZGUgTVRVIGZlYXR1cmUvY2FtcHVz LXdpZGUgTVRVIGZlYXR1cmUvDQo+ID4+Pj4+PiAtIHMvY2FtcHVzIHdpZGUgY2FwYWJpbGl0eS9j YW1wdXMtd2lkZSBjYXBhYmlsaXR5Lw0KPiA+Pj4+Pj4gLSBzL2xpbmsgbG9jYWwgcGFja2V0cy9s aW5rLWxvY2FsIHBhY2tldHMvDQo+ID4+Pj4+PiAtIHMvbGluayBsb2NhbCBNVFVzL2xpbmstbG9j YWwgTVRVcy8NCj4gPj4+Pj4+IC0gIkl0IHVwZGF0ZXMgUkZDLi4uIiBkdXBsaWNhdGVzIGhlYWRl cjogZWl0aGVyIHRvIGRyb3Agb3IgbWFrZQ0KPiA+Pj4+Pj4gbW9yZSBzcGVjaWZpYyB0byBwb2lu dCB0byBwcmVjaXNlIHNlY3Rpb25zL21lY2hhbmlzbXMuDQo+ID4+Pj4+PiAtLS0tLS0NCj4gPj4+ Pj4+IFNlY3Rpb24gMS4NCj4gPj4+Pj4+IC0tLQ0KPiA+Pj4+Pj4gLSBzL2xpbmsgc2NvcGUgUERV cyBjYW4vbGluay1zY29wZWQgUERVcyBjYW4vDQo+ID4+Pj4+PiAtLS0tLS0NCj4gPj4+Pj4+IFNl Y3Rpb24gMi4NCj4gPj4+Pj4+IC0tLQ0KPiA+Pj4+Pj4gLSBzL2NhbXB1cyB3aWRlIFN6IE1UVS9j YW1wdXMtd2lkZSBTeiBNVFUvDQo+ID4+Pj4+PiAtIHMvYXJlYSB3aWRlIHNjb3BlL2FyZWEtd2lk ZSBzY29wZS8NCj4gPj4+Pj4+IC0gcy9kb21haW4gd2lkZSBzY29wZS9kb21haW4gd2lkZSBzY29w ZS8NCj4gPj4+Pj4+IC0gcy9MMSBDaXJjdWl0IFNjb3BlZC9MMSBDaXJjdWl0LVNjb3BlZC8NCj4g Pj4+Pj4+IC0gImxpbWl0ZWQgdG8gMTQ3MCB0byA2NSw1MzUgYnl0ZXMiOiBJIGNhbm5vdCBwYXJz ZSBpdCwgaXMgaXQNCj4gPj4+Pj4+IG1lYW50IHRvIGJlIGENCj4gPj4gcmFuZ2U/DQo+ID4+Pj4+ PiAtLS0tLS0NCj4gPj4+Pj4+IFNlY3Rpb24gNC4NCj4gPj4+Pj4+IC0gT0xEDQo+ID4+Pj4+PiAi d2hpbGUgUkIxIG5vcm1hbGx5IGlnbm9yZXMgbGluayBzdGF0ZSBpbmZvcm1hdGlvbiBmb3IgYW55 IElTLUlTDQo+ID4+Pj4+PiB1bnJlYWNoYWJsZSBSQnJpZGdlIFJCMiwgb3JpZ2luYXRpbmdMMUxT UEJ1ZmZlclNpemUgaXMgYW4gZXhjZXB0aW9uLiINCj4gPj4+Pj4+ICAgICAgIE5FVw0KPiA+Pj4+ Pj4gIndoaWxlIGluIG1vc3QgY2FzZXMgUkIxIGlnbm9yZXMgbGluayBzdGF0ZSBpbmZvcm1hdGlv biBmb3IgSVMtSVMNCj4gPj4+Pj4+IHVucmVhY2hhYmxlIFJCcmlkZ2UgUkIyLCBvcmlnaW5hdGlu Z0wxTFNQQnVmZmVyU2l6ZSBpcyBtZWFuaW5nZnVsLiINCj4gPj4+Pj4+IFtjdXJyZW50IHdvcmRp bmcgc3VnZ2VzdHMgaXQgaXMgYWRkaW5nIGFuIGV4Y2VwdGlvbiB0byBhDQo+ID4+Pj4+PiBtYW5k YXRvcnkgYmVoYXZpb3IsIHdoaWNoIEFGQUlVIGl0IGRvZXMgbm90XQ0KPiA+Pj4+Pg0KPiA+Pj4+ PiBPSy4gV2lsbCB1cGRhdGUgdGhlIHdvcmRzLg0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gLS0tLS0tDQo+ ID4+Pj4+PiBTZWN0aW9uIDcuDQo+ID4+Pj4+PiAtLS0NCj4gPj4+Pj4+IC0gInRlc3RlZCBzaXpl IGNhbiBiZSBhZHZlcnRpc2VkIjogImNhbiIgaXMgdG8gYmUgYWRkcmVzc2VkIGFzDQo+ID4+Pj4+ PiBwYXJ0IG9mIHRoZSBsb29zZSBSRkMgMjExOSB3b3JkaW5nIGNvbW1lbnQuDQo+ID4+Pj4+DQo+ ID4+Pj4+IFdpbGwgdXNlIHRoZSB3b3JkICJNQVkiIGluc3RlYWQuDQo+ID4+Pj4+DQo+ID4+Pj4+ PiAtLS0tLS0NCj4gPj4+Pj4+IFNlY3Rpb24gOC4NCj4gPj4+Pj4+IC0tLQ0KPiA+Pj4+Pj4gLSAi dmFsdWUgWy4uLl0gaGFkIGJlZW4gcmVwb3J0ZWQiOiAicmVwb3J0ZWQiIHB1enpsZXMgbWUsIG1h eWJlDQo+ICJ0ZXN0ZWQiDQo+ID4+Pj4+PiB3YXMgbWVhbnQ/DQo+ID4+Pj4+PiAtIFRoZSAzcmQg cGFyYWdyYXBoICJGb3IgYW4gTHotaWdub3JhbnQgWy4uLl0gbGluay13aWRlIEx6LiINCj4gPj4+ Pj4+IHNob3VsZCBiZSBtb3ZlZCB1cCB0byBiZWNvbWUgdGhlIHNlY29uZCBwYXJhZ3JhcGgsIHNv IGFzIHRvDQo+ID4+Pj4+PiBjbGFyaWZ5IHdoYXQgYW4NCj4gPj4+PiBMei1pZ25vcmFudCBpcy4N Cj4gPj4+Pj4NCj4gPj4+Pj4gT0suIEl0IHdpbGwgYmUgbW92ZWQgdXAuDQo+ID4+Pj4+DQo+ID4+ Pj4+PiAtICJUaGUgZXh0ZW5zaW9uIG9mIFRSSUxMIE1UVSBuZWdvY2lhdGlvbi4uLiI6IHRoaXMg aXMgYW4NCj4gPj4+Pj4+IGV4cGxpY2l0IHBvc2l0aW9uaW5nIHdoaWNoIHNob3VsZCBiZSBtZW50 aW9uZWQgZWFybGllciBpbiB0aGUgSS1ELg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+PiBPSy4g VGhpcyB3aWxsIGJlIG1vdmVkIHRvIHRoZSBpbnRyb2R1Y3Rpb24uDQo+ID4+Pj4+DQo+ID4+Pj4+ PiAtLS0tLS0NCj4gPj4+Pj4+IFNlY3Rpb24gMTAuDQo+ID4+Pj4+PiAtLS0NCj4gPj4+Pj4+IC0g UkZDIDcxODAgYmlzIGlzIG5vdyBSRkMgNzc4MC4NCj4gPj4+Pj4NCj4gPj4+Pj4gWWVzLCB0aGlz IHdpbGwgYmUgdXBkYXRlZC4NCj4gPj4+Pj4NCj4gPj4+Pj4+IC0tLQ0KPiA+Pj4+Pj4NCj4gPj4+ Pj4+IFJlZ2FyZHMsDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gSnVsaWVuDQo+ID4+Pj4+DQo= From nobody Tue May 10 10:06:09 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4C112D539; Tue, 10 May 2016 10:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.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, USER_IN_WHITELIST=-100] 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 khYw1TB0_Glz; Tue, 10 May 2016 10:06:05 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::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 CBCD012D0DE; Tue, 10 May 2016 10:06:04 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id x201so26087008oif.3; Tue, 10 May 2016 10:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=1kr8mcou77awzYyeR/ATCHnVUbOxOu+IqZaGI+Oo33A=; b=gLd+funWAERLY2pSpOYgSS6ceumDsp4gNoyj3rCgJoWyFpRWscGttyI3KS/nIws5+1 /t9UtM39x8myIaDX6vTmYZP07VsEXGcXbsM0/M8CO9A4p8Ys/IKW4PSizbTeksKGp/lj VomLlvgvnxPorqAEuGawwZH9U3uEIS94yd3fXSu2tQlGm8GXsN0RxHaIS940Ba7UEh0S xisthTg6VgFyz3EOQ6G0f6nwYAzFezUw+F/4lYxX8v7YrCwQ2OlxARKnU1Zy4L+HST1W U0JaKNa/MglLEvDlSv+lqnMyd1MNKOBTik0mYcodkzszhsN2cOsJhVnTmu+7ueRxu0qC wbSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=1kr8mcou77awzYyeR/ATCHnVUbOxOu+IqZaGI+Oo33A=; b=e8r5nr5PVnUwg3wsV1+0Lm2T6p8Q/WcAvOneHdGSu+cB9MZ2eg489YX4Yn6cHv3Mr4 8mQCrM5ZrO02mm6MJ2ecfcbP0m9JHMHBjhw/T+yKo2Y0m80+vr7l5g3pDGaldURl/FMQ aWiSDMeH98Y45yc47JOmNg0he2oQrImj0HgFL11T3MjdP5Gdg//km3igifkUgrnZ3teg lAso5nzXIwfj+jeFHrQNyVZFJLUiksLeRclzHHY7eRP2XxkNMo9X4MlsEf+5HTeSEGyT NHPqSrTFu/wMIJAUJVURzx32ImiynQrlpoF8UO1E4bsCMQ7BAXAUrSOoKAcqg6n6cNA5 Y2KQ== X-Gm-Message-State: AOPr4FVBB3jtLI98tOzX4aVUQvfLjQaIErYHo9eH1YOncMDu51k2GB9bFLel1XK5MBBzpDH7F65rs3V9SPRQRA== MIME-Version: 1.0 X-Received: by 10.157.3.47 with SMTP id 44mr3468906otv.191.1462899963973; Tue, 10 May 2016 10:06:03 -0700 (PDT) Received: by 10.60.118.39 with HTTP; Tue, 10 May 2016 10:06:03 -0700 (PDT) In-Reply-To: <4552F0907735844E9204A62BBDD325E787C88C39@NKGEML515-MBX.china.huawei.com> References: <57212222.5080904@orange.com> <4552F0907735844E9204A62BBDD325E787C858FD@NKGEML515-MBX.china.huawei.com> <572706E7.7050005@orange.com> <4552F0907735844E9204A62BBDD325E787C865EB@NKGEML515-MBX.china.huawei.com> <5729D091.2040904@orange.com> <4552F0907735844E9204A62BBDD325E787C889B1@NKGEML515-MBX.china.huawei.com> <57319CE8.9020300@orange.com> <4552F0907735844E9204A62BBDD325E787C88C39@NKGEML515-MBX.china.huawei.com> Date: Tue, 10 May 2016 13:06:03 -0400 Message-ID: From: Alia Atlas To: Mingui Zhang Content-Type: multipart/alternative; boundary=94eb2c0477feb1dd2305327ff038 Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-trill-mtu-negotiation.all@ietf.org" , "trill@ietf.org" , Julien Meuric Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-trill-mtu-negotiation-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 17:06:08 -0000 --94eb2c0477feb1dd2305327ff038 Content-Type: text/plain; charset=UTF-8 Julien, Thank you very much for your review! Mingui, Thank you for addressing the comments. Regards, Alia On Tue, May 10, 2016 at 7:16 AM, Mingui Zhang wrote: > Hi Julien, > > Thanks for pointing it out. That typo will be fixed together with other > comments we would receive. > > Thanks, > Mingui > > > -----Original Message----- > > From: Julien Meuric [mailto:julien.meuric@orange.com] > > Sent: Tuesday, May 10, 2016 4:34 PM > > To: Mingui Zhang > > Cc: draft-ietf-trill-mtu-negotiation.all@ietf.org; rtg-ads@ietf.org; > rtg-dir@ietf.org; > > trill@ietf.org > > Subject: Re: RtgDir review: draft-ietf-trill-mtu-negotiation-02 > > > > Hi Mingui, > > > > This version seems to address my comment. > > > > Please note a new typo on page 8: s/any LPS/any LSP/ > > > > Thanks, > > > > Julien > > > > > > May. 10, 2016 - zhangmingui@huawei.com: > > > Hi Julien, > > > > > > I have uploaded the 04 version. Please take a look. > > > > > > Thanks, > > > Mingui > > > > > >> -----Original Message----- > > >> From: Julien Meuric [mailto:julien.meuric@orange.com] > > >> Sent: Wednesday, May 04, 2016 6:36 PM > > >> > > >> Hi Mingui, > > >> > > >> I have looked at the diff of your update and have noticed that several > > "should" > > >> have been replaced by "need[s] to": I appreciate that you acknowledge > > >> my comment on this, but none of them being RFC 2119 keyword, I still > > >> doubt this matches Standards Track expectations. > > >> > > >> I caught a nit in section 3: s/is sent to/is set to/ > > >> > > >> Regards, > > >> > > >> Julien > > >> > > >> > > >> May. 03, 2016 - zhangmingui@huawei.com: > > >>> Hi Julien, > > >>> > > >>> The updated version has just been uploaded. > > >>> > > >>> Thanks, > > >>> Mingui > > >>> > > >>>> -----Original Message----- > > >>>> From: Julien Meuric [mailto:julien.meuric@orange.com] > > >>>> Sent: Monday, May 02, 2016 3:51 PM > > >>>> > > >>>> Hi Mingui, > > >>>> > > >>>> About the "updated RFCs" issue below, my point is: "please make > > >>>> sure the text and the hearder are complete". I just had a quick > > >>>> look at those references, you know better than me which are actually > > relevant. > > >>>> > > >>>> I am looking forward to the updated version. > > >>>> > > >>>> Thanks, > > >>>> > > >>>> Julien > > >>>> > > >>>> > > >>>> Apr. 29, 2016 - zhangmingui@huawei.com: > > >>>>> Hi Julien, > > >>>>> > > >>>>> Thanks for the comments! Much appreciated! > > >>>>> > > >>>>> Please see in-lines below. An updated version will soon be > > >>>>> uploaded to resolve > > >>>> the comments. > > >>>>> > > >>>>> Thanks, > > >>>>> Mingui > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Julien Meuric [mailto:julien.meuric@orange.com] > > >>>>>> Sent: Thursday, April 28, 2016 4:34 AM > > >>>>>> > > >>>>>> Hello, > > >>>>>> > > >>>>>> I have been selected as the Routing Directorate reviewer for this > draft. > > >>>>>> The Routing Directorate seeks to review all routing or > > >>>>>> 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 > > >>>>>> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > >>>>>> > > >>>>>> Although these comments are primarily for the use of the Routing > > >>>>>> ADs, it would be helpful if you could consider them along with > > >>>>>> any other IETF Last Call comments that you receive, and strive to > > >>>>>> resolve them through discussion or by updating the draft. > > >>>>>> > > >>>>>> Document: draft-ietf-trill-mtu-negotiation-02.txt > > >>>>>> Reviewer: Julien Meuric > > >>>>>> Review Date: April 27, 2016 > > >>>>>> IETF LC End Date: April 5, 2016 > > >>>>>> > > >>>>>> Intended Status: Standards Track > > >>>>>> > > >>>>>> > > >>>>>> *Summary:* > > >>>>>> I have some minor concerns about this document that I think > > >>>>>> should be resolved before publication. > > >>>>>> > > >>>>>> *Comments:* > > >>>>>> Even though it requires to browse some other TRILL (normative) > > >>>>>> documents, the mechanism itself is simple and well described. > > >>>>>> Nevertheless, the specification deserves some improvement when it > > >>>>>> comes to obligations and options: this was part of my expectation > > >>>>>> after I realized it was upgrading a short section of the base > > >>>>>> document (RFC 6325), which needs to be emphasized as well. > > >>>>> > > >>>>> In the abstract, it's already mentioned as "optional updates" to > > >>>>> RFC 6325. I think > > >>>> "Updates: 6325 " needs to appear in the page header as well. > > >>>>> > > >>>>>> > > >>>>>> *Minor Issues:* > > >>>>>> - The document is ST and references RFC 2119. There a some "MUST" > > >>>>>> and one "SHOULD", many of them inherited from specifications out > > >>>>>> of the referenced documents. On the other side, "must" and > "should" > > >>>>>> are commonly used. This MUST be brought up to ST expectations. > > >>>>> > > >>>>> The usage of "must" and "should" will be updated as needed. I have > > >>>>> checked all > > >>>> those appearances. The changes would be editorial. > > >>>>> > > >>>>>> - The document claims to only update RFC 7177. It seems however > > >>>>>> that it also updates RFC 6325 (section 4.3.2), RFC 7176 and maybe > > >>>>>> even RFC > > >> 7780. > > >>>>> > > >>>>> Actually, I don't think this document updates RFC7176. It simply > > >>>>> makes use of > > >>>> the MTU Sub-TLV defined in RFC 7176. > > >>>>> The specification about the originatingL1LSPBufferSize of an > > >>>>> unreachable > > >>>> RBridge is a slight update to RFC7780. This will be emphasized. > > >>>>> > > >>>>>> That should be either acknowledged or clarified. The 4th > > >>>>>> paragraph of the introduction tries to tackle that topic, but it > > >>>>>> is not clear enough in defining the position of the document with > > >>>>>> respect to previously > > >>>> defined mechanisms. > > >>>>> > > >>>>> The updated to RFC 6325 will be emphasized in this paragraph. The > > >>>>> backward > > >>>> compatibility will be moved to here as well. It will help the > positioning. > > >>>>> > > >>>>>> - The 3rd paragraph of the introduction duplicates the beginning > > >>>>>> of the following section 2. A possible way to limit this > > >>>>>> repetition effect may be to summarize that part of the > introduction. > > >>>>> > > >>>>> Yes, summarization is the proper way. > > >>>>> > > >>>>>> - Section 3 specifies an algorithm. Even if it does not rely on a > > >>>>>> formal language, consistency would be valuable. My mind compiler > > >>>>>> would > > >>>> suggest: > > >>>>>> * "If" is followed by "then" only once: "then" keyword to > > >>>>>> be > > >> dropped? > > >>>>>> * The algorithm relies on a break/stop or continue > > >>>>>> principle; as such, the instance of "Else" at the end should be > > >>>>>> replaced by " > >>>>>> break> 4) Repeat Step1"; > > >>>>>> * "is set to" and "<--" seem to be similar: please pick > one or > > clarify; > > >>>>>> * to improve readability, I would drop the double naming > > >>>>>> introduced with X, > > >>>>>> X1 and X2 and rely on explicit variable names all along, as in > > >>>>>> the > > >>>>>> text: e.g., "linkMtuSize" instead of X, "lowerBound" for X1 and > > >> "upperBound" > > >>>> instead of X2. > > >>>>> > > >>>>> Sure. Explicit names will be used for the sake of readability. > > >>>>> > > >>>>>> > > >>>>>> *Nits:* > > >>>>> > > >>>>> The following nits will be fixed as suggested. > > >>>>> > > >>>>>> ------ > > >>>>>> "Updates" field in header > > >>>>>> --- > > >>>>>> - I think the "RFC" acronym should appear. > > >>>>>> - The list may be extended with RFC RFC 6325, RFC 7176 and maybe > > >>>>>> even RFC 7780. > > >>>>>> ------ > > >>>>>> Abstract > > >>>>>> --- > > >>>>>> - s/campus wide MTU feature/campus-wide MTU feature/ > > >>>>>> - s/campus wide capability/campus-wide capability/ > > >>>>>> - s/link local packets/link-local packets/ > > >>>>>> - s/link local MTUs/link-local MTUs/ > > >>>>>> - "It updates RFC..." duplicates header: either to drop or make > > >>>>>> more specific to point to precise sections/mechanisms. > > >>>>>> ------ > > >>>>>> Section 1. > > >>>>>> --- > > >>>>>> - s/link scope PDUs can/link-scoped PDUs can/ > > >>>>>> ------ > > >>>>>> Section 2. > > >>>>>> --- > > >>>>>> - s/campus wide Sz MTU/campus-wide Sz MTU/ > > >>>>>> - s/area wide scope/area-wide scope/ > > >>>>>> - s/domain wide scope/domain wide scope/ > > >>>>>> - s/L1 Circuit Scoped/L1 Circuit-Scoped/ > > >>>>>> - "limited to 1470 to 65,535 bytes": I cannot parse it, is it > > >>>>>> meant to be a > > >> range? > > >>>>>> ------ > > >>>>>> Section 4. > > >>>>>> - OLD > > >>>>>> "while RB1 normally ignores link state information for any IS-IS > > >>>>>> unreachable RBridge RB2, originatingL1LSPBufferSize is an > exception." > > >>>>>> NEW > > >>>>>> "while in most cases RB1 ignores link state information for IS-IS > > >>>>>> unreachable RBridge RB2, originatingL1LSPBufferSize is > meaningful." > > >>>>>> [current wording suggests it is adding an exception to a > > >>>>>> mandatory behavior, which AFAIU it does not] > > >>>>> > > >>>>> OK. Will update the words. > > >>>>> > > >>>>>> ------ > > >>>>>> Section 7. > > >>>>>> --- > > >>>>>> - "tested size can be advertised": "can" is to be addressed as > > >>>>>> part of the loose RFC 2119 wording comment. > > >>>>> > > >>>>> Will use the word "MAY" instead. > > >>>>> > > >>>>>> ------ > > >>>>>> Section 8. > > >>>>>> --- > > >>>>>> - "value [...] had been reported": "reported" puzzles me, maybe > > "tested" > > >>>>>> was meant? > > >>>>>> - The 3rd paragraph "For an Lz-ignorant [...] link-wide Lz." > > >>>>>> should be moved up to become the second paragraph, so as to > > >>>>>> clarify what an > > >>>> Lz-ignorant is. > > >>>>> > > >>>>> OK. It will be moved up. > > >>>>> > > >>>>>> - "The extension of TRILL MTU negociation...": this is an > > >>>>>> explicit positioning which should be mentioned earlier in the I-D. > > >>>>> > > >>>>> > > >>>>> OK. This will be moved to the introduction. > > >>>>> > > >>>>>> ------ > > >>>>>> Section 10. > > >>>>>> --- > > >>>>>> - RFC 7180 bis is now RFC 7780. > > >>>>> > > >>>>> Yes, this will be updated. > > >>>>> > > >>>>>> --- > > >>>>>> > > >>>>>> Regards, > > >>>>>> > > >>>>>> Julien > > >>>>> > --94eb2c0477feb1dd2305327ff038 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Julien,

Thank you very much for your re= view!

Mingui,

Thank you f= or addressing the comments. =C2=A0

Regards,
<= div>Alia

On Tue, May 10, 2016 at 7:16 AM, Mingui Zhang <zhangmingui@huawei.= com> wrote:
Hi Julien,

Thanks for pointing it out. That typo will be fixed together with other com= ments we would receive.

Thanks,
Mingui

> -----Original Message-----
> From: Julien Meuric [mailto:julien.meuric@orange.com]
> Sent: Tuesday, May 10, 2016 4:34 PM > To: Mingui Zhang
> Cc: d= raft-ietf-trill-mtu-negotiation.all@ietf.org; rtg-ads@ietf.org; rtg-di= r@ietf.org;
> trill@ietf.org
> Subject: Re: RtgDir review: draft-ietf-trill-mtu-negotiation-02
>
> Hi Mingui,
>
> This version seems to address my comment.
>
> Please note a new typo on page 8: s/any LPS/any LSP/
>
> Thanks,
>
> Julien
>
>
> May. 10, 2016 - zhangmingui@= huawei.com:
> > Hi Julien,
> >
> > I have uploaded the 04 version. Please take a look.
> >
> > Thanks,
> > Mingui
> >
> >> -----Original Message-----
> >> From: Julien Meuric [mailto:julien.meuric@orange.com]
> >> Sent: Wednesday, May 04, 2016 6:36 PM
> >>
> >> Hi Mingui,
> >>
> >> I have looked at the diff of your update and have noticed tha= t several
> "should"
> >> have been replaced by "need[s] to": I appreciate th= at you acknowledge
> >> my comment on this, but none of them being RFC 2119 keyword, = I still
> >> doubt this matches Standards Track expectations.
> >>
> >> I caught a nit in section 3: s/is sent to/is set to/
> >>
> >> Regards,
> >>
> >> Julien
> >>
> >>
> >> May. 03, 2016 - zha= ngmingui@huawei.com:
> >>> Hi Julien,
> >>>
> >>> The updated version has just been uploaded.
> >>>
> >>> Thanks,
> >>> Mingui
> >>>
> >>>> -----Original Message-----
> >>>> From: Julien Meuric [mailto:julien.meuric@orange.com]
> >>>> Sent: Monday, May 02, 2016 3:51 PM
> >>>>
> >>>> Hi Mingui,
> >>>>
> >>>> About the "updated RFCs" issue below, my po= int is: "please make
> >>>> sure the text and the hearder are complete". I j= ust had a quick
> >>>> look at those references, you know better than me whi= ch are actually
> relevant.
> >>>>
> >>>> I am looking forward to the updated version.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Julien
> >>>>
> >>>>
> >>>> Apr. 29, 2016 - zhangmingui@huawei.com:
> >>>>> Hi Julien,
> >>>>>
> >>>>> Thanks for the comments! Much appreciated!
> >>>>>
> >>>>> Please see in-lines below. An updated version wil= l soon be
> >>>>> uploaded to resolve
> >>>> the comments.
> >>>>>
> >>>>> Thanks,
> >>>>> Mingui
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Julien Meuric [mailto:julien.meuric@orange.com]
> >>>>>> Sent: Thursday, April 28, 2016 4:34 AM
> >>>>>>
> >>>>>> Hello,
> >>>>>>
> >>>>>> I have been selected as the Routing Directora= te reviewer for this draft.
> >>>>>> The Routing Directorate seeks to review all r= outing or
> >>>>>> routing-related drafts as they pass through I= ETF 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 Direct= orate, please see
> >>>>>> http://trac.tools.= ietf.org/area/rtg/trac/wiki/RtgDir
> >>>>>>
> >>>>>> Although these comments are primarily for the= use of the Routing
> >>>>>> ADs, it would be helpful if you could conside= r them along with
> >>>>>> any other IETF Last Call comments that you re= ceive, and strive to
> >>>>>> resolve them through discussion or by updatin= g the draft.
> >>>>>>
> >>>>>> Document: draft-ietf-trill-mtu-negotiation-02= .txt
> >>>>>> Reviewer: Julien Meuric
> >>>>>> Review Date: April 27, 2016
> >>>>>> IETF LC End Date: April 5, 2016
> >>>>>>
> >>>>>> Intended Status: Standards Track
> >>>>>>
> >>>>>>
> >>>>>> *Summary:*
> >>>>>> I have some minor concerns about this documen= t that I think
> >>>>>> should be resolved before publication.
> >>>>>>
> >>>>>> *Comments:*
> >>>>>> Even though it requires to browse some other = TRILL (normative)
> >>>>>> documents, the mechanism itself is simple and= well described.
> >>>>>> Nevertheless, the specification deserves some= improvement when it
> >>>>>> comes to obligations and options: this was pa= rt of my expectation
> >>>>>> after I realized it was upgrading a short sec= tion of the base
> >>>>>> document (RFC 6325), which needs to be emphas= ized as well.
> >>>>>
> >>>>> In the abstract, it's already mentioned as &q= uot;optional updates" to
> >>>>> RFC 6325. I think
> >>>> "Updates: 6325 " needs to appear in the pag= e header as well.
> >>>>>
> >>>>>>
> >>>>>> *Minor Issues:*
> >>>>>> - The document is ST and references RFC 2119.= There a some "MUST"
> >>>>>> and one "SHOULD", many of them inhe= rited from specifications out
> >>>>>> of the referenced documents. On the other sid= e, "must" and "should"
> >>>>>> are commonly used. This MUST be brought up to= ST expectations.
> >>>>>
> >>>>> The usage of "must" and "should&qu= ot; will be updated as needed. I have
> >>>>> checked all
> >>>> those appearances. The changes would be editorial. > >>>>>
> >>>>>> - The document claims to only update RFC 7177= . It seems however
> >>>>>> that it also updates RFC 6325 (section 4.3.2)= , RFC 7176 and maybe
> >>>>>> even RFC
> >> 7780.
> >>>>>
> >>>>> Actually, I don't think this document updates= RFC7176. It simply
> >>>>> makes use of
> >>>> the MTU Sub-TLV defined in RFC 7176.
> >>>>> The specification about the originatingL1LSPBuffe= rSize of an
> >>>>> unreachable
> >>>> RBridge is a slight update to RFC7780. This will be e= mphasized.
> >>>>>
> >>>>>> That should be either acknowledged or clarifi= ed. The 4th
> >>>>>> paragraph of the introduction tries to tackle= that topic, but it
> >>>>>> is not clear enough in defining the position = of the document with
> >>>>>> respect to previously
> >>>> defined mechanisms.
> >>>>>
> >>>>> The updated to RFC 6325 will be emphasized in thi= s paragraph. The
> >>>>> backward
> >>>> compatibility will be moved to here as well. It will = help the positioning.
> >>>>>
> >>>>>> - The 3rd paragraph of the introduction dupli= cates the beginning
> >>>>>> of the following section 2. A possible way to= limit this
> >>>>>> repetition effect may be to summarize that pa= rt of the introduction.
> >>>>>
> >>>>> Yes, summarization is the proper way.
> >>>>>
> >>>>>> - Section 3 specifies an algorithm. Even if i= t does not rely on a
> >>>>>> formal language, consistency would be valuabl= e. My mind compiler
> >>>>>> would
> >>>> suggest:
> >>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* "If&q= uot; is followed by "then" only once: "then" keyword to=
> >>>>>> be
> >> dropped?
> >>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* The algori= thm relies on a break/stop or continue
> >>>>>> principle; as such, the instance of "Els= e" at the end should be
> >>>>>> replaced by "<line
> >>>>>> break> 4) Repeat Step1";
> >>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* "is s= et to" and "<--" seem to be similar: please pick one or > clarify;
> >>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* to improve= readability, I would drop the double naming
> >>>>>> introduced with X,
> >>>>>> X1 and X2 and rely on explicit variable names= all along, as in
> >>>>>> the
> >>>>>> text: e.g., "linkMtuSize" instead o= f X, "lowerBound" for X1 and
> >> "upperBound"
> >>>> instead of X2.
> >>>>>
> >>>>> Sure. Explicit names will be used for the sake of= readability.
> >>>>>
> >>>>>>
> >>>>>> *Nits:*
> >>>>>
> >>>>> The following nits will be fixed as suggested. > >>>>>
> >>>>>> ------
> >>>>>> "Updates" field in header
> >>>>>> ---
> >>>>>> - I think the "RFC" acronym should = appear.
> >>>>>> - The list may be extended with RFC RFC 6325,= RFC 7176 and maybe
> >>>>>> even RFC 7780.
> >>>>>> ------
> >>>>>> Abstract
> >>>>>> ---
> >>>>>> - s/campus wide MTU feature/campus-wide MTU f= eature/
> >>>>>> - s/campus wide capability/campus-wide capabi= lity/
> >>>>>> - s/link local packets/link-local packets/ > >>>>>> - s/link local MTUs/link-local MTUs/
> >>>>>> - "It updates RFC..." duplicates he= ader: either to drop or make
> >>>>>> more specific to point to precise sections/me= chanisms.
> >>>>>> ------
> >>>>>> Section 1.
> >>>>>> ---
> >>>>>> - s/link scope PDUs can/link-scoped PDUs can/=
> >>>>>> ------
> >>>>>> Section 2.
> >>>>>> ---
> >>>>>> - s/campus wide Sz MTU/campus-wide Sz MTU/ > >>>>>> - s/area wide scope/area-wide scope/
> >>>>>> - s/domain wide scope/domain wide scope/
> >>>>>> - s/L1 Circuit Scoped/L1 Circuit-Scoped/
> >>>>>> - "limited to 1470 to 65,535 bytes"= : I cannot parse it, is it
> >>>>>> meant to be a
> >> range?
> >>>>>> ------
> >>>>>> Section 4.
> >>>>>> - OLD
> >>>>>> "while RB1 normally ignores link state i= nformation for any IS-IS
> >>>>>> unreachable RBridge RB2, originatingL1LSPBuff= erSize is an exception."
> >>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0NEW
> >>>>>> "while in most cases RB1 ignores link st= ate information for IS-IS
> >>>>>> unreachable RBridge RB2, originatingL1LSPBuff= erSize is meaningful."
> >>>>>> [current wording suggests it is adding an exc= eption to a
> >>>>>> mandatory behavior, which AFAIU it does not]<= br> > >>>>>
> >>>>> OK. Will update the words.
> >>>>>
> >>>>>> ------
> >>>>>> Section 7.
> >>>>>> ---
> >>>>>> - "tested size can be advertised": = "can" is to be addressed as
> >>>>>> part of the loose RFC 2119 wording comment. > >>>>>
> >>>>> Will use the word "MAY" instead.
> >>>>>
> >>>>>> ------
> >>>>>> Section 8.
> >>>>>> ---
> >>>>>> - "value [...] had been reported": = "reported" puzzles me, maybe
> "tested"
> >>>>>> was meant?
> >>>>>> - The 3rd paragraph "For an Lz-ignorant = [...] link-wide Lz."
> >>>>>> should be moved up to become the second parag= raph, so as to
> >>>>>> clarify what an
> >>>> Lz-ignorant is.
> >>>>>
> >>>>> OK. It will be moved up.
> >>>>>
> >>>>>> - "The extension of TRILL MTU negociatio= n...": this is an
> >>>>>> explicit positioning which should be mentione= d earlier in the I-D.
> >>>>>
> >>>>>
> >>>>> OK. This will be moved to the introduction.
> >>>>>
> >>>>>> ------
> >>>>>> Section 10.
> >>>>>> ---
> >>>>>> - RFC 7180 bis is now RFC 7780.
> >>>>>
> >>>>> Yes, this will be updated.
> >>>>>
> >>>>>> ---
> >>>>>>
> >>>>>> Regards,
> >>>>>>
> >>>>>> Julien
> >>>>>

--94eb2c0477feb1dd2305327ff038-- From nobody Tue May 10 14:30:51 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7696E12D61E; Tue, 10 May 2016 14:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] 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 BV6nRCxm7FSY; Tue, 10 May 2016 14:30:47 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 4A4E712D128; Tue, 10 May 2016 14:30:47 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.192.8.35; From: "Susan Hares" To: "'Alia Atlas'" , "'Mingui Zhang'" References: <57212222.5080904@orange.com> <4552F0907735844E9204A62BBDD325E787C858FD@NKGEML515-MBX.china.huawei.com> <572706E7.7050005@orange.com> <4552F0907735844E9204A62BBDD325E787C865EB@NKGEML515-MBX.china.huawei.com> <5729D091.2040904@orange.com> <4552F0907735844E9204A62BBDD325E787C889B1@NKGEML515-MBX.china.huawei.com> <57319CE8.9020300@orange.com> <4552F0907735844E9204A62BBDD325E787C88C39@NKGEML515-MBX.china.huawei.com> In-Reply-To: Date: Tue, 10 May 2016 17:30:36 -0400 Message-ID: <001b01d1ab03$31f4e680$95deb380$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01D1AAE1.AAE7DA60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHwQI23tOA+C/NzlKlNCkxa7FFqTAJIBES7AiknK5gBWv+DIQIL/qzzAqn08DYCIGAvYAIfetG0ASCHD/ee9nEroA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, draft-ietf-trill-mtu-negotiation.all@ietf.org, trill@ietf.org, 'Julien Meuric' Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-trill-mtu-negotiation-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 21:30:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001C_01D1AAE1.AAE7DA60 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Julien:=20 =20 Thank you from one of the TRILL WG chairs.=20 =20 Sue=20 =20 From: Alia Atlas [mailto:akatlas@gmail.com]=20 Sent: Tuesday, May 10, 2016 1:06 PM To: Mingui Zhang Cc: Julien Meuric; draft-ietf-trill-mtu-negotiation.all@ietf.org; = rtg-ads@ietf.org; rtg-dir@ietf.org; trill@ietf.org Subject: Re: RtgDir review: draft-ietf-trill-mtu-negotiation-02 =20 Julien, =20 Thank you very much for your review! =20 Mingui, =20 Thank you for addressing the comments. =20 =20 Regards, Alia =20 On Tue, May 10, 2016 at 7:16 AM, Mingui Zhang = wrote: Hi Julien, Thanks for pointing it out. That typo will be fixed together with other = comments we would receive. Thanks, Mingui > -----Original Message----- > From: Julien Meuric [mailto:julien.meuric@orange.com] > Sent: Tuesday, May 10, 2016 4:34 PM > To: Mingui Zhang > Cc: draft-ietf-trill-mtu-negotiation.all@ietf.org; rtg-ads@ietf.org; = rtg-dir@ietf.org; > trill@ietf.org > Subject: Re: RtgDir review: draft-ietf-trill-mtu-negotiation-02 > > Hi Mingui, > > This version seems to address my comment. > > Please note a new typo on page 8: s/any LPS/any LSP/ > > Thanks, > > Julien > > > May. 10, 2016 - zhangmingui@huawei.com: > > Hi Julien, > > > > I have uploaded the 04 version. Please take a look. > > > > Thanks, > > Mingui > > > >> -----Original Message----- > >> From: Julien Meuric [mailto:julien.meuric@orange.com] > >> Sent: Wednesday, May 04, 2016 6:36 PM > >> > >> Hi Mingui, > >> > >> I have looked at the diff of your update and have noticed that = several > "should" > >> have been replaced by "need[s] to": I appreciate that you = acknowledge > >> my comment on this, but none of them being RFC 2119 keyword, I = still > >> doubt this matches Standards Track expectations. > >> > >> I caught a nit in section 3: s/is sent to/is set to/ > >> > >> Regards, > >> > >> Julien > >> > >> > >> May. 03, 2016 - zhangmingui@huawei.com: > >>> Hi Julien, > >>> > >>> The updated version has just been uploaded. > >>> > >>> Thanks, > >>> Mingui > >>> > >>>> -----Original Message----- > >>>> From: Julien Meuric [mailto:julien.meuric@orange.com] > >>>> Sent: Monday, May 02, 2016 3:51 PM > >>>> > >>>> Hi Mingui, > >>>> > >>>> About the "updated RFCs" issue below, my point is: "please make > >>>> sure the text and the hearder are complete". I just had a quick > >>>> look at those references, you know better than me which are = actually > relevant. > >>>> > >>>> I am looking forward to the updated version. > >>>> > >>>> Thanks, > >>>> > >>>> Julien > >>>> > >>>> > >>>> Apr. 29, 2016 - zhangmingui@huawei.com: > >>>>> Hi Julien, > >>>>> > >>>>> Thanks for the comments! Much appreciated! > >>>>> > >>>>> Please see in-lines below. An updated version will soon be > >>>>> uploaded to resolve > >>>> the comments. > >>>>> > >>>>> Thanks, > >>>>> Mingui > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Julien Meuric [mailto:julien.meuric@orange.com] > >>>>>> Sent: Thursday, April 28, 2016 4:34 AM > >>>>>> > >>>>>> Hello, > >>>>>> > >>>>>> I have been selected as the Routing Directorate reviewer for = this draft. > >>>>>> The Routing Directorate seeks to review all routing or > >>>>>> 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 > >>>>>> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > >>>>>> > >>>>>> Although these comments are primarily for the use of the = Routing > >>>>>> ADs, it would be helpful if you could consider them along with > >>>>>> any other IETF Last Call comments that you receive, and strive = to > >>>>>> resolve them through discussion or by updating the draft. > >>>>>> > >>>>>> Document: draft-ietf-trill-mtu-negotiation-02.txt > >>>>>> Reviewer: Julien Meuric > >>>>>> Review Date: April 27, 2016 > >>>>>> IETF LC End Date: April 5, 2016 > >>>>>> > >>>>>> Intended Status: Standards Track > >>>>>> > >>>>>> > >>>>>> *Summary:* > >>>>>> I have some minor concerns about this document that I think > >>>>>> should be resolved before publication. > >>>>>> > >>>>>> *Comments:* > >>>>>> Even though it requires to browse some other TRILL (normative) > >>>>>> documents, the mechanism itself is simple and well described. > >>>>>> Nevertheless, the specification deserves some improvement when = it > >>>>>> comes to obligations and options: this was part of my = expectation > >>>>>> after I realized it was upgrading a short section of the base > >>>>>> document (RFC 6325), which needs to be emphasized as well. > >>>>> > >>>>> In the abstract, it's already mentioned as "optional updates" to > >>>>> RFC 6325. I think > >>>> "Updates: 6325 " needs to appear in the page header as well. > >>>>> > >>>>>> > >>>>>> *Minor Issues:* > >>>>>> - The document is ST and references RFC 2119. There a some = "MUST" > >>>>>> and one "SHOULD", many of them inherited from specifications = out > >>>>>> of the referenced documents. On the other side, "must" and = "should" > >>>>>> are commonly used. This MUST be brought up to ST expectations. > >>>>> > >>>>> The usage of "must" and "should" will be updated as needed. I = have > >>>>> checked all > >>>> those appearances. The changes would be editorial. > >>>>> > >>>>>> - The document claims to only update RFC 7177. It seems however > >>>>>> that it also updates RFC 6325 (section 4.3.2), RFC 7176 and = maybe > >>>>>> even RFC > >> 7780. > >>>>> > >>>>> Actually, I don't think this document updates RFC7176. It simply > >>>>> makes use of > >>>> the MTU Sub-TLV defined in RFC 7176. > >>>>> The specification about the originatingL1LSPBufferSize of an > >>>>> unreachable > >>>> RBridge is a slight update to RFC7780. This will be emphasized. > >>>>> > >>>>>> That should be either acknowledged or clarified. The 4th > >>>>>> paragraph of the introduction tries to tackle that topic, but = it > >>>>>> is not clear enough in defining the position of the document = with > >>>>>> respect to previously > >>>> defined mechanisms. > >>>>> > >>>>> The updated to RFC 6325 will be emphasized in this paragraph. = The > >>>>> backward > >>>> compatibility will be moved to here as well. It will help the = positioning. > >>>>> > >>>>>> - The 3rd paragraph of the introduction duplicates the = beginning > >>>>>> of the following section 2. A possible way to limit this > >>>>>> repetition effect may be to summarize that part of the = introduction. > >>>>> > >>>>> Yes, summarization is the proper way. > >>>>> > >>>>>> - Section 3 specifies an algorithm. Even if it does not rely on = a > >>>>>> formal language, consistency would be valuable. My mind = compiler > >>>>>> would > >>>> suggest: > >>>>>> * "If" is followed by "then" only once: "then" keyword = to > >>>>>> be > >> dropped? > >>>>>> * The algorithm relies on a break/stop or continue > >>>>>> principle; as such, the instance of "Else" at the end should be > >>>>>> replaced by " >>>>>> break> 4) Repeat Step1"; > >>>>>> * "is set to" and "<--" seem to be similar: please pick = one or > clarify; > >>>>>> * to improve readability, I would drop the double = naming > >>>>>> introduced with X, > >>>>>> X1 and X2 and rely on explicit variable names all along, as in > >>>>>> the > >>>>>> text: e.g., "linkMtuSize" instead of X, "lowerBound" for X1 and > >> "upperBound" > >>>> instead of X2. > >>>>> > >>>>> Sure. Explicit names will be used for the sake of readability. > >>>>> > >>>>>> > >>>>>> *Nits:* > >>>>> > >>>>> The following nits will be fixed as suggested. > >>>>> > >>>>>> ------ > >>>>>> "Updates" field in header > >>>>>> --- > >>>>>> - I think the "RFC" acronym should appear. > >>>>>> - The list may be extended with RFC RFC 6325, RFC 7176 and = maybe > >>>>>> even RFC 7780. > >>>>>> ------ > >>>>>> Abstract > >>>>>> --- > >>>>>> - s/campus wide MTU feature/campus-wide MTU feature/ > >>>>>> - s/campus wide capability/campus-wide capability/ > >>>>>> - s/link local packets/link-local packets/ > >>>>>> - s/link local MTUs/link-local MTUs/ > >>>>>> - "It updates RFC..." duplicates header: either to drop or make > >>>>>> more specific to point to precise sections/mechanisms. > >>>>>> ------ > >>>>>> Section 1. > >>>>>> --- > >>>>>> - s/link scope PDUs can/link-scoped PDUs can/ > >>>>>> ------ > >>>>>> Section 2. > >>>>>> --- > >>>>>> - s/campus wide Sz MTU/campus-wide Sz MTU/ > >>>>>> - s/area wide scope/area-wide scope/ > >>>>>> - s/domain wide scope/domain wide scope/ > >>>>>> - s/L1 Circuit Scoped/L1 Circuit-Scoped/ > >>>>>> - "limited to 1470 to 65,535 bytes": I cannot parse it, is it > >>>>>> meant to be a > >> range? > >>>>>> ------ > >>>>>> Section 4. > >>>>>> - OLD > >>>>>> "while RB1 normally ignores link state information for any = IS-IS > >>>>>> unreachable RBridge RB2, originatingL1LSPBufferSize is an = exception." > >>>>>> NEW > >>>>>> "while in most cases RB1 ignores link state information for = IS-IS > >>>>>> unreachable RBridge RB2, originatingL1LSPBufferSize is = meaningful." > >>>>>> [current wording suggests it is adding an exception to a > >>>>>> mandatory behavior, which AFAIU it does not] > >>>>> > >>>>> OK. Will update the words. > >>>>> > >>>>>> ------ > >>>>>> Section 7. > >>>>>> --- > >>>>>> - "tested size can be advertised": "can" is to be addressed as > >>>>>> part of the loose RFC 2119 wording comment. > >>>>> > >>>>> Will use the word "MAY" instead. > >>>>> > >>>>>> ------ > >>>>>> Section 8. > >>>>>> --- > >>>>>> - "value [...] had been reported": "reported" puzzles me, maybe > "tested" > >>>>>> was meant? > >>>>>> - The 3rd paragraph "For an Lz-ignorant [...] link-wide Lz." > >>>>>> should be moved up to become the second paragraph, so as to > >>>>>> clarify what an > >>>> Lz-ignorant is. > >>>>> > >>>>> OK. It will be moved up. > >>>>> > >>>>>> - "The extension of TRILL MTU negociation...": this is an > >>>>>> explicit positioning which should be mentioned earlier in the = I-D. > >>>>> > >>>>> > >>>>> OK. This will be moved to the introduction. > >>>>> > >>>>>> ------ > >>>>>> Section 10. > >>>>>> --- > >>>>>> - RFC 7180 bis is now RFC 7780. > >>>>> > >>>>> Yes, this will be updated. > >>>>> > >>>>>> --- > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Julien > >>>>> =20 ------=_NextPart_000_001C_01D1AAE1.AAE7DA60 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Julien:

 

Thank you from one of the TRILL WG chairs.

 

Sue

 

From:= = Alia Atlas [mailto:akatlas@gmail.com]
Sent: Tuesday, May 10, = 2016 1:06 PM
To: Mingui Zhang
Cc: Julien Meuric; = draft-ietf-trill-mtu-negotiation.all@ietf.org; rtg-ads@ietf.org; = rtg-dir@ietf.org; trill@ietf.org
Subject: Re: RtgDir review: = draft-ietf-trill-mtu-negotiation-02

 

Julien,

 

Thank you very much for your = review!

 

Mingui,

 

Thank you for addressing the comments. =  

 

Regards,

Alia

 

On Tue, = May 10, 2016 at 7:16 AM, Mingui Zhang <zhangmingui@huawei.com> wrote:

Hi Julien,

Thanks for pointing it out. That = typo will be fixed together with other comments we would = receive.

Thanks,
Mingui

> -----Original = Message-----
> From: Julien Meuric = [mailto:julien.meuric@orange.com]
> Sent: Tuesday, May 10, 2016 4:34 = PM
> To: Mingui Zhang
> Cc: draft-ietf-= trill-mtu-negotiation.all@ietf.org; rtg-ads@ietf.org; rtg-dir@ietf.org;
> trill@ietf.org
> Subject: Re: RtgDir review: = draft-ietf-trill-mtu-negotiation-02
>

> = Hi Mingui,
>
> This version seems to address my = comment.
>
> Please note a new typo on page 8: s/any LPS/any = LSP/
>
> Thanks,
>
> = Julien
>
>
> May. 10, 2016 - zhangmingui@huawei.com:
>= ; > Hi Julien,
> >
> > I have uploaded the 04 = version. Please take a look.
> >
> > Thanks,
> = > Mingui
> >
> >> -----Original = Message-----
> >> From: Julien Meuric [mailto:julien.meuric@orange.com]> >> Sent: Wednesday, May 04, 2016 6:36 PM
> = >>
> >> Hi Mingui,
> >>
> >> I = have looked at the diff of your update and have noticed that = several
> "should"
> >> have been replaced = by "need[s] to": I appreciate that you acknowledge
> = >> my comment on this, but none of them being RFC 2119 keyword, I = still
> >> doubt this matches Standards Track = expectations.
> >>
> >> I caught a nit in = section 3: s/is sent to/is set to/
> >>
> >> = Regards,
> >>
> >> Julien
> = >>
> >>
> >> May. 03, 2016 - zhangmingui@huawei.com:
>= ; >>> Hi Julien,
> >>>
> >>> The = updated version has just been uploaded.
> >>>
> = >>> Thanks,
> >>> Mingui
> = >>>
> >>>> -----Original Message-----
> = >>>> From: Julien Meuric [mailto:julien.meuric@orange.com]> >>>> Sent: Monday, May 02, 2016 3:51 PM
> = >>>>
> >>>> Hi Mingui,
> = >>>>
> >>>> About the "updated = RFCs" issue below, my point is: "please make
> = >>>> sure the text and the hearder are complete". I = just had a quick
> >>>> look at those references, you = know better than me which are actually
> relevant.
> = >>>>
> >>>> I am looking forward to the = updated version.
> >>>>
> >>>> = Thanks,
> >>>>
> >>>> Julien
> = >>>>
> >>>>
> >>>> Apr. = 29, 2016 - zhangmingui@huawei.com:
>= ; >>>>> Hi Julien,
> >>>>>
> = >>>>> Thanks for the comments! Much appreciated!
> = >>>>>
> >>>>> Please see in-lines = below. An updated version will soon be
> >>>>> = uploaded to resolve
> >>>> the comments.
> = >>>>>
> >>>>> Thanks,
> = >>>>> Mingui
> >>>>>
> = >>>>>> -----Original Message-----
> = >>>>>> From: Julien Meuric [mailto:julien.meuric@orange.com]> >>>>>> Sent: Thursday, April 28, 2016 4:34 = AM
> >>>>>>
> >>>>>> = Hello,
> >>>>>>
> >>>>>> = I have been selected as the Routing Directorate reviewer for this = draft.
> >>>>>> The Routing Directorate seeks to = review all routing or
> >>>>>> 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
> >>>>>> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> >>>>>>
> >>>>>> = Although these comments are primarily for the use of the Routing
> = >>>>>> ADs, it would be helpful if you could consider = them along with
> >>>>>> any other IETF Last = Call comments that you receive, and strive to
> = >>>>>> resolve them through discussion or by updating = the draft.
> >>>>>>
> = >>>>>> Document: = draft-ietf-trill-mtu-negotiation-02.txt
> >>>>>> = Reviewer: Julien Meuric
> >>>>>> Review Date: = April 27, 2016
> >>>>>> IETF LC End Date: April = 5, 2016
> >>>>>>
> = >>>>>> Intended Status: Standards Track
> = >>>>>>
> >>>>>>
> = >>>>>> *Summary:*
> >>>>>> I = have some minor concerns about this document that I think
> = >>>>>> should be resolved before publication.
> = >>>>>>
> >>>>>> = *Comments:*
> >>>>>> Even though it requires to = browse some other TRILL (normative)
> >>>>>> = documents, the mechanism itself is simple and well described.
> = >>>>>> Nevertheless, the specification deserves some = improvement when it
> >>>>>> comes to = obligations and options: this was part of my expectation
> = >>>>>> after I realized it was upgrading a short = section of the base
> >>>>>> document (RFC = 6325), which needs to be emphasized as well.
> = >>>>>
> >>>>> In the abstract, it's = already mentioned as "optional updates" to
> = >>>>> RFC 6325. I think
> >>>> = "Updates: 6325 " needs to appear in the page header as = well.
> >>>>>
> = >>>>>>
> >>>>>> *Minor = Issues:*
> >>>>>> - The document is ST and = references RFC 2119. There a some "MUST"
> = >>>>>> and one "SHOULD", many of them = inherited from specifications out
> >>>>>> of = the referenced documents. On the other side, "must" and = "should"
> >>>>>> are commonly used. = This MUST be brought up to ST expectations.
> = >>>>>
> >>>>> The usage of = "must" and "should" will be updated as needed. I = have
> >>>>> checked all
> >>>> = those appearances. The changes would be editorial.
> = >>>>>
> >>>>>> - The document = claims to only update RFC 7177. It seems however
> = >>>>>> that it also updates RFC 6325 (section 4.3.2), = RFC 7176 and maybe
> >>>>>> even RFC
> = >> 7780.
> >>>>>
> >>>>> = Actually, I don't think this document updates RFC7176. It simply
> = >>>>> makes use of
> >>>> the MTU = Sub-TLV defined in RFC 7176.
> >>>>> The = specification about the originatingL1LSPBufferSize of an
> = >>>>> unreachable
> >>>> RBridge is a = slight update to RFC7780. This will be emphasized.
> = >>>>>
> >>>>>> That should be = either acknowledged or clarified. The 4th
> = >>>>>> paragraph of the introduction tries to tackle = that topic, but it
> >>>>>> is not clear enough = in defining the position of the document with
> = >>>>>> respect to previously
> >>>> = defined mechanisms.
> >>>>>
> = >>>>> The updated to RFC 6325 will be emphasized in this = paragraph. The
> >>>>> backward
> = >>>> compatibility will be moved to here as well. It will = help the positioning.
> >>>>>
> = >>>>>> - The 3rd paragraph of the introduction = duplicates the beginning
> >>>>>> of the = following section 2. A possible way to limit this
> = >>>>>> repetition effect may be to summarize that part = of the introduction.
> >>>>>
> = >>>>> Yes, summarization is the proper way.
> = >>>>>
> >>>>>> - Section 3 = specifies an algorithm. Even if it does not rely on a
> = >>>>>> formal language, consistency would be valuable. = My mind compiler
> >>>>>> would
> = >>>> suggest:
> >>>>>>    =      * "If" is followed by "then" = only once: "then" keyword to
> >>>>>> = be
> >> dropped?
> >>>>>>  =        * The algorithm relies on a break/stop or = continue
> >>>>>> principle; as such, the = instance of "Else" at the end should be
> = >>>>>> replaced by "<line
> = >>>>>> break> 4) Repeat Step1";
> = >>>>>>         * "is set = to" and "<--" seem to be similar: please pick one = or
> clarify;
> >>>>>>      =    * to improve readability, I would drop the double = naming
> >>>>>> introduced with X,
> = >>>>>> X1 and X2 and rely on explicit variable names = all along, as in
> >>>>>> the
> = >>>>>> text: e.g., "linkMtuSize" instead of = X, "lowerBound" for X1 and
> >> = "upperBound"
> >>>> instead of X2.
> = >>>>>
> >>>>> Sure. Explicit names = will be used for the sake of readability.
> = >>>>>
> >>>>>>
> = >>>>>> *Nits:*
> >>>>>
> = >>>>> The following nits will be fixed as = suggested.
> >>>>>
> >>>>>> = ------
> >>>>>> "Updates" field in = header
> >>>>>> ---
> = >>>>>> - I think the "RFC" acronym should = appear.
> >>>>>> - The list may be extended with = RFC RFC 6325, RFC 7176 and maybe
> >>>>>> even = RFC 7780.
> >>>>>> ------
> = >>>>>> Abstract
> >>>>>> = ---
> >>>>>> - s/campus wide MTU = feature/campus-wide MTU feature/
> >>>>>> - = s/campus wide capability/campus-wide capability/
> = >>>>>> - s/link local packets/link-local = packets/
> >>>>>> - s/link local MTUs/link-local = MTUs/
> >>>>>> - "It updates RFC..." = duplicates header: either to drop or make
> = >>>>>> more specific to point to precise = sections/mechanisms.
> >>>>>> ------
> = >>>>>> Section 1.
> >>>>>> = ---
> >>>>>> - s/link scope PDUs can/link-scoped = PDUs can/
> >>>>>> ------
> = >>>>>> Section 2.
> >>>>>> = ---
> >>>>>> - s/campus wide Sz MTU/campus-wide = Sz MTU/
> >>>>>> - s/area wide scope/area-wide = scope/
> >>>>>> - s/domain wide scope/domain = wide scope/
> >>>>>> - s/L1 Circuit Scoped/L1 = Circuit-Scoped/
> >>>>>> - "limited to 1470 = to 65,535 bytes": I cannot parse it, is it
> = >>>>>> meant to be a
> >> range?
> = >>>>>> ------
> >>>>>> Section = 4.
> >>>>>> - OLD
> = >>>>>> "while RB1 normally ignores link state = information for any IS-IS
> >>>>>> unreachable = RBridge RB2, originatingL1LSPBufferSize is an exception."
> = >>>>>>       NEW
> = >>>>>> "while in most cases RB1 ignores link = state information for IS-IS
> >>>>>> unreachable = RBridge RB2, originatingL1LSPBufferSize is meaningful."
> = >>>>>> [current wording suggests it is adding an = exception to a
> >>>>>> mandatory behavior, = which AFAIU it does not]
> >>>>>
> = >>>>> OK. Will update the words.
> = >>>>>
> >>>>>> ------
> = >>>>>> Section 7.
> >>>>>> = ---
> >>>>>> - "tested size can be = advertised": "can" is to be addressed as
> = >>>>>> part of the loose RFC 2119 wording = comment.
> >>>>>
> >>>>> Will = use the word "MAY" instead.
> = >>>>>
> >>>>>> ------
> = >>>>>> Section 8.
> >>>>>> = ---
> >>>>>> - "value [...] had been = reported": "reported" puzzles me, maybe
> = "tested"
> >>>>>> was meant?
> = >>>>>> - The 3rd paragraph "For an Lz-ignorant = [...] link-wide Lz."
> >>>>>> should be = moved up to become the second paragraph, so as to
> = >>>>>> clarify what an
> >>>> = Lz-ignorant is.
> >>>>>
> = >>>>> OK. It will be moved up.
> = >>>>>
> >>>>>> - "The = extension of TRILL MTU negociation...": this is an
> = >>>>>> explicit positioning which should be mentioned = earlier in the I-D.
> >>>>>
> = >>>>>
> >>>>> OK. This will be moved = to the introduction.
> >>>>>
> = >>>>>> ------
> >>>>>> Section = 10.
> >>>>>> ---
> = >>>>>> - RFC 7180 bis is now RFC 7780.
> = >>>>>
> >>>>> Yes, this will be = updated.
> >>>>>
> >>>>>> = ---
> >>>>>>
> >>>>>> = Regards,
> >>>>>>
> = >>>>>> Julien
> = >>>>>

 

------=_NextPart_000_001C_01D1AAE1.AAE7DA60-- From nobody Tue May 10 15:04:35 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFC2E12D1D7; Tue, 10 May 2016 15:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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.996, 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 lqpTBjoFqIsS; Tue, 10 May 2016 15:04:31 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62DE512D16F; Tue, 10 May 2016 15:04:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4665; q=dns/txt; s=iport; t=1462917871; x=1464127471; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NI4Te88tlbBtJOFcM1ZkKUphPLjKy83TsHpI3TEMsWc=; b=cz04QGHLE/38khsHFsn0vpGsAmQNy8Rshf4Qhcc//S57eHpErPA41tw3 dvtPB5yNYNDYn+6Ebdr5d5uPGclOQVfLcXzIobchIRG3A5vJGWlshkpoT rtEmEB0I3X0iXZqvoukeXGGXw73P6A/5CCDOWX/aRDxkHg9axVHqXCsvE 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAgCvWTJX/4oNJK1UCYM4gVIGuS8BD?= =?us-ascii?q?YF2hhACgTo4FAEBAQEBAQFlJ4RBAQEBAwE6PwwEAgEIEQEDAQEBHhAyFwYIAQE?= =?us-ascii?q?EAQ0FCIgbBwG5RQEBAQEBAQEBAQEBAQEBAQEBAQEBARWGIIRMhBEHCgGFdQWYJ?= =?us-ascii?q?wGOFoFwhE+IYY8/AR4BAUKDa26HVTYBfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,606,1454976000"; d="scan'208";a="105770875" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 May 2016 22:04:30 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u4AM4UOp006968 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 May 2016 22:04:30 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 10 May 2016 17:04:29 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Tue, 10 May 2016 17:04:29 -0500 From: "Les Ginsberg (ginsberg)" To: "Joe Clarke (jclarke)" , "rtg-ads@ietf.org" Thread-Topic: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 Thread-Index: AdGgzHD5AnaTBqcTQJm4IHI17iI2lQBnClYAAieCg0A= Date: Tue, 10 May 2016 22:04:29 +0000 Message-ID: References: <5afaa922862d4b4a9dc67f117ae5366a@XCH-ALN-001.cisco.com> In-Reply-To: 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: [171.69.34.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-i2rs-traceability@ietf.org" , "i2rs@ietf.org" Subject: Re: [RTG-DIR] [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 22:04:34 -0000 Joe - Apologies for the delayed response. I am a victim of my own email infilters= . :-( Inline. > -----Original Message----- > From: Joe Clarke (jclarke) > Sent: Friday, April 29, 2016 10:44 AM > To: Les Ginsberg (ginsberg); rtg-ads@ietf.org > Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; i2rs@ietf.or= g > Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 >=20 > On 4/27/16 17:39, Les Ginsberg (ginsberg) wrote: > > Summary: This document is a well written document - easy to understand= . > > My compliments to the authors. I believe there is one minor issue > > which I would like to see addressed before publication. >=20 > Thanks for your comments and feedback, Les. Please see below for some > replies and questions. >=20 > > In Section 5.2 there is a definition of the information which is > > required to be kept by an I2RS Agent for each I2RS interaction. I > > would like to see the addition of "Request State" into this list. > > Operationally each request could be in one of the following states: > > > > > > > > * Enqueued (or pending if you prefer) > > > > * In process > > > > * Completed > > > > > > > > The lack of such a state seems to imply that both the queue time and > > the processing time are insignificant. While I think this may be the > > case for many requests, it will not always be the case. In queue time > > may be lengthy due to other load on the Agent. Also, some requests - > > particularly destructive requests which involve cleanup of resources - > > may take a significant amount of time to complete. >=20 > Good observation. Traceability was aimed mainly at the termination of th= e > request, but I like the idea of tracing the state machine. >=20 > > > > > > > > Along with this an additional timestamp - Processing Initiated - would > > be useful to indicate when processing of the request actually began. >=20 > I don't know we need a new timestamp. Perhaps we just need to rename > "Request Timestamp" and "Result Timestamp" to "Start Timestamp" and > "End Timestamp" to denote the time within the current state. What do you > think? [Les:] My intent was to log the time at which the request began processing = so that you can see whether a long delay in completion was due to enqueue = delay or actual lengthy processing time. I am not adamant about this so if = you want to stay with the two timestamps that is OK. >=20 > > s/Some notable elements on the architecture/ Some notable elements of > > the architecture >=20 > Fixed. Thanks! >=20 > > > > > > > > Figure 1 > > > > > > > > Not clear to me why Application IDs start at 0 but Client IDs start at = 1. >=20 > Ah. The numbers there are not IDs. They are the number of actual things= in > the boxes above. For Applications, there may be 0 to N for a given clien= t. For > Clients, you need at least 1. Does that make sense? >=20 [Les:] Maybe you want to use "shadows" on the boxes to indicate there can b= e multiple Application boxes and multiple Client boxes? What you say makes sense but I do not intuit that when I look at the ASSCII= art. > > > > > > > > Figure 1 > > > > > > > > Is the text "Op Data V" between I2RS Agent box and Routing System box > > intentional? >=20 > Yes. The 'V' is meant to be an arrow head pointed down. The request > and data go from Client to Agent whereas the Response goes from Agent to > Client. >=20 > We are open to suggestions on how to make this clearer. [Les:] I think it would be clearer if you had two lines - one flowing down = associated with the Op Data and one flowing up with the result. >=20 > > > > > > > > Section 5.2 > > > > > > > > Secondary Identity > > > > > > > > This is defined to be "opaque" yet if not provided the agent is suppose= d > > to insert "an UNAVAILABLE value". This seems to be a contradiction > > unless we have a publicly defined value that clients are prohibited fro= m > > using. Absent that you would need a "Secondary Identity Valid" indicato= r. >=20 > Good observation. I think it's fine to say that this field must be > logged. If there is no application, then the field will be logged as > empty. If there is an application, then whatever value is provided will > be logged. >=20 > Do you feel strongly that we need a field to indicate Application Present= ? > [Les:] I am fine w your changes. Les =20 > > > > > > > > Section 7.4 > > > > > > > > s/establish an vendor-agnostic/establish a vendor-agnostic >=20 > Fixed. Thanks! >=20 > Joe From nobody Wed May 11 08:18:47 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B3612DB40; Wed, 11 May 2016 08:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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.996, 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 nob-BXPH1ZOq; Wed, 11 May 2016 08:18:40 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48F3B12D0E3; Wed, 11 May 2016 08:18:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4867; q=dns/txt; s=iport; t=1462979920; x=1464189520; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=VJyxM9sO7tRQ5370S0UBH8hQY9ed7Hq13jpT9DZnUAA=; b=fkMvTfMfegonn/Lzw+k67XMnlDjK4XarY/qjD910njMhPOrrYmNhNLJt ND+Kfka1y/YeMG2B2ObGroIzzSDJjp69OjsVAM5L3ulGqemVvJ0Dzdwwj HHoVjMnLkRINPwPUbZavHqiyFBc0VtV/7/cJkVIresE2hr5ENUw4HmjbV Y=; X-IronPort-AV: E=Sophos;i="5.24,608,1454976000"; d="scan'208";a="101084280" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 May 2016 15:18:39 +0000 Received: from [10.118.87.83] (rtp-jclarke-nitro2.cisco.com [10.118.87.83]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u4BFIcxv025288; Wed, 11 May 2016 15:18:39 GMT To: "Les Ginsberg (ginsberg)" , "rtg-ads@ietf.org" References: <5afaa922862d4b4a9dc67f117ae5366a@XCH-ALN-001.cisco.com> From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <978721df-6b95-dff7-af53-31d42a731946@cisco.com> Date: Wed, 11 May 2016 11:18:38 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-i2rs-traceability@ietf.org" , "i2rs@ietf.org" Subject: Re: [RTG-DIR] [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 15:18:43 -0000 On 5/10/16 18:04, Les Ginsberg (ginsberg) wrote: > Joe - > > Apologies for the delayed response. I am a victim of my own email infilters. :-( > Inline. Thanks, Les. Have a look at https://www.marcuscom.com/draft-ietf-i2rs-traceability.txt-from-09-10.diff.html . I added a new line to show the flow in both directions. Joe > >> -----Original Message----- >> From: Joe Clarke (jclarke) >> Sent: Friday, April 29, 2016 10:44 AM >> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org >> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; i2rs@ietf.org >> Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 >> >> On 4/27/16 17:39, Les Ginsberg (ginsberg) wrote: >>> Summary: This document is a well written document - easy to understand. >>> My compliments to the authors. I believe there is one minor issue >>> which I would like to see addressed before publication. >> >> Thanks for your comments and feedback, Les. Please see below for some >> replies and questions. >> >>> In Section 5.2 there is a definition of the information which is >>> required to be kept by an I2RS Agent for each I2RS interaction. I >>> would like to see the addition of "Request State" into this list. >>> Operationally each request could be in one of the following states: >>> >>> >>> >>> * Enqueued (or pending if you prefer) >>> >>> * In process >>> >>> * Completed >>> >>> >>> >>> The lack of such a state seems to imply that both the queue time and >>> the processing time are insignificant. While I think this may be the >>> case for many requests, it will not always be the case. In queue time >>> may be lengthy due to other load on the Agent. Also, some requests - >>> particularly destructive requests which involve cleanup of resources - >>> may take a significant amount of time to complete. >> >> Good observation. Traceability was aimed mainly at the termination of the >> request, but I like the idea of tracing the state machine. >> >>> >>> >>> >>> Along with this an additional timestamp - Processing Initiated - would >>> be useful to indicate when processing of the request actually began. >> >> I don't know we need a new timestamp. Perhaps we just need to rename >> "Request Timestamp" and "Result Timestamp" to "Start Timestamp" and >> "End Timestamp" to denote the time within the current state. What do you >> think? > > [Les:] My intent was to log the time at which the request began processing so that you can see whether a long delay in completion was due to enqueue delay or actual lengthy processing time. I am not adamant about this so if you want to stay with the two timestamps that is OK. > >> >>> s/Some notable elements on the architecture/ Some notable elements of >>> the architecture >> >> Fixed. Thanks! >> >>> >>> >>> >>> Figure 1 >>> >>> >>> >>> Not clear to me why Application IDs start at 0 but Client IDs start at 1. >> >> Ah. The numbers there are not IDs. They are the number of actual things in >> the boxes above. For Applications, there may be 0 to N for a given client. For >> Clients, you need at least 1. Does that make sense? >> > [Les:] Maybe you want to use "shadows" on the boxes to indicate there can be multiple Application boxes and multiple Client boxes? > What you say makes sense but I do not intuit that when I look at the ASSCII art. > >>> >>> >>> >>> Figure 1 >>> >>> >>> >>> Is the text "Op Data V" between I2RS Agent box and Routing System box >>> intentional? >> >> Yes. The 'V' is meant to be an arrow head pointed down. The request >> and data go from Client to Agent whereas the Response goes from Agent to >> Client. >> >> We are open to suggestions on how to make this clearer. > > [Les:] I think it would be clearer if you had two lines - one flowing down associated with the Op Data and one flowing up with the result. > >> >>> >>> >>> >>> Section 5.2 >>> >>> >>> >>> Secondary Identity >>> >>> >>> >>> This is defined to be "opaque" yet if not provided the agent is supposed >>> to insert "an UNAVAILABLE value". This seems to be a contradiction >>> unless we have a publicly defined value that clients are prohibited from >>> using. Absent that you would need a "Secondary Identity Valid" indicator. >> >> Good observation. I think it's fine to say that this field must be >> logged. If there is no application, then the field will be logged as >> empty. If there is an application, then whatever value is provided will >> be logged. >> >> Do you feel strongly that we need a field to indicate Application Present? >> > [Les:] I am fine w your changes. > > Les > >>> >>> >>> >>> Section 7.4 >>> >>> >>> >>> s/establish an vendor-agnostic/establish a vendor-agnostic >> >> Fixed. Thanks! >> >> Joe From nobody Wed May 11 14:41:55 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF7612D1B3; Wed, 11 May 2016 14:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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.996, 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 lqvluXrWeELB; Wed, 11 May 2016 14:41:48 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F52112D141; Wed, 11 May 2016 14:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5644; q=dns/txt; s=iport; t=1463002908; x=1464212508; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VvzmrQzucvj18jvcaGPTLwXg93B16bkrB2lBxVPQUzo=; b=AnTNnSSz5b1zsIY0NW3tIzuZH5+WUN8G+qAQij20cmQZZ8tsfIZ6+bEZ l8GC1/kgzpmjUPP+dEXSSlbhjuIWThQimPgknRqCgwfz2ZhlyN/VJjPxM 19tKq+wQpZPf/UzjdR5pWs4+Qwo5PZJ61ZM5E8ImWTwPu9gKkSBctO7Wr o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvAgDOpTNX/5ldJa1VCYQNgQO5Mw2Bd?= =?us-ascii?q?oYUAoE+OBQBAQEBAQEBZSeEQgEBBTo/DAQCAQgRAQMBAQEeEDIXBggBAQQBDQ2?= =?us-ascii?q?IJw66XgSGIIRMhBEHCgGFdQWYJwGOFoFwhE+IYY9AAR4CQoNriEM2fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,609,1454976000"; d="scan'208";a="271628577" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 May 2016 21:39:30 +0000 Received: from XCH-RCD-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u4BLdUDS032706 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 May 2016 21:39:30 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 11 May 2016 16:39:29 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Wed, 11 May 2016 16:39:29 -0500 From: "Les Ginsberg (ginsberg)" To: "Joe Clarke (jclarke)" , "rtg-ads@ietf.org" Thread-Topic: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 Thread-Index: AdGgzHD5AnaTBqcTQJm4IHI17iI2lQBnClYAAieCg0AALuo+AAACzD3Q Date: Wed, 11 May 2016 21:39:29 +0000 Message-ID: <6dde8ef61dbf4faa98387fee01516dc3@XCH-ALN-001.cisco.com> References: <5afaa922862d4b4a9dc67f117ae5366a@XCH-ALN-001.cisco.com> <978721df-6b95-dff7-af53-31d42a731946@cisco.com> In-Reply-To: <978721df-6b95-dff7-af53-31d42a731946@cisco.com> 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.24.120.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-i2rs-traceability@ietf.org" , "i2rs@ietf.org" Subject: Re: [RTG-DIR] [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 21:41:51 -0000 Joe - Yes - this looks better to me. What about the "shadow boxes" for Applications/Clients? Les > -----Original Message----- > From: Joe Clarke (jclarke) > Sent: Wednesday, May 11, 2016 8:19 AM > To: Les Ginsberg (ginsberg); rtg-ads@ietf.org > Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; i2rs@ietf.or= g > Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 >=20 > On 5/10/16 18:04, Les Ginsberg (ginsberg) wrote: > > Joe - > > > > Apologies for the delayed response. I am a victim of my own email > > infilters. :-( Inline. >=20 > Thanks, Les. Have a look at > https://www.marcuscom.com/draft-ietf-i2rs-traceability.txt-from-09- > 10.diff.html > . I added a new line to show the flow in both directions. >=20 > Joe >=20 > > > >> -----Original Message----- > >> From: Joe Clarke (jclarke) > >> Sent: Friday, April 29, 2016 10:44 AM > >> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org > >> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; > >> i2rs@ietf.org > >> Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 > >> > >> On 4/27/16 17:39, Les Ginsberg (ginsberg) wrote: > >>> Summary: This document is a well written document - easy to > understand. > >>> My compliments to the authors. I believe there is one minor issue > >>> which I would like to see addressed before publication. > >> > >> Thanks for your comments and feedback, Les. Please see below for > >> some replies and questions. > >> > >>> In Section 5.2 there is a definition of the information which is > >>> required to be kept by an I2RS Agent for each I2RS interaction. I > >>> would like to see the addition of "Request State" into this list. > >>> Operationally each request could be in one of the following states: > >>> > >>> > >>> > >>> * Enqueued (or pending if you prefer) > >>> > >>> * In process > >>> > >>> * Completed > >>> > >>> > >>> > >>> The lack of such a state seems to imply that both the queue time and > >>> the processing time are insignificant. While I think this may be the > >>> case for many requests, it will not always be the case. In queue > >>> time may be lengthy due to other load on the Agent. Also, some > >>> requests - particularly destructive requests which involve cleanup > >>> of resources - may take a significant amount of time to complete. > >> > >> Good observation. Traceability was aimed mainly at the termination > >> of the request, but I like the idea of tracing the state machine. > >> > >>> > >>> > >>> > >>> Along with this an additional timestamp - Processing Initiated - > >>> would be useful to indicate when processing of the request actually > began. > >> > >> I don't know we need a new timestamp. Perhaps we just need to > rename > >> "Request Timestamp" and "Result Timestamp" to "Start Timestamp" and > >> "End Timestamp" to denote the time within the current state. What do > >> you think? > > > > [Les:] My intent was to log the time at which the request began process= ing > so that you can see whether a long delay in completion was due to enqueue > delay or actual lengthy processing time. I am not adamant about this so i= f you > want to stay with the two timestamps that is OK. > > > >> > >>> s/Some notable elements on the architecture/ Some notable elements > >>> of the architecture > >> > >> Fixed. Thanks! > >> > >>> > >>> > >>> > >>> Figure 1 > >>> > >>> > >>> > >>> Not clear to me why Application IDs start at 0 but Client IDs start a= t 1. > >> > >> Ah. The numbers there are not IDs. They are the number of actual > >> things in the boxes above. For Applications, there may be 0 to N for > >> a given client. For Clients, you need at least 1. Does that make sen= se? > >> > > [Les:] Maybe you want to use "shadows" on the boxes to indicate there > can be multiple Application boxes and multiple Client boxes? > > What you say makes sense but I do not intuit that when I look at the AS= SCII > art. > > > >>> > >>> > >>> > >>> Figure 1 > >>> > >>> > >>> > >>> Is the text "Op Data V" between I2RS Agent box and Routing System > >>> box intentional? > >> > >> Yes. The 'V' is meant to be an arrow head pointed down. The request > >> and data go from Client to Agent whereas the Response goes from Agent > >> to Client. > >> > >> We are open to suggestions on how to make this clearer. > > > > [Les:] I think it would be clearer if you had two lines - one flowing d= own > associated with the Op Data and one flowing up with the result. > > > >> > >>> > >>> > >>> > >>> Section 5.2 > >>> > >>> > >>> > >>> Secondary Identity > >>> > >>> > >>> > >>> This is defined to be "opaque" yet if not provided the agent is > >>> supposed to insert "an UNAVAILABLE value". This seems to be a > >>> contradiction unless we have a publicly defined value that clients > >>> are prohibited from using. Absent that you would need a "Secondary > Identity Valid" indicator. > >> > >> Good observation. I think it's fine to say that this field must be > >> logged. If there is no application, then the field will be logged as > >> empty. If there is an application, then whatever value is provided > >> will be logged. > >> > >> Do you feel strongly that we need a field to indicate Application Pres= ent? > >> > > [Les:] I am fine w your changes. > > > > Les > > > >>> > >>> > >>> > >>> Section 7.4 > >>> > >>> > >>> > >>> s/establish an vendor-agnostic/establish a vendor-agnostic > >> > >> Fixed. Thanks! > >> > >> Joe From nobody Wed May 11 15:21:25 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B75B12D593; Wed, 11 May 2016 15:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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.996, 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 RyI9TxUTJFxJ; Wed, 11 May 2016 15:21:22 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD42012D521; Wed, 11 May 2016 15:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5767; q=dns/txt; s=iport; t=1463005281; x=1464214881; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=d2y/tUeJvte8NefVuXPFq0hD1EI5W1TMsyNghZz9tuI=; b=dqWh5EqN5lJ+0Vqz/M3XreL7kQsfazptNHwAr63R/PYcY9/JVzLaoiif qgl4YafvOH5ugicC3o3pSbkUgdp6JlBJO+4QDBZLIUYEoqChSb1AqUk/D 7bX12hkz0i9HFNd5yNKPZAu/jEk6Lf4EnaPWPkP715T3P1eYgpXhkbuFA 8=; X-IronPort-AV: E=Sophos;i="5.24,609,1454976000"; d="scan'208";a="272403085" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 May 2016 22:21:00 +0000 Received: from [10.118.87.83] (rtp-jclarke-nitro2.cisco.com [10.118.87.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4BML0YX008578; Wed, 11 May 2016 22:21:00 GMT To: "Les Ginsberg (ginsberg)" , "rtg-ads@ietf.org" References: <5afaa922862d4b4a9dc67f117ae5366a@XCH-ALN-001.cisco.com> <978721df-6b95-dff7-af53-31d42a731946@cisco.com> <6dde8ef61dbf4faa98387fee01516dc3@XCH-ALN-001.cisco.com> From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <26dfa4d7-dd81-de1f-57b7-ae6fa9641fb5@cisco.com> Date: Wed, 11 May 2016 18:20:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <6dde8ef61dbf4faa98387fee01516dc3@XCH-ALN-001.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-i2rs-traceability@ietf.org" , "i2rs@ietf.org" Subject: Re: [RTG-DIR] [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 22:21:24 -0000 On 5/11/16 17:39, Les Ginsberg (ginsberg) wrote: > Joe - > > Yes - this looks better to me. > > What about the "shadow boxes" for Applications/Clients? Do you have an example draft I could look at for that? Joe > > Les > > >> -----Original Message----- >> From: Joe Clarke (jclarke) >> Sent: Wednesday, May 11, 2016 8:19 AM >> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org >> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; i2rs@ietf.org >> Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 >> >> On 5/10/16 18:04, Les Ginsberg (ginsberg) wrote: >>> Joe - >>> >>> Apologies for the delayed response. I am a victim of my own email >>> infilters. :-( Inline. >> >> Thanks, Les. Have a look at >> https://www.marcuscom.com/draft-ietf-i2rs-traceability.txt-from-09- >> 10.diff.html >> . I added a new line to show the flow in both directions. >> >> Joe >> >>> >>>> -----Original Message----- >>>> From: Joe Clarke (jclarke) >>>> Sent: Friday, April 29, 2016 10:44 AM >>>> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org >>>> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; >>>> i2rs@ietf.org >>>> Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 >>>> >>>> On 4/27/16 17:39, Les Ginsberg (ginsberg) wrote: >>>>> Summary: This document is a well written document - easy to >> understand. >>>>> My compliments to the authors. I believe there is one minor issue >>>>> which I would like to see addressed before publication. >>>> >>>> Thanks for your comments and feedback, Les. Please see below for >>>> some replies and questions. >>>> >>>>> In Section 5.2 there is a definition of the information which is >>>>> required to be kept by an I2RS Agent for each I2RS interaction. I >>>>> would like to see the addition of "Request State" into this list. >>>>> Operationally each request could be in one of the following states: >>>>> >>>>> >>>>> >>>>> * Enqueued (or pending if you prefer) >>>>> >>>>> * In process >>>>> >>>>> * Completed >>>>> >>>>> >>>>> >>>>> The lack of such a state seems to imply that both the queue time and >>>>> the processing time are insignificant. While I think this may be the >>>>> case for many requests, it will not always be the case. In queue >>>>> time may be lengthy due to other load on the Agent. Also, some >>>>> requests - particularly destructive requests which involve cleanup >>>>> of resources - may take a significant amount of time to complete. >>>> >>>> Good observation. Traceability was aimed mainly at the termination >>>> of the request, but I like the idea of tracing the state machine. >>>> >>>>> >>>>> >>>>> >>>>> Along with this an additional timestamp - Processing Initiated - >>>>> would be useful to indicate when processing of the request actually >> began. >>>> >>>> I don't know we need a new timestamp. Perhaps we just need to >> rename >>>> "Request Timestamp" and "Result Timestamp" to "Start Timestamp" and >>>> "End Timestamp" to denote the time within the current state. What do >>>> you think? >>> >>> [Les:] My intent was to log the time at which the request began processing >> so that you can see whether a long delay in completion was due to enqueue >> delay or actual lengthy processing time. I am not adamant about this so if you >> want to stay with the two timestamps that is OK. >>> >>>> >>>>> s/Some notable elements on the architecture/ Some notable elements >>>>> of the architecture >>>> >>>> Fixed. Thanks! >>>> >>>>> >>>>> >>>>> >>>>> Figure 1 >>>>> >>>>> >>>>> >>>>> Not clear to me why Application IDs start at 0 but Client IDs start at 1. >>>> >>>> Ah. The numbers there are not IDs. They are the number of actual >>>> things in the boxes above. For Applications, there may be 0 to N for >>>> a given client. For Clients, you need at least 1. Does that make sense? >>>> >>> [Les:] Maybe you want to use "shadows" on the boxes to indicate there >> can be multiple Application boxes and multiple Client boxes? >>> What you say makes sense but I do not intuit that when I look at the ASSCII >> art. >>> >>>>> >>>>> >>>>> >>>>> Figure 1 >>>>> >>>>> >>>>> >>>>> Is the text "Op Data V" between I2RS Agent box and Routing System >>>>> box intentional? >>>> >>>> Yes. The 'V' is meant to be an arrow head pointed down. The request >>>> and data go from Client to Agent whereas the Response goes from Agent >>>> to Client. >>>> >>>> We are open to suggestions on how to make this clearer. >>> >>> [Les:] I think it would be clearer if you had two lines - one flowing down >> associated with the Op Data and one flowing up with the result. >>> >>>> >>>>> >>>>> >>>>> >>>>> Section 5.2 >>>>> >>>>> >>>>> >>>>> Secondary Identity >>>>> >>>>> >>>>> >>>>> This is defined to be "opaque" yet if not provided the agent is >>>>> supposed to insert "an UNAVAILABLE value". This seems to be a >>>>> contradiction unless we have a publicly defined value that clients >>>>> are prohibited from using. Absent that you would need a "Secondary >> Identity Valid" indicator. >>>> >>>> Good observation. I think it's fine to say that this field must be >>>> logged. If there is no application, then the field will be logged as >>>> empty. If there is an application, then whatever value is provided >>>> will be logged. >>>> >>>> Do you feel strongly that we need a field to indicate Application Present? >>>> >>> [Les:] I am fine w your changes. >>> >>> Les >>> >>>>> >>>>> >>>>> >>>>> Section 7.4 >>>>> >>>>> >>>>> >>>>> s/establish an vendor-agnostic/establish a vendor-agnostic >>>> >>>> Fixed. Thanks! >>>> >>>> Joe > From nobody Thu May 12 09:37:44 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2418512D676; Thu, 12 May 2016 09:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.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, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 tiUysa6uQaSt; Thu, 12 May 2016 09:37:38 -0700 (PDT) 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 4F44F12D0AF; Thu, 12 May 2016 09:37:38 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id x19so128522339oix.2; Thu, 12 May 2016 09:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=gsn7cnJM/Lwu7OrHTQrNBvSSK766kUyo/hSp6EENSt4=; b=YFSNl8MUkCdZpSxYLNWF3qWn52L/rwfcw2dXOFx46hCkL6E9oHwMAwqVhRU6NFrHo+ 2hx/B89+G2BGsJO/P2i2A2rrXSm5N6cDPccllFAN72xWX/uLSEON7UvGmFmTwWGLjXa/ 7TpXQQeG4PbZ8oow0do1qvZ0cYA4Ub4QC6keOyA33Un+ajg5CXTuzp83c1YbJG0VVs5j QJQVgkkSHWe9K3EDeb2HQlyCkmYS+gSnTyOtfO0fBc5eDFc/IVPRBxLMLV+F4crsU4Vl oV1Au79+s83mVyU61IMupK8cbUBHx1UBQyPnW3ojoVjoeNG8SSwE2NU2CmB3wktwIGxS t8wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=gsn7cnJM/Lwu7OrHTQrNBvSSK766kUyo/hSp6EENSt4=; b=XTthDG8LKaR5rgJW9QrH2tyioBG7qUPA52K60jUcP2pywyJm0WVzbJqTgkxkvE0eCI Xuu1FY6v7pyR3E1wiePkYA7OxKRrnyTFK4wb/Q4disTTrHsdh5lDqBx1ee5m5bCe0Xt3 Id3qqP0q0irFAwm2cUnBQDG6ribPhLqHf5vAbfn89vlfNBePDc2KqC5jfsq7snxN1rjO vf74AYFU4LDN9WtifmrPIm/g5wap8fITS9mPNkhwuRKIhHJsNmG6eFT/uXXfHiztGqTF zJioSHQ/lcNghiLHuxFt4g9n9zKJpZFz4+3sfnCX31dE+7GKaRX8XfYU1ZawfWYIw3Bk ng3w== X-Gm-Message-State: AOPr4FUz2FxMWk3394caKxvrggfs0fNrmvVDgaNOgAnTHQPU2HEQMhcicKIFTioBHY82xAAnlZqz6pR8DpScBg== MIME-Version: 1.0 X-Received: by 10.202.224.138 with SMTP id x132mr5267097oig.28.1463071057612; Thu, 12 May 2016 09:37:37 -0700 (PDT) Received: by 10.60.118.39 with HTTP; Thu, 12 May 2016 09:37:37 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 May 2016 12:37:37 -0400 Message-ID: From: Alia Atlas To: Donald Eastlake Content-Type: multipart/alternative; boundary=001a113d306aab99740532a7c614 Archived-At: Cc: Jonathan Hardwick , " \(rtg-ads@ietf.org\)" , "trill@ietf.org" , "draft-ietf-trill-channel-tunnel@ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] Routing directorate review of draft-ietf-trill-channel-tunnel X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 16:37:42 -0000 --001a113d306aab99740532a7c614 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jonathan, Thank you very much for your review and for following up with Donald to resolve the concerns. Donald, Thanks for resolving these quickly. Regards, Alia On Wed, May 4, 2016 at 11:57 AM, Donald Eastlake wrote: > Hi Jonathan, > > Thanks for agreeing that the suggested changes resolve our comments. I > think they are pretty much editorial/clarification so I'll go ahead and > post a revision incorporating them. > > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > On Wed, May 4, 2016 at 7:29 AM, Jonathan Hardwick < > Jonathan.Hardwick@metaswitch.com> wrote: > >> Hi Donald, >> >> Thanks for the replies - I agree with the changes you propose. Please >> see discussion below (look for [JEH]). >> >> Best regards >> Jon >> >> -----Original Message----- >> From: Donald Eastlake [mailto:d3e3e3@gmail.com] >> Sent: 01 May 2016 21:46 >> To: Jonathan Hardwick >> Cc: (rtg-ads@ietf.org) ; >> akatlas@gmail.com; rtg-dir@ietf.org; >> draft-ietf-trill-channel-tunnel@ietf.org; trill@ietf.org >> Subject: Re: Routing directorate review of draft-ietf-trill-channel-tunn= el >> >> On Thu, Apr 28, 2016 at 9:26 AM, Jonathan Hardwick < >> Jonathan.Hardwick@metaswitch.com> wrote: >> > Hello, >> > >> > I have been selected as the Routing Directorate reviewer for this >> > draft. The Routing Directorate seeks to review all routing or >> > 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 >> > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >> > >> > Although these comments are primarily for the use of the Routing ADs, >> > it would be helpful if you could consider them along with any other >> > IETF Last Call comments that you receive, and strive to resolve them >> > through discussion or by updating the draft. >> > >> > Best regards >> > Jon >> > =3D=3D=3D >> > >> > Document: draft-ietf-trill-channel-tunnel >> > Reviewer: Jon Hardwick >> > Review Date: 28 April 2016 >> > Intended Status: Standards Track >> > >> > >> > Summary >> > >> > I have some concerns about this document and recommend that the >> > Routing ADs discuss these issues further with the authors. >> > >> > >> > Comments >> > >> > The draft is overall well written and the specification is quite easy >> > to understand, >> >> Thanks. >> >> > but I found some of the terminology and rationale >> > to be confusing. I would prefer to see this clarified before the >> > document is published as RFC. Note that this is the first TRILL >> > document I=E2=80=99ve reviewed, so my context comes largely from maili= ng list >> > searches and the shepherd=E2=80=99s report. >> > >> > >> > Major Comments >> > >> > The motivations for this draft are quite obscure from the perspective >> > of the outsider J which makes it hard for me to evaluate the proposed >> > mechanism. >> > >> > I think the problems that the draft solves should be more clearly >> > spelled out. From the introduction: >> > >> > This document updates [RFC7178] and specifies extensions to RBridge >> > Channel that provide two additional facilities as follows: >> > >> > (1) A standard method to tunnel a variety of payload types by >> > encapsulating them in an RBridge Channel message. >> > >> > (2) A method to provide security facilities for RBridge Channel >> > messages. >> > >> > I think that number (1) requires more explanation because the RBridge >> > channel already provides a standard method for a variety of payload >> > types to be transmitted without needing the current draft. >> > What tunneling capability is this draft adding? >> >> Good point. >> >> The RBridge Channel facility does provide a "protocol number" which is, >> in essence, the "type" of its payload. However, there are three limitati= ons >> of RBridge Channel: (1) No security; (2) No way to leverage the many >> existing defined Ethertypes as a payload type; and >> >> [JEH] OK, now I understand (2), thank you. I thought maybe you'd >> allocate Chanel protocol numbers to match Ethertypes as needed, though I >> now see that this would be quite tedious process-wise (not to mention th= at >> Ethertype has 4 additional bits). [/JEH] >> >> (3) RBridge Channel can only send typed messages either (3a) between >> RBridges in a campus and (3b) between end stations and RBridges on the s= ame >> link. Earlier versions of this draft included mechanisms extensions in a= rea >> 3, for example, for sending RBridge Channel messages between end station= s >> and RBridges not on the same link; however, this added significant >> complexity and there appears to be no current need for such extensions s= o >> they were dropped, leaving only extensions in areas 1 and 2. >> >> [JEH] OK. Number 3 does sound a bit more like tunnelling than 1 or 2. >> Helps to have the history, thanks. [/JEH] >> >> How about the following change on additional facility 1 in the draft: >> >> OLD >> (1) A standard method to tunnel a variety of payload types by >> encapsulating them in an RBridge Channel message. >> NEW >> (1) A standard method to tunnel payloads whose type may be >> indicated by Ethertype through encapsulation in RBridge >> Channel messages. >> >> [JEH] Yes, looks good. [/JEH] >> >> > A significant amount of text in the draft discusses number (2), which >> > secures the channel payload, presumably to cover cases where the >> > payload has no in-built security mechanism. This appears to be the >> > major purpose of the draft. The draft achieves number (2) by adding a >> > security shim header between the RBridge channel header and the >> > payload. One consideration in doing this is to remain backwards >> > compatible with RFC 7178, and it looks like the working group has >> > decided to achieve backwards compatibility by defining a new RBridge >> > channel protocol type called =E2=80=9Cchannel tunnel=E2=80=9D =E2=80= =93 where this effectively >> > means the RBridge channel payload contains an additional security shim >> > which in turn contains an identifier that determines the real payload >> > protocol type. >> > >> > I find the term =E2=80=9Cchannel tunnel=E2=80=9D misleading, as the dr= aft does not >> > appear to add any additional tunnelling capability above and beyond >> > the tunnelling that can already be done using RFC 7178. The draft >> > actually describes an RBridge channel with enhanced security, so a >> > term like =E2=80=9Csecure channel=E2=80=9D would make more sense to me= than =E2=80=9Cchannel >> > tunnel=E2=80=9D. >> >> OK, I understand why you think that term is misleading. While it seems >> quite reasonable to called the added fields a "shim", note that the >> facility currently called "Channel Tunnel" is quite closely integrated w= ith >> the existing RFC 7178 RBridge Channel facility. For example, there is on= ly >> one error reporting mechanism. Errors in the "Channel Tunnel" facility >> added by this draft are reported as if they were errors in the RBridge >> Channel messages to which the "shim" was added. >> >> I don't actually like your suggestion of "secure channel" as a new name. >> How about re-naming the facility being added by this draft as the "RBrid= ge >> Channel Header Extension"? >> >> [JEH] OK, I like RBridge Channel Header Extension. [/JEH] >> >> I believe that RFC 7783 and only that RFC that references this draft >> using the term "Channel Tunnel" but this is a very minor informational >> passing reference. There are drafts in the publication requested state t= hat >> reference this draft using the term "Channel Tunnel" but it seems that i= t >> would be relatively straightforward to change the name to "RBridge Chann= el >> Header Extension" or some other new name in those drafts and even easier= to >> change it in drafts still under the control of the TRILL WG. >> >> [JEH] Thanks, this works for me. [/JEH] >> >> > Minor Comments >> > >> > Section 3.1 =E2=80=93 =E2=80=9CAny particular use of the Null Payload = should specify >> > what VLAN or priority should be used when relevant.=E2=80=9D =E2=80=93= is unclear and >> > no context for this statement is given. Should be used by what and >> > for what purpose? >> >> OK. How about: >> >> Any particular use of the Null Payload should specify what VLAN or >> FGL and what priority should be used in the inner data label of the >> RBridge Channel message (or in an outer VLAN tag for the native >> RBridge Channel message case) when those values are relevant. >> >> [JEH] Fine [/JEH] >> >> > Section 4.3 feels like a corollary to section 4.5 and so may be better >> > placed as a subsection of 4.5. >> >> The method of deriving keying material given in Section 4.3 is also used >> in DTLS security as mentioned in Section 4.6 so I think it should remain= a >> separate section. >> >> [JEH] OK [/JEH] >> >> > Section 4.6 =E2=80=9CThe PType indicates the nature of the application= _data.=E2=80=9D >> > - is potentially open to misinterpretation. At face value it sounds >> > like you are leaking some potentially sensitive information about the >> > =E2=80=9Cnature=E2=80=9D of the encrypted payload. I think all you ar= e actually >> > saying is that it indicates whether the payload is an Ethertype, an >> > Ethernet frame etc. Suggest instead =E2=80=9CIn this case, the PType = value in >> > the RBridge Channel Tunnel Protocol Specific Data applies to the >> > decrypted application_data.=E2=80=9D >> >> OK. >> >> > Section 5.2 =E2=80=9Cwith a payload type (PType) indicating a nested R= Bridge >> > Channel message=E2=80=9D =E2=80=93 strictly all the PType can indicate= is that the >> > payload is Ethertyped; on its own it cannot indicate a nested RBridge >> > Chanel message. Suggest =E2=80=9Cand it contains a nested RBridge Cha= nel >> > message=E2=80=9D. >> >> OK. >> >> > Section 6.2 >> > >> > =E2=80=9CSection xxx of [RFC 7178]=E2=80=9D should be =E2=80=9CSection= 3.2 of [RFC 7178]=E2=80=9D. >> >> Right. Sorry about that. >> >> > Don=E2=80=99t you also need a new IANA registry for the =E2=80=9CRbrid= ge Channel Error >> > Subcodes=E2=80=9D listed in table 5.2? >> >> My opinion is that, for the first document in which you specify a field >> and some values, it is a judgment call whether you should create an IANA >> registry or not. If you expect multiple groups to start requesting valu= es >> to multiple purposes, then creating a registry from the start is the way= to >> go. On the other hand, if a field is internal to a particular protocol a= nd >> you don't expect any new field values to be assigned until there is a >> significant extension of that protocol, I don't see any problem in >> deferring the registry creation to the second document. This is the seco= nd >> document assigning values for RBridge Channel Error Codes so it creates = a >> registry for them. It does not create a registry for SubERR field values= . >> >> [JEH] OK, just checking, and happy to defer to your judgment here. [/JEH= ] >> >> > Nits >> > >> > Section 3.2 >> > >> > =E2=80=9Cas describe in=E2=80=9D -> =E2=80=9Cas described in=E2=80=9D >> >> OK. >> >> > Section 4 >> > >> > =E2=80=9Cnot to met=E2=80=9D -> =E2=80=9Cnot to meet=E2=80=9D >> >> OK. >> >> > 2nd paragraph =E2=80=93 this sentence is quite long and hard to parse. >> >> You're right. Looking at the sentence, it seems fairly easy to simplify >> and split into two sentences. How about the following >> replacement: >> >> The Channel Tunnel DTLS based security specified in Section 4.6 >> below is intended for pairwise (known unicast) use. That is, the >> case where the M bit in the TRILL Header is zero and any >> Outer.MacDA is individually addressed. >> >> [JEH] Looks good. [/JEH] >> >> > Section 4.2 & Section 5.1 >> > >> > =E2=80=9CAs show in=E2=80=9D - > =E2=80=9CAs shown in=E2=80=9D >> >> OK. >> >> > Section 4.3 >> > >> > =E2=80=9CThe use Derived Material=E2=80=9D -> =E2=80=9CThe use of the = Derived Material=E2=80=9D >> >> OK. >> >> > Does Derived Material really need to be capitalized in this section? >> >> Well, it is capitalized in the equation. Seems to me reasonable to >> capitalize in both cases to indicate that a specific type of Derived >> Material is being talked about. >> >> [JEH] OK. [/JEH] >> >> > Section 4.5 >> > >> > =E2=80=9Ccan reasonable be=E2=80=9D -> =E2=80=9Ccan reasonably be=E2= =80=9D >> >> OK. >> >> > Section 4.6 >> > >> > =E2=80=9Cminimum MTU Sz=E2=80=9D -> =E2=80=9Cminimum MTU size=E2=80=9D >> >> Sz is a standard TRILL symbol widely used in TRILL documents and defined >> in Section 1.1 of this draft. I would prefer to make the following chang= e >> in Section 4.6: "the TRILL campus wide minimum MTU Sz" -> "Sz". >> >> [JEH] OK - sorry, I missed the definition! [/JEH] >> >> > =E2=80=9CActual application_data sent with Channel Tunnel=E2=80=9D -> = =E2=80=9CActual >> > application_data sent within the Channel Tunnel=E2=80=9D >> >> OK. >> >> > Why do you say =E2=80=9Capplication_data=E2=80=9D not =E2=80=9Capplica= tion data=E2=80=9D? >> >> "application_data" is the name of the field type in DTLS. >> >> [JEH] OK. [/JEH] >> >> > Appendix Z should presumably be removed prior to IETF last call. >> >> While I'm not sure how much help it would be to IESG members or IETF >> participants in reviewing the draft, I don't see any reason for Appendix= Z >> to be removed until RFC publication. But at least a notation asked the R= FC >> Editor to delete it should be added. >> >> [JEH] OK - please add the RFC editor note. [/JEH] >> >> Thanks, >> Donald >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com >> > > --001a113d306aab99740532a7c614 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jonathan,

Thank you very much for your = review and for following up with Donald to resolve the concerns.
=
Donald,

Thanks for resolving these = quickly.

Regards,
Alia

On Wed, May 4, 2016 at = 11:57 AM, Donald Eastlake <d3e3e3@gmail.com> wrote:
Hi Jonathan,

T= hanks for agreeing that the suggested changes resolve our comments.=C2=A0 I= think they are pretty much editorial/clarification so I'll go ahead an= d post a revision incorporating them.

Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2= =A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A0155 Be= aver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com

On Wed, May 4, 2016 at 7:29 AM, Jonathan Har= dwick <Jonathan.Hardwick@metaswitch.com> wrot= e:
Hi Donald,

Thanks for the replies - I agree with the changes you propose.=C2=A0 Please= see discussion below (look for [JEH]).

Best regards
Jon

-----Original Message-----
From: Donald Eastlake [mailto:d3e3e3@gmail.com]
Sent: 01 May 2016 21:46
To: Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>
Cc: <rtg-ads@ietf.= org> (rtg-ads@= ietf.org) <rtg= -ads@ietf.org>; akatlas@gmail.com; rtg-dir@ietf.org; draft-ietf-trill-channel-tunnel@ietf.org;= trill@ietf.org
Subject: Re: Routing directorate review of draft-ietf-trill-channel-tunnel<= br>
On Thu, Apr 28, 2016 at 9:26 AM, Jonathan Hardwick <Jonathan.Hardwick@metaswi= tch.com> wrote:
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this
> draft. The Routing Directorate seeks to review all routing or
> 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
> http://trac.tools.ietf.org/area/rtg/trac/= wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs,<= br> > it would be helpful if you could consider them along with any other > IETF Last Call comments that you receive, and strive to resolve them > through discussion or by updating the draft.
>
> Best regards
> Jon
> =3D=3D=3D
>
> Document: draft-ietf-trill-channel-tunnel
> Reviewer: Jon Hardwick
> Review Date: 28 April 2016
> Intended Status: Standards Track
>
>
> Summary
>
> I have some concerns about this document and recommend that the
> Routing ADs discuss these issues further with the authors.
>
>
> Comments
>
> The draft is overall well written and the specification is quite easy<= br> > to understand,

Thanks.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 but I found some of the terminology and rationale
> to be confusing.=C2=A0 I would prefer to see this clarified before the=
> document is published as RFC.=C2=A0 Note that this is the first TRILL<= br> > document I=E2=80=99ve reviewed, so my context comes largely from maili= ng list
> searches and the shepherd=E2=80=99s report.
>
>
> Major Comments
>
> The motivations for this draft are quite obscure from the perspective<= br> > of the outsider J which makes it hard for me to evaluate the proposed<= br> > mechanism.
>
> I think the problems that the draft solves should be more clearly
> spelled out.=C2=A0 From the introduction:
>
>=C2=A0 =C2=A0 This document updates [RFC7178] and specifies extensions = to RBridge
>=C2=A0 =C2=A0 Channel that provide two additional facilities as follows= :
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(1) A standard method to tunnel a variety of= payload types by
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0encapsulating them in an RBrid= ge Channel message.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(2) A method to provide security facilities = for RBridge Channel
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0messages.
>
> I think that number (1) requires more explanation because the RBridge<= br> > channel already provides a standard method for a variety of payload > types to be transmitted without needing the current draft.
> What tunneling capability is this draft adding?

Good point.

The RBridge Channel facility does provide a "protocol number" whi= ch is, in essence, the "type" of its payload. However, there are = three limitations of RBridge Channel: (1) No security; (2) No way to levera= ge the many existing defined Ethertypes as a payload type; and

[JEH] OK, now I understand (2), thank you.=C2=A0 I thought mayb= e you'd allocate Chanel protocol numbers to match Ethertypes as needed,= though I now see that this would be quite tedious process-wise (not to men= tion that Ethertype has 4 additional bits). [/JEH]

(3) RBridge Channel can only send typed messages either (3a) between RBridg= es in a campus and (3b) between end stations and RBridges on the same link.= Earlier versions of this draft included mechanisms extensions in area 3, f= or example, for sending RBridge Channel messages between end stations and R= Bridges not on the same link; however, this added significant complexity an= d there appears to be no current need for such extensions so they were drop= ped, leaving only extensions in areas 1 and 2.

[JEH] OK.=C2=A0 Number 3 does sound a bit more like tunnelling than = 1 or 2.=C2=A0 Helps to have the history, thanks. [/JEH]

How about the following change on additional facility 1 in the draft:

OLD
=C2=A0 =C2=A0 =C2=A0 (1) A standard method to tunnel a variety of payload t= ypes by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 encapsulating them in an RBridge Channel= message.
NEW
=C2=A0 =C2=A0 =C2=A0 (1) A standard method to tunnel payloads whose type ma= y be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 indicated by Ethertype through encapsula= tion in RBridge=C2=A0 Channel messages.

[JEH] Yes, looks good. [/JEH]

> A significant amount of text in the draft discusses number (2), which<= br> > secures the channel payload, presumably to cover cases where the
> payload has no in-built security mechanism.=C2=A0 This appears to be t= he
> major purpose of the draft.=C2=A0 The draft achieves number (2) by add= ing a
> security shim header between the RBridge channel header and the
> payload.=C2=A0 One consideration in doing this is to remain backwards<= br> > compatible with RFC 7178, and it looks like the working group has
> decided to achieve backwards compatibility by defining a new RBridge > channel protocol type called =E2=80=9Cchannel tunnel=E2=80=9D =E2=80= =93 where this effectively
> means the RBridge channel payload contains an additional security shim=
> which in turn contains an identifier that determines the real payload<= br> > protocol type.
>
> I find the term =E2=80=9Cchannel tunnel=E2=80=9D misleading, as the dr= aft does not
> appear to add any additional tunnelling capability above and beyond > the tunnelling that can already be done using RFC 7178.=C2=A0 The draf= t
> actually describes an RBridge channel with enhanced security, so a
> term like =E2=80=9Csecure channel=E2=80=9D would make more sense to me= than =E2=80=9Cchannel
> tunnel=E2=80=9D.

OK, I understand why you think that term is misleading. While it seems quit= e reasonable to called the added fields a "shim", note that the f= acility currently called "Channel Tunnel" is quite closely integr= ated with the existing RFC 7178 RBridge Channel facility. For example, ther= e is only one error reporting mechanism. Errors in the "Channel Tunnel= " facility added by this draft are reported as if they were errors in = the RBridge Channel messages to which the "shim" was added.

I don't actually like your suggestion of "secure channel" as = a new name.=C2=A0 How about re-naming the facility being added by this draf= t as the "RBridge Channel Header Extension"?

[JEH] OK, I like RBridge Channel Header Extension. [/JEH]

I believe that RFC 7783 and only that RFC that references this draft using = the term "Channel Tunnel" but this is a very minor informational = passing reference. There are drafts in the publication requested state that= reference this draft using the term "Channel Tunnel" but it seem= s that it would be relatively straightforward to change the name to "R= Bridge Channel Header Extension" or some other new name in those draft= s and even easier to change it in drafts still under the control of the TRI= LL WG.

[JEH] Thanks, this works for me. [/JEH]

> Minor Comments
>
> Section 3.1 =E2=80=93 =E2=80=9CAny particular use of the Null Payload = should specify
> what VLAN or priority should be used when relevant.=E2=80=9D =E2=80=93= is unclear and
> no context for this statement is given.=C2=A0 Should be used by what a= nd
> for what purpose?

OK. How about:

=C2=A0 =C2=A0Any particular use of the Null Payload should specify what VLA= N or
=C2=A0 =C2=A0FGL and what priority should be used in the inner data label o= f the
=C2=A0 =C2=A0RBridge Channel message (or in an outer VLAN tag for the nativ= e
=C2=A0 =C2=A0RBridge Channel message case) when those values are relevant.<= br>
[JEH] Fine [/JEH]

> Section 4.3 feels like a corollary to section 4.5 and so may be better=
> placed as a subsection of 4.5.

The method of deriving keying material given in Section 4.3 is also used in= DTLS security as mentioned in Section 4.6 so I think it should remain a se= parate section.

[JEH] OK [/JEH]

> Section 4.6 =E2=80=9CThe PType indicates the nature of the application= _data.=E2=80=9D
> - is potentially open to misinterpretation.=C2=A0 At face value it sou= nds
> like you are leaking some potentially sensitive information about the<= br> > =E2=80=9Cnature=E2=80=9D of the encrypted payload.=C2=A0 I think all y= ou are actually
> saying is that it indicates whether the payload is an Ethertype, an > Ethernet frame etc.=C2=A0 Suggest instead =E2=80=9CIn this case, the P= Type value in
> the RBridge Channel Tunnel Protocol Specific Data applies to the
> decrypted application_data.=E2=80=9D

OK.

> Section 5.2 =E2=80=9Cwith a payload type (PType) indicating a nested R= Bridge
> Channel message=E2=80=9D =E2=80=93 strictly all the PType can indicate= is that the
> payload is Ethertyped; on its own it cannot indicate a nested RBridge<= br> > Chanel message.=C2=A0 Suggest =E2=80=9Cand it contains a nested RBridg= e Chanel
> message=E2=80=9D.

OK.

> Section 6.2
>
> =E2=80=9CSection xxx of [RFC 7178]=E2=80=9D should be =E2=80=9CSection= 3.2 of [RFC 7178]=E2=80=9D.

Right. Sorry about that.

> Don=E2=80=99t you also need a new IANA registry for the =E2=80=9CRbrid= ge Channel Error
> Subcodes=E2=80=9D listed in table 5.2?

My opinion is that, for the first document in which you specify a field and= some values, it is a judgment call whether you should create an IANA regis= try or not.=C2=A0 If you expect multiple groups to start requesting values = to multiple purposes, then creating a registry from the start is the way to= go. On the other hand, if a field is internal to a particular protocol and= you don't expect any new field values to be assigned until there is a = significant extension of that protocol, I don't see any problem in defe= rring the registry creation to the second document. This is the second docu= ment assigning values for RBridge Channel Error Codes so it creates a regis= try for them. It does not create a registry for SubERR field values.

[JEH] OK, just checking, and happy to defer to your judgment here. [= /JEH]

> Nits
>
> Section 3.2
>
> =E2=80=9Cas describe in=E2=80=9D -> =E2=80=9Cas described in=E2=80= =9D

OK.

> Section 4
>
> =E2=80=9Cnot to met=E2=80=9D -> =E2=80=9Cnot to meet=E2=80=9D

OK.

> 2nd paragraph =E2=80=93 this sentence is quite long and hard to parse.=

You're right. Looking at the sentence, it seems fairly easy to simplify= and split into two sentences. How about the following
replacement:

=C2=A0 =C2=A0The Channel Tunnel DTLS based security specified in Section 4.= 6
=C2=A0 =C2=A0below is intended for pairwise (known unicast) use. That is, t= he
=C2=A0 =C2=A0case where the M bit in the TRILL Header is zero and any
=C2=A0 =C2=A0Outer.MacDA is individually addressed.

[JEH] Looks good. [/JEH]

> Section 4.2 & Section 5.1
>
> =E2=80=9CAs show in=E2=80=9D - > =E2=80=9CAs shown in=E2=80=9D

OK.

> Section 4.3
>
> =E2=80=9CThe use Derived Material=E2=80=9D -> =E2=80=9CThe use of t= he Derived Material=E2=80=9D

OK.

> Does Derived Material really need to be capitalized in this section?
Well, it is capitalized in the equation. Seems to me reasonable to capitali= ze in both cases to indicate that a specific type of Derived Material is be= ing talked about.

[JEH] OK. [/JEH]

> Section 4.5
>
> =E2=80=9Ccan reasonable be=E2=80=9D -> =E2=80=9Ccan reasonably be= =E2=80=9D

OK.

> Section 4.6
>
> =E2=80=9Cminimum MTU Sz=E2=80=9D -> =E2=80=9Cminimum MTU size=E2=80= =9D

Sz is a standard TRILL symbol widely used in TRILL documents and defined in= Section 1.1 of this draft. I would prefer to make the following change in = Section 4.6: "the TRILL campus wide minimum MTU Sz" -> "S= z".

[JEH] OK - sorry, I missed the definition! [/JEH]

> =E2=80=9CActual application_data sent with Channel Tunnel=E2=80=9D -&g= t; =E2=80=9CActual
> application_data sent within the Channel Tunnel=E2=80=9D

OK.

> Why do you say =E2=80=9Capplication_data=E2=80=9D not =E2=80=9Capplica= tion data=E2=80=9D?

"application_data" is the name of the field type in DTLS.

[JEH] OK. [/JEH]

> Appendix Z should presumably be removed prior to IETF last call.

While I'm not sure how much help it would be to IESG members or IETF pa= rticipants in reviewing the draft, I don't see any reason for Appendix = Z to be removed until RFC publication. But at least a notation asked the RF= C Editor to delete it should be added.

[JEH] OK - please add the RFC editor note. [/JEH]

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd=C2=A0 =C2=A0+1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Milford, MA 01757 USA=C2=A0 d3e3e3@gmail.com


--001a113d306aab99740532a7c614-- From nobody Fri May 13 00:25:19 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA49212D0C8; Fri, 13 May 2016 00:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.206 X-Spam-Level: X-Spam-Status: No, score=-5.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, T_HTML_ATTACH=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 fQRxCJxz51z0; Fri, 13 May 2016 00:25:12 -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 C2E5C12D0F0; Fri, 13 May 2016 00:25:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id COO83103; Fri, 13 May 2016 07:25:07 +0000 (GMT) Received: from SZXEMA418-HUB.china.huawei.com (10.82.72.36) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 13 May 2016 08:25:05 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.171]) by SZXEMA418-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0235.001; Fri, 13 May 2016 15:24:58 +0800 From: Mach Chen To: Daniele Ceccarelli , " (rtg-ads@ietf.org)" Thread-Topic: RtgDir review: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06 Thread-Index: AdGe+Z/lFOzQc8O7SFSbqLe7ce8oewAG1OFwA2v05+AAAARS8A== Date: Fri, 13 May 2016 07:24:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.135] Content-Type: multipart/mixed; boundary="_002_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28C206D6FSZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.57358154.0025, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.171, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 593c4ad207c3471a05cac2e9b01da41e Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-pals-mpls-tp-pw-over-bidir-lsp.all@tools.ietf.org" , "pals@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 07:25:17 -0000 --_002_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28C206D6FSZXEMA510MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGFuaWVsZSwNCg0KVGhhbmtzIGZvciB0aGUgZGV0YWlsZWQgcmV2aWV3IGFuZCB2YWx1YWJs ZSBjb21tZW50cyENCg0KUGxlYXNlIHNlZSBteSByZXNwb25zZXMgaW5saW5lLi4uDQoNCkkgYWxz byBhdHRhY2hlZCBhIGRpZmYgdGhhdCBzaG93cyB0aGUgdXBkYXRlcyB0aGF0IHRyeSB0byBhZGRy ZXNzIHlvdXIgY29tbWVudHMuIElmIHlvdSBhcmUgT0sgd2l0aCB0aGUgdXBkYXRlcywgSSB3aWxs IHN1Ym1pdCBpdCB0aGVuLg0KDQpUaGFua3MsDQpNYWNoDQogDQo+IEZyb206IERhbmllbGUgQ2Vj Y2FyZWxsaQ0KPiBTZW50OiBsdW5lZMOsIDI1IGFwcmlsZSAyMDE2IDE5OjA0DQo+IFRvOiA8cnRn LWFkc0BpZXRmLm9yZz4gKHJ0Zy1hZHNAaWV0Zi5vcmcpDQo+IENjOiAncnRnLWRpckBpZXRmLm9y Zyc7ICdkcmFmdC1pZXRmLXBhbHMtbXBscy10cC1wdy1vdmVyLWJpZGlyLWxzcC5hbGxAaWV0Zi5v cmcnDQo+IFN1YmplY3Q6IFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtcGFscy1tcGxzLXRwLXB3 LW92ZXItYmlkaXItbHNwLTA2DQo+IA0KPiBIZWxsbywNCj4gSSBoYXZlIGJlZW4gc2VsZWN0ZWQg YXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZQ0K PiBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtzIHRvIHJldmlldyBhbGwgcm91dGluZyBvciByb3V0 aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkNCj4gcGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxs IGFuZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVlc3QuDQo+IFRo ZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBS b3V0aW5nIEFEcy4gRm9yDQo+IG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGly ZWN0b3JhdGUsIHBsZWFzZSBzZWXCoA0KPiBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVh L3J0Zy90cmFjL3dpa2kvUnRnRGlyDQo+IEFsdGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmlt YXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURzLCBpdCB3b3VsZA0KPiBiZSBoZWxw ZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90aGVyIElFVEYg TGFzdCBDYWxsDQo+IGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8gcmVz b2x2ZSB0aGVtIHRocm91Z2ggZGlzY3Vzc2lvbiBvciBieQ0KPiB1cGRhdGluZyB0aGUgZHJhZnQu DQo+IERvY3VtZW50OsKgZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtcHctb3Zlci1iaWRpci1sc3At MDYNCj4gUmV2aWV3ZXI6IERhbmllbGUgQ2VjY2FyZWxsaQ0KPiBSZXZpZXcgRGF0ZTogQXByaWwg MjUgMjAxNg0KPiBJRVRGIExDIEVuZCBEYXRlOiAtDQo+IEludGVuZGVkIFN0YXR1czogU3RhbmRh cmQgVHJhY2sNCj4gU3VtbWFyeToNCj4g4oCiIEkgaGF2ZSBzb21lIG1pbm9yIGNvbmNlcm5zIGFi b3V0IHRoaXMgZG9jdW1lbnQgdGhhdCBJIHRoaW5rIHNob3VsZCBiZQ0KPiByZXNvbHZlZCBiZWZv cmUgcHVibGljYXRpb24uDQo+IENvbW1lbnRzOg0KPiDigKIgV2hhdCB0aGUgZHJhZnRzIGlzIHBy b3Bvc2luZyBhcyBwcm90b2NvbCBtb2RpZmljYXRpb24gaXMgY2xlYXIgYW5kIGFsc28gdGhlDQo+ IG9wZXJhdGlvbiBzZWN0aW9uIGFyZSBwcmV0dHkgc3RyYWlnaGZvcndhcmQuIFdoYXQgbmVlZHMg dG8gYmUgaW1wcm92ZWQgaXMgdGhlDQo+IGludHJvZHVjdGlvbiBwYXJ0LCB3aGljaCBzaG91bGQg YmUgcmV2aWV3ZWQgYnkgYSBuYXRpdmUgRW5nbGlzaCBzcGVha2VyLiBBbHNvDQo+IHRoZSBJQU5B IHNlY3Rpb24gc2hvdWxkIGJlIG1hZGUgY2xlYXJlci4NCg0KVGhhbmtzIGZvciB5b3VyIHN1Z2dl c3Rpb24sIEkgYXNzdW1lIHRoZSBSRkMgZWRpdG9yIHdpbGwgZG8gYW5vdGhlciByZXZpZXcgb25j ZSB0aGUgZG9jdW1lbnQgcHJvZ3Jlc3NlZCB0byB0aGF0IHN0YWdlLiANCg0KPiBNYWpvciBJc3N1 ZXM6DQo+IOKAoiBObyBtYWpvciBpc3N1ZXMgZm91bmQNCj4gTWlub3IgSXNzdWVzOg0KPiDigKIg QWJzdHJhY3Q6IOKAnEluIGFkZGl0aW9uLCB0aGUgdXNlciB0cmFmZmljIG1heSB0cmF2ZXJzZSB0 aHJvdWdoIG11bHRpcGxlDQo+IHRyYW5zcG9ydCBuZXR3b3Jrcy7igJ0gTWF5YmUgaXMgd29ydGgg ZWxhYm9yYXRpbmcgYSBiaXQgdGhpcyBzZW50ZW5jZSBzYXlpbmcNCj4gdGhhdCB0aGUgZXh0ZW5z aW9ucyBkZWZpbmVkIGluIHRoaXMgZHJhZnQgYXBwbHkgYm90aCB0byBTUy1QVyBhbmQgTVMtUFcu DQoNCkhvdyBhYm91dCB0aGlzOg0KDQoiTWFueSB0cmFuc3BvcnQgc2VydmljZXMgcmVxdWlyZSB0 aGF0IHVzZXIgdHJhZmZpYywgaW4gdGhlIGZvcm0gb2YgUHNldWRvd2lyZXMgKFBXKSwgYmUgZGVs aXZlcmVkIG9uIGEgc2luZ2xlIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIHR1bm5lbCBvciB0d28g dHVubmVscyB0aGF0IHNoYXJlIHRoZSBzYW1lIHJvdXRlcy4gVGhpcyBkb2N1bWVudCBkZWZpbmVz IGFuIG9wdGlvbmFsIGV4dGVuc2lvbiB0byBMRFAgdGhhdCBlbmFibGVzIHRoZSBiaW5kaW5nIGJl dHdlZW4gUFdzIGFuZCB0aGUgdW5kZXJseWluZyBURSB0dW5uZWxzLiBUaGUgZXh0ZW5zaW9uIGFw cGxpZXMgdG8gYm90aCBTUy1QVyBhbmQgTVMtUFcuIg0KDQo+IOKAoiBJbiB0aGUgYWJzdHJhY3Qg aXQgaXMgc2FpZCB0aGF0IGEgUFcgaXMgbGlua2VkIHRvIGFuIExTUCBidXQgdGhlbiBpbiB0aGUg aW50cm8gaXQgaXMNCj4gc2FpZCB0aGF0IHRoZSBQVyBiaW5kaW5nIGlzIHRvIGEgdHVubmVsLiBD YW4geW91IGNsYXJpZnkgdGhpcz8gSeKAmWQgc2F5IHRoYXQgaXQNCj4gc2hvdWxkIGJlIGxpbmtl ZCB0byBhIHR1bm5lbCwgcmlnaHQ/DQoNClllcywgaXQncyBiZXR0ZXIgdG8gdXNlIHR1bm5lbCwg SSBoYXZlIHVwZGF0ZWQgdGhlIGFic3RyYWN0IHRvIG1ha2UgQWJzdHJhY3QgYW5kIEludHJvZHVj dGlvbiBoYXZlIHRoZSBjb25zaXN0ZW50IHVzYWdlLiBQbGVhc2Ugc2VlIGFib3ZlIHRoZSBuZXcg dGV4dCBmb3IgQWJzdHJhY3QuDQoNCj4g4oCiIEludHJvOsKgwqAg4oCcUFctdG8tUFNOIFR1bm5l bCBiaW5kaW5nIGhhcyBiZWNvbWUgaW5jcmVhc2luZ2x5IGNvbW1vbiBhbmQNCj4gaW1wb3J0YW50 IGluIG1hbnkgZGVwbG95bWVudCBzY2VuYXJpb3PigJ0uIEkgZ3Vlc3MgeW91IG1lYW4gYW4gYXV0 b21hdGljDQo+IGJpbmRpbmcgZG9uZSB2aWEgYSBzaWduYWxpbmcgcHJvdG9jb2w/DQoNCk5vLCB0 aGlzIHNlbnRlbmNlIGp1c3QgYnJpbmdzIHRoZSByZXF1aXJlbWVudHMgb2YgZXhwbGljaXQgUFcg dG8gUFNOIHR1bm5lbCBiaW5kaW5nLCB3aGF0ZXZlciBpdCBpcyBhdXRvbWF0aWMgc2lnbmFsaW5n IG9yIG1hbnVhbCBjb25maWd1cmF0aW9uLiANCg0KPiDigKIgV2hhdCBkbyB5b3UgbWVhbiB3aXRo IOKAnG1heSB0cmF2ZXJzZSB0aHJvdWdoIGRpZmZlcmVudCByb3V0ZXPigJ0/IEkgc3VnZ2VzdA0K PiBsZWF2aW5nIOKAnG1heSB0cmF2ZXJzZSBtdWx0aXBsZSBuZXR3b3JrcyBvciBkb21haW5zLg0K DQpIZXJlIHRoZSAicm91dGVzIiBtZWFucyAicGF0aHMiLiANCg0KSG93IGFib3V0OiAiLi4ubWF5 IHRyYXZlcnNlIHRocm91Z2ggZGlmZmVyZW50IHBhdGhzIG9yIG5ldHdvcmtzIj8NCg0KPiDigKIg SW50cm8gYW5kIEZpZ3VyZSAxOiBjb3VsZCBiZSBleGFtcGxlIGJlIG1hZGUgYSBiaXQgbW9yZSBn ZW5lcmljIHdpdGggYQ0KPiBuZXR3b3JrIGJldHdlZW4gdGhlIFBFcz8gV2l0aCBkaXJlY3RseSBj b25uZWN0ZWQgUEVzIGl0IGRvZXNu4oCZdCBzZWVtIGENCj4gcmVhbGlzdGljIGFuZCBnZW5lcmlj IGVub3VnaCBleGFtcGxlLg0KDQoNCj4g4oCiIEludHJvOiBzdWdnZXN0IHJlbW92aW5nIOKAnEFz IG1lbnRpb25lZCBhYm92ZeKAnS4NCg0KT0suDQoNCj4g4oCiIMKgVGhlIG5hbWUgb2YgdGhlIGRy YWZ0IGV4cGxpY2l0bHkgbWVudGlvbnMgTVBMUy1UUCBidXQgaW4gdGhlIHJlc3Qgb2YgdGhlDQo+ IGRyYWZ0IHRoZXJlIGlzIG5vIG1lbnRpb24gb2YgaXQsIGp1c3QgdGhlIG11Y2ggbW9yZSBnZW5l cmFsIFBhY2tldCBTd2l0Y2hpbmcNCj4gTmV0d29yayB0ZXJtIGlzIHVzZWQuDQoNCkluZGVlZCwg dGhhdCdzIHRoZSBpbnRlbnRpb24uIFRoaXMgd29yayB3YXMgdHJpZ2dlcmVkIGJ5IHRoZSBkaXNj dXNzaW9uIG9mIE1QTFMtVFAuIEJ1dCB3aXRoIHRoZSBwcm9ncmVzcyBvZiB0aGlzIGRyYWZ0IGFu ZCBkaXNjdXNzaW9uIHdpdGhpbiB0aGUgV0csIHRoZXJlIGlzIGEgY29uc2Vuc3VzIHRoYXQgdGhp cyB0ZWNobmlxdWUgaXMgYSBnZW5lcmFsIHNvbHV0aW9uIHRoYXQgY2FuIGFjdHVhbGx5IGFwcGx5 IHRvIGJvdGggVFAgYW5kIG5vbi1UUCBjYXNlcy4gDQoNCj4g4oCiIFNlY3Rpb24gMjrCoMKgIOKA nFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5ldyBvcHRpb25hbCBUTFYsIFBTTiBUdW5uZWwgQmlu ZGluZw0KPiBUTFYsIHRvIGNvbW11bmljYXRlIHR1bm5lbC9MU1BzIHNlbGVjdGlvbiBhbmQgYmlu ZGluZyByZXF1ZXN0cyBiZXR3ZWVuIFBFcy4NCj4g4oCcIFRoZSBiaW5kaW5nIHJlcXVlc3QgaXMg YmV0d2VlbiBQRXM/IE9yIGJldHdlZW4gYW4gUFcgYW5kIGEgVHVubmVsIChvciBMU1A/KQ0KPiBi ZXR3ZWVuIHR3byBQRXM/DQoNCkJldHdlZW4gUEVzIG9mIGFuIFBXLg0KDQo+IOKAoiBTZWN0aW9u IDI6IFN0cmljdCBiaW5kaW5nIHZzIENvLXJvdXRlZCBiaW5kaW5nOiBmcm9tIHRoZSBkZXNjcmlw dGlvbiBpdCBzZWVtcw0KPiB0aGF0IHRoZSBmaXJzdCBvbmUgaXMgc3RyaWN0IGFuZCB0aGUgc2Vj b25kIG9uZSBpcyDigJxsb29zZeKAnSAoaW4gdGhlIHNlbnNlIHRoYXQgdGhlDQo+IFBFIGNhbiBh Y2NlcHQgdGhlIHJlcXVlc3Qgb3Igbm90KS4gRG9u4oCZdCBib3RoIGFwcGx5IHRvIGNvLXJvdXRl ZCBMU1BzPw0KDQpZZXMsIGJvdGggY2FuIGFwcGx5IHRvIGNvLXJvdXRlZCBMU1BzLiBCdXQgZm9y ICJzdHJpY3QiIG1vZGUsIGlmIHRoZSBlZ3Jlc3MgUEUgbXVzdCBiaW5kIHRvIHRoZSBzcGVjaWZp ZWQgdHVubmVsIGJ5IHRoZSBpbmdyZXNzIFBFLCBvdGhlcndpc2UsIHRoZSBiaW5kaW5nIHdpbGwg bm90IHN1Y2Nlc3MuIFRoZSAiY28tcm91dGVkIiBtb2RlIGdpdmVzIHRoZSBlZ3Jlc3MgUEUgdGhl IHVzZSBhbHRlcm5hdGl2ZSB0dW5uZWwuDQoNCj4g4oCiIFNlY3Rpb24gMjog4oCdVGhlIHRlcm1p bm9sb2d5ICJMU1AiIGlzwqAgaWRlbnRpY2FsIHRvIHRoZSAiTFNQIHR1bm5lbCIgZGVmaW5lZCBp bg0KPiBTZWN0aW9uIDIuMSBvZiBbUkZDMzIwOV0swqAgd2hpY2ggaXMgdW5pcXVlbHkgaWRlbnRp ZmllZCBieSB0aGUgU0VTU0lPTiBvYmplY3QNCj4gdG9nZXRoZXIgd2l0aMKgIFNFTkRFUl9URU1Q TEFURSAob3IgRklMVEVSX1NQRUMpIG9iamVjdCB0aGF0IGNvbnNpc3RzIG9mDQo+IExTUCBJRCBh bmQgVHVubmVsIGVuZHBvaW50IGFkZHJlc3Mu4oCdIFdoeSBpcyB0aGUgZHJhZnQgY29uc2lkZXJp bmcgb25seSBzaWduYWxlZA0KPiBMU1BzPyBEb2VzbuKAmXQgaXQgYXBwbHkgYWxzbyB0byBjZW50 cmFsbHkgcHJvdmlzaW9uZWQgb25lcz8gKGUuZy4gTk1TIG9yIFNETikuDQoNClRoZSBtYWluIHB1 cnBvc2UgaGVyZSBpcyB0byBnaXZlIGEgcmVmZXJlbmNlIHRvIHRoZSB0ZXJtIG9mICJMU1AiIGFu ZCAidHVubmVsIiwgaGVuY2UgdG8gZWxpbWluYXRlIHRoZSBjb25mdXNpb24gb2Ygd2hlbiB1c2Ug dGhlc2UgaW4gdGhlIGZvbGxvd2luZyBzZWN0aW9ucy4gQXMgZm9yIHRoZSBOTVMgYW5kIFNETiBi YXNlZCBURSBMU1AvVHVubmVsLCB0ZWNobmljYWxseSwgaXQgY2FuIGFwcGx5IHRvIGFzIHdlbGwg b25seSBpZiB0aGUgVEUgTFNQL1R1bm5lbCBoYXMgdGhlIExTUCBudW1iZXIsIG5vZGUgSUQgZXRj LiBpbmZvcm1hdGlvbi4gDQoNCj4g4oCiIFNlY3Rpb24gMi4xOiDigJxMRFAgTGFiZWwgTWFwcGlu ZyBtZXNzYWdl4oCdIG1pc3NpbmcgcmVmZXJlbmNlLiBBbmQgd2h5IHRoZQ0KPiBUeXBlIGZpZWxk IHN0YXJ0cyB3aXRoIDEgYW5kIDA/DQoNCkdvb2QgY2F0Y2gsIHdpbGwgYWRkIGEgcmVmZXJlbmNl IGhlcmUuDQoNCg0KPiBOaXRzOg0KPiDigKIgQWJzdHJhY3Qgcy8gdHJhdmVyc2UgdGhyb3VnaCBt dWx0aXBsZS8gdHJhdmVyc2UgbXVsdGlwbGUg4oCiIEludHJvZHVjdGlvbjoNCj4g4oCcUHNldWRv d2lyZSAoUFcpIEVtdWxhdGlvbiBFZGdlLXRvLUVkZ2UgKFBXRTMp4oCdLiBJIHN1Z2dlc3QgcmVt b3ZpbmcgKFBXKSwNCj4gaXTigJlzIGFscmVhZHkgaW5jbHVkZWQgaW50byBQV0UzLg0KDQpPSy4N Cj4g4oCiIEludHJvOiBzLyBhIGJpZGlyZWN0aW9uYWwgY2lyY3VpdHMvIGEgYmlkaXJlY3Rpb25h bCBjaXJjdWl0IA0KDQpPSy4NCg0K4oCiIEludHJvOiBzdWdnZXN0DQo+IHJlcGhyYXNpbmc6IOKA nEJpZGlyZWN0aW9uYWwgTFNQcyBzaGFyZSBmYXRlIGFuZCBzaW1wbGlmeSB0aGUgcm91dGluZyBv ZiBhDQo+IHByb3RlY3Rpb24gcGF0aCBhbHNvIGNvbnNpc3Rpbmcgb2YgYmlkaXJlY3Rpb25hbMKg wqAgTFNQcyBiZWNhdXNlIHdvcmtpbmcgYW5kDQo+IHByb3RlY3Rpb24gcGF0aHMgaGF2ZSB0byBi ZSBkaXNqb2ludC7igJ0NCg0KT0suDQoNCj4g4oCiIEludHJvOiBzLyB0aGVyZSBhcmUgYSBsYXJn ZSBudW1iZXIvIHRoZXJlIGlzIGEgbGFyZ2UgbnVtYmVyIA0KDQpPSy4NCg0K4oCiIEludHJvOnMv dG8gYmUNCj4gY2FycmllZC9hcmUgY2FycmllZCANCg0KT0suDQoNCuKAoiBJbnRybzpzL3RoZXJl IGFyZSBhIG51bWJlci90aGVyZSBpcyBhIG51bWJlciANCg0KT0suDQoNCuKAoiBJbnRybzogcy8N Cj4gdHJhZmZpYyBiZWxvbmdzL3RyYWZmaWMgYmVsb25naW5nIA0KDQpPSy4NCg0K4oCiIEludHJv OiAoc3VnZ2VzdGlvbikgcy8oUEUxLVAzLVBFMikvDQo+IChQRTItUDMtUEUxKSBzaW5jZSB3ZSBh cmUgc3BlYWtpbmcgYWJvdXQgZGlyZWN0aW9uYWxpdHkgaXQgbWFrZXMgbW9yZSBzZW5zZSB0bw0K PiBsaXN0IHRoZSBub2RlcyBvZiB0aGUgcGF0aCBpbiB0aGUgcmV2ZXJzZSBkaXJlY3Rpb24uDQoN Ck9LLg0KDQo+IOKAoiBJbnRybzogcy8gVGhlIHNpbWlsYXIgcHJvYmxlbXMvQSBzaW1pbGFyIHBy b2JsZW0gDQoNCk9LLg0KDQo+4oCiIEludHJvOiBzLyB3b24ndC9kb2VzIG5vdCANCg0KT0suDQo+ 4oCiSW50cm86IHMvIEluIHRoaXMgZG9jdW1lbnQsIGl0IGludHJvZHVjZXMvVGhpcyBkb2N1bWVu dCBpbnRyb2R1Y2VzIEJSIERhbmllbGUNCg0KT0suDQoNCj4gDQoNCg== --_002_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28C206D6FSZXEMA510MBXchi_ Content-Type: text/html; name="Diff draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06_txt - draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-07_txt_htm.htm" Content-Description: Diff draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06_txt - draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-07_txt_htm.htm Content-Disposition: attachment; filename="Diff draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06_txt - draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-07_txt_htm.htm"; size=54609; creation-date="Fri, 13 May 2016 07:23:05 GMT"; modification-date="Fri, 13 May 2016 07:23:07 GMT" Content-Transfer-Encoding: base64 CjwhRE9DVFlQRSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgWEhUTUwgMS4wIFRyYW5zaXRpb25h bC8vRU4iICJodHRwOi8vd3d3LnczLm9yZy9UUi94aHRtbDEvRFREL3hodG1sMS10cmFuc2l0aW9u YWwuZHRkIj4gCjwhLS0gR2VuZXJhdGVkIGJ5IHJmY2RpZmYgMS40NTogcmZjZGlmZiAgLS0+IAo8 IS0tIDwhRE9DVFlQRSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgSFRNTCA0LjAxIFRyYW5zaXRp b25hbCIgPiAtLT4KPCEtLSBTeXN0ZW06IExpbnV4IHppbmZhbmRlbCAzLjIuMC00LWFtZDY0ICMx IFNNUCBEZWJpYW4gMy4yLjY4LTErZGViN3UyIHg4Nl82NCBHTlUvTGludXggLS0+IAo8IS0tIFVz aW5nIGF3azogL3Vzci9iaW4vZ2F3azogR05VIEF3ayA0LjAuMSAtLT4gCjwhLS0gVXNpbmcgZGlm ZjogL3Vzci9iaW4vZGlmZjogZGlmZiAoR05VIGRpZmZ1dGlscykgMy4yIC0tPiAKPCEtLSBVc2lu ZyB3ZGlmZjogL3Vzci9iaW4vd2RpZmY6IHdkaWZmIChHTlUgd2RpZmYpIDEuMS4yIC0tPiAKPGh0 bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiPiAKPGhlYWQ+IAogIDxtZXRh IGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PVVU Ri04IiAvPiAKICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVN0eWxlLVR5cGUiIGNvbnRlbnQ9 InRleHQvY3NzIiAvPiAKICA8dGl0bGU+RGlmZjogZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtcHct b3Zlci1iaWRpci1sc3AtMDYudHh0IC0gZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtcHctb3Zlci1i aWRpci1sc3AtMDcudHh0PC90aXRsZT4gCiAgPHN0eWxlIHR5cGU9InRleHQvY3NzIj4gCiAgICBi b2R5ICAgIHsgbWFyZ2luOiAwLjRleDsgbWFyZ2luLXJpZ2h0OiBhdXRvOyB9IAogICAgdHIgICAg ICB7IH0gCiAgICB0ZCAgICAgIHsgd2hpdGUtc3BhY2U6IHByZTsgZm9udC1mYW1pbHk6IG1vbm9z cGFjZTsgdmVydGljYWwtYWxpZ246IHRvcDsgZm9udC1zaXplOiAwLjg2ZW07fSAKICAgIHRoICAg ICAgeyBmb250LXNpemU6IDAuODZlbTsgfSAKICAgIC5zbWFsbCAgeyBmb250LXNpemU6IDAuNmVt OyBmb250LXN0eWxlOiBpdGFsaWM7IGZvbnQtZmFtaWx5OiBWZXJkYW5hLCBIZWx2ZXRpY2EsIHNh bnMtc2VyaWY7IH0gCiAgICAubGVmdCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgfSAKICAg IC5yaWdodCAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkZGOyB9IAogICAgLmRpZmYgICB7IGJhY2tn cm91bmQtY29sb3I6ICNDQ0Y7IH0gCiAgICAubGJsb2NrIHsgYmFja2dyb3VuZC1jb2xvcjogI0JG QjsgfSAKICAgIC5yYmxvY2sgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkY4OyB9IAogICAgLmluc2Vy dCB7IGJhY2tncm91bmQtY29sb3I6ICM4RkY7IH0gCiAgICAuZGVsZXRlIHsgYmFja2dyb3VuZC1j b2xvcjogI0FDRjsgfSAKICAgIC52b2lkICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkZCOyB9IAog ICAgLmNvbnQgICB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7IH0gCiAgICAubGluZWJyIHsgYmFj a2dyb3VuZC1jb2xvcjogI0FBQTsgfSAKICAgIC5saW5lbm8geyBjb2xvcjogcmVkOyBiYWNrZ3Jv dW5kLWNvbG9yOiAjRkZGOyBmb250LXNpemU6IDAuN2VtOyB0ZXh0LWFsaWduOiByaWdodDsgcGFk ZGluZzogMCAycHg7IH0gCiAgICAuZWxpcHNpc3sgYmFja2dyb3VuZC1jb2xvcjogI0FBQTsgfSAK ICAgIC5sZWZ0IC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogI0RERDsgfSAKICAgIC5yaWdodCAu Y29udCB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7IH0gCiAgICAubGJsb2NrIC5jb250IHsgYmFj a2dyb3VuZC1jb2xvcjogIzlEOTsgfSAKICAgIC5yYmxvY2sgLmNvbnQgeyBiYWNrZ3JvdW5kLWNv bG9yOiAjREQ2OyB9IAogICAgLmluc2VydCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICMwREQ7 IH0gCiAgICAuZGVsZXRlIC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogIzhBRDsgfSAKICAgIC5z dGF0cywgLnN0YXRzIHRkLCAuc3RhdHMgdGggeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyBwYWRk aW5nOiAycHggMDsgfSAKICAgIHNwYW4uaGlkZSB7IGRpc3BsYXk6IG5vbmU7IGNvbG9yOiAjYWFh O30gICAgYTpob3ZlciBzcGFuIHsgZGlzcGxheTogaW5saW5lOyB9ICAgIHRyLmNoYW5nZSB7IGJh Y2tncm91bmQtY29sb3I6IGdyYXk7IH0gCiAgICB0ci5jaGFuZ2UgYSB7IHRleHQtZGVjb3JhdGlv bjogbm9uZTsgY29sb3I6IGJsYWNrIH0gCiAgPC9zdHlsZT4gCiAgICAgPHNjcmlwdD4KdmFyIGNo dW5rX2luZGV4ID0gMDsKdmFyIG9sZF9jaHVuayA9IG51bGw7CgpmdW5jdGlvbiBmb3JtYXRfY2h1 bmsoaW5kZXgpIHsKICAgIHZhciBwcmVmaXggPSAiZGlmZiI7CiAgICB2YXIgc3RyID0gaW5kZXgu dG9TdHJpbmcoKTsKICAgIGZvciAoeD0wOyB4PCg0LXN0ci5sZW5ndGgpOyArK3gpIHsKICAgICAg ICBwcmVmaXgrPScwJzsKICAgIH0KICAgIHJldHVybiBwcmVmaXggKyBzdHI7Cn0KCmZ1bmN0aW9u IGZpbmRfY2h1bmsobil7CiAgICByZXR1cm4gZG9jdW1lbnQucXVlcnlTZWxlY3RvcigndHJbaWQk PSInICsgbiArICciXScpOwp9CgpmdW5jdGlvbiBjaGFuZ2VfY2h1bmsob2Zmc2V0KSB7CiAgICB2 YXIgaW5kZXggPSBjaHVua19pbmRleCArIG9mZnNldDsKICAgIHZhciBuZXdfc3RyOwogICAgdmFy IG5ld19jaHVuazsKCiAgICBuZXdfc3RyID0gZm9ybWF0X2NodW5rKGluZGV4KTsKICAgIG5ld19j aHVuayA9IGZpbmRfY2h1bmsobmV3X3N0cik7CiAgICBpZiAoIW5ld19jaHVuaykgewogICAgICAg IHJldHVybjsKICAgIH0KICAgIGlmIChvbGRfY2h1bmspIHsKICAgICAgICBvbGRfY2h1bmsuc3R5 bGUub3V0bGluZSA9ICIiOwogICAgfQogICAgb2xkX2NodW5rID0gbmV3X2NodW5rOwogICAgb2xk X2NodW5rLnN0eWxlLm91dGxpbmUgPSAiMXB4IHNvbGlkIHJlZCI7CiAgICB3aW5kb3cubG9jYXRp b24uaGFzaCA9ICIjIiArIG5ld19zdHI7CiAgICB3aW5kb3cuc2Nyb2xsQnkoMCwtMTAwKTsKICAg IGNodW5rX2luZGV4ID0gaW5kZXg7Cn0KCmRvY3VtZW50Lm9ua2V5ZG93biA9IGZ1bmN0aW9uKGUp IHsKICAgIHN3aXRjaCAoZS5rZXlDb2RlKSB7CiAgICBjYXNlIDc4OgogICAgICAgIGNoYW5nZV9j aHVuaygxKTsKICAgICAgICBicmVhazsKICAgIGNhc2UgODA6CiAgICAgICAgY2hhbmdlX2NodW5r KC0xKTsKICAgICAgICBicmVhazsKICAgIH0KfTsKICAgPC9zY3JpcHQ+IAo8L2hlYWQ+IAo8Ym9k eSA+IAogIDx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+ IAogIDx0ciBpZD0icGFydC0xIiBiZ2NvbG9yPSJvcmFuZ2UiPjx0aD48L3RoPjx0aD48YSBocmVm PSIvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtcGFscy1tcGxzLXRwLXB3LW92ZXItYmlkaXItbHNw LTA2LnR4dCIgc3R5bGU9ImNvbG9yOiMwMDg7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+Jmx0Ozwv YT4mbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1w YWxzLW1wbHMtdHAtcHctb3Zlci1iaWRpci1sc3AtMDYudHh0IiBzdHlsZT0iY29sb3I6IzAwOCI+ ZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtcHctb3Zlci1iaWRpci1sc3AtMDYudHh0PC9hPiZuYnNw OzwvdGg+PHRoPiA8L3RoPjx0aD4mbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtcHctb3Zlci1iaWRpci1sc3AtMDcudHh0IiBz dHlsZT0iY29sb3I6IzAwOCI+ZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtcHctb3Zlci1iaWRpci1s c3AtMDcudHh0PC9hPiZuYnNwOzxhIGhyZWY9Ii9yZmNkaWZmP3VybDE9ZHJhZnQtaWV0Zi1wYWxz LW1wbHMtdHAtcHctb3Zlci1iaWRpci1sc3AtMDcudHh0IiBzdHlsZT0iY29sb3I6IzAwODsgdGV4 dC1kZWNvcmF0aW9uOm5vbmU7Ij4mZ3Q7PC9hPjwvdGg+PHRoPjwvdGg+PC90cj4gCiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+TmV0d29yayBX b3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBN LiBDaGVuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+TmV0d29yayBXb3JraW5nIEdy b3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNLiBDaGVuPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBXLiBDYW88L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij5JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBXLiBDYW88L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPkludGVuZGVkIHN0YXR1czogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEh1YXdlaTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkludGVu ZGVkIHN0YXR1czogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEh1YXdlaTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlk PSJkaWZmMDAwMSI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj5FeHBpcmVzOiA8c3BhbiBjbGFzcz0iZGVsZXRlIj5KdW5l IDUsIDIwMTYgICAgIDwvc3Bhbj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg QS4gVGFrYWNzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPkV4cGlyZXM6IDxzcGFu IGNsYXNzPSJpbnNlcnQiPk5vdmVtYmVyIDE0LCAyMDE2PC9zcGFuPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBBLiBUYWthY3M8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBFcmljc3NvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBF cmljc3NvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUC4gUGFuPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUC4gUGFuPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDAyIj48dGQ+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHNw YW4gY2xhc3M9ImRlbGV0ZSI+RGVjZW1iZXIgMywgMjAxNTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgTWF5IDEzLCAyMDE2PC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgTERQIEV4dGVu c2lvbnMgZm9yIFBzZXVkb3dpcmUgQmluZGluZyB0byBMU1AgVHVubmVsczwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICBMRFAgRXh0ZW5zaW9ucyBmb3IgUHNldWRvd2ly ZSBCaW5kaW5nIHRvIExTUCBUdW5uZWxzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHIgaWQ9ImRpZmYwMDAzIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAgIGRyYWZ0LWll dGYtcGFscy1tcGxzLXRwLXB3LW92ZXItYmlkaXItbHNwLTA8c3BhbiBjbGFzcz0iZGVsZXRlIj42 PC9zcGFuPi50eHQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAg ZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtcHctb3Zlci1iaWRpci1sc3AtMDxzcGFuIGNsYXNzPSJp bnNlcnQiPjc8L3NwYW4+LnR4dDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5BYnN0 cmFjdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkFic3RyYWN0PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE1hbnkgdHJhbnNwb3J0IHNlcnZpY2VzIHJlcXVpcmUg dGhhdCB1c2VyIHRyYWZmaWMsIGluIHRoZSBmb3JtIG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgTWFueSB0cmFuc3BvcnQgc2VydmljZXMgcmVxdWlyZSB0aGF0IHVzZXIgdHJh ZmZpYywgaW4gdGhlIGZvcm0gb2Y8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFBzZXVk b3dpcmVzIChQVyksIGJlIGRlbGl2ZXJlZCBvbiBhIHNpbmdsZSBjby1yb3V0ZWQgYmlkaXJlY3Rp b25hbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFBzZXVkb3dpcmVzIChQVyks IGJlIGRlbGl2ZXJlZCBvbiBhIHNpbmdsZSBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwNCI+PHRkPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5MU1A8L3NwYW4+IG9yIHR3byA8c3BhbiBjbGFz cz0iZGVsZXRlIj5MU1BzPC9zcGFuPiB0aGF0IHNoYXJlIHRoZSBzYW1lIHJvdXRlcy4gIDxzcGFu IGNsYXNzPSJkZWxldGUiPkluIGFkZGl0aW9uLCB0aGUgdXNlcjwvc3Bhbj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+dHVubmVsPC9zcGFu PiBvciB0d28gPHNwYW4gY2xhc3M9Imluc2VydCI+dHVubmVsczwvc3Bhbj4gdGhhdCBzaGFyZSB0 aGUgc2FtZSByb3V0ZXMuICBUaGlzIGRvY3VtZW50PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIHRyYWZmaWMgbWF5IHRyYXZlcnNlIHRocm91Z2gg bXVsdGlwbGUgdHJhbnNwb3J0IG5ldHdvcmtzLjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgZGVmaW5lcyBhbiBvcHRpb25hbCBleHRlbnNpb24gdG8gTERQIHRoYXQg ZW5hYmxlcyB0aGUgYmluZGluZyBiZXR3ZWVuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgUFdz IGFuZCB0aGUgdW5kZXJseWluZyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5URSB0dW5uZWxzLiAgVGhl IGV4dGVuc2lvbiBhcHBsaWVzIHRvIGJvdGggU1MtPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYW4gb3B0aW9uYWwgZXh0ZW5zaW9u IHRvIExEUCB0aGF0IGVuYWJsZXMgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIFBXIGFuZCBNUy1QVy48L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPiAgIGJpbmRpbmcgYmV0d2VlbiBQV3MgYW5kIHRoZSB1bmRlcmx5 aW5nIDxzcGFuIGNsYXNzPSJkZWxldGUiPkxTUHMuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+UmVxdWlyZW1l bnRzIExhbmd1YWdlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+UmVxdWlyZW1lbnRz IExhbmd1YWdlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBrZXkgd29y ZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiw8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUga2V5IHdvcmRzICJNVVNUIiwg Ik1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQi LCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBh bmQgIk9QVElPTkFMIiBpbiB0aGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkb2N1 bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQyAyMTE5IFtSRkMy MTE5XS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkb2N1bWVudCBhcmUgdG8g YmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQyAyMTE5IFtSRkMyMTE5XS48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+U3RhdHVzIG9mIFRoaXMgTWVtbzwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPlN0YXR1cyBvZiBUaGlzIE1lbW88L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4g ZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ug d2l0aCB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy IGlkPSJwYXJ0LTIiIGNsYXNzPSJjaGFuZ2UiID48dGQ+PC90ZD48dGg+PHNtYWxsPnNraXBwaW5n IHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iI3BhcnQtMiI+PGVtPiBwYWdlIDEsIGxpbmUg NDU8c3BhbiBjbGFzcz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90 aD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iI3BhcnQt MiI+PGVtPiBwYWdlIDEsIGxpbmUgNDQ8c3BhbiBjbGFzcz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48 L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1 bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUg SW50ZXJuZXQgRW5naW5lZXJpbmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRhc2sg Rm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRl PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGFzayBGb3JjZSAoSUVURikuICBO b3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGU8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRo ZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2Yg Y3VycmVudCBJbnRlcm5ldC08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIERyYWZ0cyBp cyBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBt YXhpbXVtIG9mIHNpeCBtb250aHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJ bnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9m IHNpeCBtb250aHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFuZCBtYXkgYmUgdXBk YXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBs YWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnk8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRl cm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyBy ZWZlcmVuY2U8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG1hdGVyaWFsIG9yIHRvIGNp dGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiI8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBh cyAid29yayBpbiBwcm9ncmVzcy4iPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDUiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgVGhpcyBJbnRlcm5ldC1E cmFmdCB3aWxsIGV4cGlyZSBvbiA8c3BhbiBjbGFzcz0iZGVsZXRlIj5KdW5lIDU8L3NwYW4+LCAy MDE2LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBUaGlzIEludGVybmV0LURy YWZ0IHdpbGwgZXhwaXJlIG9uIDxzcGFuIGNsYXNzPSJpbnNlcnQiPk5vdmVtYmVyIDE0PC9zcGFu PiwgMjAxNi48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Q29weXJpZ2h0IE5vdGlj ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkNvcHlyaWdodCBOb3RpY2U8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwNiI+ PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gICBDb3B5cmlnaHQgKGMpIDIwMTxzcGFuIGNsYXNzPSJkZWxldGUiPjU8L3Nw YW4+IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIENvcHlyaWdodCAoYykgMjAxPHNwYW4gY2xhc3M9 Imluc2VydCI+Njwvc3Bhbj4gSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBh cyB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRvY3VtZW50IGF1dGhvcnMuICBB bGwgcmlnaHRzIHJlc2VydmVkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRv Y3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0 aGUgSUVURiBUcnVzdCdzIExlZ2FsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg VGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBM ZWdhbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0 byBJRVRGIERvY3VtZW50czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFByb3Zp c2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBv biB0aGUgZGF0ZSBvZjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIChodHRwOi8v dHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVu dC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcg dGhlc2UgZG9jdW1lbnRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBjYXJlZnVsbHks IGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3Bl Y3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBjYXJlZnVsbHksIGFzIHRoZXkg ZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3Q8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVu dHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0 ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0 aW9uIDQuZSBvZjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGluY2x1ZGUgU2lt cGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMg YW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRl ZCB3aXRob3V0IHdhcnJhbnR5IGFzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkZXNj cmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5UYWJsZSBvZiBDb250ZW50czwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPlRhYmxlIG9mIENvbnRlbnRzPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDEuICBJbnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIDEuICBJbnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwNyI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAyLiAgTERQIEV4dGVuc2lv bnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDxzcGFu IGNsYXNzPSJkZWxldGUiPjU8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgIDIuICBMRFAgRXh0ZW5zaW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAgPHNwYW4gY2xhc3M9Imluc2VydCI+NDwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgICAgMi4xLiAgUFNOIFR1bm5lbCBCaW5kaW5nIFRMViAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgICAgMi4xLiAgUFNOIFR1bm5lbCBCaW5kaW5nIFRMViAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAgNTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAg IDIuMS4xLiAgUFNOIFR1bm5lbCBTdWItVExWICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gICA2PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgIDIuMS4xLiAg UFNOIFR1bm5lbCBTdWItVExWICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2 PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAzLiAgVGhlb3J5IG9mIE9wZXJhdGlvbiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDg8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAzLiAgVGhlb3J5IG9mIE9wZXJhdGlvbiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDg8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIDQuICBQU04gQmluZGluZyBPcGVyYXRpb24gZm9yIFNTLVBXIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAgOTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IDQuICBQU04gQmluZGluZyBPcGVyYXRpb24gZm9yIFNTLVBXIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAgOTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgNS4gIFBTTiBCaW5k aW5nIE9wZXJhdGlvbiBmb3IgTVMtUFcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEx PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgNS4gIFBTTiBCaW5kaW5nIE9wZXJh dGlvbiBmb3IgTVMtUFcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDExPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICA2LiAgUFNOIFR1bm5lbCBTZWxlY3QgQ29uc2lkZXJhdGlv biAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTM8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICA2LiAgUFNOIFR1bm5lbCBTZWxlY3QgQ29uc2lkZXJhdGlvbiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IDcuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAxMzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDcuICBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAxMzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgOC4gIElBTkEgQ29uc2lkZXJhdGlv bnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEzPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgOC4gIElBTkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEzPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgIDguMS4gIExEUCBUTFYgVHlwZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgIDguMS4gIExEUCBUTFYgVHlwZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgMTM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICA4LjEu MS4gIFBTTiBUdW5uZWwgU3ViLVRMVnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAxMzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICA4LjEuMS4gIFBTTiBU dW5uZWwgU3ViLVRMVnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMzwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICA4LjIuICBMRFAgU3RhdHVzIENvZGVzICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE0PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICA4LjIuICBMRFAgU3RhdHVzIENvZGVzICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICA5LiAgQWNrbm93bGVkZ2VtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgMTQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICA5LiAg QWNrbm93bGVkZ2VtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMTQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDEwLiBSZWZlcmVuY2VzICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDEwLiBSZWZlcmVuY2VzICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgICAxMC4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAxMC4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDE0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDEw LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMTU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDEwLjIuICBJbmZv cm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTU8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4xLiAgSW50cm9kdWN0aW9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+MS4gIEludHJvZHVjdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHIgaWQ9ImRpZmYwMDA4Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJkZWxl dGUiPlBzZXVkb3dpcmUgKFBXKTwvc3Bhbj4gRW11bGF0aW9uIEVkZ2UtdG8tRWRnZSAoUFdFMykg W1JGQzM5ODVdIGlzIGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4g Y2xhc3M9Imluc2VydCI+UHNldWRvIFdpcmU8L3NwYW4+IEVtdWxhdGlvbiBFZGdlLXRvLUVkZ2Ug KFBXRTMpIFtSRkMzOTg1XSBpcyBhIG1lY2hhbmlzbSB0bzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj4gICBtZWNoYW5pc20gdG8gZW11bGF0ZSBsYXllciAyIHNlcnZpY2VzLCBzdWNoIGFz IEV0aGVybmV0IDxzcGFuIGNsYXNzPSJkZWxldGUiPlBvaW50LXRvLTwvc3Bhbj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgZW11bGF0ZSBsYXllciAyIHNlcnZpY2VzLCBzdWNo IGFzIEV0aGVybmV0IDxzcGFuIGNsYXNzPSJpbnNlcnQiPlBvaW50LXRvLVBvaW50PC9zcGFuPiAo UDJQKTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4g ICBQb2ludDwvc3Bhbj4gKFAyUCkgY2lyY3VpdHMuICBTdWNoIHNlcnZpY2VzIGFyZSBlbXVsYXRl ZCBiZXR3ZWVuIHR3bzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBjaXJjdWl0 cy4gIFN1Y2ggc2VydmljZXMgYXJlIGVtdWxhdGVkIGJldHdlZW4gdHdvIEF0dGFjaG1lbnQgQ2ly Y3VpdHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgQXR0YWNobWVudCBDaXJjdWl0 cyAoQUNzKSBhbmQgdGhlIDxzcGFuIGNsYXNzPSJkZWxldGUiPlBXPC9zcGFuPiBlbmNhcHN1bGF0 ZWQgbGF5ZXIgMiBzZXJ2aWNlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIChB Q3MpIGFuZCB0aGUgPHNwYW4gY2xhc3M9Imluc2VydCI+UHNldWRvd2lyZSAoUFcpPC9zcGFuPiBl bmNhcHN1bGF0ZWQgbGF5ZXIgMiBzZXJ2aWNlIHBheWxvYWQgaXM8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+ICAgcGF5bG9hZCBpcyBjYXJyaWVkIHRocm91Z2ggUGFja2V0IFN3aXRjaGlu ZyBOZXR3b3JrIChQU04pIHR1bm5lbHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ ICAgY2FycmllZCB0aHJvdWdoIFBhY2tldCBTd2l0Y2hpbmcgTmV0d29yayAoUFNOKSB0dW5uZWxz IGJldHdlZW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgYmV0d2VlbiBQcm92aWRl ciBFZGdlcyAoUEVzKS4gIFBXRTMgdHlwaWNhbGx5IHVzZXMgTGFiZWwgRGlzdHJpYnV0aW9uPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIFByb3ZpZGVyIEVkZ2VzIChQRXMpLiAg UFdFMyB0eXBpY2FsbHkgdXNlcyBMYWJlbCBEaXN0cmlidXRpb248L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIFByb3RvY29sIChMRFApIFtSRkM1MDM2XSBvciBSZXNvdXJjZSBSZXNlclZh dGlvbiBQcm90b2NvbC1UcmFmZmljPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg UHJvdG9jb2wgKExEUCkgW1JGQzUwMzZdIG9yIFJlc291cmNlIFJlc2VyVmF0aW9uIFByb3RvY29s LVRyYWZmaWM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEVuZ2luZWVyaW5nIChSU1ZQ LVRFKSBbUkZDMzIwOV0gTFNQcyBhcyBQU04gdHVubmVscy4gIFRoZSBQRXMgc2VsZWN0PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRW5naW5lZXJpbmcgKFJTVlAtVEUpIFtSRkMz MjA5XSBMU1BzIGFzIFBTTiB0dW5uZWxzLiAgVGhlIFBFcyBzZWxlY3Q8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIGFuZCBiaW5kIHRoZSBQc2V1ZG93aXJlcyB0byBQU04gdHVubmVscyBp bmRlcGVuZGVudGx5LiAgVG9kYXksIHRoZXJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgYW5kIGJpbmQgdGhlIFBzZXVkb3dpcmVzIHRvIFBTTiB0dW5uZWxzIGluZGVwZW5kZW50 bHkuICBUb2RheSwgdGhlcmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGlzIG5vIHBy b3RvY29sLWJhc2VkIHByb3Zpc2lvbmluZyBtZWNoYW5pc20gdG8gYXNzb2NpYXRlIFBXcyB0byBQ U048L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpcyBubyBwcm90b2NvbC1iYXNl ZCBwcm92aXNpb25pbmcgbWVjaGFuaXNtIHRvIGFzc29jaWF0ZSBQV3MgdG8gUFNOPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0dW5uZWxzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIHR1bm5lbHMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFBX LXRvLVBTTiBUdW5uZWwgYmluZGluZyBoYXMgYmVjb21lIGluY3JlYXNpbmdseSBjb21tb24gYW5k IGltcG9ydGFudDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFBXLXRvLVBTTiBU dW5uZWwgYmluZGluZyBoYXMgYmVjb21lIGluY3JlYXNpbmdseSBjb21tb24gYW5kIGltcG9ydGFu dDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaW4gbWFueSBkZXBsb3ltZW50IHNjZW5h cmlvcy4gIEZvciBpbnN0YW5jZSwgd2hlbiBjb25uZWN0aW5nIHR3bzwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIGluIG1hbnkgZGVwbG95bWVudCBzY2VuYXJpb3MuICBGb3IgaW5z dGFuY2UsIHdoZW4gY29ubmVjdGluZyB0d288L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IHJlbW90ZWx5IGxvY2F0ZWQgc2l0ZXMsIHN1Y2ggYXMgZGF0YSBjZW50ZXJzLCBvdmVyIHRoZSBi YWNrYm9uZSwgZWFjaDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHJlbW90ZWx5 IGxvY2F0ZWQgc2l0ZXMsIHN1Y2ggYXMgZGF0YSBjZW50ZXJzLCBvdmVyIHRoZSBiYWNrYm9uZSwg ZWFjaDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgc2l0ZSBtYXkgZGVwbG95IGEgaGln aC1wZXJmb3JtYW5jZSByb3V0ZXIgb3Igc3dpdGNoIHRvIGFnZ3JlZ2F0ZTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIHNpdGUgbWF5IGRlcGxveSBhIGhpZ2gtcGVyZm9ybWFuY2Ug cm91dGVyIG9yIHN3aXRjaCB0byBhZ2dyZWdhdGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIHRob3VzYW5kcyBvZiBFdGhlcm5ldCBWTEFOIGZsb3dzLiAgVGhlIGFnZ3JlZ2F0aW5nIHJv dXRlcnMgYW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGhvdXNhbmRzIG9m IEV0aGVybmV0IFZMQU4gZmxvd3MuICBUaGUgYWdncmVnYXRpbmcgcm91dGVycyBhbmQ8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHN3aXRjaGVzIGFyZSBpbnRlcmNvbm5lY3RlZCB2aWEg b25lIG9yIG11bHRpcGxlIE1QTFMvR01QTFMgTFNQcyw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBzd2l0Y2hlcyBhcmUgaW50ZXJjb25uZWN0ZWQgdmlhIG9uZSBvciBtdWx0aXBs ZSBNUExTL0dNUExTIExTUHMsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHIgaWQ9ImRpZmYwMDA5Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHdoaWNoIG1heSB0cmF2ZXJzZSB0aHJv dWdoIGRpZmZlcmVudCA8c3BhbiBjbGFzcz0iZGVsZXRlIj5yb3V0ZTwvc3Bhbj5zIG9yIG5ldHdv cmtzLiAgRnVydGhlciw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgd2hpY2gg bWF5IHRyYXZlcnNlIHRocm91Z2ggZGlmZmVyZW50IDxzcGFuIGNsYXNzPSJpbnNlcnQiPnBhdGg8 L3NwYW4+cyBvciBuZXR3b3Jrcy4gIEZ1cnRoZXIsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBlYWNoIEV0aGVybmV0IGZsb3cgaXMgb2ZmZXJlZCB0byB0aGUgY3VzdG9tZXJzIGFzIGEg YmlkaXJlY3Rpb25hbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGVhY2ggRXRo ZXJuZXQgZmxvdyBpcyBvZmZlcmVkIHRvIHRoZSBjdXN0b21lcnMgYXMgYSBiaWRpcmVjdGlvbmFs PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDEw Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgIGNpcmN1aXQ8c3BhbiBjbGFzcz0iZGVsZXRlIj5zPC9zcGFuPiB3aXRo IGNlcnRhaW4gU0xBIGF0dHJpYnV0ZXMsIHN1Y2ggYXMgYmFuZHdpZHRoLCBsYXRlbmN5IGFuZDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBjaXJjdWl0IHdpdGggY2VydGFpbiBT TEEgYXR0cmlidXRlcywgc3VjaCBhcyBiYW5kd2lkdGgsIGxhdGVuY3kgYW5kPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBhdmFpbGFiaWxpdHkuICBBdmFpbGFiaWxpdHkgY2FuIGJlIGRl bGl2ZXJlZCBieSBwcm8tYWN0aXZlIG1vbml0b3Jpbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBhdmFpbGFiaWxpdHkuICBBdmFpbGFiaWxpdHkgY2FuIGJlIGRlbGl2ZXJlZCBi eSBwcm8tYWN0aXZlIG1vbml0b3Jpbmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0ciBpZD0iZGlmZjAwMTEiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgYW5kIHByb3RlY3Rpb24gc3dp dGNoaW5nLiAgQmlkaXJlY3Rpb25hbCA8c3BhbiBjbGFzcz0iZGVsZXRlIj5MU1BzIHNoYXJlIGZh dGUgYW5kIHNpbXBsaWZ5PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4g ICBhbmQgcHJvdGVjdGlvbiBzd2l0Y2hpbmcuICBCaWRpcmVjdGlvbmFsIDxzcGFuIGNsYXNzPSJp bnNlcnQiPmNvLXJvdXRlZCBMU1Agc2hhcmVzIGZhdGUsPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICB0aGUgcm91dGluZyBvZiBhIHByb3RlY3Rpb24gcGF0aCBhbHNvIDxz cGFuIGNsYXNzPSJkZWxldGUiPmNvbnNpc3Rpbmc8L3NwYW4+IG9mIGJpZGlyZWN0aW9uYWw8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgaXQg c2ltcGxpZmllczwvc3Bhbj4gdGhlIHJvdXRpbmcgb2YgYSBwcm90ZWN0aW9uIHBhdGggPHNwYW4g Y2xhc3M9Imluc2VydCI+dGhhdDwvc3Bhbj4gYWxzbyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5jb25z aXN0czwvc3Bhbj4gb2Y8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgPHNwYW4gY2xh c3M9ImRlbGV0ZSI+TFNQcyBiZWNhdXNlIHdvcmtpbmcgYW5kIHByb3RlY3Rpb24gcGF0aHMgaGF2 ZSB0byBiZSBkaXNqb2ludC48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgIGJpZGlyZWN0aW9uYWwgPHNwYW4gY2xhc3M9Imluc2VydCI+Y28tcm91dGVkIExTUC48L3Nw YW4+ICBIZW5jZSwgaXQncyBpbXBvcnRhbnQgZm9yIHRoZSBvcGVyYXRvcnM8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgSGVuY2UsIGl0J3MgaW1wb3J0YW50IGZvciB0aGUgb3BlcmF0 b3JzIHRvIG1hcCB0aGUgZm9yd2FyZGluZyBhbmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgdG8gbWFwIHRoZSBmb3J3YXJkaW5nIGFuZCByZXZlcnNlLWRpcmVjdGlvbiB0cmFm ZmljIGZyb20gYW4gRXRoZXJuZXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgcmV2 ZXJzZS1kaXJlY3Rpb24gdHJhZmZpYyBmcm9tIGFuIEV0aGVybmV0IGNpcmN1aXQgdG8gYSBzaW5n bGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgY2lyY3VpdCB0byBhIHNpbmds ZSBiaWRpcmVjdGlvbmFsIGNvLXJvdXRlZCBMU1Agb3IgdHdvIExTUHMgdGhhdDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBiaWRpcmVjdGlvbmFsIGNvLXJvdXRlZCBMU1Agb3IgdHdv IExTUHMgdGhhdCBzaGFyZSB0aGUgc2FtZSByb3V0ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICBzaGFyZSB0aGUgc2FtZSByb3V0ZSAobGlua3MgYW5kIG5vZGVzKS48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgKGxpbmtzIGFuZCBub2RlcykuPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBUaGUgcmVxdWlyZW1lbnQgZm9yIGV4cGxpY2l0IGNvbnRyb2wgb2YgUFctdG8tTFNQIG1hcHBp bmcgaGFzIGJlZW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgcmVxdWly ZW1lbnQgZm9yIGV4cGxpY2l0IGNvbnRyb2wgb2YgUFctdG8tTFNQIG1hcHBpbmcgaGFzIGJlZW48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDUuMy4y ICggIlN1cHBvcnQgZm9yIEV4cGxpY2l0IENvbnRyb2wgb2YgUFctdG8tPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgZGVzY3JpYmVkIGluIFNlY3Rpb24gNS4zLjIgKCAiU3VwcG9y dCBmb3IgRXhwbGljaXQgQ29udHJvbCBvZiBQVy10by08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIExTUCBCaW5kaW5nIiApIG9mIFtSRkM2MzczXS4gIFRoZSBmb2xsb3dpbmcgZmlndXJl IChGaWd1cmUgMSk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBMU1AgQmluZGlu ZyIgKSBvZiBbUkZDNjM3M10uICBUaGUgZm9sbG93aW5nIGZpZ3VyZSAoRmlndXJlIDEpPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBwcm92aWRlcyB0aGUgaWxsdXN0cmF0aW9uLjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHByb3ZpZGVzIHRoZSBpbGx1c3RyYXRpb24u PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAr LS0tLS0tKyAgICAgICAgICAgICAgICAgICstLS0tLS0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0rICAgICAgICAgICAgICAgICAg Ky0tLS0tLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgIC0tLUFDMSAt LS18Li4uLi4uLi4uLi4uLi5QV3MuLi4uLi4uLi4uLi4uLi58LS0tQUMxLS0tPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgLS0tQUMxIC0tLXwuLi4uLi4uLi4uLi4u LlBXcy4uLi4uLi4uLi4uLi4uLnwtLS1BQzEtLS08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgICAgICAgIC0tLS4uLi0tLS18IFBFMSAgfD09PT09PT1MU1BzPT09PT09PXwgUEUyICB8 LS0tLi4uLS0tPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgLS0t Li4uLS0tLXwgUEUxICB8PT09PT09PUxTUHM9PT09PT09fCBQRTIgIHwtLS0uLi4tLS08L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgIC0tLUFDbiAtLS18ICAgICAgfC0tLS0t LS1MaW5rcy0tLS0tLXwgICAgICB8LS0tQUNuLS0tPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAgICAgICAgLS0tQUNuIC0tLXwgICAgICB8LS0tLS0tLUxpbmtzLS0tLS0tfCAg ICAgIHwtLS1BQ24tLS08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAg ICAgICAgICArLS0tLS0tKyAgICAgICAgICAgICAgICAgICstLS0tLS0rPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0rICAgICAgICAg ICAgICAgICAgKy0tLS0tLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAg ICAgICAgICAgICBGaWd1cmUgMTogRXhwbGljaXQgUFctdG8tTFNQIGJpbmRpbmcgc2NlbmFyaW88 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgIEZpZ3VyZSAx OiBFeHBsaWNpdCBQVy10by1MU1AgYmluZGluZyBzY2VuYXJpbzwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBUaGVyZSBhcmUgdHdvIFBFcyAoUEUxIGFuZCBQRTIpIGNvbm5lY3Rl ZCB0aHJvdWdoIG11bHRpcGxlIHBhcmFsbGVsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgVGhlcmUgYXJlIHR3byBQRXMgKFBFMSBhbmQgUEUyKSBjb25uZWN0ZWQgdGhyb3VnaCBt dWx0aXBsZSBwYXJhbGxlbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbGlua3MgdGhh dCBtYXkgYmUgb24gZGlmZmVyZW50IGZpYmVycy4gIEVhY2ggbGluayBpcyBtYW5hZ2VkIGFuZDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGxpbmtzIHRoYXQgbWF5IGJlIG9uIGRp ZmZlcmVudCBmaWJlcnMuICBFYWNoIGxpbmsgaXMgbWFuYWdlZCBhbmQ8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIGNvbnRyb2xsZWQgYXMgYSBiaS1kaXJlY3Rpb25hbCBMU1AuICBBdCBl YWNoIFBFLCB0aGVyZSBhcmUgYSBsYXJnZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIGNvbnRyb2xsZWQgYXMgYSBiaS1kaXJlY3Rpb25hbCBMU1AuICBBdCBlYWNoIFBFLCB0aGVy ZSBhcmUgYSBsYXJnZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbnVtYmVyIG9mIGJp LWRpcmVjdGlvbmFsIHVzZXIgZmxvd3MgZnJvbSBtdWx0aXBsZSBFdGhlcm5ldDwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG51bWJlciBvZiBiaS1kaXJlY3Rpb25hbCB1c2VyIGZs b3dzIGZyb20gbXVsdGlwbGUgRXRoZXJuZXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IGludGVyZmFjZXMuICBFYWNoIHVzZXIgZmxvdyB1c2VzIFBXcyB0byBjYXJyeSB0cmFmZmljIG9u IGZvcndhcmRpbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpbnRlcmZhY2Vz LiAgRWFjaCB1c2VyIGZsb3cgdXNlcyBQV3MgdG8gY2FycnkgdHJhZmZpYyBvbiBmb3J3YXJkaW5n PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhbmQgcmV2ZXJzZSBkaXJlY3Rpb24uICBU aGUgb3BlcmF0b3JzIG5lZWQgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIHVzZXI8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhbmQgcmV2ZXJzZSBkaXJlY3Rpb24uICBUaGUgb3BlcmF0 b3JzIG5lZWQgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIHVzZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTIiPjx0ZD48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgZmxvd3Mg KHRoYXQgaXMsIHRoZSBQVy1wYWlycykgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+dG8gYjwvc3Bhbj5l IGNhcnJpZWQgb24gdGhlIHNhbWUgZmliZXIgKG9yLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICBmbG93cyAodGhhdCBpcywgdGhlIFBXLXBhaXJzKSA8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij5hcjwvc3Bhbj5lIGNhcnJpZWQgb24gdGhlIHNhbWUgZmliZXIgKG9yLDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgYmlkaXJlY3Rpb25hbCBMU1ApLjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIGJpZGlyZWN0aW9uYWwgTFNQKS48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAxMyI+PHRkPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5BcyBtZW50aW9uZWQgYWJvdmUsIHRoZXJlIGFyZTwvc3Bh bj4gYSBudW1iZXIgb2YgcmVhc29ucyBiZWhpbmQgdGhpczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5UaGVyZSBpczwvc3Bhbj4gYSBudW1i ZXIgb2YgcmVhc29ucyBiZWhpbmQgdGhpcyByZXF1aXJlbWVudC4gIEZpcnN0LCBkdWUgdG88L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgcmVxdWlyZW1lbnQuICBGaXJzdCwgZHVlIHRv IGRlbGF5IGFuZCBsYXRlbmN5IGNvbnN0cmFpbnRzLCB0cmFmZmljPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgIGRlbGF5IGFuZCBsYXRlbmN5IGNvbnN0cmFpbnRzLCB0cmFmZmlj IGdvaW5nIG92ZXIgZGlmZmVyZW50IGZpYmVyczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gICBnb2luZyBvdmVyIGRpZmZlcmVudCBmaWJlcnMgbWF5IHJlcXVpcmUgbGFyZ2UgYW1vdW50 IG9mIGV4cGVuc2l2ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBtYXkgcmVx dWlyZSBsYXJnZSBhbW91bnQgb2YgZXhwZW5zaXZlIGJ1ZmZlciBtZW1vcnkgdG8gY29tcGVuc2F0 ZSBmb3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgYnVmZmVyIG1lbW9yeSB0byBj b21wZW5zYXRlIGZvciB0aGUgZGlmZmVyZW50aWFsIGRlbGF5IGF0IHRoZSBoZWFkZW5kPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHRoZSBkaWZmZXJlbnRpYWwgZGVsYXkgYXQg dGhlIGhlYWRlbmQgbm9kZXMuICBGdXJ0aGVyLCB0aGUgb3BlcmF0b3JzPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPiAgIG5vZGVzLiAgRnVydGhlciwgdGhlIG9wZXJhdG9ycyBtYXkgYXBw bHkgZGlmZmVyZW50IHByb3RlY3Rpb248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ ICAgbWF5IGFwcGx5IGRpZmZlcmVudCBwcm90ZWN0aW9uIG1lY2hhbmlzbXMgb24gZGlmZmVyZW50 IHBhcnRzIG9mIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBtZWNoYW5pc21z IG9uIGRpZmZlcmVudCBwYXJ0cyBvZiB0aGUgbmV0d29yay4gIEFzIHN1Y2gsIGZvciBvcHRpbWFs PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIG5ldHdvcmsuICBBcyBzdWNoLCBm b3Igb3B0aW1hbCB0cmFmZmljIG1hbmFnZW1lbnQsIHRyYWZmaWMgPHNwYW4gY2xhc3M9Imluc2Vy dCI+YmVsb25naW5nPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICB0cmFm ZmljIG1hbmFnZW1lbnQsIHRyYWZmaWMgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+YmVsb25nczwvc3Bh bj4gdG8gYSBwYXJ0aWN1bGFyIHVzZXIgc2hvdWxkPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgIHRvIGEgcGFydGljdWxhciB1c2VyIHNob3VsZCB0cmF2ZXJzZSBvdmVyIHRoZSBz YW1lIGZpYmVyLiAgVGhhdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICB0cmF2ZXJz ZSBvdmVyIHRoZSBzYW1lIGZpYmVyLiAgVGhhdCBpbXBsaWVzIHRoYXQgYm90aCBmb3J3YXJkaW5n IGFuZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBpbXBsaWVzIHRoYXQgYm90 aCBmb3J3YXJkaW5nIGFuZCByZXNlcnZlIGRpcmVjdGlvbiBQV3MgdGhhdCBiZWxvbmcgdG88L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgcmVzZXJ2ZSBkaXJlY3Rpb24gUFdzIHRoYXQg YmVsb25nIHRvIHRoZSBzYW1lIHVzZXIgZmxvdyBuZWVkIHRvIGJlPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgIHRoZSBzYW1lIHVzZXIgZmxvdyBuZWVkIHRvIGJlIG1hcHBlZCB0 byB0aGUgc2FtZSBjby1yb3V0ZWQgPHNwYW4gY2xhc3M9Imluc2VydCI+YmktPC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBtYXBwZWQgdG8gdGhlIHNhbWUgY28tcm91dGVk IDxzcGFuIGNsYXNzPSJkZWxldGUiPmJpLWRpcmVjdGlvbmFsPC9zcGFuPiBMU1Agb3IgdHdvIExT UHMgd2l0aCB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9 Imluc2VydCI+ICAgZGlyZWN0aW9uYWw8L3NwYW4+IExTUCBvciB0d28gTFNQcyB3aXRoIHRoZSBz YW1lIHJvdXRlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBzYW1lIHJvdXRlLjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgRmlndXJlIDIgaWxsdXN0cmF0ZXMgYSBzY2VuYXJpbyB3aGVyZSBQVy1MU1Ag YmluZGluZyBpcyBub3QgYXBwbGllZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBGaWd1cmUgMiBpbGx1c3RyYXRlcyBhIHNjZW5hcmlvIHdoZXJlIFBXLUxTUCBiaW5kaW5nIGlz IG5vdCBhcHBsaWVkLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAg ICAgICAgICAgICstLS0tKyAgICstLSsgTFNQMSArLS0rICAgKy0tLS0rPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICArLS0tLSsgICArLS0rIExTUDEg Ky0tKyAgICstLS0tKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgKy0tLS0t KyAgICB8IFBFMXw9PT18UDF8PT09PT09fFAyfD09PXwgUEUyfCAgICArLS0tLS0rPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgKy0tLS0tKyAgICB8IFBFMXw9PT18UDF8 PT09PT09fFAyfD09PXwgUEUyfCAgICArLS0tLS0rPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgICAgICB8ICAgICB8LS0tLXwgICAgfCAgICstLSsgICAgICArLS0rICAgfCAgICB8LS0t LXwgICAgIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICB8ICAgICB8 LS0tLXwgICAgfCAgICstLSsgICAgICArLS0rICAgfCAgICB8LS0tLXwgICAgIHw8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgIHwgQ0UxIHwgICAgfC4uLi4uLi4uLi4uLlBXLi4u Li4uLi4uLi4uLi4uLnwgICAgfCBDRTIgfDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgICAgICAgIHwgQ0UxIHwgICAgfC4uLi4uLi4uLi4uLlBXLi4uLi4uLi4uLi4uLi4uLnwgICAg fCBDRTIgfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgfCAgICAgfC0tLS18 ICAgIHwgICAgICArLS0rICAgICAgICAgIHwgICAgfC0tLS18ICAgICB8PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgfCAgICAgfC0tLS18ICAgIHwgICAgICArLS0rICAg ICAgICAgIHwgICAgfC0tLS18ICAgICB8PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAg ICAgICArLS0tLS0rICAgIHwgICAgfD09PT09PXxQM3w9PT09PT09PT09fCAgICB8ICAgICstLS0t LSs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICArLS0tLS0rICAgIHwg ICAgfD09PT09PXxQM3w9PT09PT09PT09fCAgICB8ICAgICstLS0tLSs8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgKy0tLS0rICAgICAgKy0tKyBMU1AyICAg ICArLS0tLSs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAg ICAgICstLS0tKyAgICAgICstLSsgTFNQMiAgICAgKy0tLS0rPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICAgICBGaWd1cmUgMjogSW5jb25zaXN0ZW50IFNTLVBXIHRvIExT UCBiaW5kaW5nIHNjZW5hcmlvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAg ICAgIEZpZ3VyZSAyOiBJbmNvbnNpc3RlbnQgU1MtUFcgdG8gTFNQIGJpbmRpbmcgc2NlbmFyaW88 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgTFNQMSBhbmQgTFNQMiBhcmUgdHdv IGJpZGlyZWN0aW9uYWwgY29ubmVjdGlvbnMgb24gZGl2ZXJzZSBwYXRocy48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBMU1AxIGFuZCBMU1AyIGFyZSB0d28gYmlkaXJlY3Rpb25h bCBjb25uZWN0aW9ucyBvbiBkaXZlcnNlIHBhdGhzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgVGhlIG9wZXJhdG9yIGlzIHRvIGRlbGl2ZXIgYSBiaS1kaXJlY3Rpb25hbCBmbG93IGJl dHdlZW4gUEUxIGFuZCBQRTIuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhl IG9wZXJhdG9yIGlzIHRvIGRlbGl2ZXIgYSBiaS1kaXJlY3Rpb25hbCBmbG93IGJldHdlZW4gUEUx IGFuZCBQRTIuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBVc2luZyB0aGUgZXhpc3Rp bmcgbWVjaGFuaXNtcywgaXQncyBwb3NzaWJsZSB0aGF0IFBFMSBtYXkgc2VsZWN0IExTUDE8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBVc2luZyB0aGUgZXhpc3RpbmcgbWVjaGFu aXNtcywgaXQncyBwb3NzaWJsZSB0aGF0IFBFMSBtYXkgc2VsZWN0IExTUDE8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIChQRTEtUDEtUDItUEUyKSBhcyB0aGUgUFNOIHR1bm5lbCBmb3Ig dHJhZmZpYyBmcm9tIFBFMSB0byBQRTIsIHdoaWxlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgKFBFMS1QMS1QMi1QRTIpIGFzIHRoZSBQU04gdHVubmVsIGZvciB0cmFmZmljIGZy b20gUEUxIHRvIFBFMiwgd2hpbGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0ciBpZD0iZGlmZjAwMTQiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgc2VsZWN0aW5nIExTUDIgKFBFPHNw YW4gY2xhc3M9ImRlbGV0ZSI+MS1QMy1QRTI8L3NwYW4+KSBhcyB0aGUgUFNOIHR1bm5lbCBmb3Ig dHJhZmZpYyBmcm9tIFBFMiB0bzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBz ZWxlY3RpbmcgTFNQMiAoUEU8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4yLVAzLVBFMTwvc3Bhbj4pIGFz IHRoZSBQU04gdHVubmVsIGZvciB0cmFmZmljIGZyb20gUEUyIHRvPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBQRTEuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUEUx LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBDb25zZXF1ZW50bHksIHRoZSB1 c2VyIHRyYWZmaWMgaXMgZGVsaXZlcmVkIG92ZXIgdHdvIGRpc2pvaW50IExTUHM8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBDb25zZXF1ZW50bHksIHRoZSB1c2VyIHRyYWZmaWMg aXMgZGVsaXZlcmVkIG92ZXIgdHdvIGRpc2pvaW50IExTUHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIHRoYXQgbWF5IGhhdmUgdmVyeSBkaWZmZXJlbnQgc2VydmljZSBhdHRyaWJ1dGVz IGluIHRlcm1zIG9mIGxhdGVuY3k8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0 aGF0IG1heSBoYXZlIHZlcnkgZGlmZmVyZW50IHNlcnZpY2UgYXR0cmlidXRlcyBpbiB0ZXJtcyBv ZiBsYXRlbmN5PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhbmQgcHJvdGVjdGlvbi4g IFRoaXMgbWF5IG5vdCBiZSBhY2NlcHRhYmxlIGFzIGEgcmVsaWFibGUgYW5kPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYW5kIHByb3RlY3Rpb24uICBUaGlzIG1heSBub3QgYmUg YWNjZXB0YWJsZSBhcyBhIHJlbGlhYmxlIGFuZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgZWZmZWN0aXZlIHRyYW5zcG9ydCBzZXJ2aWNlIHRvIHRoZSBjdXN0b21lcnMuPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZWZmZWN0aXZlIHRyYW5zcG9ydCBzZXJ2aWNlIHRv IHRoZSBjdXN0b21lcnMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0ciBpZD0iZGlmZjAwMTUiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ VGhlPC9zcGFuPiBzaW1pbGFyIDxzcGFuIGNsYXNzPSJkZWxldGUiPnByb2JsZW1zPC9zcGFuPiBt YXkgYWxzbyBleGlzdCBpbiBtdWx0aS1zZWdtZW50IFBXcyAoTVMtUFdzKSw8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+QTwvc3Bhbj4gc2lt aWxhciA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5wcm9ibGVtPC9zcGFuPiBtYXkgYWxzbyBleGlzdCBp biBtdWx0aS1zZWdtZW50IFBXcyAoTVMtUFdzKSwgd2hlcmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgd2hlcmUgdXNlciB0cmFmZmljIG9uIGEgcGFydGljdWxhciBQVyBtYXkgaG9w IG92ZXIgZGlmZmVyZW50IG5ldHdvcmtzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgIHVzZXIgdHJhZmZpYyBvbiBhIHBhcnRpY3VsYXIgUFcgbWF5IGhvcCBvdmVyIGRpZmZlcmVu dCBuZXR3b3JrcyBvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBvbiBmb3J3YXJk IGFuZCByZXZlcnNlIGRpcmVjdGlvbnMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgIGZvcndhcmQgYW5kIHJldmVyc2UgZGlyZWN0aW9ucy48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgT25lIHdheSB0byBzb2x2ZSB0aGlzIHByb2JsZW0gaXMgYnkgaW50cm9k dWNpbmcgbWFudWFsIGNvbmZpZ3VyYXRpb248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBPbmUgd2F5IHRvIHNvbHZlIHRoaXMgcHJvYmxlbSBpcyBieSBpbnRyb2R1Y2luZyBtYW51 YWwgY29uZmlndXJhdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYXQgZWFjaCBQ RSB0byBiaW5kIHRoZSBQV3MgdG8gdGhlIHVuZGVybHlpbmcgUFNOIHR1bm5lbHMuICBIb3dldmVy LDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGF0IGVhY2ggUEUgdG8gYmluZCB0 aGUgUFdzIHRvIHRoZSB1bmRlcmx5aW5nIFBTTiB0dW5uZWxzLiAgSG93ZXZlciw8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTYiPjx0ZD48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgdGhpcyBpcyBwcm9uZSB0byBjb25maWd1cmF0aW9uIGVycm9ycyBhbmQgPHNwYW4gY2xh c3M9ImRlbGV0ZSI+d29uJzwvc3Bhbj50IHNjYWxlLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICB0aGlzIGlzIHByb25lIHRvIGNvbmZpZ3VyYXRpb24gZXJyb3JzIGFuZCA8c3Bh biBjbGFzcz0iaW5zZXJ0Ij5kb2VzIG5vPC9zcGFuPnQgc2NhbGUuPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTciPjx0ZD48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+SW4gdGhpcyBkb2N1bWVudCwgaXQ8L3NwYW4+IGludHJv ZHVjZXMgYW4gYXV0b21hdGljIHNvbHV0aW9uIGJ5IGV4dGVuZGluZzwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5UaGlzIGRvY3VtZW50PC9z cGFuPiBpbnRyb2R1Y2VzIGFuIGF1dG9tYXRpYyBzb2x1dGlvbiBieSBleHRlbmRpbmcgRkVDPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIEZFQyAxMjgvMTI5IFBXIGJhc2VkIG9uIFtS RkM0NDQ3XS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgMTI4LzEyOSBQVyBi YXNlZCBvbiBbUkZDNDQ0N10uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjIuICBM RFAgRXh0ZW5zaW9uczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjIuICBMRFAgRXh0 ZW5zaW9uczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIGRvY3VtZW50 IGRlZmluZXMgYSBuZXcgb3B0aW9uYWwgVExWLCBQU04gVHVubmVsIEJpbmRpbmcgVExWLCB0bzwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBh IG5ldyBvcHRpb25hbCBUTFYsIFBTTiBUdW5uZWwgQmluZGluZyBUTFYsIHRvPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBjb21tdW5pY2F0ZSB0dW5uZWwvTFNQcyBzZWxlY3Rpb24gYW5k IGJpbmRpbmcgcmVxdWVzdHMgYmV0d2VlbiBQRXMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgY29tbXVuaWNhdGUgdHVubmVsL0xTUHMgc2VsZWN0aW9uIGFuZCBiaW5kaW5nIHJl cXVlc3RzIGJldHdlZW4gUEVzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIFRM ViBjYXJyaWVzIFBXJ3MgYmluZGluZyBwcm9maWxlIGFuZCBwcm92aWRlcyBleHBsaWNpdCBvcjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBUTFYgY2FycmllcyBQVydzIGJp bmRpbmcgcHJvZmlsZSBhbmQgcHJvdmlkZXMgZXhwbGljaXQgb3I8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIGltcGxpY2l0IGluZm9ybWF0aW9uIGZvciB0aGUgdW5kZXJseWluZyBQU04g dHVubmVsIGJpbmRpbmcgb3BlcmF0aW9uLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIGltcGxpY2l0IGluZm9ybWF0aW9uIGZvciB0aGUgdW5kZXJseWluZyBQU04gdHVubmVsIGJp bmRpbmcgb3BlcmF0aW9uLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUg YmluZGluZyBvcGVyYXRpb24gYXBwbGllcyBpbiBib3RoIHNpbmdsZS1zZWdtZW50IChTUykgYW5k IG11bHRpLTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBiaW5kaW5nIG9w ZXJhdGlvbiBhcHBsaWVzIGluIGJvdGggc2luZ2xlLXNlZ21lbnQgKFNTKSBhbmQgbXVsdGktPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBzZWdtZW50IChNUykgc2NlbmFyaW9zLjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHNlZ21lbnQgKE1TKSBzY2VuYXJpb3MuPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0icGFydC0z IiBjbGFzcz0iY2hhbmdlIiA+PHRkPjwvdGQ+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2Ug YXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTMiPjxlbT4gcGFnZSA1LCBsaW5lIDM5PHNwYW4gY2xh c3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxzbWFs bD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTMiPjxlbT4gcGFn ZSA1LCBsaW5lIDMyPHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90 aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBpZGVudGlmaWVkIGJ5IGEgU0VTU0lPTiBvYmplY3QgdGhhdCBpbmNsdWRl cyBUdW5uZWwgZW5kIHBvaW50PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaWRl bnRpZmllZCBieSBhIFNFU1NJT04gb2JqZWN0IHRoYXQgaW5jbHVkZXMgVHVubmVsIGVuZCBwb2lu dDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYWRkcmVzcywgVHVubmVsIElEIGFuZCBF eHRlbmRlZCBUdW5uZWwgSUQuICBUaGUgdGVybWlub2xvZ3kgIkxTUCIgaXM8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhZGRyZXNzLCBUdW5uZWwgSUQgYW5kIEV4dGVuZGVkIFR1 bm5lbCBJRC4gIFRoZSB0ZXJtaW5vbG9neSAiTFNQIiBpczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgaWRlbnRpY2FsIHRvIHRoZSAiTFNQIHR1bm5lbCIgZGVmaW5lZCBpbiBTZWN0aW9u IDIuMSBvZiBbUkZDMzIwOV0sPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaWRl bnRpY2FsIHRvIHRoZSAiTFNQIHR1bm5lbCIgZGVmaW5lZCBpbiBTZWN0aW9uIDIuMSBvZiBbUkZD MzIwOV0sPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB3aGljaCBpcyB1bmlxdWVseSBp ZGVudGlmaWVkIGJ5IHRoZSBTRVNTSU9OIG9iamVjdCB0b2dldGhlciB3aXRoPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgd2hpY2ggaXMgdW5pcXVlbHkgaWRlbnRpZmllZCBieSB0 aGUgU0VTU0lPTiBvYmplY3QgdG9nZXRoZXIgd2l0aDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgU0VOREVSX1RFTVBMQVRFIChvciBGSUxURVJfU1BFQykgb2JqZWN0IHRoYXQgY29uc2lz dHMgb2YgTFNQIElEIGFuZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFNFTkRF Ul9URU1QTEFURSAob3IgRklMVEVSX1NQRUMpIG9iamVjdCB0aGF0IGNvbnNpc3RzIG9mIExTUCBJ RCBhbmQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFR1bm5lbCBlbmRwb2ludCBhZGRy ZXNzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFR1bm5lbCBlbmRwb2ludCBh ZGRyZXNzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4yLjEuICBQU04gVHVubmVs IEJpbmRpbmcgVExWPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Mi4xLiAgUFNOIFR1 bm5lbCBCaW5kaW5nIFRMVjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBQU04g VHVubmVsIEJpbmRpbmcgVExWIGlzIGFuIG9wdGlvbmFsIFRMViBhbmQgTVVTVCBiZSBjYXJyaWVk IGluIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFBTTiBUdW5uZWwgQmlu ZGluZyBUTFYgaXMgYW4gb3B0aW9uYWwgVExWIGFuZCBNVVNUIGJlIGNhcnJpZWQgaW4gdGhlPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDE4Ij48 dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPiAgIExEUCBMYWJlbCBNYXBwaW5nIG1lc3NhZ2UgaWYgUFcgdG8gTFNQIGJpbmRp bmcgaXMgcmVxdWlyZWQuICBUaGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg TERQIExhYmVsIE1hcHBpbmcgbWVzc2FnZSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5bUkZDNTAzNl08 L3NwYW4+IGlmIFBXIHRvIExTUCBiaW5kaW5nIGlzIHJlcXVpcmVkLjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICBmb3JtYXQgaXMgYXMgZm9sbG93czo8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICAgVGhlIGZvcm1hdCBpcyBhcyBmb2xsb3dzOjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAg ICAgICAgICAyICAgICAgICAgICAgICAgICAgIDM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAg ICAgICAgICAgICAgIDM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgMCAxIDIgMyA0 IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgIHwxfDB8IFBTTiBU dW5uZWwgQmluZGluZyAoVEJEMSkgfCAgICAgICAgICAgICBMZW5ndGggICAgICAgICAgICB8PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgIHwxfDB8IFBTTiBUdW5uZWwgQmluZGlu ZyAoVEJEMSkgfCAgICAgICAgICAgICBMZW5ndGggICAgICAgICAgICB8PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICB8ICAgICAgICAg ICAgICBGbGFnICAgICAgICAgICAgIHwgICAgICAgICAgICBSZXNlcnZlZCAgICAgICAgICAgfDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICB8ICAgICAgICAgICAgICBGbGFnICAg ICAgICAgICAgIHwgICAgICAgICAgICBSZXNlcnZlZCAgICAgICAgICAgfDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgfiAgICAgICAg ICAgICAgICAgICAgICAgUFNOIFR1bm5lbCBTdWItVExWICAgICAgICAgICAgICAgICAgICAgIH48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgfiAgICAgICAgICAgICAgICAgICAg ICAgUFNOIFR1bm5lbCBTdWItVExWICAgICAgICAgICAgICAgICAgICAgIH48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KCiAgICAg PHRyPjx0ZD48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQ+PC90ZD48L3RyPgogICAgIDx0ciBpZD0iZW5kIiBiZ2NvbG9yPSJncmF5 Ij48dGggY29sc3Bhbj0iNSIgYWxpZ249ImNlbnRlciI+Jm5ic3A7RW5kIG9mIGNoYW5nZXMuIDE4 IGNoYW5nZSBibG9ja3MuJm5ic3A7PC90aD48L3RyPgogICAgIDx0ciBjbGFzcz0ic3RhdHMiPjx0 ZD48L3RkPjx0aD48aT40NyBsaW5lcyBjaGFuZ2VkIG9yIGRlbGV0ZWQ8L2k+PC90aD48dGg+PGk+ IDwvaT48L3RoPjx0aD48aT40NCBsaW5lcyBjaGFuZ2VkIG9yIGFkZGVkPC9pPjwvdGg+PHRkPjwv dGQ+PC90cj4KICAgICA8dHI+PHRkIGNvbHNwYW49IjUiIGFsaWduPSJjZW50ZXIiIGNsYXNzPSJz bWFsbCI+PGJyLz5UaGlzIGh0bWwgZGlmZiB3YXMgcHJvZHVjZWQgYnkgcmZjZGlmZiAxLjQ1LiBU aGUgbGF0ZXN0IHZlcnNpb24gaXMgYXZhaWxhYmxlIGZyb20gPGEgaHJlZj0iaHR0cDovL3d3dy50 b29scy5pZXRmLm9yZy90b29scy9yZmNkaWZmLyIgPmh0dHA6Ly90b29scy5pZXRmLm9yZy90b29s cy9yZmNkaWZmLzwvYT4gPC90ZD48L3RyPgogICA8L3RhYmxlPgogICA8L2JvZHk+CiAgIDwvaHRt bD4K --_002_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28C206D6FSZXEMA510MBXchi_-- From nobody Fri May 13 05:17:56 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4C812D185; Fri, 13 May 2016 05:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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.996, 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 ZRb9OSKC4l-h; Fri, 13 May 2016 05:17:50 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8BB112D18F; Fri, 13 May 2016 05:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10242; q=dns/txt; s=iport; t=1463141869; x=1464351469; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=On3CJIF6VoY7nRclT4NZ3E3ygT2jTMQgcPPkMD304g8=; b=eZSFZjFzN4VXwoQjEMu+3preUDZ0dVfzj7B/RT6aNcSqy68LYLah1tTp 1cEZ+c8zMz62YQc/lRmsoQ2yT+5W2yqI6gAUUvhj5T4glE+GOp4WubBTW xosX+bIPPe0mTR+hLVVy12E79SXNUw2Iguwl4RgSdkkb2UN8Zcjo/mYpa E=; X-Files: shadow.txt : 2271 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C6AgDgxDVX/5xdJa1VCYM3VX4GuVEOg?= =?us-ascii?q?XYihXICgS84FAEBAQEBAQFlJ4RCAQEBBCdSDAQCAQgRAQMBAQEuAjAXBggCBAE?= =?us-ascii?q?NBQgGiCEOv24BAQEBAQEBAQEBAQEBAQEBAQEBAQEOCQWGJYRNhBEHCgEzhUIBB?= =?us-ascii?q?Id+kCkBgyiBaIkGgXCET4hhj0ABHgFDg2xuAYckNn8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,614,1454976000"; d="txt'?scan'208";a="273254413" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 May 2016 12:17:48 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u4DCHmMK027746 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 May 2016 12:17:48 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 May 2016 07:17:48 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Fri, 13 May 2016 07:17:47 -0500 From: "Les Ginsberg (ginsberg)" To: "Joe Clarke (jclarke)" , "rtg-ads@ietf.org" Thread-Topic: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 Thread-Index: AdGgzHD5AnaTBqcTQJm4IHI17iI2lQBnClYAAieCg0AALuo+AAACzD3QAAvztwAARQFW8A== Date: Fri, 13 May 2016 12:17:47 +0000 Message-ID: <30733d2a0880449dbd5cf930c48ad6be@XCH-ALN-001.cisco.com> References: <5afaa922862d4b4a9dc67f117ae5366a@XCH-ALN-001.cisco.com> <978721df-6b95-dff7-af53-31d42a731946@cisco.com> <6dde8ef61dbf4faa98387fee01516dc3@XCH-ALN-001.cisco.com> <26dfa4d7-dd81-de1f-57b7-ae6fa9641fb5@cisco.com> In-Reply-To: <26dfa4d7-dd81-de1f-57b7-ae6fa9641fb5@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.107.134] Content-Type: multipart/mixed; boundary="_002_30733d2a0880449dbd5cf930c48ad6beXCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-i2rs-traceability@ietf.org" , "i2rs@ietf.org" Subject: Re: [RTG-DIR] [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 12:17:52 -0000 --_002_30733d2a0880449dbd5cf930c48ad6beXCHALN001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Joe - Something like the attached file perhaps? Les > -----Original Message----- > From: Joe Clarke (jclarke) > Sent: Wednesday, May 11, 2016 3:21 PM > To: Les Ginsberg (ginsberg); rtg-ads@ietf.org > Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; i2rs@ietf.or= g > Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 >=20 > On 5/11/16 17:39, Les Ginsberg (ginsberg) wrote: > > Joe - > > > > Yes - this looks better to me. > > > > What about the "shadow boxes" for Applications/Clients? >=20 > Do you have an example draft I could look at for that? >=20 > Joe >=20 > > > > Les > > > > > >> -----Original Message----- > >> From: Joe Clarke (jclarke) > >> Sent: Wednesday, May 11, 2016 8:19 AM > >> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org > >> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; > >> i2rs@ietf.org > >> Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 > >> > >> On 5/10/16 18:04, Les Ginsberg (ginsberg) wrote: > >>> Joe - > >>> > >>> Apologies for the delayed response. I am a victim of my own email > >>> infilters. :-( Inline. > >> > >> Thanks, Les. Have a look at > >> https://www.marcuscom.com/draft-ietf-i2rs-traceability.txt-from-09- > >> 10.diff.html > >> . I added a new line to show the flow in both directions. > >> > >> Joe > >> > >>> > >>>> -----Original Message----- > >>>> From: Joe Clarke (jclarke) > >>>> Sent: Friday, April 29, 2016 10:44 AM > >>>> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org > >>>> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; > >>>> i2rs@ietf.org > >>>> Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 > >>>> > >>>> On 4/27/16 17:39, Les Ginsberg (ginsberg) wrote: > >>>>> Summary: This document is a well written document - easy to > >> understand. > >>>>> My compliments to the authors. I believe there is one minor issue > >>>>> which I would like to see addressed before publication. > >>>> > >>>> Thanks for your comments and feedback, Les. Please see below for > >>>> some replies and questions. > >>>> > >>>>> In Section 5.2 there is a definition of the information which is > >>>>> required to be kept by an I2RS Agent for each I2RS interaction. I > >>>>> would like to see the addition of "Request State" into this list. > >>>>> Operationally each request could be in one of the following states: > >>>>> > >>>>> > >>>>> > >>>>> * Enqueued (or pending if you prefer) > >>>>> > >>>>> * In process > >>>>> > >>>>> * Completed > >>>>> > >>>>> > >>>>> > >>>>> The lack of such a state seems to imply that both the queue time > >>>>> and the processing time are insignificant. While I think this may > >>>>> be the case for many requests, it will not always be the case. In > >>>>> queue time may be lengthy due to other load on the Agent. Also, > >>>>> some requests - particularly destructive requests which involve > >>>>> cleanup of resources - may take a significant amount of time to > complete. > >>>> > >>>> Good observation. Traceability was aimed mainly at the termination > >>>> of the request, but I like the idea of tracing the state machine. > >>>> > >>>>> > >>>>> > >>>>> > >>>>> Along with this an additional timestamp - Processing Initiated - > >>>>> would be useful to indicate when processing of the request > >>>>> actually > >> began. > >>>> > >>>> I don't know we need a new timestamp. Perhaps we just need to > >> rename > >>>> "Request Timestamp" and "Result Timestamp" to "Start Timestamp" > and > >>>> "End Timestamp" to denote the time within the current state. What > >>>> do you think? > >>> > >>> [Les:] My intent was to log the time at which the request began > >>> processing > >> so that you can see whether a long delay in completion was due to > >> enqueue delay or actual lengthy processing time. I am not adamant > >> about this so if you want to stay with the two timestamps that is OK. > >>> > >>>> > >>>>> s/Some notable elements on the architecture/ Some notable > elements > >>>>> of the architecture > >>>> > >>>> Fixed. Thanks! > >>>> > >>>>> > >>>>> > >>>>> > >>>>> Figure 1 > >>>>> > >>>>> > >>>>> > >>>>> Not clear to me why Application IDs start at 0 but Client IDs start= at 1. > >>>> > >>>> Ah. The numbers there are not IDs. They are the number of actual > >>>> things in the boxes above. For Applications, there may be 0 to N > >>>> for a given client. For Clients, you need at least 1. Does that ma= ke > sense? > >>>> > >>> [Les:] Maybe you want to use "shadows" on the boxes to indicate > >>> there > >> can be multiple Application boxes and multiple Client boxes? > >>> What you say makes sense but I do not intuit that when I look at the > >>> ASSCII > >> art. > >>> > >>>>> > >>>>> > >>>>> > >>>>> Figure 1 > >>>>> > >>>>> > >>>>> > >>>>> Is the text "Op Data V" between I2RS Agent box and Routing System > >>>>> box intentional? > >>>> > >>>> Yes. The 'V' is meant to be an arrow head pointed down. The > >>>> request and data go from Client to Agent whereas the Response goes > >>>> from Agent to Client. > >>>> > >>>> We are open to suggestions on how to make this clearer. > >>> > >>> [Les:] I think it would be clearer if you had two lines - one > >>> flowing down > >> associated with the Op Data and one flowing up with the result. > >>> > >>>> > >>>>> > >>>>> > >>>>> > >>>>> Section 5.2 > >>>>> > >>>>> > >>>>> > >>>>> Secondary Identity > >>>>> > >>>>> > >>>>> > >>>>> This is defined to be "opaque" yet if not provided the agent is > >>>>> supposed to insert "an UNAVAILABLE value". This seems to be a > >>>>> contradiction unless we have a publicly defined value that clients > >>>>> are prohibited from using. Absent that you would need a "Secondary > >> Identity Valid" indicator. > >>>> > >>>> Good observation. I think it's fine to say that this field must be > >>>> logged. If there is no application, then the field will be logged > >>>> as empty. If there is an application, then whatever value is > >>>> provided will be logged. > >>>> > >>>> Do you feel strongly that we need a field to indicate Application > Present? > >>>> > >>> [Les:] I am fine w your changes. > >>> > >>> Les > >>> > >>>>> > >>>>> > >>>>> > >>>>> Section 7.4 > >>>>> > >>>>> > >>>>> > >>>>> s/establish an vendor-agnostic/establish a vendor-agnostic > >>>> > >>>> Fixed. Thanks! > >>>> > >>>> Joe > > --_002_30733d2a0880449dbd5cf930c48ad6beXCHALN001ciscocom_ Content-Type: text/plain; name="shadow.txt" Content-Description: shadow.txt Content-Disposition: attachment; filename="shadow.txt"; size=2271; creation-date="Fri, 13 May 2016 12:06:05 GMT"; modification-date="Fri, 13 May 2016 12:16:43 GMT" Content-Transfer-Encoding: base64 DQoNCiAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgKy0tLS0tLS0tLS0t LS0tLS0rICB8DQogICAgICAgICB8QXBwbGljYXRpb24gICAgIHwgIHwNCiAgICAgICAgIHwuLi4u Li4uLi4uLi4uLiAgfCAgfCAgMCBvciBtb3JlIEFwcGxpY2F0aW9ucw0KICAgICAgICAgfCBBcHBs aWNhdGlvbiBJRCB8ICArDQogICAgICAgICArLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAg ICAgICBeDQogICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAg ICAgICB2DQogICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0rDQogICAgICAgICArLS0tLS0tLS0t LS0tLSsgICB8DQogICAgICAgICB8STJSUyBDbGllbnQgIHwgICB8ICAgMSBvciBtb3JlIENsaWVu dHMNCiAgICAgICAgIHwuLi4uLi4uLi4uLi4ufCAgIHwNCiAgICAgICAgIHwgIENsaWVudCBJRCAg fCAgICsNCiAgICAgICAgICstLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgIF4NCiAgICAg ICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgIHYNCiAgICAg ICAgICstLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKw0KICAgICAgICAgfEkyUlMgQWdlbnQgICB8LS0tLS0tLS0tLS0tLS0tLT58VHJh Y2UgTG9nICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICB8ICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgIHwuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLnwNCiAgICAgICAgICst LS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgfExvZyBFbnRyeSAgWzEgLi4gTl0gICAgICAg ICAgfA0KICAgICAgICAgICAgICAgIF4gICAgICAgICAgICAgICAgICAgICAgICB8Li4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi58DQogICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgIHxTdGFydGluZyBUaW1lc3RhbXAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgfFJlcXVlc3QgU3RhdGUgICAgICAgICAgICAgICAgfA0K ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8Q2xpZW50IElEICAgICAg ICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg IHxDbGllbnQgUHJpb3JpdHkgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICB8ICAgICAg XiAgICAgICAgICAgICAgICAgfFNlY29uZGFyeSBJRCAgICAgICAgICAgICAgICAgfA0KICAgIE9w ZXJhdGlvbiArIHwgUmVzdWx0IENvZGUgICAgICAgICAgICB8Q2xpZW50IEFkZHJlc3MgICAgICAg ICAgICAgICB8DQogICAgIE9wIERhdGEgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHxSZXF1 ZXN0ZWQgT3BlcmF0aW9uICAgICAgICAgIHwNCiAgICAgICB2ICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgfEFwcGxpZWQgT3BlcmF0aW9uICAgICAgICAgICAgfA0KICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8T3BlcmF0aW9uIERhdGEgUHJlc2VudCAgICAg ICB8DQogICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHxSZXF1ZXN0ZWQg T3BlcmF0aW9uIERhdGEgICAgIHwNCiAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgfEFwcGxpZWQgT3BlcmF0aW9uIERhdGEgICAgICAgfA0KICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICB8VHJhbnNhY3Rpb24gSUQgICAgICAgICAgICAgICB8DQog ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHxSZXN1bHQgQ29kZSAgICAg ICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg fEVuZGluZyBUaW1lc3RhbXAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICB8VGltZW91dCBPY2N1cnJlZCAgICAgICAgICAgICB8DQogICAgICAg ICAgICAgICAgdiAgICAgICAgICAgICAgICAgICAgICAgIHxFbmQgT2YgTWVzc2FnZSAgICAgICAg ICAgICAgIHwNCiAgICAgICAgICstLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgfFJvdXRpbmcgICAgICB8DQogICAg ICAgICB8U3lzdGVtICAgICAgIHwNCiAgICAgICAgICstLS0tLS0tLS0tLS0tKw0K --_002_30733d2a0880449dbd5cf930c48ad6beXCHALN001ciscocom_-- From nobody Fri May 13 08:35:47 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274A812D588; Fri, 13 May 2016 08:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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.996, 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 n6DDLLZOH5Yt; Fri, 13 May 2016 08:35:41 -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 31E0D12D594; Fri, 13 May 2016 08:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6734; q=dns/txt; s=iport; t=1463153739; x=1464363339; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=or1u/pEM7cstaQ84KGrAQeTAliYj8b4P78S4DuA7f4M=; b=UPj+I9vIDsX19zU43xqJCk4WzkBdb1pexOseveM1ynYbpMqjC4SyLRMp L64kPZXos/IMLHkY9is7C43MkraET0upiPjO/GD/uXDyrtnSUx99kijnh kIAT/hJhhjIzjTxDSHqVG9JX0UP+H2dtDJWctHxkjXjE+YmknopqPfE46 I=; X-IronPort-AV: E=Sophos;i="5.24,614,1454976000"; d="scan'208";a="104055048" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 May 2016 15:35:38 +0000 Received: from [10.118.87.83] (rtp-jclarke-nitro2.cisco.com [10.118.87.83]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u4DFZbV3000687; Fri, 13 May 2016 15:35:38 GMT To: "Les Ginsberg (ginsberg)" , "rtg-ads@ietf.org" References: <5afaa922862d4b4a9dc67f117ae5366a@XCH-ALN-001.cisco.com> <978721df-6b95-dff7-af53-31d42a731946@cisco.com> <6dde8ef61dbf4faa98387fee01516dc3@XCH-ALN-001.cisco.com> <26dfa4d7-dd81-de1f-57b7-ae6fa9641fb5@cisco.com> <30733d2a0880449dbd5cf930c48ad6be@XCH-ALN-001.cisco.com> From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: Date: Fri, 13 May 2016 11:35:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <30733d2a0880449dbd5cf930c48ad6be@XCH-ALN-001.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-i2rs-traceability@ietf.org" , "i2rs@ietf.org" Subject: Re: [RTG-DIR] [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 15:35:44 -0000 On 5/13/16 08:17, Les Ginsberg (ginsberg) wrote: > Joe - > > Something like the attached file perhaps? Thanks. We have posted rev -10 of this draft that should address all of your comments. Joe > > Les > > >> -----Original Message----- >> From: Joe Clarke (jclarke) >> Sent: Wednesday, May 11, 2016 3:21 PM >> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org >> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; i2rs@ietf.org >> Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 >> >> On 5/11/16 17:39, Les Ginsberg (ginsberg) wrote: >>> Joe - >>> >>> Yes - this looks better to me. >>> >>> What about the "shadow boxes" for Applications/Clients? >> >> Do you have an example draft I could look at for that? >> >> Joe >> >>> >>> Les >>> >>> >>>> -----Original Message----- >>>> From: Joe Clarke (jclarke) >>>> Sent: Wednesday, May 11, 2016 8:19 AM >>>> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org >>>> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; >>>> i2rs@ietf.org >>>> Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 >>>> >>>> On 5/10/16 18:04, Les Ginsberg (ginsberg) wrote: >>>>> Joe - >>>>> >>>>> Apologies for the delayed response. I am a victim of my own email >>>>> infilters. :-( Inline. >>>> >>>> Thanks, Les. Have a look at >>>> https://www.marcuscom.com/draft-ietf-i2rs-traceability.txt-from-09- >>>> 10.diff.html >>>> . I added a new line to show the flow in both directions. >>>> >>>> Joe >>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Joe Clarke (jclarke) >>>>>> Sent: Friday, April 29, 2016 10:44 AM >>>>>> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org >>>>>> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; >>>>>> i2rs@ietf.org >>>>>> Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 >>>>>> >>>>>> On 4/27/16 17:39, Les Ginsberg (ginsberg) wrote: >>>>>>> Summary: This document is a well written document - easy to >>>> understand. >>>>>>> My compliments to the authors. I believe there is one minor issue >>>>>>> which I would like to see addressed before publication. >>>>>> >>>>>> Thanks for your comments and feedback, Les. Please see below for >>>>>> some replies and questions. >>>>>> >>>>>>> In Section 5.2 there is a definition of the information which is >>>>>>> required to be kept by an I2RS Agent for each I2RS interaction. I >>>>>>> would like to see the addition of "Request State" into this list. >>>>>>> Operationally each request could be in one of the following states: >>>>>>> >>>>>>> >>>>>>> >>>>>>> * Enqueued (or pending if you prefer) >>>>>>> >>>>>>> * In process >>>>>>> >>>>>>> * Completed >>>>>>> >>>>>>> >>>>>>> >>>>>>> The lack of such a state seems to imply that both the queue time >>>>>>> and the processing time are insignificant. While I think this may >>>>>>> be the case for many requests, it will not always be the case. In >>>>>>> queue time may be lengthy due to other load on the Agent. Also, >>>>>>> some requests - particularly destructive requests which involve >>>>>>> cleanup of resources - may take a significant amount of time to >> complete. >>>>>> >>>>>> Good observation. Traceability was aimed mainly at the termination >>>>>> of the request, but I like the idea of tracing the state machine. >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Along with this an additional timestamp - Processing Initiated - >>>>>>> would be useful to indicate when processing of the request >>>>>>> actually >>>> began. >>>>>> >>>>>> I don't know we need a new timestamp. Perhaps we just need to >>>> rename >>>>>> "Request Timestamp" and "Result Timestamp" to "Start Timestamp" >> and >>>>>> "End Timestamp" to denote the time within the current state. What >>>>>> do you think? >>>>> >>>>> [Les:] My intent was to log the time at which the request began >>>>> processing >>>> so that you can see whether a long delay in completion was due to >>>> enqueue delay or actual lengthy processing time. I am not adamant >>>> about this so if you want to stay with the two timestamps that is OK. >>>>> >>>>>> >>>>>>> s/Some notable elements on the architecture/ Some notable >> elements >>>>>>> of the architecture >>>>>> >>>>>> Fixed. Thanks! >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Figure 1 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Not clear to me why Application IDs start at 0 but Client IDs start at 1. >>>>>> >>>>>> Ah. The numbers there are not IDs. They are the number of actual >>>>>> things in the boxes above. For Applications, there may be 0 to N >>>>>> for a given client. For Clients, you need at least 1. Does that make >> sense? >>>>>> >>>>> [Les:] Maybe you want to use "shadows" on the boxes to indicate >>>>> there >>>> can be multiple Application boxes and multiple Client boxes? >>>>> What you say makes sense but I do not intuit that when I look at the >>>>> ASSCII >>>> art. >>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Figure 1 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Is the text "Op Data V" between I2RS Agent box and Routing System >>>>>>> box intentional? >>>>>> >>>>>> Yes. The 'V' is meant to be an arrow head pointed down. The >>>>>> request and data go from Client to Agent whereas the Response goes >>>>>> from Agent to Client. >>>>>> >>>>>> We are open to suggestions on how to make this clearer. >>>>> >>>>> [Les:] I think it would be clearer if you had two lines - one >>>>> flowing down >>>> associated with the Op Data and one flowing up with the result. >>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Section 5.2 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Secondary Identity >>>>>>> >>>>>>> >>>>>>> >>>>>>> This is defined to be "opaque" yet if not provided the agent is >>>>>>> supposed to insert "an UNAVAILABLE value". This seems to be a >>>>>>> contradiction unless we have a publicly defined value that clients >>>>>>> are prohibited from using. Absent that you would need a "Secondary >>>> Identity Valid" indicator. >>>>>> >>>>>> Good observation. I think it's fine to say that this field must be >>>>>> logged. If there is no application, then the field will be logged >>>>>> as empty. If there is an application, then whatever value is >>>>>> provided will be logged. >>>>>> >>>>>> Do you feel strongly that we need a field to indicate Application >> Present? >>>>>> >>>>> [Les:] I am fine w your changes. >>>>> >>>>> Les >>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Section 7.4 >>>>>>> >>>>>>> >>>>>>> >>>>>>> s/establish an vendor-agnostic/establish a vendor-agnostic >>>>>> >>>>>> Fixed. Thanks! >>>>>> >>>>>> Joe >>> > From nobody Tue May 17 00:06:54 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B51D12D58B for ; Tue, 17 May 2016 00:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 Gwh6jhoaUmcd for ; Tue, 17 May 2016 00:06:50 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F29C712D59D for ; Tue, 17 May 2016 00:06:49 -0700 (PDT) Received: from rufsun5.fkie.fraunhofer.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1b2Z5Z-0002n3-Fp; Tue, 17 May 2016 09:06:45 +0200 Received: from mailserv2acas.fkie.fraunhofer.de ([128.7.96.54] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1b2Z5Z-0007Cx-Bu; Tue, 17 May 2016 09:06:45 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 17 May 2016 09:06:45 +0200 To: , , , "shares@ndzh.com >> Susan Hares" From: Henning Rogge Message-ID: <573AC2F9.8050607@fkie.fraunhofer.de> Date: Tue, 17 May 2016 09:06:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000900090208060501070001" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.98.1/21560/Tue May 17 06:56:46 2016) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 8318846d41f6f18a0ab4cdd00a4712ab Archived-At: Cc: rtg-dir@ietf.org Subject: Re: [RTG-DIR] Routing directorate QA review of draft-ietf-i2rs-yang-l2-network-topology X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 07:06:52 -0000 --------------ms000900090208060501070001 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I have been asked to provide a review to the following document to the=20 routing directorate mailing list. Please be aware that this is the first time I work with YANG and related = drafts. Document: draft-ietf-i2rs-yang-l2-network-topology-02 Reviewer: Henning Rogge Review Date: Mai 16th, 2016 Intended Status: Standards Track The data structure suggested by the draft is reasonable and would fit=20 most Layer2 network technologies. I have a couple of points on the draft = document which might be worth looking into: * The introduction in=20 https://tools.ietf.org/html/draft-ietf-i2rs-yang-l2-network-topology-02=20 includes a link to "I-D.ietf-netmod-rfc6020bis" that links back to the=20 draft document itself. Maybe some links in the document refer to an=20 older name of the draft? * the "termination-point" element only contains the types "ethernet" and = "legacy" (which does not contain any data like mac-address). Is this=20 reasonable or should a few data elements moved from the "ethernet"=20 category to the "l2-termination-point-attributes" category? * there are different types of VLAN tags be used... should there be=20 another field ("vlan-type" ?) to announce 802.1ad QinQ usage? I think=20 the 802.1ad tag is also sometimes also used to move VLAN over a switch=20 that doesn't support it (unknown Ethertypes are usually just ignored),=20 which means just knowing the VLAN-id is not enough to reach the endpoint.= * the type of ethernet (100, 1000, 10000) or data-rate could be an=20 important attribute for an ethernet termination point, not only for links= =2E Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms000900090208060501070001 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC Fc4wggTVMIIDvaADAgECAghQTsb1PRG0ZDANBgkqhkiG9w0BAQsFADBxMQswCQYDVQQGEwJE RTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMTQw NzIyMTIwODI2WhcNMTkwNzA5MjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZO LVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xv YmFsIC0gRzAxMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTD llA1PWLpbkztlNcAW5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1 OXstkEXQ7aAAeny/Sg4bAMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8B r3QPwQmi9mvOvdPNFDBP9eXjpMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9 bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSa cXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7wxLyvQIDAQABo4IBhjCCAYIwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAWgBQxw3kbuvVT 1xfgiXotF2wKsyudMzASBgNVHRMBAf8ECDAGAQH/AgECMGIGA1UdIARbMFkwEQYPKwYBBAGB rSGCLAEBBAICMBEGDysGAQQBga0hgiwBAQQDADARBg8rBgEEAYGtIYIsAQEEAwEwDwYNKwYB BAGBrSGCLAEBBDANBgsrBgEEAYGtIYIsHjA+BgNVHR8ENzA1MDOgMaAvhi1odHRwOi8vcGtp MDMzNi50ZWxlc2VjLmRlL3JsL0RUX1JPT1RfQ0FfMi5jcmwweAYIKwYBBQUHAQEEbDBqMCwG CCsGAQUFBzABhiBodHRwOi8vb2NzcDAzMzYudGVsZXNlYy5kZS9vY3NwcjA6BggrBgEFBQcw AoYuaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9jcnQvRFRfUk9PVF9DQV8yLmNlcjANBgkq hkiG9w0BAQsFAAOCAQEAYyAo/ZwhhnK+OUZZOTIlvKkBmw3Myn1BnIZtCm4ssxNZdbEzkhth Jxb/w7LVNYL7hCoBSb1mu2YvssIGXW4/buMBWlvKQ2NclbbhMacf1QdfTeZlgk4y+cN8ekvN TVx07iHydQLsUj7SyWrTkCNuSWc1vn9NVqTszC/Pt6GXqHI+ybxA1lqkCD3WvILDt7cyjrEs jmpttzUCGc/1OURYY6ckABCwu/xOr24vOLulV0k/2G5QbyyXltwdRpplic+uzPLl2Z9Tsz6h L5Kp2AvGhB8Exuse6J99tXulAvEkxSRjETTMWpMgKnmIOiVCkKllO3yG0xIVIyn8LNrMOVtU FzCCBUowggQyoAMCAQICBxeQYKGRdGswDQYJKoZIhvcNAQELBQAwWjELMAkGA1UEBhMCREUx EzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1W ZXJlaW4gUENBIEdsb2JhbCAtIEcwMTAeFw0xNDA1MTIxNTA0NDlaFw0xOTA3MDYwMDAwMDBa MIGMMQswCQYDVQQGEwJERTEPMA0GA1UECBMGQmF5ZXJuMREwDwYDVQQHEwhNdWVuY2hlbjET MBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJ MSEwHwYDVQQDExhGcmF1bmhvZmVyIFVzZXIgQ0EgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCsA4caCbardAYRYqXl5xaisARZ+KTdO6XHnMoJRnznUB8kwhyy9LyV QEoiEhbqT3Gl3oNnEoIhZDx6mGOgYwcI1M4Z/eVrmJYBsumo5doNWi/ajmNmX62SCG84jaR9 7Q3ZuGMHJpybRwbTnpPQ0bGx4pWfnN9nht9gqA0Utczy46AhEo/lrKhKz1vCEZ3yVMBTc6tH qCZ9SAx4L2gaIZcsWiMY75CZq1h/L/ED/XJKjE4kkeZvMAFORtvw6+YRIEOqkDix4FCh2pwS h8+/LqF3JOTo7yg+l6kTc6H51NsjkbcPP8Ji5fk9kOxELcOE1SmQGux75B6DXivTa6Solauf AgMBAAGjggHgMIIB3DASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjARBgNV HSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFBFNpHezEtYG9X6MCLgaSsyiebjNMB8GA1UdIwQY MBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2Nk cDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNybDA9oDugOYY3 aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2NhY3JsLmNy bDCB1wYIKwYBBQUHAQEEgcowgccwMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4u ZGUvT0NTUC1TZXJ2ZXIvT0NTUDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5k ZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0 dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQu Y3J0MA0GCSqGSIb3DQEBCwUAA4IBAQB+OiPDi5ODuL1fyrhg6k+czYftfviedRpAOlXLSvY1 ++toS7+zT4cmbRBjxA0V50MqP9UrGZ4CxCnmxRSMPeoxOyqEc1sCnbtx44kvibBcWtfi2xBc suagX8EkZU73uhVZZzziEy+keFQo8hEESDIgwksBbbvN/EMkDLXxzjfJlgEuNaxoedfP3u5g RYZgkH1unnjb5slV63+Nq/T5oLPRCfvbiTPzeQ2eW3IsTgbt0TSaw3328vtpxSLE6F713zKX IOxgtxLt/LjSy/g9a23l25pSyox+3Mj7aCeow1hWFQbOWWG3+FKAgVRkt4N1DU2RJ+OfC+km J6LCsk3Dpra6MIIFwzCCBKugAwIBAgIHGqCN/G9HdzANBgkqhkiG9w0BAQsFADCBjDELMAkG A1UEBhMCREUxDzANBgNVBAgTBkJheWVybjERMA8GA1UEBxMITXVlbmNoZW4xEzARBgNVBAoT CkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEhMB8GA1UE AxMYRnJhdW5ob2ZlciBVc2VyIENBIC0gRzAxMB4XDTE1MTIyODEwMzUyNVoXDTE4MTIyNzEw MzUyNVowWjELMAkGA1UEBhMCREUxEzARBgNVBAoMCkZyYXVuaG9mZXIxDTALBgNVBAsMBEZL SUUxDzANBgNVBAsMBlBlb3BsZTEWMBQGA1UEAwwNSGVubmluZyBSb2dnZTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAJqU80SAMrJq3cc7pirN6gPjt8eptOkU7SDJH2DxFBHl 8zXSLZE9TlMyaPw3ndOUlPXBYRq+1yqB+zGkV4+PdSNvO+J/ea/9vA2W2mgPBqkRQQEUkCMz EsAjnJko8flUbpMn0T0X8srCFvbd4LpDg2V61/t77XhB3bE2MsoXxkoDRvaysesWx6aDUbuM F4+hH8T0ay6tP3NBhpyeErXp3tstOxLEWFv+YUrqEJyZNyZgjAAAEUEQc6bIQWg+fhPGM40D FMNhNRN8u8k+UdiIwv7ZTL46ERWUZOYMxiJgPpSK8y9O26jNA0dgtY/w8mo+vbtHjqXLPF+I MA+m/NljfXkCAwEAAaOCAlkwggJVMAkGA1UdEwQCMAAwDgYDVR0PAQH/BAQDAgbAMBMGA1Ud JQQMMAoGCCsGAQUFBwMEMB0GA1UdDgQWBBSw2Y0tMTuZ9qLtRyucM12s6K0plTAfBgNVHSME GDAWgBQRTaR3sxLWBvV+jAi4GkrMonm4zTArBgNVHREEJDAigSBoZW5uaW5nLnJvZ2dlQGZr aWUuZnJhdW5ob2Zlci5kZTCBkQYDVR0fBIGJMIGGMEGgP6A9hjtodHRwOi8vY2RwMS5wY2Eu ZGZuLmRlL2ZyYXVuaG9mZXItdXNlci1jYS9wdWIvY3JsL2NhY3JsLmNybDBBoD+gPYY7aHR0 cDovL2NkcDIucGNhLmRmbi5kZS9mcmF1bmhvZmVyLXVzZXItY2EvcHViL2NybC9jYWNybC5j cmwwgd8GCCsGAQUFBwEBBIHSMIHPMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZu LmRlL09DU1AtU2VydmVyL09DU1AwSwYIKwYBBQUHMAKGP2h0dHA6Ly9jZHAxLnBjYS5kZm4u ZGUvZnJhdW5ob2Zlci11c2VyLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDBLBggrBgEFBQcw AoY/aHR0cDovL2NkcDIucGNhLmRmbi5kZS9mcmF1bmhvZmVyLXVzZXItY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MEAGA1UdIAQ5MDcwEQYPKwYBBAGBrSGCLAEBBAMEMBEGDysGAQQBga0h giwCAQQDATAPBg0rBgEEAYGtIYIsAQEEMA0GCSqGSIb3DQEBCwUAA4IBAQAmBG8KZSxaC5he gmzI2SK7UJup9fFpRuXOresf7v2zrg50DmbYrcScGkTEryHuVlVvQWePI5vW42036AYdbPrs pzLlHi/S49+H8BMWHerhvxFO+Kv9/8slhlIiQI7/ENWiQwzt1wOBaZsG9RtvymfniIQYgIiI 7ZG/QilPK382Txcq7+AyDoXp92cUGDaLBADcx3+XyBRGcmVpPgiC+1mz1DBt4oqmvmWTsikj gIIXx1Pe8ZVQQ8wyZ44vVZGmvjGOqlQrbmYsooENS0lt/Phc7iA8ieyx7OLosWRTUJ65sBLy Sr85oqavZpAiteu/HB1UKc2qcpMCkgLrr+OHKU6AMIIF3DCCBMSgAwIBAgIHGqCNeNg/kDAN BgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCREUxDzANBgNVBAgTBkJheWVybjERMA8GA1UE BxMITXVlbmNoZW4xEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIg Q29ycG9yYXRlIFBLSTEhMB8GA1UEAxMYRnJhdW5ob2ZlciBVc2VyIENBIC0gRzAxMB4XDTE1 MTIyODEwMzMxMloXDTE4MTIyNzEwMzMxMlowWjELMAkGA1UEBhMCREUxEzARBgNVBAoMCkZy YXVuaG9mZXIxDTALBgNVBAsMBEZLSUUxDzANBgNVBAsMBlBlb3BsZTEWMBQGA1UEAwwNSGVu bmluZyBSb2dnZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJE4YUeC1hfs3UkL AeTiNUATgn9J5O+BpAjxwXsLVFCjsSbcB3vsGTXbUzjoee3stmJjGh+5OlPy88mD2u4OaNNQ djjcJXRlQ3bNWVXykjRyxp7yT6uhLtNgw0M0A8qyFHs8WRY2s+HJE3S4QxdleciAKL9WJwLF Sm4uf7Ery/eg4OrRNe/IXiJgFwAymC4/h5AOOtrmnb0c2B4Odk+6uGqAIb1zv+wTnjmnhek+ 1ERJP0CYnJyKmJCb/6QqpYPT+p9x7/G9jTdWw+k6URDDO4tyrudKCzcGVKLuE30FtEafkmxX kjyoClgeAu09X6RY+wOELvHidfATuRJbkmYaI1cCAwEAAaOCAnIwggJuMAkGA1UdEwQCMAAw DgYDVR0PAQH/BAQDAgQwMCwGA1UdJQQlMCMGCCsGAQUFBwMEBgorBgEEAYI3CgMEBgsrBgEE AYI3CgMEATAdBgNVHQ4EFgQUZlkxmMazXLU1Ux36PhoaBoVAZV0wHwYDVR0jBBgwFoAUEU2k d7MS1gb1fowIuBpKzKJ5uM0wKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwgZEGA1UdHwSBiTCBhjBBoD+gPYY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9m cmF1bmhvZmVyLXVzZXItY2EvcHViL2NybC9jYWNybC5jcmwwQaA/oD2GO2h0dHA6Ly9jZHAy LnBjYS5kZm4uZGUvZnJhdW5ob2Zlci11c2VyLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHfBggr BgEFBQcBAQSB0jCBzzAzBggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQ LVNlcnZlci9PQ1NQMEsGCCsGAQUFBzAChj9odHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ZyYXVu aG9mZXItdXNlci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSwYIKwYBBQUHMAKGP2h0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZnJhdW5ob2Zlci11c2VyLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0 LmNydDBABgNVHSAEOTA3MBEGDysGAQQBga0hgiwBAQQDBDARBg8rBgEEAYGtIYIsAgEEAwEw DwYNKwYBBAGBrSGCLAEBBDANBgkqhkiG9w0BAQsFAAOCAQEAYuwqpLk5/9gHeRk3sawSxuZ5 wR9sOrZecLuBdvfY4QfyabQWDV9Of/4gLys/VAb3G+DlGopUYpfZACemokyP+6g82eO5d7kx oKx/rPxm7AAh2ZuyYH9nXLHYO89yaBV6ROleCfNj+Z0O4W1EZmMgAg7rnBaNsK4plVTPoaVx R5uX8hcriroWJCKUmQQfcEEzw7YDUispvJkKrVFp+VJPmxN+1w+UXnU+tqlUS9QW1O5NiLUU j6KapjMu6+E9kOzbOUDsZWyLKq1fOLM/9/n3UDYumGpvLLpwPS8TRf9ZzSC2oobIE3Fx8bPg mm6Y5EsObIsy+rQnXTLRckXQp9S46zGCA/kwggP1AgEBMIGYMIGMMQswCQYDVQQGEwJERTEP MA0GA1UECBMGQmF5ZXJuMREwDwYDVQQHEwhNdWVuY2hlbjETMBEGA1UEChMKRnJhdW5ob2Zl cjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSEwHwYDVQQDExhGcmF1bmhv ZmVyIFVzZXIgQ0EgLSBHMDECBxqgjfxvR3cwDQYJYIZIAWUDBAIBBQCgggIxMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDUxNzA3MDY0MFowLwYJKoZI hvcNAQkEMSIEINQpz+aEPL04l9RRWK2JUL/J8Y4RnUxsuaJhE7mlzZodMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgakGCSsGAQQB gjcQBDGBmzCBmDCBjDELMAkGA1UEBhMCREUxDzANBgNVBAgTBkJheWVybjERMA8GA1UEBxMI TXVlbmNoZW4xEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEhMB8GA1UEAxMYRnJhdW5ob2ZlciBVc2VyIENBIC0gRzAxAgcaoI142D+Q MIGrBgsqhkiG9w0BCRACCzGBm6CBmDCBjDELMAkGA1UEBhMCREUxDzANBgNVBAgTBkJheWVy bjERMA8GA1UEBxMITXVlbmNoZW4xEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEhMB8GA1UEAxMYRnJhdW5ob2ZlciBVc2VyIENBIC0g RzAxAgcaoI142D+QMA0GCSqGSIb3DQEBAQUABIIBAHcIAK+sh07I6n8P73UEgbdACx4SubX0 FcN7jdwTZaQGqSGEepNIHB62QRkuaR+7Ba9V+asDqWNsDY8qbeWtkhJs3to02Wb9M7FXakBU WY/hCU9AyK+TbLlRGNF2zlBQGb1980HrgUOD2ggID0AvDeNkgPotgyQRRTg4SI6s90bNs/7h lpYhzxF4qGStyq6DtoQEB/KpXCvwI3a0C7AYP8TNrD9uwLqBZHlu1Ni56g4bkYmuB8sOkwtg ObZjvhcA+M8uaLXAC15nc2S/7Jie+6dnb9pZevaXDb8+bP9qCciuNMlIp+pqgx5wrWAtvrdT r0TrQ6Qu5FwedoPpt1ENH7AAAAAAAAA= --------------ms000900090208060501070001-- From nobody Tue May 17 00:12:06 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E3512B05C; Tue, 17 May 2016 00:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 N-iw8x2qpkw1; Tue, 17 May 2016 00:12:02 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 860CF12D09C; Tue, 17 May 2016 00:12:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7582; q=dns/txt; s=iport; t=1463469122; x=1464678722; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jpmPW3Ct0ykNElmxg8plB3dPxgsxJkHyOwFMrJZh4CM=; b=EUU+s6BWIqv0i0ENYFFD3/38W+j9tMfHJHrORQLvFF2dbNuLpGJ8wt6N MVaH0QhMXlkfP6adYxFXDLnZdd7DinUs7NAfoTQhjss8K8I7alLi6r8gO Y22quynrfTdPRKVViXZdnefnntcLW06jweNKUWYY5V+Hd282BqquG1X93 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BiAgAmwzpX/5FdJa1UCYM3VX4GuWoBD?= =?us-ascii?q?YF2IoVvAoEyOBQBAQEBAQEBZSeEQgEBAQQ6PwwEAgEIEQEDAQEBHhAyFwYIAgQ?= =?us-ascii?q?BDQUIiCcOwiwBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYlhE2EEQcKAYV1BZgoA?= =?us-ascii?q?Y4WgXCET4hhj0ABHgEBQoNsbgGGUDZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,324,1459814400"; d="scan'208";a="273712276" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 May 2016 07:12:01 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u4H7C1D3005779 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 May 2016 07:12:01 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 17 May 2016 02:12:00 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Tue, 17 May 2016 02:12:00 -0500 From: "Les Ginsberg (ginsberg)" To: "Joe Clarke (jclarke)" , "rtg-ads@ietf.org" Thread-Topic: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 Thread-Index: AdGgzHD5AnaTBqcTQJm4IHI17iI2lQBnClYAAieCg0AALuo+AAACzD3QAAvztwAARQFW8AARa8OAAK0WXnA= Date: Tue, 17 May 2016 07:12:00 +0000 Message-ID: References: <5afaa922862d4b4a9dc67f117ae5366a@XCH-ALN-001.cisco.com> <978721df-6b95-dff7-af53-31d42a731946@cisco.com> <6dde8ef61dbf4faa98387fee01516dc3@XCH-ALN-001.cisco.com> <26dfa4d7-dd81-de1f-57b7-ae6fa9641fb5@cisco.com> <30733d2a0880449dbd5cf930c48ad6be@XCH-ALN-001.cisco.com> In-Reply-To: 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.24.97.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-i2rs-traceability@ietf.org" , "i2rs@ietf.org" Subject: Re: [RTG-DIR] [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 07:12:04 -0000 Thanx Joe - looks good. Les > -----Original Message----- > From: Joe Clarke (jclarke) > Sent: Friday, May 13, 2016 8:36 AM > To: Les Ginsberg (ginsberg); rtg-ads@ietf.org > Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; i2rs@ietf.or= g > Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 >=20 > On 5/13/16 08:17, Les Ginsberg (ginsberg) wrote: > > Joe - > > > > Something like the attached file perhaps? >=20 > Thanks. We have posted rev -10 of this draft that should address all of = your > comments. >=20 > Joe >=20 > > > > Les > > > > > >> -----Original Message----- > >> From: Joe Clarke (jclarke) > >> Sent: Wednesday, May 11, 2016 3:21 PM > >> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org > >> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; > >> i2rs@ietf.org > >> Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 > >> > >> On 5/11/16 17:39, Les Ginsberg (ginsberg) wrote: > >>> Joe - > >>> > >>> Yes - this looks better to me. > >>> > >>> What about the "shadow boxes" for Applications/Clients? > >> > >> Do you have an example draft I could look at for that? > >> > >> Joe > >> > >>> > >>> Les > >>> > >>> > >>>> -----Original Message----- > >>>> From: Joe Clarke (jclarke) > >>>> Sent: Wednesday, May 11, 2016 8:19 AM > >>>> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org > >>>> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; > >>>> i2rs@ietf.org > >>>> Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 > >>>> > >>>> On 5/10/16 18:04, Les Ginsberg (ginsberg) wrote: > >>>>> Joe - > >>>>> > >>>>> Apologies for the delayed response. I am a victim of my own email > >>>>> infilters. :-( Inline. > >>>> > >>>> Thanks, Les. Have a look at > >>>> https://www.marcuscom.com/draft-ietf-i2rs-traceability.txt-from-09- > >>>> 10.diff.html > >>>> . I added a new line to show the flow in both directions. > >>>> > >>>> Joe > >>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Joe Clarke (jclarke) > >>>>>> Sent: Friday, April 29, 2016 10:44 AM > >>>>>> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org > >>>>>> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; > >>>>>> i2rs@ietf.org > >>>>>> Subject: Re: [i2rs] RtgDir review: > >>>>>> draft-ietf-i2rs-traceability-08 > >>>>>> > >>>>>> On 4/27/16 17:39, Les Ginsberg (ginsberg) wrote: > >>>>>>> Summary: This document is a well written document - easy to > >>>> understand. > >>>>>>> My compliments to the authors. I believe there is one minor > >>>>>>> issue which I would like to see addressed before publication. > >>>>>> > >>>>>> Thanks for your comments and feedback, Les. Please see below for > >>>>>> some replies and questions. > >>>>>> > >>>>>>> In Section 5.2 there is a definition of the information which is > >>>>>>> required to be kept by an I2RS Agent for each I2RS interaction. > >>>>>>> I would like to see the addition of "Request State" into this lis= t. > >>>>>>> Operationally each request could be in one of the following state= s: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> * Enqueued (or pending if you prefer) > >>>>>>> > >>>>>>> * In process > >>>>>>> > >>>>>>> * Completed > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> The lack of such a state seems to imply that both the queue time > >>>>>>> and the processing time are insignificant. While I think this > >>>>>>> may be the case for many requests, it will not always be the > >>>>>>> case. In queue time may be lengthy due to other load on the > >>>>>>> Agent. Also, some requests - particularly destructive requests > >>>>>>> which involve cleanup of resources - may take a significant > >>>>>>> amount of time to > >> complete. > >>>>>> > >>>>>> Good observation. Traceability was aimed mainly at the > >>>>>> termination of the request, but I like the idea of tracing the sta= te > machine. > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Along with this an additional timestamp - Processing Initiated - > >>>>>>> would be useful to indicate when processing of the request > >>>>>>> actually > >>>> began. > >>>>>> > >>>>>> I don't know we need a new timestamp. Perhaps we just need to > >>>> rename > >>>>>> "Request Timestamp" and "Result Timestamp" to "Start Timestamp" > >> and > >>>>>> "End Timestamp" to denote the time within the current state. > >>>>>> What do you think? > >>>>> > >>>>> [Les:] My intent was to log the time at which the request began > >>>>> processing > >>>> so that you can see whether a long delay in completion was due to > >>>> enqueue delay or actual lengthy processing time. I am not adamant > >>>> about this so if you want to stay with the two timestamps that is OK= . > >>>>> > >>>>>> > >>>>>>> s/Some notable elements on the architecture/ Some notable > >> elements > >>>>>>> of the architecture > >>>>>> > >>>>>> Fixed. Thanks! > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Figure 1 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Not clear to me why Application IDs start at 0 but Client IDs sta= rt at > 1. > >>>>>> > >>>>>> Ah. The numbers there are not IDs. They are the number of > >>>>>> actual things in the boxes above. For Applications, there may be > >>>>>> 0 to N for a given client. For Clients, you need at least 1. > >>>>>> Does that make > >> sense? > >>>>>> > >>>>> [Les:] Maybe you want to use "shadows" on the boxes to indicate > >>>>> there > >>>> can be multiple Application boxes and multiple Client boxes? > >>>>> What you say makes sense but I do not intuit that when I look at > >>>>> the ASSCII > >>>> art. > >>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Figure 1 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Is the text "Op Data V" between I2RS Agent box and Routing > >>>>>>> System box intentional? > >>>>>> > >>>>>> Yes. The 'V' is meant to be an arrow head pointed down. The > >>>>>> request and data go from Client to Agent whereas the Response > >>>>>> goes from Agent to Client. > >>>>>> > >>>>>> We are open to suggestions on how to make this clearer. > >>>>> > >>>>> [Les:] I think it would be clearer if you had two lines - one > >>>>> flowing down > >>>> associated with the Op Data and one flowing up with the result. > >>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Section 5.2 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Secondary Identity > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> This is defined to be "opaque" yet if not provided the agent is > >>>>>>> supposed to insert "an UNAVAILABLE value". This seems to be a > >>>>>>> contradiction unless we have a publicly defined value that > >>>>>>> clients are prohibited from using. Absent that you would need a > >>>>>>> "Secondary > >>>> Identity Valid" indicator. > >>>>>> > >>>>>> Good observation. I think it's fine to say that this field must > >>>>>> be logged. If there is no application, then the field will be > >>>>>> logged as empty. If there is an application, then whatever value > >>>>>> is provided will be logged. > >>>>>> > >>>>>> Do you feel strongly that we need a field to indicate Application > >> Present? > >>>>>> > >>>>> [Les:] I am fine w your changes. > >>>>> > >>>>> Les > >>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Section 7.4 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> s/establish an vendor-agnostic/establish a vendor-agnostic > >>>>>> > >>>>>> Fixed. Thanks! > >>>>>> > >>>>>> Joe > >>> > > From nobody Tue May 17 09:55:06 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D1712DBB2 for ; Tue, 17 May 2016 09:55:04 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZMplDBWbgmDk for ; Tue, 17 May 2016 09:55:01 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0754.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::754]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E9212DBB0 for ; Tue, 17 May 2016 09:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7LLhSli407I9rHa+EQqnEkNSXjXAr6peA5I39eSYewM=; b=GUr2aib0BetPFag1rkVJUiza/9riHt7XcxrA6EUFWVYfZzIL9S3Y6vrwtLtmGWPWioQZjEg4t2fHfaqYWJ+yNMEBHfWqAjQqgyMqo5modMWYnI8e3f92MC+ouq7VL0tSY/xisvF/xHfagT4+sHsDXfIzls1gPKdmKmcNwhFGhno= Received: from CY1PR05MB2521.namprd05.prod.outlook.com (10.167.10.136) by CY1PR05MB2523.namprd05.prod.outlook.com (10.167.10.138) with Microsoft SMTP Server (TLS) id 15.1.497.12; Tue, 17 May 2016 16:54:41 +0000 Received: from CY1PR05MB2521.namprd05.prod.outlook.com ([10.167.10.136]) by CY1PR05MB2521.namprd05.prod.outlook.com ([10.167.10.136]) with mapi id 15.01.0497.019; Tue, 17 May 2016 16:54:41 +0000 From: Ravi Singh To: "rtg-dir@ietf.org" Thread-Topic: RE: Routing directorate QA review of draft-ietf-i2rs-rib-info-model Thread-Index: AdGwXE/cjuqe7xG3Q8G/QzkJ5sJXpQ== Date: Tue, 17 May 2016 16:54:41 +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=juniper.net; x-originating-ip: [66.129.239.15] x-ms-office365-filtering-correlation-id: c6f72950-ddd1-4ac7-18a2-08d37e73f0dd x-microsoft-exchange-diagnostics: 1; CY1PR05MB2523; 5:KcimzbmiIF5m2bfUEKbttv9YM/aXLN1zu90l+cAscU5YzEme7JCfhh+N9WfyEOlHNnHP1Nr+87hqvQsLHiKVzSMWhmsne2KeYN0qMLjb5TlGMOoNCR7pDE1kcyOceXMo+fcsi8McED6bZMPMN7mjVA==; 24:uKT5Qyk1sgwAxMRSjFs/stAwT+khgBgtjNfkR3Rpn78W7m0wYeQGB6n6kNPUAgG39C+kfiPizjtdCeYyShRg96DQijB2dyjoXnV3Si4dCRU=; 7:AZ287BBRDbHvttz7mKdQoq2wZxBaCtvGXckV6wqJZcTbdSb3nldk68vtqI5VuJoonHtDG9sRqz8iupXQnOTOeQa2/7Op1SbJP7JckSziHPCnxdSKXQ/zJmML/DeZ/5STIWLXTy9kEHk2bTEWFGMxh310T8yy8ch9D1da673auNp5RLBpxg+TfsIEC6NE5m4d x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB2523; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:CY1PR05MB2523; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2523; x-forefront-prvs: 0945B0CC72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(54356999)(4326007)(99286002)(9686002)(2501003)(50986999)(5640700001)(5004730100002)(16236675004)(86362001)(9326002)(5630700001)(66066001)(11100500001)(10400500002)(5003600100002)(189998001)(92566002)(110136002)(74316001)(87936001)(8936002)(8676002)(586003)(2906002)(230783001)(81166006)(2900100001)(19300405004)(77096005)(15975445007)(790700001)(6116002)(19617315012)(102836003)(3846002)(19625215002)(122556002)(3660700001)(33656002)(68736007)(3280700002)(76576001)(5002640100001)(2351001)(19580395003)(5008740100001)(1220700001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2523; H:CY1PR05MB2521.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR05MB2521CF777B19613C0FFE74B7AB480CY1PR05MB2521namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2016 16:54:41.5325 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2523 Archived-At: Cc: 'Jonathan Hardwick' , "Zhangxian \(Xian\)" , Susan Hares , 'Jon Hudson' Subject: Re: [RTG-DIR] Routing directorate QA review of draft-ietf-i2rs-rib-info-model X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 16:55:04 -0000 --_000_CY1PR05MB2521CF777B19613C0FFE74B7AB480CY1PR05MB2521namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I had been designated the RTG-DIR QA-reviewer for https://tools.ietf.org/ht= ml/draft-ietf-i2rs-rib-info-model-08 I reviewed this doc. Overall, the doc is clear and does a decent job of creating a RIB model. However, I have a minor concern with the tone of the doc at certain places. The document, at places, reads like a requirements doc specifying what an i= mplementation of the RIB "SHOULD"/MUST do. I am not sure if that is correct form for an informational draft documentin= g a specific RIB model. Examples of such instances would be: A. Section 8 B. Section 9 C. Wherever in the doc a "SHOULD" or "MUST" shows up stating desirabil= ity of certain behavior of an external entity accessing the RIB. An aspect that has not been touched-upon in the document, that however migh= t be worthy of consideration is about how this RIB model accommodates an ex= ternal input about traffic-statistics-monitoring desired for the various co= nstructs. Specific comments on the various sections in the text: 1. Introduction: a. First 2 paras: some typos and sentences with redundant words. 2. 2.1: a. "type" is somewhat ambiguous. Suggest reword "type" as "address-fa= mily" 3. 2.2: a. Some sentences could be made shorter/broken-up to improve readabil= ity of this section. b. Interface_list and router-id: For a functioning routing-instance, c= an't think of a routing-instance without either of those defined. So, eithe= r the optionality aspect needs to be changed to "required" or specify how a= routing-instance would work with either missing. c. Interface-list: per-interface parameters could also be listed (sin= ce the interface-list is called out in a RIB model): address, families, MTU= , extensibility-consideration-for-other-interface-attributes 4. 2.3: a. ROUTE_PREFERENCE: The text is mixing-up route-preference with "rou= te-metric". Administrative-distance (the route metric) is the IGP cost of a= route. Both route_preference and route-metric would be attributes of the route. b. An additional attribute that should be included is "installing prot= ocol". That would require defining a list of protocols that may install a r= oute. 5. 2.4: a. Second paragraph could use rewording to enhance clarity. Specifica= lly: i. Need to mention about = "(appearing to be) directly connected IP" to distinguish between: 1. Nexthops that don't need to be resolved (by other RIB events) to b= e installable 2. Nexthops that need to be resolved (by other RIB events/properties)= to be installable: a. Those that are currently resolved b. Those that are currently not-resolved b. Next-hop property should also include IP of (appearing to be) local= ly-connected device for which to ARP 6. 2.4.1: a. Last paragraph: "preceded by" would be more accurate than "followe= d by" 7. 2.4.3: a. Under "tunnel encap": The following text " An optional egress interface can be chained to the tunnel encap to indicate which interface to send the packet out on. The egress interface is useful when the network device contains Ethernet interfaces and one needs to perform address resolution for the IP packet." appears a bit incorrect. If one wishes to do resolution for the tunnel-remote-dst then specifying an= interface serves no purpose. Either that address does not need resolution = and this specified interface is a p2p interface or there is a need for reso= lution (without needing to specify an interface-name). Can't be both. 8. Sections 4 & 5 can be merged. What is the point of having a separa= te section 5 when it is not really saying anything new beyond what text exi= sts in section 4. 9. Section 6: a. Not repeating remarks made about specific attributes (listed above= ) for each item in the BNF. Eg. Route-metric/preference related remark made= above about 2.3. b. In-label is not logically a nexthop attribute. It is infact a route= . This should be fixed. ::=3D ( [] [] []) | ( []) c. VXLAN headers needs to have a way to specify src/dst MAC in inner = header, since it is possible to use VXLAN as a general-purpose encapsulatio= n without L2-learning semantics. 10. Section 6 describes the RIB grammar. The nexthop grammar is a part of= that. However, some of that sub-grammar appears under section 7. 11. Section 7 "Using the RIB grammar" starts out by explaining how the co= mplex nexthops maybe used. However, it ends up being a listing of the nexth= op sub-grammar which should really have been listed in section 6 along with= the RIB grammar. I'd suggest either take the entirety of the next-hop grammar listing to the= section 6, or break section 7 so that the next-hop grammar is listed in se= ction 7 & the "using the rib" grammar is a purely text only description of = Rib/NH grammar maybe used. 12. Syntax for needs to be reconciled beween section= 7.2.3 and section 6 where there is an syntax mismatch, Doesn't section 6 need to say: ::=3D ... Regards Ravi --_000_CY1PR05MB2521CF777B19613C0FFE74B7AB480CY1PR05MB2521namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

I had been desig= nated the RTG-DIR QA-reviewer for h= ttps://tools.ietf.org/html/draft-ietf-i2rs-rib-info-model-08=

 

I reviewed this = doc.

Overall, the doc= is clear and does a decent job of creating a RIB model.<= /p>

However, I have = a minor concern with the tone of the doc at certain places.

The document, at= places, reads like a requirements doc specifying what an implementation of= the RIB "SHOULD"/MUST do.

I am not sure if= that is correct form for an informational draft documenting a specific RIB= model.

Examples of such= instances would be:

A.  =     Section 8

B.  =     Section 9

C.  =     Wherever in the = doc a "SHOULD" or "MUST" shows up stating desirability = of certain behavior of an external entity accessing the RIB.

 

An aspect that h= as not been touched-upon in the document, that however might be worthy of c= onsideration is about how this RIB model accommodates an external input about traffic-statistics-monitoring desired for the vari= ous constructs.

Specific comment= s on the various sections in the text:

1.  =      Introduction:

a.  =      First 2 paras: s= ome typos and sentences with redundant words.

 

2.  =      2.1:<= /span>

a.  =      "type"= is somewhat ambiguous. Suggest reword "type" as "address-fa= mily"

 

3.  =      2.2: =

a.  =      Some sentences c= ould be made shorter/broken-up to improve readability of this section.=

b.  =     Interface_list a= nd router-id: For a functioning routing-instance, can't think of a routing-= instance without either of those defined. So, either the optionality aspect= needs to be changed to "required" or specify how a routing-instance would work with either missing.

c.  =      Interface-list: = per-interface parameters could also be listed (since the interface-list is = called out in a RIB model): address, families, MTU, extensibility-considera= tion-for-other-interface-attributes

 

4.  =      2.3:<= /span>

a.  =      ROUTE_PREFERENCE= : The text is mixing-up route-preference with "route-metric". Adm= inistrative-distance (the route metric) is the IGP cost of a route.

Both route_preference and route-metric would be attributes of = the route.

b.  =     An additional at= tribute that should be included is "installing protocol". That wo= uld require defining a list of protocols that may install a route.

 

5.  =      2.4:<= /span>

a.  =      Second paragraph= could use rewording to enhance clarity. Specifically:

  &n= bsp;            = ;            &n= bsp;           i.  = ;          Need to mention about "(appear= ing to be) directly connected IP" to distinguish between:

1.  =      Nexthops that do= n't need to be resolved (by other RIB events) to be installable<= /span>

2.  =      Nexthops that ne= ed to be resolved (by other RIB events/properties) to be installable:<= /o:p>

a.  =      Those that are c= urrently resolved

b.  =     Those that are c= urrently not-resolved

b.  =     Next-hop propert= y should also include IP of (appearing to be) locally-connected device for = which to ARP

 

6.  =      2.4.1:

a.  =      Last paragraph: = "preceded by" would be more accurate than "followed by"

 

7.  =      2.4.3:

a.  =      Under "tunn= el encap": The following text

"

An optional

      egress interface can be chained= to the tunnel encap to indicate

      which interface to send the pac= ket out on.  The egress interface

      is useful when the network devi= ce contains Ethernet interfaces and

      one needs to perform address re= solution for the IP packet."

appears a bit incorrect.

If one wishes to do resolution for the tunnel-remote-dst then = specifying an interface serves no purpose. Either that address does not nee= d resolution and this specified interface is a p2p interface or there is a need for resolution (without needing to spec= ify an interface-name). Can't be both.

 

8.  =      Sections 4 &= 5 can be merged. What is the point of having a separate section 5 when it = is not really saying anything new beyond what text exists in section 4.

 

9.  =      Section 6:<= /o:p>

a.  =      Not repeating re= marks made about specific attributes (listed above) for each item in the BN= F. Eg. Route-metric/preference related remark made above about 2.3.

 

b.  =     In-label is not = logically a nexthop attribute. It is infact a route. This should be fixed.<= o:p>

  <mpls-label-operation> ::=3D (<MPLS_PUSH> &= lt;MPLS_LABEL> [<S_BIT>]

          &n= bsp;            = ;            &n= bsp;      [<TOS_VALUE>] [<TTL_VALUE>])= |

          &n= bsp;            = ;      (<MPLS_SWAP> <IN_LABEL> <OUT= _LABEL>

          &n= bsp;            &nbs= p;            &= nbsp;    [<TTL_ACTION>])

c.  =      VXLAN headers ne= eds to have a way to specify src/dst MAC in inner header, since it is possi= ble to use VXLAN as a general-purpose encapsulation without L2-learning sem= antics.

 

10.  = ; Section 6 descri= bes the RIB grammar. The nexthop grammar is a part of that. However, some o= f that sub-grammar appears under section 7.

 

11.  = ; Section 7 "= Using the RIB grammar" starts out by explaining how the complex nextho= ps maybe used. However, it ends up being a listing of the nexthop sub-gramm= ar which should really have been listed in section 6 along with the RIB grammar.

I'd suggest either take the entirety of the next-hop grammar l= isting to the section 6, or break section 7 so that the next-hop grammar is= listed in section 7 & the "using the rib" grammar is a purely text only description of Rib/NH grammar maybe used.=

 

12.  = ; Syntax for <n= exthop-replicate>  needs to be reconciled beween section 7.2.3 and = section 6 where

there is an syntax mismatch,

Doesn’t section 6 need to say:

<nexthop-replicate> ::=3D <NEXTHOP_REPLICATE> <= nexthop> <nexthop> ...

 

Regards

Ravi<= /span>

 

--_000_CY1PR05MB2521CF777B19613C0FFE74B7AB480CY1PR05MB2521namp_-- From nobody Thu May 19 03:59:04 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFEC412D919; Thu, 19 May 2016 03:59:02 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=eci365.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 oFKcVzOqnLvQ; Thu, 19 May 2016 03:58:59 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0792.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::792]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8428512D916; Thu, 19 May 2016 03:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NowBp8x6ZOaXZkDNqaDTwO0YzHdCUlPXVRn8JMLtRMk=; b=WW3PZDRqqLtvVXKODtIPdoaRLQQBiCjKXpFUC+vabub/xdQHDPz52FXtjF0G+FmWeUpulnaZdTw8sPcjV93WwlbGvnOOZmQHIydinAEi/HWxn/AZgIb8uvtGiNki2oTNl7OPqAifYsgv1WhWkbpuAbGPJoNxVH3l3Qlfk19+cEI= Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) by DB3PR03MB0777.eurprd03.prod.outlook.com (10.161.54.27) with Microsoft SMTP Server (TLS) id 15.1.497.12; Thu, 19 May 2016 10:58:33 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) with mapi id 15.01.0497.019; Thu, 19 May 2016 10:58:33 +0000 From: Alexander Vainshtein To: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" Thread-Topic: RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname Thread-Index: AdGxvD1O5NXHbyN7QyqT5SoYhCMmtA== Date: Thu, 19 May 2016 10:58:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: metaswitch.com; dkim=none (message not signed) header.d=none; metaswitch.com; dmarc=none action=none header.from=ecitele.com; x-originating-ip: [79.178.205.5] x-ms-office365-filtering-correlation-id: a5546a25-f8ce-4f19-0c11-08d37fd4853d x-microsoft-exchange-diagnostics: 1; DB3PR03MB0777; 5:iBnj3lOBTnEmNRasNfq3heMwsvJlkdpsXRQ7sRY0X4v5i1cmcYdcSJWTINZgkE39bS4zZW4gW5V4mbbG1AIMsHv0dxkNgduQWCHOFY+S87O4MMkwF2oLRos7l/dMURbVhBOVGAryJHbefkZpeAUxWA==; 24:i5jPeua2r1/LcyjcksaUmA9hpwGcMvnGn252E65y85KuzjurXzk0pRscPU8ZMZRxAMFz7QF9DONKCWRIf6VXnuzdqWXrPkQmnFGuieYNFUU=; 7:Kj9mLqK82fh6K5rOyuoWXYjdpU3c7EO0kXyKU+XcNiYegaRcqY4s1nas+9fVmxuKyNk5N2f+3KfnnKeQDlPuIi+n+jr/W8lo3nOS60smzZpClsKcOaSOlsfF1X9Ip1yKcplVKoH5pU3z1j2Gtkk1cboNNWGVK5ibnwevmYz6xzyN/gjbP585x1nNneeGETll x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0777; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:DB3PR03MB0777; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0777; x-forefront-prvs: 094700CA91 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(252514010)(54094003)(53754006)(230783001)(189998001)(16236675004)(87936001)(5008740100001)(15975445007)(561944003)(19625215002)(81166006)(77096005)(33656002)(2900100001)(110136002)(66066001)(5003600100002)(19300405004)(8936002)(19580395003)(19580405001)(19617315012)(8676002)(1220700001)(5002640100001)(5004730100002)(4326007)(586003)(3846002)(11100500001)(2906002)(86362001)(92566002)(50986999)(102836003)(6116002)(229853001)(790700001)(122556002)(54356999)(76576001)(9686002)(10400500002)(74316001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0777; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB3PR03MB0780AEC260B5293DA90DAFC09D4A0DB3PR03MB0780eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2016 10:58:33.3286 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0777 Archived-At: Cc: "'rtg-dir@ietf.org'" , "zhang.xian@huawei.com" , "trill@ietf.org" , "draft-ietf-trill-multilevel-single-nickname@ietf.org" , "Susan Hares \(shares@ndzh.com\)" , "jon.hudson@gmail.com" Subject: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 10:59:03 -0000 --_000_DB3PR03MB0780AEC260B5293DA90DAFC09D4A0DB3PR03MB0780eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I have been appointed as the QA reviewer for draft-ietf-trill-multilevel-si= ngle-nickname. Before going into the review proper, I would like to make a couple of intro= ductory statements. 1. I am NOT a TRILL expert and actually never before has been involve= d with TRILL. I have been told that this is OK and the ADs are interested i= nto getting reviews from non-experts. Well, in my case this is what they wi= ll get. 2. The time frame for providing the review was quite demanding (at le= ast for me). This probably affected the review quality and it effectively p= revented me from discussing the review with the draft authors privately - I= owe them a sincere apology for that. 3. The RtgDirDocQa - Rtg Area Wiki states that the QA review is usually performed wh= en a draft is going to be adopted as a WG document. While it mentions, that= a WG document may be also subjected to such a review at the discretion of = the WG Chairs, the initial guidelines for the QA reviewer in the Wiki menti= on only reviewing the draft for a QA adoption. As a consequence, I had to c= reate my own list of questions that will try to answer based on what I have= found in the Wiki. Here is this list: a. Is the draft easily readable and understandable? b. Does the draft represent an attempt to solve a real problem? c. Are there some serious technical gaps that the authors should try = to fill? d. Are there any potential IETF process issues with the draft in its p= resent form? Please note that the question about "a good start for a WG draft" which app= ears in the Wiki does not appear on my list (since the draft is already a W= G document). At the same time I have included the question about solving a real problem = (which appeared in the previous version of the Wiki page). The current vers= ion only asks if the draft "makes sense" which, from my POV, is something e= lse. My answers to these questions follow. Is the draft easily readable and understandable? Of course, "easily readable and understandable" is in the eye of the behold= er. But as a non-expert can say that it was quite difficult for me to under= stand what this draft is really about. Eventually, I have succeeded to build the following scheme that helped me t= o understand what I am dealing with: * The TRILL base spec: o Explicitly restricts TRILL to a single Level 1 IS-IS o Explicitly states that the nicknames of RBridges in the Trill packet he= ader remain unchanged when the packet traverses the TRILL domain from ingre= ss (where the TRILL header is pushed on the original Ethernet frame) to egr= ess (where this header is popped) * An Informational Multi-Level TRILL WG draft claims t= hat this restriction negatively affects TRILL scalability: o It mentions several scalability issues o However, it ? Neither mentions any specific scale parameters where these issues become= real ? Nor provides any explanations about the reasons that make single-level I= S-IS used by TRILL less scalable that single-level IS-IS when it is used fo= r distributing IP reachability o It claims that some of these issues may be addressed by allowing usage = of multi-level IS-IS for TRILL o It provides two specific proposals for making multi-level TRILL work: o One of these proposals is called "unique nicknames". This proposal: ? Does not require any changes in the TRILL data plane ? Requires introducing some structure in the nicknames of RBridges in orde= r to guarantee that these names are unique within the TRILL-based campus o The other proposal is called "aggregate nicknames". This proposal: ? Allows RBridges in different L1 areas of the campus to share nicknames ? Requires a change in the TRILL data plane: the nicknames in the TRILL he= ader of a packet will be modified by the L12 RBridges ? Allows two possible flavors (bot mentioned in the draft): * The flavor that uses L1 area nicknames * The flavor that uses the nicknames of all L12 RBridges connected = to a given L1 area as its name * The Standards Track Single Nickname draft (one that I have been a= sked to review) provides details on the second of the above-mentioned flavo= rs of the "Aggregate Nicknames" approach: o It also allows sharing the same nickname between RBridges in different = L1 areas o It also requires the same change in the TRILL data plane o It eliminates the need for allocating nicknames to L1 areas. Instead, e= ach such area is identified by the set of nicknames of all L12 RBridges tha= t connect to it. It took me quite some time to build this scheme, and the text in the draft = was not very helpful in this. The following points contributed to "negative readability" from my POV: * The draft positions itself as an alternative to the Aggregate Nic= knames approach while, from my POV, it is just provides additional details = on one of the possible flavors of this approach * The draft is intended for the Standards Track, but it does not sa= y that it updates the base TRILL spec (neither in the text nor in metadata)= . (I guess that a TRILL expert would not have any problems with reading and u= nderstanding the draft - but I am providing a non-expert review here. If I may suggest so, the authors could consider making the introduction mor= e structured and clearly present the flow of dependencies there.) Does the Draft Represent an Attempt To Solve a Real Problem? Unfortunately I cannot provide a definite "Yes" or "No" answer for this que= stion: * Neither the draft I am reviewing, nor its "parent" multi-level TR= ILL draft do not provide sufficient information for a non-expert to underst= and why TRILL scalability is a real issue. o I know that these days single-level IS-IS used for distributing IP rout= ing information is expected to support up to 1K nodes in "sparse mesh" topo= logy o I do not know whether this level of scale is considered as simply not s= ufficient for TRILL deployments, be it from the POV of the number of RBridg= es, or from the POV of topological complexity o I also do not know whether there are some aspects of TRILL that make it= less scalable than IS-IS used for distributing IP routing information * I know (as we all do) that in IP routing the preferred approach t= o solving IGP scalability issues is by using BGP. I wonder if this (or simi= lar) approach has ever been considered for TRILL, and, if it was, why did t= he authors go for multi-level IS-IS. * I understand that the "Unique Nicknames" approach introduces some= issues to TRILL (like structuring the nicknames). But I find it somewhat d= ifficult to believe to the claim (in the Multi-Level TRILL draft) that the = pool of 64K nicknames imposes any serious scalability restrictions on TRILL * Last but not least, I do not understand why the heed to assign ni= cknames to L1 areas (in the other flavor of the "aggregate nicknames" appro= ach) carries with it any serious issues. Are there some serious technical gaps that the authors should try to fill? I see a potential for one such gap that I believe addressed by the authors:= The draft does not say what is supposed to happen when a new border RBridg= e is added a given L1 area. The draft mentions that if the L1 area with multiple border RBridges is par= titioned so that some RBridges remain in one part and some - in the other p= art, all reachability information learned from it will be flushed. The resu= lting traffic hits in this scenario are expected of course. But when a new border RBridge is connected to a L1 area, or when the failur= e of a link (or node) that has caused partition of such an area is repaire= d - what should happen? Would such a "positive event" also result in flush = of all learned reachability information and the accompanying traffic hit? Are there any potential IETF process issues with the draft in its present f= orm? As I have said already, I see this draft as a logical extension of the Mult= i-Level TRILL one, so that, From my POV the reference to the Multi-Level T= RILL draft in this one should be Normative. However, the Multi-Level Trill = draft is intended for the Informational track, while the Single Nickname dr= aft positions itself as the Standard Track. Simply making the reference In= formative may be good enough as far as the letter of law goes, but I do not= feel this is the right way to handle this. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com --_000_DB3PR03MB0780AEC260B5293DA90DAFC09D4A0DB3PR03MB0780eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

I have been appointed = as the QA reviewer for draft-ietf-trill-multilevel-single-nickname.

Before going into the = review proper, I would like to make a couple of introductory statements.

 

1.&= nbsp;      I am NOT a TRILL expert and actually never before has been invol= ved with TRILL. I have been told that this is OK and the ADs are interested= into getting reviews from non-experts. Well, in my case this is what they will get.

2.&= nbsp;      The time frame for providing the review was quite demanding (at = least for me). This probably affected the review quality and it effectively= prevented me from discussing the review with the draft authors privately – I owe them a sincere apology for = that.

3.&= nbsp;      The RtgD= irDocQa – Rtg Area Wiki states that the QA review is usually perf= ormed when a draft is going to be adopted as a WG document. While it mentio= ns, that a WG document may be also subjected to such a review at the discretion of the WG Chairs, the initial guideline= s for the QA reviewer in the Wiki mention only reviewing the draft for a QA= adoption. As a consequence, I had to create my own list of questions that = will try to answer based on what I have found in the Wiki. Here is this list:

a. &nbs= p;     Is the draft easily readable and understandable?

b. &nbs= p;    Does the draft represent an attempt to solve a real problem?

c. &nbs= p;     Are there some serious technical gaps that the authors should tr= y to fill?

d. &nbs= p;    Are there any potential IETF process issues with the draft in it= s present form?

Please note that the q= uestion about “a good start for a WG draft” which appears in th= e Wiki does not appear on my list (since the draft is already a WG document= ).

At the same time I hav= e included the question about solving a real problem (which appeared in the= previous version of the Wiki page). The current version only asks if the d= raft “makes sense” which, from my POV, is something else.

 

 

My answers to these qu= estions follow.

 

Is the draft eas= ily readable and understandable?

Of course, “easily readable and understandable” is in th= e eye of the beholder. But as a non-expert can say that it was quite diffic= ult for me to understand what this draft is really about.

Eventually, I have succeeded to build the following scheme that help= ed me to understand what I am dealing with:

·         The TRIL= L base spec:

o   Explicitly restricts TRILL to a single Level 1 IS-IS

o   Explicitly states that the nicknames of RBridges in the Trill pa= cket header remain unchanged when the packet traverses the TRILL domain fro= m ingress (where the TRILL header is pushed on the original Ethernet frame) to egress (where this header is pop= ped)

·         An Informational Multi-Level TRILL WG draft claims that this restriction negatively affe= cts TRILL scalability:

o   It mentions several scalability issues  <= /p>

o   However, it

§  Neither mentions any specific scale parameters where these is= sues become real

§  Nor provides any explanations about the reasons that make sin= gle-level IS-IS used by TRILL less scalable that single-level IS-IS when it= is used for distributing IP reachability

o   It claims that some of these issues may be addressed by allowing= usage of multi-level IS-IS for TRILL

o   It provides two specific proposals for making multi-level TRILL = work:

o   One of these proposals is called “unique nicknames”.= This proposal:

§   Does not require any changes in the TRILL data plane<= /o:p>

§  Requires introducing some structure in the nicknames of RBridges= in order to guarantee that these names are unique within the TRILL-based c= ampus

o   The other proposal is called “aggregate nicknames”. = This proposal:

§  Allows RBridges in different L1 areas of the campus to share nic= knames

§  Requires a change in the TRILL data plane: the nicknames in the = TRILL header of a packet will be modified by the L12 RBridges

§  Allows two possible flavors (bot mentioned in the draft):

·         The flavor that uses L1 area nicknames

·         The flavor that uses the nicknames of all L12 RBridges connected= to a given L1 area as its name

·         The Standards Track Single Nickname draft (one that I have been = asked to review) provides details on the second of the above-mentioned flav= ors of the “Aggregate Nicknames” approach:

o   It also allows sharing the same nickname between RBridges in dif= ferent L1 areas

o   It also requires the same change in the TRILL data plane

o   It eliminates the need for allocating nicknames to L1 areas. Ins= tead, each such area is identified by the set of nicknames of all L12 RBrid= ges that connect to it.

It took me quite some time to build this scheme, and the text in the= draft was not very helpful in this.

The following points contributed to “negative readability̶= 1; from my POV:

·         The draft positions itself as an alternative to the Aggregate Ni= cknames approach while, from my POV, it is just provides additional details= on one of the possible flavors of this approach

·         The draft is intended for the Standards Track, but it does not s= ay that it updates the base TRILL spec (neither in the text nor in metadata).

(I guess that a TRILL expert would not have any problems with readin= g and understanding the draft – but I am providing a non-expert revie= w here.

If I may suggest so, the authors could consider making the introduct= ion more structured and clearly present the flow of dependencies  ther= e.)

 

Does the Draft R= epresent an Attempt To Solve a Real Problem?

 

Unfortunately I cannot provide a definite “Yes” or ̶= 0;No” answer for this question:

·         Neither the draft I am reviewing, nor its “parent” m= ulti-level TRILL draft do not provide sufficient information for a non-expe= rt to understand why TRILL scalability is a real issue.

o   I know that these days single-level IS-IS used for distributing = IP routing information is expected to support up to 1K nodes in “spar= se mesh” topology

o   I do not know whether this level of scale is considered as simpl= y not sufficient for TRILL deployments, be it from the POV of the number of= RBridges, or from the POV of topological complexity

o   I also do not know whether there are some aspects of TRILL that = make it less scalable than IS-IS used for distributing IP routing informati= on

·         I know (as we all do) that in IP routing the preferred approach = to solving IGP scalability issues is by using BGP. I wonder if this (or sim= ilar) approach has ever been considered for TRILL, and, if it was, why did the authors go for multi-level IS-IS.

·         I understand that the “Unique Nicknames” approach in= troduces some issues to TRILL (like structuring the nicknames). But I find = it somewhat difficult to believe to the claim (in the Multi-Level TRILL draft) that the pool of 64K nicknames imposes any se= rious scalability restrictions on TRILL

·         Last but not least, I do not understand why the heed to assign n= icknames to L1 areas (in the other flavor of the “aggregate nicknames= ” approach) carries with it any serious issues.

 

Are there some s= erious technical gaps that the authors should try to fill?

 

I see a potential for one such gap that I believe addressed by the a= uthors: The draft does not say what is supposed to happen when a new border RBri= dge is added a given L1 area.

The draft mentions that if the L1 area with multiple border RBridges= is partitioned so that some RBridges remain in one part and some – i= n the other part, all reachability information learned from it will be flushed. The resulting traffic hits in this scenar= io are expected of course.

But when a new border RBridge is connected to a L1 area, or when the= failure of a link  (or node) that has caused partition of such an are= a is repaired – what should happen? Would such a “positive event” also result in flush of all learned reachab= ility information and the accompanying traffic hit?

 

Are there any po= tential IETF process issues with the draft in its present form?

 

As I have said already, I see this draft as a logical extension of t= he Multi-Level TRILL one, so that,  From my POV the reference to the M= ulti-Level TRILL draft in this one should be Normative. However, the Multi-Level Trill draft is intended for the Inform= ational track, while the Single Nickname draft positions itself as the Stan= dard Track.  Simply making the reference Informative may be good enoug= h as far as the letter of law goes, but I do not feel this is the right way to handle this.

 

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-5492663= 02

Email:   Alexander.Vainshtein@ecitele.com<= o:p>

 

--_000_DB3PR03MB0780AEC260B5293DA90DAFC09D4A0DB3PR03MB0780eurp_-- From nobody Thu May 19 09:39:37 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A6E12DA8C; Thu, 19 May 2016 09:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, 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 yTIQrl_OLomp; Thu, 19 May 2016 09:39:29 -0700 (PDT) Received: from mgw030.noc.ntt.com (mgw030.noc.ntt.com [210.160.55.3]) by ietfa.amsl.com (Postfix) with ESMTP id 47B4312DA8E; Thu, 19 May 2016 09:39:25 -0700 (PDT) Received: from c0043i0.coe.ntt.com (c0043i0.nc.agilit-hosting.com [10.18.161.12]) by mgw030.noc.ntt.com (NTT Com MailSV) with ESMTP id EDFEF1C5824F; Fri, 20 May 2016 01:39:23 +0900 (JST) Received: from C0568I0.coe.ntt.com (10.18.160.119) by c0043i0.coe.ntt.com (10.18.161.12) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 20 May 2016 01:39:20 +0900 Received: from C0561I0.coe.ntt.com ([169.254.1.38]) by C0568I0.coe.ntt.com ([10.18.161.254]) with mapi id 14.03.0181.006; Fri, 20 May 2016 01:39:23 +0900 From: Tomonori Takeda To: "rtg-ads@ietf.org" Thread-Topic: RTG-DIR QA review: draft-ietf-i2rs-protocol-security-requirements-04.txt Thread-Index: AdGx5fCxDq0YNmnWSrK+7ayI8V3BEQ== Date: Thu, 19 May 2016 16:39:22 +0000 Message-ID: Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ccmail-original-to: rtg-ads@ietf.org x-ccmail-original-cc: rtg-dir@ietf.org, draft-ietf-i2rs-protocol-security-requirements.all@ietf.org, i2rs@ietf.org x-originating-ip: [10.25.150.237] Content-Type: text/plain; charset="iso-2022-jp" MIME-Version: 1.0 Archived-At: Cc: "'rtg-dir@ietf.org'" , "'draft-ietf-i2rs-protocol-security-requirements.all@ietf.org'" , "i2rs@ietf.org" Subject: [RTG-DIR] RTG-DIR QA review: draft-ietf-i2rs-protocol-security-requirements-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 16:39:33 -0000 Hi, I have been selected as the Routing Directorate QA reviewer for this draft. Document: draft-ietf-i2rs-protocol-security-requirements-04.txt Reviewer: Tomonori Takeda Review Date: May 20, 2016 Intended Status: Standards Track I am not following I2RS work closely, but in the spirit of QA review, this is OK in my understanding. https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa Here are my comments. I think it is very important to have documents dedicated for security for new protocols such as I2RS protocols. Overall, I think the document is well organized and clear what are security requirements for I2RS. Some specific comments. 1) The document is intended to be Standards Track. I do not think it is common for requirement drafts to be Standards Track. 2) In Section 3.1, requirements are mentioned that are set in draft-ietf-i2rs-architecture-15. Some of these requirements are not directly mentioned in draft-ietf-i2rs-architecture-15, but rather implied. For example, draft-ietf-i2rs-architecture-15 mentions identifier for I2RS client, but does not mention identifier for I2RS agent (IMO). Please note that I think requirements mentioned in Section 3.1. makes sense and valid. I am just commenting on the way of writing. 3) I think there is dependency on requirements mentioned in this document. Specifically, if mutual authentication (Section 3.1), secure transport (Section 3.2), and role-based security (Section 3.3) are met, confidentiality (Section 3.3) and integrity (Section 3.4) can be achieved (expect SEC-REQ-16: traceability requirement). Perhaps, it depends on in which aspects security requirements should be written (in terms of mechanisms or in terms of features). Again, I am just commenting on the way of writing. 4) This is just an edit, but in page.10, "Requirements SEC-REQ-13 and SEC-REQ-14" should be "Requirements SEC-REQ-14 and SEC-REQ-15". Thanks, Tomonori Takeda From nobody Thu May 19 22:56:48 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFD712D6A2; Thu, 19 May 2016 22:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 sw-6EZ24rOZH; Thu, 19 May 2016 22:56:44 -0700 (PDT) Received: from gilfert.gredler.at (gilfert.gredler.at [87.106.222.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89E9612D6A7; Thu, 19 May 2016 22:56:43 -0700 (PDT) Received: from hannes-mba.local ([::ffff:106.51.28.182]) (AUTH: PLAIN hannes, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by gilfert.gredler.at with ESMTPSA; Fri, 20 May 2016 07:56:37 +0200 id 0000000002F75146.00000000573EA715.00007363 From: Hannes Gredler To: rtg-ads@ietf.org Message-ID: Date: Fri, 20 May 2016 07:56:06 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: akatlas@gmail.com, rtg-dir@ietf.org, zhang.xian@huawei.com, Jonathan.Hardwick@metaswitch.com, jon.hudson@gmail.com Subject: [RTG-DIR] Routing directorate review of draft-ietf-trill-irb X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 05:56:46 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or 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 ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-trill-irb Reviewer: Hannes Gredler Review Date: 20-May-2015 IETF LC End Date: date-if-known Intended Status: Proposed Standard Summary: No issues found. This document is ready for publication. I'd have used the term "anycast MAC" for the L3-gw address, then it becomes obvious that more than one Rbridge is advertising the same "virtual L3-gw" MAC address. Please supply an overview of the draft quality and readability. The draft is very readable by use of the numerous examples and illustrations. Enough substance for proper implementations. Personal comments to IESG and routing-ADs (sorry i could not resist) The IETF has to think hard wether it wants to double invent its protocols. IMO the following combo: 1) Control-plane : L2 IS-IS 2) Encapsulation/TTL protection : Trill 3) Label-Stacking: https://tools.ietf.org/html/rfc7172 4) Routing: Distributed L3 gateway (this document) does solve the very same problem as this combo: 1) Control-Plane: L3 IS-IS + SPRING, L3VPN 2) Encapsulation/TTL protection: MPLS 3) Label-Stacking: MPLS 4) Routing: vanilla L3 host-routing thanks, /hannes From nobody Fri May 20 05:32:01 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525EF12D82F; Fri, 20 May 2016 05:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 O83LDnWi2xcN; Fri, 20 May 2016 05:31:59 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39D1C12D19E; Fri, 20 May 2016 05:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1876; q=dns/txt; s=iport; t=1463747518; x=1464957118; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=zH1AqYi6C69DBK2f0yxXy25JT2NsVje3T6lBLOKJQcw=; b=f01em/8Y1IKmqyZg5qfItiOmRgSPHmyrq/gTPPch+xiAVYw6Ore6yOsw 3fZB37LN98HqBjfh3oe39cqZlRk6ll+D8+pqiY36brA8lddQO4FQ1NB2J Yj7GSgCOo0CXfq6u1c2oHJLBnhEzeDl3IhT82Iu9w1Dg1lqlw3kF44Jo7 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CNBgBcAz9X/xbLJq1ehA1+AaU7AgIID?= =?us-ascii?q?AEBAQEBAQUBgQ+DBJIaIoVvggQBAQEBAQFmJ4RsVhkWBgImAl+IQg6VBp0dkWE?= =?us-ascii?q?BAQEBAQEEAQEBAQEBAQEBHoEBhFyCPgiEX4UwK4IuBZg0hgCIIIFpToQBiGSPS?= =?us-ascii?q?2KDbzoziAIBAQE?= X-IronPort-AV: E=Sophos;i="5.26,339,1459814400"; d="scan'208";a="635740922" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 May 2016 12:31:56 +0000 Received: from ams-iwijnand-88113.cisco.com (ams-iwijnand-88113.cisco.com [10.60.202.94]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4KCVt28005874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 May 2016 12:31:56 GMT From: IJsbrand Wijnands Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 20 May 2016 14:31:55 +0200 Message-Id: <887E0412-D057-4404-ACED-69F7B162AEC5@cisco.com> To: "" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Cc: rtg-dir@ietf.org, draft-smirnov-ospf-xaf-te@ietf.org Subject: [RTG-DIR] RtgDir review: draft-smirnov-ospf-xaf-te X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 12:32:00 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or 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 = =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. Document: draft-smirnov-ospf-xaf-te=20 Reviewer: IJsbrand Wijnands=20 Review Date: 20-05-2016 Intended Status: Standards Track Summary:=20 This document is basically ready for publication, but has nits that = should be considered prior to publication. Comments: This document is well written and the use-case is very clear and useful = to solve. Does this also solve the use-case for P2MP TE LSPs? If it = does, maybe its good to mention this. I do think it has consequences as = it requires an IPv4/IPv6 explicit NULL label, if you want to share IPv4 = and IPv6 traffic over the same P2MP LSP. Major Issues:=20 No major issues found. Minor Issues:=20 Section 3. "For example, suppose the OSPFv2 instance =E2=80=A6=E2=80=9D This paragraph could benefit from a rewrite as I find it hard to follow = what the intention is. I would also advise not to use real IP addresses = as an example since the actual value does not matter. Better to say = IPv4_1, IPv4_2,.. IMO.=20 Nits: The acronym =E2=80=9CASON=E2=80=9D is used in this document, but it is = not spelled out what it stands for. Thx, Ice.= From nobody Fri May 20 05:35:51 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7904612D60C; Fri, 20 May 2016 05:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.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, USER_IN_WHITELIST=-100] 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 8Rr3aP3iHsGb; Fri, 20 May 2016 05:35:48 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::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 84ECC12D609; Fri, 20 May 2016 05:35:45 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id j74so107563144ywg.1; Fri, 20 May 2016 05:35:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=quiZcy6j3oyhd/7Fjkhf8JjvU26ershtqlkjVTDxMbQ=; b=ADnSfRy9w86Jl6tOcaxiWAy6IKW1Fl0uuw3TSi6sT4ebEVyeBvBCvwaOfcd64AkR4Q SqHdMmV/zfhya94WvV9Lxv6GLE5Nx2GhU1BBvKrJeZCvU5eucXfnGXiPMtwTmn8GCDT5 D+zBYX7g3wlutvb0xdhARbCRFYlv69BKGsnpt56v4890YKgbFg28i4cLNoMhfjg5C4kK 98rhuq3iFLpujYQ0ehY7y2i5zXkpygyh15g34YLAJGPG5VqkFNepHjAi8/pSBAN8/NzT /ErPcv/h3AMUvghB9D0CT3eyMRdz1/4S8AbRwRY8KOPYxv64rvtj8duFIusWqV2ctqIq mYSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=quiZcy6j3oyhd/7Fjkhf8JjvU26ershtqlkjVTDxMbQ=; b=Y3nL5htaBmLxXcbBVi0S/hiSn2Ef4hFwSe+QzdGsWsoPma47GQdjLY4LUKAmhX1h8V ht6BC8BWkfy467oA4qRrc+RODuX+R+Ejva1K7wUk69vUVD0nnftahxmfx707CY2NYvH7 oxFTv+jJjhCe/Mpx0ERNVMxxdbU8t2PC+pLmeE0evWfbgQrLHOMBzp+La8hwBrUwd6Nq SR7l97frjuREKQ1ve2Htxq73ZSngHB5z/j62zIJBDb4elDLzpR6xepBW1GjcRbJshCAQ ZKrjbyY9zPxTt4wLIbwVSh3z2H1y2uiF27ekIjXuALLoPE7ZLvm4vOuL5D80uGM0wW0O 6R3g== X-Gm-Message-State: AOPr4FULve5BmdRvzE3snRE9FYj2OEmN3A3ao1tIvU/p1kcibNEjYc/B0PNTYhZDFlVAAsIat/TVshnYtSRMeQ== MIME-Version: 1.0 X-Received: by 10.37.218.2 with SMTP id n2mr1651139ybf.125.1463747744771; Fri, 20 May 2016 05:35:44 -0700 (PDT) Received: by 10.13.217.85 with HTTP; Fri, 20 May 2016 05:35:44 -0700 (PDT) In-Reply-To: <887E0412-D057-4404-ACED-69F7B162AEC5@cisco.com> References: <887E0412-D057-4404-ACED-69F7B162AEC5@cisco.com> Date: Fri, 20 May 2016 08:35:44 -0400 Message-ID: From: Alia Atlas To: IJsbrand Wijnands Content-Type: multipart/alternative; boundary=94eb2c07ecd05e38de05334554ce Archived-At: Cc: "" , "rtg-dir@ietf.org" , draft-smirnov-ospf-xaf-te@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-smirnov-ospf-xaf-te X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 12:35:50 -0000 --94eb2c07ecd05e38de05334554ce Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ice, Thank you for doing this review. Regards, Alia On Fri, May 20, 2016 at 8:31 AM, IJsbrand Wijnands wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or 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, plea= se > see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF Las= t > Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-smirnov-ospf-xaf-te > Reviewer: IJsbrand Wijnands > Review Date: 20-05-2016 > Intended Status: Standards Track > > Summary: > > This document is basically ready for publication, but has nits that shoul= d > be considered prior to publication. > > Comments: > > This document is well written and the use-case is very clear and useful t= o > solve. Does this also solve the use-case for P2MP TE LSPs? If it does, > maybe its good to mention this. I do think it has consequences as it > requires an IPv4/IPv6 explicit NULL label, if you want to share IPv4 and > IPv6 traffic over the same P2MP LSP. > > > Major Issues: > No major issues found. > > Minor Issues: > > Section 3. > "For example, suppose the OSPFv2 instance =E2=80=A6=E2=80=9D > > This paragraph could benefit from a rewrite as I find it hard to follow > what the intention is. I would also advise not to use real IP addresses a= s > an example since the actual value does not matter. Better to say IPv4_1, > IPv4_2,.. IMO. > > Nits: > > The acronym =E2=80=9CASON=E2=80=9D is used in this document, but it is no= t spelled out > what it stands for. > > Thx, > > Ice. --94eb2c07ecd05e38de05334554ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ice,

Thank you for doing this review.

Regards,
Alia

On Fri, May 20, 2016 at 8:31 AM, = IJsbrand Wijnands <ice@cisco.com> wrote:
Hello,

I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see =E2= =80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/= wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft.

Document: draft-smirnov-ospf-xaf-te
Reviewer: IJsbrand Wijnands
Review Date: 20-05-2016
Intended Status: Standards Track

Summary:

This document is basically ready for publication, but has nits that should = be considered prior to publication.

Comments:

This document is well written and the use-case is very clear and useful to = solve. Does this also solve the use-case for P2MP TE LSPs? If it does, mayb= e its good to mention this. I do think it has consequences as it requires a= n IPv4/IPv6 explicit NULL label, if you want to share IPv4 and IPv6 traffic= over the same P2MP LSP.


Major Issues:
No major issues found.

Minor Issues:

Section 3.
"For example, suppose the OSPFv2 instance =E2=80=A6=E2=80=9D

This paragraph could benefit from a rewrite as I find it hard to follow wha= t the intention is. I would also advise not to use real IP addresses as an = example since the actual value does not matter. Better to say IPv4_1, IPv4_= 2,.. IMO.

Nits:

The acronym =E2=80=9CASON=E2=80=9D is used in this document, but it is not = spelled out what it stands for.

Thx,

Ice.

--94eb2c07ecd05e38de05334554ce-- From nobody Fri May 20 06:08:39 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18C012D934; Fri, 20 May 2016 06:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] 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 DVnysscAnyiV; Fri, 20 May 2016 06:08:32 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 BE63212D932; Fri, 20 May 2016 06:08:31 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.182.128; From: "Susan Hares" To: "'Alexander Vainshtein'" , "'Jonathan Hardwick'" References: In-Reply-To: Date: Fri, 20 May 2016 09:08:22 -0400 Message-ID: <008d01d1b298$b0646e40$112d4ac0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008E_01D1B277.295A6F60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIr4IXo1xiaoEsxBm33xQ/gINpKbp8NcB2A Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: rtg-dir@ietf.org, draft-ietf-trill-multilevel-single-nickname@ietf.org, zhang.xian@huawei.com, trill@ietf.org, jon.hudson@gmail.com Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 13:08:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_008E_01D1B277.295A6F60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alexander:=20 =20 Thank you for the excellent review. The authors will be responding to = you. I will send further comments later todsay.=20 =20 Sue=20 =20 From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Thursday, May 19, 2016 6:59 AM To: Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com) Cc: Susan Hares (shares@ndzh.com); jon.hudson@gmail.com; zhang.xian@huawei.com; = draft-ietf-trill-multilevel-single-nickname@ietf.org; 'rtg-dir@ietf.org'; trill@ietf.org Subject: RTG-DIR QA review for = draft-ietf-trill-multilevel-single-nickname =20 Hi all, I have been appointed as the QA reviewer for draft-ietf-trill-multilevel-single-nickname . Before going into the review proper, I would like to make a couple of introductory statements. =20 1. I am NOT a TRILL expert and actually never before has been = involved with TRILL. I have been told that this is OK and the ADs are interested = into getting reviews from non-experts. Well, in my case this is what they = will get. 2. The time frame for providing the review was quite demanding (at least for me). This probably affected the review quality and it = effectively prevented me from discussing the review with the draft authors privately = =96 I owe them a sincere apology for that.=20 3. The RtgDirDocQa =96 Rtg = Area Wiki states that the QA review is usually performed when a draft is going to = be adopted as a WG document. While it mentions, that a WG document may be = also subjected to such a review at the discretion of the WG Chairs, the = initial guidelines for the QA reviewer in the Wiki mention only reviewing the = draft for a QA adoption. As a consequence, I had to create my own list of questions that will try to answer based on what I have found in the = Wiki. Here is this list: a. Is the draft easily readable and understandable? b. Does the draft represent an attempt to solve a real problem? c. Are there some serious technical gaps that the authors should = try to fill? d. Are there any potential IETF process issues with the draft in = its present form? Please note that the question about =93a good start for a WG draft=94 = which appears in the Wiki does not appear on my list (since the draft is = already a WG document). At the same time I have included the question about solving a real = problem (which appeared in the previous version of the Wiki page). The current version only asks if the draft =93makes sense=94 which, from my POV, is something else. =20 =20 My answers to these questions follow. =20 Is the draft easily readable and understandable? Of course, =93easily readable and understandable=94 is in the eye of the beholder. But as a non-expert can say that it was quite difficult for me = to understand what this draft is really about. Eventually, I have succeeded to build the following scheme that helped = me to understand what I am dealing with: =B7 The TRILL base spec : o Explicitly restricts TRILL to a single Level 1 IS-IS=20 o Explicitly states that the nicknames of RBridges in the Trill packet header remain unchanged when the packet traverses the TRILL domain from ingress (where the TRILL header is pushed on the original Ethernet = frame) to egress (where this header is popped) =B7 An Informational Multi-Level TRILL WG draft claims that this restriction negatively affects = TRILL scalability: o It mentions several scalability issues =20 o However, it=20 =A7 Neither mentions any specific scale parameters where these issues = become real=20 =A7 Nor provides any explanations about the reasons that make = single-level IS-IS used by TRILL less scalable that single-level IS-IS when it is = used for distributing IP reachability o It claims that some of these issues may be addressed by allowing = usage of multi-level IS-IS for TRILL o It provides two specific proposals for making multi-level TRILL = work: o One of these proposals is called =93unique nicknames=94. This = proposal: =A7 Does not require any changes in the TRILL data plane =A7 Requires introducing some structure in the nicknames of RBridges in = order to guarantee that these names are unique within the TRILL-based campus o The other proposal is called =93aggregate nicknames=94. This = proposal: =A7 Allows RBridges in different L1 areas of the campus to share = nicknames=20 =A7 Requires a change in the TRILL data plane: the nicknames in the = TRILL header of a packet will be modified by the L12 RBridges =A7 Allows two possible flavors (bot mentioned in the draft): =B7 The flavor that uses L1 area nicknames =B7 The flavor that uses the nicknames of all L12 RBridges = connected to a given L1 area as its name =B7 The Standards Track Single Nickname draft (one that I have = been asked to review) provides details on the second of the above-mentioned flavors of the =93Aggregate Nicknames=94 approach: o It also allows sharing the same nickname between RBridges in = different L1 areas o It also requires the same change in the TRILL data plane o It eliminates the need for allocating nicknames to L1 areas. = Instead, each such area is identified by the set of nicknames of all L12 RBridges that connect to it. It took me quite some time to build this scheme, and the text in the = draft was not very helpful in this. The following points contributed to =93negative readability=94 from my = POV: =B7 The draft positions itself as an alternative to the = Aggregate Nicknames approach while, from my POV, it is just provides additional details on one of the possible flavors of this approach =B7 The draft is intended for the Standards Track, but it does = not say that it updates the base TRILL spec (neither in the text nor in = metadata). (I guess that a TRILL expert would not have any problems with reading = and understanding the draft =96 but I am providing a non-expert review here. If I may suggest so, the authors could consider making the introduction = more structured and clearly present the flow of dependencies there.) =20 Does the Draft Represent an Attempt To Solve a Real Problem? =20 Unfortunately I cannot provide a definite =93Yes=94 or =93No=94 answer = for this question: =B7 Neither the draft I am reviewing, nor its =93parent=94 = multi-level TRILL draft do not provide sufficient information for a non-expert to understand why TRILL scalability is a real issue.=20 o I know that these days single-level IS-IS used for distributing IP routing information is expected to support up to 1K nodes in =93sparse = mesh=94 topology o I do not know whether this level of scale is considered as simply = not sufficient for TRILL deployments, be it from the POV of the number of RBridges, or from the POV of topological complexity o I also do not know whether there are some aspects of TRILL that make = it less scalable than IS-IS used for distributing IP routing information =B7 I know (as we all do) that in IP routing the preferred = approach to solving IGP scalability issues is by using BGP. I wonder if this (or similar) approach has ever been considered for TRILL, and, if it was, = why did the authors go for multi-level IS-IS. =B7 I understand that the =93Unique Nicknames=94 approach = introduces some issues to TRILL (like structuring the nicknames). But I find it somewhat difficult to believe to the claim (in the Multi-Level TRILL draft) that = the pool of 64K nicknames imposes any serious scalability restrictions on = TRILL=20 =B7 Last but not least, I do not understand why the heed to = assign nicknames to L1 areas (in the other flavor of the =93aggregate = nicknames=94 approach) carries with it any serious issues. =20 Are there some serious technical gaps that the authors should try to = fill? =20 I see a potential for one such gap that I believe addressed by the = authors: The draft does not say what is supposed to happen when a new border = RBridge is added a given L1 area. The draft mentions that if the L1 area with multiple border RBridges is partitioned so that some RBridges remain in one part and some =96 in the = other part, all reachability information learned from it will be flushed. The resulting traffic hits in this scenario are expected of course. But when a new border RBridge is connected to a L1 area, or when the = failure of a link (or node) that has caused partition of such an area is = repaired =96 what should happen? Would such a =93positive event=94 also result in = flush of all learned reachability information and the accompanying traffic hit? =20 Are there any potential IETF process issues with the draft in its = present form? =20 As I have said already, I see this draft as a logical extension of the Multi-Level TRILL one, so that, From my POV the reference to the Multi-Level TRILL draft in this one should be Normative. However, the Multi-Level Trill draft is intended for the Informational track, while = the Single Nickname draft positions itself as the Standard Track. Simply = making the reference Informative may be good enough as far as the letter of law goes, but I do not feel this is the right way to handle this. =20 =20 Regards, Sasha =20 Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com =20 ------=_NextPart_000_008E_01D1B277.295A6F60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Alexander: =

 

Thank you for the = excellent review.=A0 The authors will be responding to you. =A0I will = send further comments later todsay.

 

Sue =

 

From:= = Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] =
Sent: Thursday, May 19, 2016 6:59 AM
To: Jonathan = Hardwick (Jonathan.Hardwick@metaswitch.com)
Cc: Susan Hares = (shares@ndzh.com); jon.hudson@gmail.com; zhang.xian@huawei.com; = draft-ietf-trill-multilevel-single-nickname@ietf.org; = 'rtg-dir@ietf.org'; trill@ietf.org
Subject: RTG-DIR QA review = for = draft-ietf-trill-multilevel-single-nickname

 

Hi all,

I have been appointed as = the QA reviewer for draft-ietf-trill-multilevel-single-nicknam= e.

Before going into the review proper, I would = like to make a couple of introductory = statements.

 

1.       = I am NOT a TRILL expert and = actually never before has been involved with TRILL. I have been told = that this is OK and the ADs are interested into getting reviews from = non-experts. Well, in my case this is what they will = get.

2.       = The time frame for providing the = review was quite demanding (at least for me). This probably affected the = review quality and it effectively prevented me from discussing the = review with the draft authors privately – I owe them a sincere = apology for that.

3.       = The RtgDi= rDocQa – Rtg Area Wiki states that the QA review is usually = performed when a draft is going to be adopted as a WG document. While it = mentions, that a WG document may be also subjected to such a review at = the discretion of the WG Chairs, the initial guidelines for the QA = reviewer in the Wiki mention only reviewing the draft for a QA adoption. = As a consequence, I had to create my own list of questions that will try = to answer based on what I have found in the Wiki. Here is this = list:

a.       = Is the draft easily readable and = understandable?

b.      = Does the draft represent an attempt = to solve a real problem?

c.       = Are there some serious technical = gaps that the authors should try to fill?

d.      = Are there any potential IETF = process issues with the draft in its present = form?

Please note that the question about “a = good start for a WG draft” which appears in the Wiki does not = appear on my list (since the draft is already a WG = document).

At the same time I have included the question = about solving a real problem (which appeared in the previous version of = the Wiki page). The current version only asks if the draft “makes = sense” which, from my POV, is something = else.

 

 

My answers to these = questions follow.

 

Is the draft = easily readable and understandable?

Of course, = “easily readable and understandable” is in the eye of the = beholder. But as a non-expert can say that it was quite difficult for me = to understand what this draft is really about.

Eventually, I have succeeded to build the = following scheme that helped me to understand what I am dealing = with:

=B7       &= nbsp; The TRILL= base spec:

o   Explicitly restricts TRILL to a single Level 1 = IS-IS

o   Explicitly states that the nicknames of RBridges = in the Trill packet header remain unchanged when the packet traverses = the TRILL domain from ingress (where the TRILL header is pushed on the = original Ethernet frame) to egress (where this header is = popped)

=B7       &= nbsp; An Informational Multi-Level TRILL WG draft claims that this = restriction negatively affects TRILL = scalability:

o   It mentions several scalability issues =  

o   However, it

=A7  Neither mentions any specific scale parameters = where these issues become real

=A7  Nor provides any explanations about the reasons = that make single-level IS-IS used by TRILL less scalable that = single-level IS-IS when it is used for distributing IP = reachability

o   It claims that some of these issues may be = addressed by allowing usage of multi-level IS-IS for = TRILL

o   It provides two specific proposals for making = multi-level TRILL work:

o   One of these proposals is called “unique = nicknames”. This proposal:

=A7   Does not require any changes in the TRILL = data plane

=A7  Requires introducing some structure in the = nicknames of RBridges in order to guarantee that these names are unique = within the TRILL-based campus

o   The other proposal is called “aggregate = nicknames”. This proposal:

=A7  Allows RBridges in different L1 areas of the = campus to share nicknames

=A7  Requires a change in the TRILL data plane: the = nicknames in the TRILL header of a packet will be modified by the L12 = RBridges

=A7  Allows two possible flavors (bot mentioned in = the draft):

=B7       &= nbsp; The flavor that uses L1 area = nicknames

=B7       &= nbsp; The flavor that uses the = nicknames of all L12 RBridges connected to a given L1 area as its = name

=B7       &= nbsp; The Standards Track Single = Nickname draft (one that I have been asked to review) provides details = on the second of the above-mentioned flavors of the “Aggregate = Nicknames” approach:

o   It also allows sharing the same nickname between = RBridges in different L1 areas

o   It also requires the same change in the TRILL = data plane

o   It eliminates the need for allocating nicknames = to L1 areas. Instead, each such area is identified by the set of = nicknames of all L12 RBridges that connect to = it.

It took me = quite some time to build this scheme, and the text in the draft was not = very helpful in this.

The following = points contributed to “negative readability” from my = POV:

=B7       &= nbsp; The draft positions itself as = an alternative to the Aggregate Nicknames approach while, from my POV, = it is just provides additional details on one of the possible flavors of = this approach

=B7       &= nbsp; The draft is intended for the = Standards Track, but it does not say that it updates the base = TRILL spec (neither in the text nor in = metadata).

(I guess that a = TRILL expert would not have any problems with reading and understanding = the draft – but I am providing a non-expert review = here.

If I may = suggest so, the authors could consider making the introduction more = structured and clearly present the flow of dependencies =  there.)

 

Does the Draft = Represent an Attempt To Solve a Real Problem?

 

Unfortunately I = cannot provide a definite “Yes” or “No” answer = for this question:

=B7       &= nbsp; Neither the draft I am = reviewing, nor its “parent” multi-level TRILL draft do not = provide sufficient information for a non-expert to understand why TRILL = scalability is a real issue.

o   I know that these days single-level IS-IS used = for distributing IP routing information is expected to support up to 1K = nodes in “sparse mesh” topology

o   I do not know whether this level of scale is = considered as simply not sufficient for TRILL deployments, be it from = the POV of the number of RBridges, or from the POV of topological = complexity

o   I also do not know whether there are some = aspects of TRILL that make it less scalable than IS-IS used for = distributing IP routing information

=B7       &= nbsp; I know (as we all do) that in = IP routing the preferred approach to solving IGP scalability issues is = by using BGP. I wonder if this (or similar) approach has ever been = considered for TRILL, and, if it was, why did the authors go for = multi-level IS-IS.

=B7       &= nbsp; I understand that the = “Unique Nicknames” approach introduces some issues to TRILL = (like structuring the nicknames). But I find it somewhat difficult to = believe to the claim (in the Multi-Level TRILL draft) that the pool of = 64K nicknames imposes any serious scalability restrictions on TRILL =

=B7       &= nbsp; Last but not least, I do not = understand why the heed to assign nicknames to L1 areas (in the other = flavor of the “aggregate nicknames” approach) carries with = it any serious issues.

 

Are there some = serious technical gaps that the authors should try to = fill?

 

I see a = potential for one such gap that I believe addressed by the authors: = The draft does not say what is supposed to happen when a new border = RBridge is added a given L1 area.

The draft mentions that if the L1 area with = multiple border RBridges is partitioned so that some RBridges remain in = one part and some – in the other part, all reachability = information learned from it will be flushed. The resulting traffic hits = in this scenario are expected of course.

But when a new border RBridge is connected to a = L1 area, or when the failure of a link  (or node) that has caused = partition of such an area is repaired – what should happen? Would = such a “positive event” also result in flush of all learned = reachability information and the accompanying traffic = hit?

 

Are there any = potential IETF process issues with the draft in its present = form?

 

As I have said = already, I see this draft as a logical extension of the Multi-Level = TRILL one, so that,  From my POV the reference to the Multi-Level = TRILL draft in this one should be Normative. However, the Multi-Level = Trill draft is intended for the Informational track, while the Single = Nickname draft positions itself as the Standard Track.  Simply = making the reference Informative may be good enough as far as the letter = of law goes, but I do not feel this is the right way to handle = this.

 

 

Regards,

Sasha

 

Office: = +972-39266302

Cell:      = +972-549266302

Email:   Alexander.Vainshtein@eci= tele.com

 

------=_NextPart_000_008E_01D1B277.295A6F60-- From nobody Fri May 20 06:46:10 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E14C12D0EA; Fri, 20 May 2016 06:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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=-1.426, 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 orCY5Wio4MRX; Fri, 20 May 2016 06:46:03 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 175E012D513; Fri, 20 May 2016 06:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10367; q=dns/txt; s=iport; t=1463751963; x=1464961563; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Z6kpOeNMcJ6HFVUV1fZgFfTPlPi1j45wJ7t8BzVkgYw=; b=H6i1KQXw7AYdoaDZ4Ui4S8qDPENjGgSJHUNcD7qC1kODt8HcO1ZADCIw dNNhzq5D590Tk3MfCt4EBhq25hN2yWUDfeIX1iSvn0lajtR57eLr0ayrb X/Oia0QkGl7MYynmW4jf/wVzjGEtLqagkRb33zuYpWaSLdl7vqgtW3hez g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BHAgD3Ez9X/49dJa1egmxLVn0GrhSGd?= =?us-ascii?q?oR5AQ2BdSKFbwIcgRo4FAEBAQEBAQFlJ4RCAQEBBCNWEAIBBgIOAwMBAigDAgI?= =?us-ascii?q?CHxEUCQgCBAENBYgVAxcOlRedHY0hDYQwAQEBAQEBAQEBAQEBAQEBAQEBAQEBH?= =?us-ascii?q?IpygkOCHIJhglkFmAEzAYV/hieBeYFpToQBiGSHY4dnAQ8PAQFCg21uAYcDfwE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.26,339,1459814400"; d="scan'208,217";a="274074304" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 May 2016 13:46:02 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u4KDk1WH026772 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 20 May 2016 13:46:02 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 20 May 2016 09:46:01 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Fri, 20 May 2016 09:46:01 -0400 From: "Acee Lindem (acee)" To: Alia Atlas , "IJsbrand Wijnands (iwijnand)" Thread-Topic: [RTG-DIR] RtgDir review: draft-smirnov-ospf-xaf-te Thread-Index: AQHRspOfqf+uKT3yUkukqL/OW1QYYJ/CBicA///QkgA= Date: Fri, 20 May 2016 13:46:00 +0000 Message-ID: References: <887E0412-D057-4404-ACED-69F7B162AEC5@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D3648C9D61DA9aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "" , "rtg-dir@ietf.org" , "draft-smirnov-ospf-xaf-te@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-smirnov-ospf-xaf-te X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 13:46:09 -0000 --_000_D3648C9D61DA9aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzIC0gdGhhbmtzIEljZSwNCkFjZWUNCg0KUC5TLiAgQVNPTiBzdGFuZHMgZm9yIEF1dG9tYXRp Y2FsbHkgU3dpdGNoZWQgT3B0aWNhbCBOZXR3b3JrcyB3aXRoIHRoZSBPU1BGIGV4dGVuc2lvbnMg ZGVmaW5lZCBpbiBSRkMgNTc4Ny4NCg0KDQpGcm9tOiBydGctZGlyIDxydGctZGlyLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOnJ0Zy1kaXItYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBB bGlhIEF0bGFzIDxha2F0bGFzQGdtYWlsLmNvbTxtYWlsdG86YWthdGxhc0BnbWFpbC5jb20+Pg0K RGF0ZTogRnJpZGF5LCBNYXkgMjAsIDIwMTYgYXQgODozNSBBTQ0KVG86ICJJSnNicmFuZCBXaWpu YW5kcyAoaXdpam5hbmQpIiA8aWNlQGNpc2NvLmNvbTxtYWlsdG86aWNlQGNpc2NvLmNvbT4+DQpD YzogIjxydGctYWRzQGlldGYub3JnPG1haWx0bzpydGctYWRzQGlldGYub3JnPj4iIDxydGctYWRz QGlldGYub3JnPG1haWx0bzpydGctYWRzQGlldGYub3JnPj4sIFJvdXRpbmcgRGlyZWN0b3JhdGUg PHJ0Zy1kaXJAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1kaXJAaWV0Zi5vcmc+PiwgImRyYWZ0LXNtaXJu b3Ytb3NwZi14YWYtdGVAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LXNtaXJub3Ytb3NwZi14YWYtdGVA aWV0Zi5vcmc+IiA8ZHJhZnQtc21pcm5vdi1vc3BmLXhhZi10ZUBpZXRmLm9yZzxtYWlsdG86ZHJh ZnQtc21pcm5vdi1vc3BmLXhhZi10ZUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW1JURy1ESVJd IFJ0Z0RpciByZXZpZXc6IGRyYWZ0LXNtaXJub3Ytb3NwZi14YWYtdGUNCg0KSWNlLA0KDQpUaGFu ayB5b3UgZm9yIGRvaW5nIHRoaXMgcmV2aWV3Lg0KDQpSZWdhcmRzLA0KQWxpYQ0KDQpPbiBGcmks IE1heSAyMCwgMjAxNiBhdCA4OjMxIEFNLCBJSnNicmFuZCBXaWpuYW5kcyA8aWNlQGNpc2NvLmNv bTxtYWlsdG86aWNlQGNpc2NvLmNvbT4+IHdyb3RlOg0KSGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNl bGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0 LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Ig cm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2Fs bCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMgb24gc3BlY2lhbCByZXF1ZXN0LiBUaGUg cHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91 dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9y YXRlLCBwbGVhc2Ugc2VlIOKAi2h0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3Ry YWMvd2lraS9SdGdEaXINCg0KQWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBm b3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91 IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgSUVURiBMYXN0IENhbGwg Y29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0gdGhy b3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBkcmFmdC4NCg0KRG9jdW1lbnQ6IGRy YWZ0LXNtaXJub3Ytb3NwZi14YWYtdGUNClJldmlld2VyOiBJSnNicmFuZCBXaWpuYW5kcw0KUmV2 aWV3IERhdGU6IDIwLTA1LTIwMTYNCkludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIFRyYWNrDQoN ClN1bW1hcnk6DQoNClRoaXMgZG9jdW1lbnQgaXMgYmFzaWNhbGx5IHJlYWR5IGZvciBwdWJsaWNh dGlvbiwgYnV0IGhhcyBuaXRzIHRoYXQgc2hvdWxkIGJlIGNvbnNpZGVyZWQgcHJpb3IgdG8gcHVi bGljYXRpb24uDQoNCkNvbW1lbnRzOg0KDQpUaGlzIGRvY3VtZW50IGlzIHdlbGwgd3JpdHRlbiBh bmQgdGhlIHVzZS1jYXNlIGlzIHZlcnkgY2xlYXIgYW5kIHVzZWZ1bCB0byBzb2x2ZS4gRG9lcyB0 aGlzIGFsc28gc29sdmUgdGhlIHVzZS1jYXNlIGZvciBQMk1QIFRFIExTUHM/IElmIGl0IGRvZXMs IG1heWJlIGl0cyBnb29kIHRvIG1lbnRpb24gdGhpcy4gSSBkbyB0aGluayBpdCBoYXMgY29uc2Vx dWVuY2VzIGFzIGl0IHJlcXVpcmVzIGFuIElQdjQvSVB2NiBleHBsaWNpdCBOVUxMIGxhYmVsLCBp ZiB5b3Ugd2FudCB0byBzaGFyZSBJUHY0IGFuZCBJUHY2IHRyYWZmaWMgb3ZlciB0aGUgc2FtZSBQ Mk1QIExTUC4NCg0KDQpNYWpvciBJc3N1ZXM6DQpObyBtYWpvciBpc3N1ZXMgZm91bmQuDQoNCk1p bm9yIElzc3VlczoNCg0KU2VjdGlvbiAzLg0KIkZvciBleGFtcGxlLCBzdXBwb3NlIHRoZSBPU1BG djIgaW5zdGFuY2Ug4oCm4oCdDQoNClRoaXMgcGFyYWdyYXBoIGNvdWxkIGJlbmVmaXQgZnJvbSBh IHJld3JpdGUgYXMgSSBmaW5kIGl0IGhhcmQgdG8gZm9sbG93IHdoYXQgdGhlIGludGVudGlvbiBp cy4gSSB3b3VsZCBhbHNvIGFkdmlzZSBub3QgdG8gdXNlIHJlYWwgSVAgYWRkcmVzc2VzIGFzIGFu IGV4YW1wbGUgc2luY2UgdGhlIGFjdHVhbCB2YWx1ZSBkb2VzIG5vdCBtYXR0ZXIuIEJldHRlciB0 byBzYXkgSVB2NF8xLCBJUHY0XzIsLi4gSU1PLg0KDQpOaXRzOg0KDQpUaGUgYWNyb255bSDigJxB U09O4oCdIGlzIHVzZWQgaW4gdGhpcyBkb2N1bWVudCwgYnV0IGl0IGlzIG5vdCBzcGVsbGVkIG91 dCB3aGF0IGl0IHN0YW5kcyBmb3IuDQoNClRoeCwNCg0KSWNlLg0KDQo= --_000_D3648C9D61DA9aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <47013B27C2F2FB4EB9F77FE9886772BF@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5ZZXMgLSB0aGFu a3MgSWNlLCZuYnNwOzwvZGl2Pg0KPGRpdj5BY2VlJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5QLlMuICZuYnNwO0FTT04gc3RhbmRzIGZvciBBdXRvbWF0aWNhbGx5IFN3aXRj aGVkIE9wdGljYWwgTmV0d29ya3Mgd2l0aCB0aGUgT1NQRiBleHRlbnNpb25zIGRlZmluZWQgaW4g UkZDIDU3ODcuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFj azsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsg UEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBp bjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5v bmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZy b206IDwvc3Bhbj5ydGctZGlyICZsdDs8YSBocmVmPSJtYWlsdG86cnRnLWRpci1ib3VuY2VzQGll dGYub3JnIj5ydGctZGlyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgQWxp YSBBdGxhcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFrYXRsYXNAZ21haWwuY29tIj5ha2F0bGFzQGdt YWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6 IDwvc3Bhbj5GcmlkYXksIE1heSAyMCwgMjAxNiBhdCA4OjM1IEFNPGJyPg0KPHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+JnF1b3Q7SUpzYnJhbmQgV2lqbmFuZHMgKGl3 aWpuYW5kKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmljZUBjaXNjby5jb20iPmljZUBjaXNj by5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9z cGFuPiZxdW90OyZsdDs8YSBocmVmPSJtYWlsdG86cnRnLWFkc0BpZXRmLm9yZyI+cnRnLWFkc0Bp ZXRmLm9yZzwvYT4mZ3Q7JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cnRnLWFkc0BpZXRmLm9y ZyI+cnRnLWFkc0BpZXRmLm9yZzwvYT4mZ3Q7LCBSb3V0aW5nIERpcmVjdG9yYXRlICZsdDs8YSBo cmVmPSJtYWlsdG86cnRnLWRpckBpZXRmLm9yZyI+cnRnLWRpckBpZXRmLm9yZzwvYT4mZ3Q7LCAm cXVvdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtc21pcm5vdi1vc3BmLXhhZi10ZUBpZXRmLm9yZyI+ ZHJhZnQtc21pcm5vdi1vc3BmLXhhZi10ZUBpZXRmLm9yZzwvYT4mcXVvdDsNCiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmRyYWZ0LXNtaXJub3Ytb3NwZi14YWYtdGVAaWV0Zi5vcmciPmRyYWZ0LXNtaXJu b3Ytb3NwZi14YWYtdGVAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtSVEctRElSXSBSdGdEaXIgcmV2aWV3OiBk cmFmdC1zbWlybm92LW9zcGYteGFmLXRlPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxl PSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjow IDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPkljZSwNCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PlRoYW5rIHlvdSBmb3IgZG9pbmcgdGhpcyByZXZpZXcuPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRzLDwvZGl2Pg0KPGRpdj5BbGlhPC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90 ZSI+T24gRnJpLCBNYXkgMjAsIDIwMTYgYXQgODozMSBBTSwgSUpzYnJhbmQgV2lqbmFuZHMgPHNw YW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzppY2VAY2lzY28uY29tIiB0YXJnZXQ9 Il9ibGFuayI+aWNlQGNpc2NvLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXIt bGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCkhlbGxvLDxicj4NCjxicj4N CkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmlld2Vy IGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcg YWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3Vn aCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMgb24gc3BlY2lh bCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUNCiByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Np c3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhl IFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUg4oCLPGEgaHJlZj0iaHR0cDovL3RyYWMu dG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpciIgcmVsPSJub3JlZmVycmVy IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJh Yy93aWtpL1J0Z0RpcjwvYT48YnI+DQo8YnI+DQpBbHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUg cHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291bGQgYmUgaGVs cGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBJRVRG IExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJlc29s dmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0Ljxicj4N Cjxicj4NCkRvY3VtZW50OiBkcmFmdC1zbWlybm92LW9zcGYteGFmLXRlPGJyPg0KUmV2aWV3ZXI6 IElKc2JyYW5kIFdpam5hbmRzPGJyPg0KUmV2aWV3IERhdGU6IDIwLTA1LTIwMTY8YnI+DQpJbnRl bmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBUcmFjazxicj4NCjxicj4NClN1bW1hcnk6PGJyPg0KPGJy Pg0KVGhpcyBkb2N1bWVudCBpcyBiYXNpY2FsbHkgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLCBidXQg aGFzIG5pdHMgdGhhdCBzaG91bGQgYmUgY29uc2lkZXJlZCBwcmlvciB0byBwdWJsaWNhdGlvbi48 YnI+DQo8YnI+DQpDb21tZW50czo8YnI+DQo8YnI+DQpUaGlzIGRvY3VtZW50IGlzIHdlbGwgd3Jp dHRlbiBhbmQgdGhlIHVzZS1jYXNlIGlzIHZlcnkgY2xlYXIgYW5kIHVzZWZ1bCB0byBzb2x2ZS4g RG9lcyB0aGlzIGFsc28gc29sdmUgdGhlIHVzZS1jYXNlIGZvciBQMk1QIFRFIExTUHM/IElmIGl0 IGRvZXMsIG1heWJlIGl0cyBnb29kIHRvIG1lbnRpb24gdGhpcy4gSSBkbyB0aGluayBpdCBoYXMg Y29uc2VxdWVuY2VzIGFzIGl0IHJlcXVpcmVzIGFuIElQdjQvSVB2NiBleHBsaWNpdCBOVUxMIGxh YmVsLA0KIGlmIHlvdSB3YW50IHRvIHNoYXJlIElQdjQgYW5kIElQdjYgdHJhZmZpYyBvdmVyIHRo ZSBzYW1lIFAyTVAgTFNQLjxicj4NCjxicj4NCjxicj4NCk1ham9yIElzc3Vlczo8YnI+DQpObyBt YWpvciBpc3N1ZXMgZm91bmQuPGJyPg0KPGJyPg0KTWlub3IgSXNzdWVzOjxicj4NCjxicj4NClNl Y3Rpb24gMy48YnI+DQomcXVvdDtGb3IgZXhhbXBsZSwgc3VwcG9zZSB0aGUgT1NQRnYyIGluc3Rh bmNlIOKApuKAnTxicj4NCjxicj4NClRoaXMgcGFyYWdyYXBoIGNvdWxkIGJlbmVmaXQgZnJvbSBh IHJld3JpdGUgYXMgSSBmaW5kIGl0IGhhcmQgdG8gZm9sbG93IHdoYXQgdGhlIGludGVudGlvbiBp cy4gSSB3b3VsZCBhbHNvIGFkdmlzZSBub3QgdG8gdXNlIHJlYWwgSVAgYWRkcmVzc2VzIGFzIGFu IGV4YW1wbGUgc2luY2UgdGhlIGFjdHVhbCB2YWx1ZSBkb2VzIG5vdCBtYXR0ZXIuIEJldHRlciB0 byBzYXkgSVB2NF8xLCBJUHY0XzIsLi4gSU1PLjxicj4NCjxicj4NCk5pdHM6PGJyPg0KPGJyPg0K VGhlIGFjcm9ueW0g4oCcQVNPTuKAnSBpcyB1c2VkIGluIHRoaXMgZG9jdW1lbnQsIGJ1dCBpdCBp cyBub3Qgc3BlbGxlZCBvdXQgd2hhdCBpdCBzdGFuZHMgZm9yLjxicj4NCjxicj4NClRoeCw8YnI+ DQo8YnI+DQpJY2UuPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D3648C9D61DA9aceeciscocom_-- From nobody Fri May 20 07:05:40 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09C112D98E; Fri, 20 May 2016 07:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] 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 Jasng2igxoJG; Fri, 20 May 2016 07:05:37 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 C00EB12D988; Fri, 20 May 2016 07:05:36 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.182.128; From: "Susan Hares" To: "'Tomonori Takeda'" , References: In-Reply-To: Date: Fri, 20 May 2016 10:05:33 -0400 Message-ID: <00c701d1b2a0$ad254f30$076fed90$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C8_01D1B27F.2616BC70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFZkbV8xMTMF+FMKLR7WGNqnq+0AaCxLJGA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: rtg-dir@ietf.org, draft-ietf-i2rs-protocol-security-requirements.all@ietf.org, i2rs@ietf.org Subject: Re: [RTG-DIR] [i2rs] RTG-DIR QA review: draft-ietf-i2rs-protocol-security-requirements-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 14:05:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00C8_01D1B27F.2616BC70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Takeda-san: Thank you for your excellent review. My responses to your comments are below. I've released a version-05 to address your comments. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Tomonori Takeda Sent: Thursday, May 19, 2016 12:39 PM To: rtg-ads@ietf.org Cc: 'rtg-dir@ietf.org'; 'draft-ietf-i2rs-protocol-security-requirements.all@ietf.org'; i2rs@ietf.org Subject: [i2rs] RTG-DIR QA review: draft-ietf-i2rs-protocol-security-requirements-04.txt Hi, I have been selected as the Routing Directorate QA reviewer for this draft. Document: draft-ietf-i2rs-protocol-security-requirements-04.txt Reviewer: Tomonori Takeda Review Date: May 20, 2016 Intended Status: Standards Track I am not following I2RS work closely, but in the spirit of QA review, this is OK in my understanding. https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa Here are my comments. I think it is very important to have documents dedicated for security for new protocols such as I2RS protocols. Overall, I think the document is well organized and clear what are security requirements for I2RS. Some specific comments. 1) The document is intended to be Standards Track. I do not think it is common for requirement drafts to be Standards Track. Sue: You are correct. This is my error. I should have changed it this morning. 2) In Section 3.1, requirements are mentioned that are set in draft-ietf-i2rs-architecture-15. Some of these requirements are not directly mentioned in draft-ietf-i2rs-architecture-15, but rather implied. For example, draft-ietf-i2rs-architecture-15 mentions identifier for I2RS client, but does not mention identifier for I2RS agent (IMO). Please note that I think requirements mentioned in Section 3.1. makes sense and valid. I am just commenting on the way of writing. Sue: You are correct that the mutual identification implies an identity for the agent. Also in Section 2 of draft-ietf-i2rs-architecture-15 mentions: role or security role: A security role specifies the scope, resources, priorities, etc. that a client or agent has. If a identity has multiple roles in the security system, the identity is permitted to perform any operations any of those roles permit. Multiple identities may use the same security role. 3) I think there is dependency on requirements mentioned in this document. Specifically, if mutual authentication (Section 3.1), secure transport (Section 3.2), and role-based security (Section 3.3) are met, confidentiality (Section 3.3) and integrity (Section 3.4) can be achieved (expect SEC-REQ-16: traceability requirement). Perhaps, it depends on in which aspects security requirements should be written (in terms of mechanisms or in terms of features). Again, I am just commenting on the way of writing. Sue: You make an excellent point: I have added to the first part section 3.0 after the first paragraph: New/ There are dependencies in some of the requirements below. For confidentiality (section 3.3) and integrity (section 3.4) to be achieved, the client-agent must have mutual authentication (section 3.1) and secure transport (section 3.2). I2RS allows the use of an insecure transport for portions of data models that clearly indicate insecure transport. If insecure transport is used, then confidentiality and integrity cannot be achieved. 4) This is just an edit, but in page.10, "Requirements SEC-REQ-13 and SEC-REQ-14" should be "Requirements SEC-REQ-14 and SEC-REQ-15". --- Thank you for the editorial comment Thanks, Tomonori Takeda _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs ------=_NextPart_000_00C8_01D1B27F.2616BC70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Takeda-san:

 

Thank = you for your excellent review.  My responses to your comments are = below.  I’ve released a version-05 to address your comments. =

 

Sue

 

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

From: i2rs [mailto:i2rs-bounces@ietf.org] = On Behalf Of Tomonori Takeda

Sent: = Thursday, May 19, 2016 12:39 PM

To: rtg-ads@ietf.org

Cc: 'rtg-dir@ietf.org'; = 'draft-ietf-i2rs-protocol-security-requirements.all@ietf.org'; i2rs@ietf.org

Subject: [i2rs] RTG-DIR QA review: = draft-ietf-i2rs-protocol-security-requirements-04.txt

 

Hi,

 

I have = been selected as the Routing Directorate QA reviewer for this = draft.

 

Document: = draft-ietf-i2rs-protocol-security-requirements-04.txt

Reviewer: Tomonori Takeda

Review Date: May 20, 2016

Intended Status: Standards Track

 

I am = not following I2RS work closely, but in the spirit of QA review, this is = OK in my understanding.

https= ://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa

<= p class=3DMsoPlainText> 

Here = are my comments.

 

I = think it is very important to have documents dedicated for security for = new protocols such as I2RS protocols.

Overall, I think the document is well organized and = clear what are security requirements for I2RS.

 

Some = specific comments.

 

1) The = document is intended to be Standards Track. I do not think it is common = for requirement drafts to be Standards Track.

 

Sue: = You are correct.  This is my error. I should have changed it this = morning.

 

2) In Section 3.1, requirements are mentioned that = are set in draft-ietf-i2rs-architecture-15.

   Some of these requirements are = not directly mentioned in draft-ietf-i2rs-architecture-15, =

   but rather = implied.

 

   For example, = draft-ietf-i2rs-architecture-15 mentions identifier for I2RS = client,

   but does not = mention identifier for I2RS agent (IMO).

   Please note that I think requirements = mentioned in Section 3.1. makes sense and valid.

   I am just commenting on the way of = writing.

 

Sue: You are correct = that the mutual identification implies an identity for the agent. =

Also in Section 2 of = draft-ietf-i2rs-architecture-15 mentions:

   role or security = role:   A security role specifies the = scope,

      resources, = priorities, etc. that a client or agent has.  If = a

      identity has = multiple roles in the security system, the = identity

      is permitted to = perform any operations any of those roles = permit.

      Multiple = identities may use the same security role.

 

 

3) I = think there is dependency on requirements mentioned in this = document.

   = Specifically, if mutual authentication (Section 3.1), secure transport = (Section 3.2),

   and = role-based security (Section 3.3) are met, confidentiality (Section 3.3) = and

   integrity = (Section 3.4) can be achieved (expect SEC-REQ-16: traceability = requirement).

 

   Perhaps, it depends on in which = aspects security requirements should be written

   (in terms of mechanisms or in terms of = features). Again, I am just commenting

   on the way of = writing.

 

Sue: You make an excellent point:

I have added to the first part section 3.0 after = the first paragraph:

New/

<t>There are = dependencies in some of the requirements below.  For =

confidentiality (section 3.3) and integrity = (section 3.4) to be achieved, the

client-agent must = have mutual authentication (section 3.1) and secure transport (section = 3.2).   I2RS allows the use of an insecure transport for = portions of data models that clearly indicate insecure transport.  = If insecure transport is used, then confidentiality and integrity cannot = be achieved.

</t>

4) This is just an edit, but in page.10, =

   "Requirements SEC-REQ-13 and = SEC-REQ-14" should be

   "Requirements SEC-REQ-14 and = SEC-REQ-15".

 

--- Thank you for the editorial comment =

 

Thanks,

Tomonori Takeda

 

_______________________________________________=

i2rs mailing list

i2rs@ietf.org

https://www.ietf.org/= mailman/listinfo/i2rs

------=_NextPart_000_00C8_01D1B27F.2616BC70-- From nobody Fri May 20 07:22:16 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8224312D9A6; Fri, 20 May 2016 07:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] 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 HzwiZ7Hl-0ZL; Fri, 20 May 2016 07:22:13 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 D252A12D0ED; Fri, 20 May 2016 07:22:12 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.182.128; From: "Susan Hares" To: "'Hannes Gredler'" , References: In-Reply-To: Date: Fri, 20 May 2016 10:22:05 -0400 Message-ID: <00d601d1b2a2$fcaf7ba0$f60e72e0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMPzxHWiB6dl2eX1fxKKBniXuSaz51Fpujg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Jonathan.Hardwick@metaswitch.com, rtg-dir@ietf.org, zhang.xian@huawei.com, jon.hudson@gmail.com, akatlas@gmail.com Subject: Re: [RTG-DIR] Routing directorate review of draft-ietf-trill-irb X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 14:22:14 -0000 Hannes: Thank you for the review of draft-ietf-trill-irb. The authors will = reply to your textural revision comments. =20 We'll see what the IESG /ADs say regarding your comments. There are = deployments of TRILL - so the WG focus has been to address distributed = gateway issues.=20 Sue Hares=20 -----Original Message----- From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Hannes = Gredler Sent: Friday, May 20, 2016 1:56 AM To: rtg-ads@ietf.org Cc: akatlas@gmail.com; rtg-dir@ietf.org; zhang.xian@huawei.com; = Jonathan.Hardwick@metaswitch.com; jon.hudson@gmail.com Subject: [RTG-DIR] Routing directorate review of draft-ietf-trill-irb Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or 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 = =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. Document: draft-ietf-trill-irb Reviewer: Hannes Gredler Review Date: 20-May-2015 IETF LC End Date: date-if-known Intended Status: Proposed Standard Summary: No issues found. This document is ready for publication. I'd have used the term "anycast MAC" for the L3-gw address, then it = becomes obvious that more than one Rbridge is advertising the same "virtual = L3-gw" MAC address. Please supply an overview of the draft quality and readability. The draft is very readable by use of the numerous examples and = illustrations. Enough substance for proper implementations. Personal comments to IESG and routing-ADs (sorry i could not resist) The IETF has to think hard wether it wants to double invent its = protocols. IMO the following combo: 1) Control-plane : L2 IS-IS 2) Encapsulation/TTL protection : Trill 3) Label-Stacking: https://tools.ietf.org/html/rfc7172 4) Routing: Distributed L3 gateway (this document) does solve the very same problem as this combo: 1) Control-Plane: L3 IS-IS + SPRING, L3VPN 2) Encapsulation/TTL protection: MPLS 3) Label-Stacking: MPLS 4) Routing: vanilla L3 host-routing thanks, /hannes From nobody Fri May 20 07:36:38 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5135812D10E; Fri, 20 May 2016 07:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.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, USER_IN_WHITELIST=-100] 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 W1MemJO_haLe; Fri, 20 May 2016 07:36:35 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 5809212D14A; Fri, 20 May 2016 07:36:33 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id j74so110940137ywg.1; Fri, 20 May 2016 07:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=39rtQ0mAKpoefF2kIGKIJoFPszI0I20ffzhfhVCAUlY=; b=bGmDKmBejoZf07c/xcPfRIUNxu4Znc55o3nihIJ1zCnUKzYa2qkxnhUgkFBc3V5gYw g1ULbIJea3TbDkQ4l6bx5Jn/r/8QoyTEpK2BUBRBT5D48TqOjNOF7lfnQCYUJWEL7b0Y QjKwrmrlPj849bSPJeBvUN01801pVqkHIgJeSOS8eTHl3o208JeQb1CnEMlpfFSq7zv2 aYXgEVuTYjMk7YFh4oYmmjbEwAT6dRC5IGcCGwLo+rtbxczRzss+rgW0ocBigrurRRQU n4bnwGis+ULQwRx88g6HGF8ScMjuKrS+mpL6A8qsHz7S7HWLEsxZ8sAwj2J8tBkZc1Nk w7ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=39rtQ0mAKpoefF2kIGKIJoFPszI0I20ffzhfhVCAUlY=; b=D6BrM6edcqP1G8/JXVwWffOqZDqNJzoO+t71/OceU4J8bAJULi3VxgWeMeDcK18w9I hUlNiWDgqHSPHCfJka3imnq7n7sqKMGNr/uguVmAAqtMralYAJ/6Os7HHwtltPObQpfy 7rlfhAzQ+XLVDwjl5j4VQHRGezTAKtiWF5EaH++c9PM+mWtZR4bqL5pTTOw29zN2x9EJ oSjp/nQBBm777vw28+acvzb6qxsfaK0iNbSFqYc3ep5u0+kGNEIanX4J7iGqmBtKZXbA f60zfgGShvc5jwbnF4AC1n2H1duvkw4Yc1n4zhRshBKTPlwix1v7ByHsl3dLejsYCZC/ YQOg== X-Gm-Message-State: AOPr4FUYco3pRUVKD2RtgxA/gkdyI1u2T8ZymrbnBvwSK2LSbyqtm3g2NkYYJz5BxbTReS99DzTTvY5jUmS3Tg== MIME-Version: 1.0 X-Received: by 10.129.132.83 with SMTP id u80mr2369178ywf.7.1463754992609; Fri, 20 May 2016 07:36:32 -0700 (PDT) Received: by 10.13.221.74 with HTTP; Fri, 20 May 2016 07:36:32 -0700 (PDT) In-Reply-To: References: Date: Fri, 20 May 2016 10:36:32 -0400 Message-ID: From: Alia Atlas To: Hannes Gredler Content-Type: multipart/alternative; boundary=001a114f2c985f703e053347049c Archived-At: Cc: "" , "rtg-dir@ietf.org" , "Zhangxian \(Xian\)" , Jonathan Hardwick , Jon Hudson Subject: Re: [RTG-DIR] Routing directorate review of draft-ietf-trill-irb X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 14:36:37 -0000 --001a114f2c985f703e053347049c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hannes, Thanks for the review. As far as multiple solutions, I don't see having a small number for data-center networks as an issue. In particular, this is giving the L3 Routing for what is mostly a layer-2 network. While L2VPN or EVPN can also address it, there's tossing in more protocols and overhead which assume a very different data-center network. There are trill deployments that need this functionality. Regards, Alia On Fri, May 20, 2016 at 1:56 AM, Hannes Gredler wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or 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 > =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-trill-irb > Reviewer: Hannes Gredler > Review Date: 20-May-2015 > IETF LC End Date: date-if-known Intended Status: Proposed Standard > > Summary: No issues found. This document is ready for publication. > > I'd have used the term "anycast MAC" for the L3-gw address, then it > becomes > obvious that more than one Rbridge is advertising the same "virtual > L3-gw" > MAC address. > > Please supply an overview of the draft quality and readability. > The draft is very readable by use of the numerous examples and > illustrations. > Enough substance for proper implementations. > > > Personal comments to IESG and routing-ADs (sorry i could not resist) > > The IETF has to think hard wether it wants to double invent its > protocols. > > IMO the following combo: > > 1) Control-plane : L2 IS-IS > 2) Encapsulation/TTL protection : Trill > 3) Label-Stacking: https://tools.ietf.org/html/rfc7172 > 4) Routing: Distributed L3 gateway (this document) > > does solve the very same problem as this combo: > > 1) Control-Plane: L3 IS-IS + SPRING, L3VPN > 2) Encapsulation/TTL protection: MPLS > 3) Label-Stacking: MPLS > 4) Routing: vanilla L3 host-routing > > thanks, > > /hannes > --001a114f2c985f703e053347049c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hannes,

Thanks for the review. =C2=A0

As far as multiple solutions, I don't see havin= g a small number for data-center networks as an issue.
In particu= lar, this is giving the L3 Routing for what is mostly a layer-2 network. = =C2=A0 While L2VPN or EVPN
can also address it, there's tossi= ng in more protocols and overhead which assume a very different
d= ata-center network. =C2=A0 There are trill deployments that need this funct= ionality.

Regards,
Alia

On Fri, May 20, 2016 a= t 1:56 AM, Hannes Gredler <hannes@gredler.at> wrote:
Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or 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
=E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/tra= c/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF
Last Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-trill-irb
Reviewer: Hannes Gredler
Review Date: 20-May-2015
IETF LC End Date: date-if-known Intended Status: Proposed Standard

Summary:=C2=A0 =C2=A0No issues found. This document is ready for publicatio= n.

=C2=A0 I'd have used the term "anycast MAC" for the L3-gw add= ress, then it
becomes
=C2=A0 obvious that more than one Rbridge is advertising the same "vir= tual L3-gw"
=C2=A0 MAC address.

Please supply an overview of the draft quality and readability.
=C2=A0 The draft is very readable by use of the numerous examples and
illustrations.
=C2=A0 Enough substance for proper implementations.


Personal comments to IESG and routing-ADs (sorry i could not resist)

=C2=A0 The IETF has to think hard wether it wants to double invent its prot= ocols.

=C2=A0 IMO the following combo:

=C2=A0 =C2=A0 1) Control-plane : L2 IS-IS
=C2=A0 =C2=A0 2) Encapsulation/TTL protection : Trill
=C2=A0 =C2=A0 3) Label-Stacking: https://tools.ietf.org/html/rfc7= 172
=C2=A0 =C2=A0 4) Routing:=C2=A0 =C2=A0 =C2=A0 =C2=A0 Distributed L3 gateway= (this document)

=C2=A0 does solve the very same problem as this combo:

=C2=A0 =C2=A0 1) Control-Plane: L3 IS-IS + SPRING, L3VPN
=C2=A0 =C2=A0 2) Encapsulation/TTL protection: MPLS
=C2=A0 =C2=A0 3) Label-Stacking: MPLS
=C2=A0 =C2=A0 4) Routing: vanilla L3 host-routing

thanks,

/hannes

--001a114f2c985f703e053347049c-- From nobody Sat May 21 06:51:32 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFB212B030; Sat, 21 May 2016 06:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, 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 OX_ZRBa_HgeV; Sat, 21 May 2016 06:51:24 -0700 (PDT) Received: from mgw030.noc.ntt.com (mgw030.noc.ntt.com [210.160.55.3]) by ietfa.amsl.com (Postfix) with ESMTP id 2E52912D0AD; Sat, 21 May 2016 06:51:24 -0700 (PDT) Received: from c0042i0.coe.ntt.com (c0042i0.nc.agilit-hosting.com [10.18.161.11]) by mgw030.noc.ntt.com (NTT Com MailSV) with ESMTP id 2987F1C58090; Sat, 21 May 2016 22:51:23 +0900 (JST) Received: from C0036I0.coe.ntt.com (10.18.160.40) by c0042i0.coe.ntt.com (10.18.161.11) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sat, 21 May 2016 22:51:14 +0900 Received: from C0561I0.coe.ntt.com ([169.254.1.38]) by C0036I0.coe.ntt.com ([10.18.160.40]) with mapi id 14.03.0181.006; Sat, 21 May 2016 22:51:22 +0900 From: Tomonori Takeda To: 'Susan Hares' , "rtg-ads@ietf.org" Thread-Topic: [i2rs] RTG-DIR QA review: draft-ietf-i2rs-protocol-security-requirements-04.txt Thread-Index: AdGx5fCxDq0YNmnWSrK+7ayI8V3BEQAb0v2AAESJF1A= Date: Sat, 21 May 2016 13:51:21 +0000 Message-ID: References: <00c701d1b2a0$ad254f30$076fed90$@ndzh.com> In-Reply-To: <00c701d1b2a0$ad254f30$076fed90$@ndzh.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ccmail-original-to: shares@ndzh.com, rtg-ads@ietf.org x-ccmail-original-cc: rtg-dir@ietf.org, draft-ietf-i2rs-protocol-security-requirements.all@ietf.org, i2rs@ietf.org x-originating-ip: [10.25.130.6] Content-Type: multipart/alternative; boundary="_000_EB0F2EAC05E9C64D80571F2042700A2A6C7FE8AEC0561I0coenttco_" MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-i2rs-protocol-security-requirements.all@ietf.org" , "i2rs@ietf.org" Subject: Re: [RTG-DIR] [i2rs] RTG-DIR QA review: draft-ietf-i2rs-protocol-security-requirements-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2016 13:51:28 -0000 --_000_EB0F2EAC05E9C64D80571F2042700A2A6C7FE8AEC0561I0coenttco_ Content-Type: text/plain; charset="iso-2022-jp" Hi Sue, Thanks for the update. This version looks good to me, except one editorial comment. > 4) This is just an edit, but in page.10, > "Requirements SEC-REQ-13 and SEC-REQ-14" should be > "Requirements SEC-REQ-14 and SEC-REQ-15". > > --- Thank you for the editorial comment Now, text is $B!H(BRequirements SEC-REQ-14 and SEC-REQ-16$B!I(B, but it should be $B!H(BRequirements SEC-REQ-14 and SEC-REQ-15$B!I(B. (Again, this is just an editorial comment.) Thanks, Tomonori Takeda From: Susan Hares [mailto:shares@ndzh.com] Sent: Friday, May 20, 2016 11:06 PM To: Tomonori Takeda$B!JIpEDCNE5!K(B; rtg-ads@ietf.org Cc: rtg-dir@ietf.org; draft-ietf-i2rs-protocol-security-requirements.all@ietf.org; i2rs@ietf.org Subject: RE: [i2rs] RTG-DIR QA review: draft-ietf-i2rs-protocol-security-requirements-04.txt Takeda-san: Thank you for your excellent review. My responses to your comments are below. I$B!G(Bve released a version-05 to address your comments. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Tomonori Takeda Sent: Thursday, May 19, 2016 12:39 PM To: rtg-ads@ietf.org Cc: 'rtg-dir@ietf.org'; 'draft-ietf-i2rs-protocol-security-requirements.all@ietf.org'; i2rs@ietf.org Subject: [i2rs] RTG-DIR QA review: draft-ietf-i2rs-protocol-security-requirements-04.txt Hi, I have been selected as the Routing Directorate QA reviewer for this draft. Document: draft-ietf-i2rs-protocol-security-requirements-04.txt Reviewer: Tomonori Takeda Review Date: May 20, 2016 Intended Status: Standards Track I am not following I2RS work closely, but in the spirit of QA review, this is OK in my understanding. https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa Here are my comments. I think it is very important to have documents dedicated for security for new protocols such as I2RS protocols. Overall, I think the document is well organized and clear what are security requirements for I2RS. Some specific comments. 1) The document is intended to be Standards Track. I do not think it is common for requirement drafts to be Standards Track. Sue: You are correct. This is my error. I should have changed it this morning. 2) In Section 3.1, requirements are mentioned that are set in draft-ietf-i2rs-architecture-15. Some of these requirements are not directly mentioned in draft-ietf-i2rs-architecture-15, but rather implied. For example, draft-ietf-i2rs-architecture-15 mentions identifier for I2RS client, but does not mention identifier for I2RS agent (IMO). Please note that I think requirements mentioned in Section 3.1. makes sense and valid. I am just commenting on the way of writing. Sue: You are correct that the mutual identification implies an identity for the agent. Also in Section 2 of draft-ietf-i2rs-architecture-15 mentions: role or security role: A security role specifies the scope, resources, priorities, etc. that a client or agent has. If a identity has multiple roles in the security system, the identity is permitted to perform any operations any of those roles permit. Multiple identities may use the same security role. 3) I think there is dependency on requirements mentioned in this document. Specifically, if mutual authentication (Section 3.1), secure transport (Section 3.2), and role-based security (Section 3.3) are met, confidentiality (Section 3.3) and integrity (Section 3.4) can be achieved (expect SEC-REQ-16: traceability requirement). Perhaps, it depends on in which aspects security requirements should be written (in terms of mechanisms or in terms of features). Again, I am just commenting on the way of writing. Sue: You make an excellent point: I have added to the first part section 3.0 after the first paragraph: New/ There are dependencies in some of the requirements below. For confidentiality (section 3.3) and integrity (section 3.4) to be achieved, the client-agent must have mutual authentication (section 3.1) and secure transport (section 3.2). I2RS allows the use of an insecure transport for portions of data models that clearly indicate insecure transport. If insecure transport is used, then confidentiality and integrity cannot be achieved. 4) This is just an edit, but in page.10, "Requirements SEC-REQ-13 and SEC-REQ-14" should be "Requirements SEC-REQ-14 and SEC-REQ-15". --- Thank you for the editorial comment Thanks, Tomonori Takeda _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --_000_EB0F2EAC05E9C64D80571F2042700A2A6C7FE8AEC0561I0coenttco_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby0yMDIyLWpwIj4NCjxtZXRhIG5hbWU9Ikdl bmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0K PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IhskQiNNI1MbKEIgGyRCTEBEKxsoQiI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4 IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiIbJEIjTSNTGyhCIBskQiU0JTclQyUv GyhCIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiIbJEIjTSNTGyhCIBskQiU0JTclQyUvGyhCIjsNCglwYW5vc2UtMToyIDExIDYg OSA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi GyRCI00jUxsoQiAbJEIjUCU0JTclQyUvGyhCIjsNCglwYW5vc2UtMToyIDExIDYgMCA3IDIgNSA4 IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDEx IDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQBskQiNNI1Mb KEIgGyRCJTQlNyVDJS8bKEIiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAGyRCI00jUxsoQiAbJEIjUCU0JTclQyUvGyhCIjsN CglwYW5vc2UtMToyIDExIDYgMCA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQBskQiNNI1MbKEIgGyRCTEBEKxsoQiI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4 IDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MG1tOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IhskQj1xPDAkSiQ3GyhCIFwoGyRCSjg7ehsoQlwpIjsNCgltYXJn aW46MG1tOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29B Y2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IhskQj9hJC09UCQ3GyhCIFwoGyRCSjg7ehsoQlwpIjsNCgltYXJnaW46MG1tOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uYQ0KCXttc28tc3R5bGUtbmFtZToiGyRCPXE8 MCRKJDcbKEIgXCgbJEJKODt6GyhCXCkiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazobJEI9cTwwJEokNxsoQjsNCglmb250LWZhbWlseToiGyRCI00jUxsoQiAbJEJM QEQrGyhCIiwic2VyaWYiO30NCnNwYW4uYTANCgl7bXNvLXN0eWxlLW5hbWU6IhskQj9hJC09UCQ3 GyhCIFwoGyRCSjg7ehsoQlwpIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6GyRCP2EkLT1QJDcbKEI7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 fQ0KcC5QbGFpblRleHQsIGxpLlBsYWluVGV4dCwgZGl2LlBsYWluVGV4dA0KCXttc28tc3R5bGUt bmFtZToiUGxhaW4gVGV4dCI7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJ bWFyZ2luOjBtbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uUGxhaW5UZXh0Q2hh cg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7fQ0KcC5CYWxsb29uVGV4dCwgbGkuQmFsbG9vblRleHQsIGRpdi5C YWxsb29uVGV4dA0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IjsNCgltc28tc3R5bGUt bGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowbW07DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi4yNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0 IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiI+DQo8djp0ZXh0Ym94IGluc2V0PSI1Ljg1cHQsLjdw dCw1Ljg1cHQsLjdwdCIgLz4NCjwvbzpzaGFwZWRlZmF1bHRzPjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJKQSIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkg U3VlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgdGhlIHVwZGF0 ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIHZlcnNpb24gbG9va3MgZ29v ZCB0byBtZSwgZXhjZXB0IG9uZSBlZGl0b3JpYWwgY29tbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA0KSBUaGlzIGlzIGp1 c3QgYW4gZWRpdCwgYnV0IGluIHBhZ2UuMTAsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmbmJzcDsmbmJzcDsm bmJzcDsmcXVvdDtSZXF1aXJlbWVudHMgU0VDLVJFUS0xMyBhbmQgU0VDLVJFUS0xNCZxdW90OyBz aG91bGQgYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAmbmJzcDsmbmJzcDsgJnF1b3Q7UmVxdWlyZW1lbnRzIFNF Qy1SRVEtMTQgYW5kIFNFQy1SRVEtMTUmcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjojMDA3MEMwIj4mZ3Q7IC0tLSBUaGFuayB5b3UgZm9yIHRoZSBlZGl0b3JpYWwg Y29tbWVudA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Tm93LCB0ZXh0IGlzIBsk QiFIGyhCUmVxdWlyZW1lbnRzIFNFQy1SRVEtMTQgYW5kIFNFQy1SRVEtMTYbJEIhSRsoQiwgYnV0 IGl0IHNob3VsZCBiZSAbJEIhSBsoQlJlcXVpcmVtZW50cyBTRUMtUkVRLTE0IGFuZCBTRUMtUkVR LTE1GyRCIUkbKEIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KEFn YWluLCB0aGlzIGlzIGp1c3QgYW4gZWRpdG9yaWFsIGNvbW1lbnQuKTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5Ub21vbm9yaSBUYWtlZGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MG1tIDBtbSAwbW0iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU3VzYW4gSGFyZXMgW21haWx0bzpzaGFyZXNAbmR6aC5j b21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXkgMjAsIDIwMTYgMTE6MDYgUE08YnI+ DQo8Yj5Ubzo8L2I+IFRvbW9ub3JpIFRha2VkYTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDsbJEIjTSNTGyhCIBskQiNQJTQlNyVDJS8bKEImcXVv dDsiPhskQiFKSXBFRENORTUhSxsoQjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjsgcnRnLWFkc0BpZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gcnRnLWRpckBp ZXRmLm9yZzsgZHJhZnQtaWV0Zi1pMnJzLXByb3RvY29sLXNlY3VyaXR5LXJlcXVpcmVtZW50cy5h bGxAaWV0Zi5vcmc7IGkycnNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtpMnJz XSBSVEctRElSIFFBIHJldmlldzogZHJhZnQtaWV0Zi1pMnJzLXByb3RvY29sLXNlY3VyaXR5LXJl cXVpcmVtZW50cy0wNC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5U YWtlZGEtc2FuOiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rIHlvdSBmb3IgeW91ciBl eGNlbGxlbnQgcmV2aWV3LiZuYnNwOyBNeSByZXNwb25zZXMgdG8geW91ciBjb21tZW50cyBhcmUg YmVsb3cuJm5ic3A7IEkbJEIhRxsoQnZlIHJlbGVhc2VkIGEgdmVyc2lvbi0wNSB0byBhZGRyZXNz IHlvdXIgY29tbWVudHMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlN1ZSA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206 IGkycnMgWzxhIGhyZWY9Im1haWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzppMnJz LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgVG9tb25vcmkgVGFrZWRhPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t VVMiPlNlbnQ6IFRodXJzZGF5LCBNYXkgMTksIDIwMTYgMTI6MzkgUE08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VG86IDxh IGhyZWY9Im1haWx0bzpydGctYWRzQGlldGYub3JnIj4NCnJ0Zy1hZHNAaWV0Zi5vcmc8L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPkNjOiAncnRnLWRpckBpZXRmLm9yZyc7ICdkcmFmdC1pZXRmLWkycnMtcHJvdG9jb2wt c2VjdXJpdHktcmVxdWlyZW1lbnRzLmFsbEBpZXRmLm9yZyc7DQo8YSBocmVmPSJtYWlsdG86aTJy c0BpZXRmLm9yZyI+aTJyc0BpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+U3ViamVjdDogW2kycnNdIFJU Ry1ESVIgUUEgcmV2aWV3OiBkcmFmdC1pZXRmLWkycnMtcHJvdG9jb2wtc2VjdXJpdHktcmVxdWly ZW1lbnRzLTA0LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SGksPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj5JIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0 ZSBRQSByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkRv Y3VtZW50OiBkcmFmdC1pZXRmLWkycnMtcHJvdG9jb2wtc2VjdXJpdHktcmVxdWlyZW1lbnRzLTA0 LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj5SZXZpZXdlcjogVG9tb25vcmkgVGFrZWRhPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJldmlldyBE YXRlOiBNYXkgMjAsIDIwMTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SW50ZW5kZWQgU3RhdHVzOiBTdGFuZGFyZHMgVHJh Y2s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgYW0gbm90IGZvbGxvd2luZyBJMlJTIHdvcmsg Y2xvc2VseSwgYnV0IGluIHRoZSBzcGlyaXQgb2YgUUEgcmV2aWV3LCB0aGlzIGlzIE9LIGluIG15 IHVuZGVyc3RhbmRpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vdHJhYy50b29scy5pZXRm Lm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyRG9jUWEiPmh0dHBzOi8vdHJhYy50b29scy5p ZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyRG9jUWE8L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj5IZXJlIGFyZSBteSBjb21tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PkkgdGhpbmsgaXQgaXMgdmVyeSBpbXBvcnRhbnQgdG8gaGF2ZSBkb2N1bWVudHMgZGVkaWNhdGVk IGZvciBzZWN1cml0eSBmb3IgbmV3IHByb3RvY29scyBzdWNoIGFzIEkyUlMgcHJvdG9jb2xzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj5PdmVyYWxsLCBJIHRoaW5rIHRoZSBkb2N1bWVudCBpcyB3ZWxsIG9yZ2FuaXplZCBh bmQgY2xlYXIgd2hhdCBhcmUgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGZvciBJMlJTLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+U29tZSBzcGVjaWZpYyBjb21tZW50cy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjEpIFRoZSBkb2N1bWVudCBpcyBpbnRlbmRlZCB0byBiZSBTdGFuZGFyZHMgVHJh Y2suIEkgZG8gbm90IHRoaW5rIGl0IGlzIGNvbW1vbiBmb3IgcmVxdWlyZW1lbnQgZHJhZnRzIHRv IGJlIFN0YW5kYXJkcyBUcmFjay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlN1ZTogWW91IGFy ZSBjb3JyZWN0LiZuYnNwOyBUaGlzIGlzIG15IGVycm9yLiBJIHNob3VsZCBoYXZlIGNoYW5nZWQg aXQgdGhpcyBtb3JuaW5nLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4yKSBJbiBTZWN0aW9u IDMuMSwgcmVxdWlyZW1lbnRzIGFyZSBtZW50aW9uZWQgdGhhdCBhcmUgc2V0IGluIGRyYWZ0LWll dGYtaTJycy1hcmNoaXRlY3R1cmUtMTUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7U29t ZSBvZiB0aGVzZSByZXF1aXJlbWVudHMgYXJlIG5vdCBkaXJlY3RseSBtZW50aW9uZWQgaW4gZHJh ZnQtaWV0Zi1pMnJzLWFyY2hpdGVjdHVyZS0xNSwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJz cDtidXQgcmF0aGVyIGltcGxpZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJz cDsgRm9yIGV4YW1wbGUsIGRyYWZ0LWlldGYtaTJycy1hcmNoaXRlY3R1cmUtMTUgbWVudGlvbnMg aWRlbnRpZmllciBmb3IgSTJSUyBjbGllbnQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBidXQgZG9l cyBub3QgbWVudGlvbiBpZGVudGlmaWVyIGZvciBJMlJTIGFnZW50IChJTU8pLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDsmbmJzcDsgUGxlYXNlIG5vdGUgdGhhdCBJIHRoaW5rIHJlcXVpcmVtZW50cyBtZW50aW9u ZWQgaW4gU2VjdGlvbiAzLjEuIG1ha2VzIHNlbnNlIGFuZCB2YWxpZC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 Jm5ic3A7IEkgYW0ganVzdCBjb21tZW50aW5nIG9uIHRoZSB3YXkgb2Ygd3JpdGluZy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAw NzBDMCI+U3VlOiBZb3UgYXJlIGNvcnJlY3QgdGhhdCB0aGUgbXV0dWFsIGlkZW50aWZpY2F0aW9u IGltcGxpZXMgYW4gaWRlbnRpdHkgZm9yIHRoZSBhZ2VudC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6IzAwNzBDMCI+QWxzbyBpbiBTZWN0aW9uIDIgb2YgZHJhZnQtaWV0Zi1pMnJzLWFyY2hpdGVj dHVyZS0xNSBtZW50aW9uczoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7cm9sZSBvciBzZWN1cml0eSByb2xlOiZuYnNwOyZuYnNwOyBBIHNlY3VyaXR5 IHJvbGUgc3BlY2lmaWVzIHRoZSBzY29wZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDcwQzAi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXNvdXJjZXMsIHByaW9yaXRpZXMsIGV0 Yy4gdGhhdCBhIGNsaWVudCBvciBhZ2VudCBoYXMuJm5ic3A7IElmIGE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOiMwMDcwQzAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpZGVudGl0eSBo YXMgbXVsdGlwbGUgcm9sZXMgaW4gdGhlIHNlY3VyaXR5IHN5c3RlbSwgdGhlIGlkZW50aXR5PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgaXMgcGVybWl0dGVkIHRvIHBlcmZvcm0gYW55IG9wZXJhdGlvbnMgYW55IG9mIHRob3NlIHJv bGVzIHBlcm1pdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDcwQzAiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBNdWx0aXBsZSBpZGVudGl0aWVzIG1heSB1c2UgdGhlIHNhbWUgc2Vj dXJpdHkgcm9sZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4zKSBJ IHRoaW5rIHRoZXJlIGlzIGRlcGVuZGVuY3kgb24gcmVxdWlyZW1lbnRzIG1lbnRpb25lZCBpbiB0 aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgU3BlY2lmaWNhbGx5LCBpZiBtdXR1 YWwgYXV0aGVudGljYXRpb24gKFNlY3Rpb24gMy4xKSwgc2VjdXJlIHRyYW5zcG9ydCAoU2VjdGlv biAzLjIpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgYW5kIHJvbGUtYmFzZWQgc2VjdXJpdHkgKFNl Y3Rpb24gMy4zKSBhcmUgbWV0LCBjb25maWRlbnRpYWxpdHkgKFNlY3Rpb24gMy4zKSBhbmQNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDtpbnRlZ3JpdHkgKFNlY3Rpb24gMy40KSBjYW4gYmUg YWNoaWV2ZWQgKGV4cGVjdCBTRUMtUkVRLTE2OiB0cmFjZWFiaWxpdHkgcmVxdWlyZW1lbnQpLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IFBlcmhhcHMsIGl0IGRlcGVuZHMg b24gaW4gd2hpY2ggYXNwZWN0cyBzZWN1cml0eSByZXF1aXJlbWVudHMgc2hvdWxkIGJlIHdyaXR0 ZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IChpbiB0ZXJtcyBvZiBtZWNoYW5pc21zIG9yIGluIHRl cm1zIG9mIGZlYXR1cmVzKS4gQWdhaW4sIEkgYW0ganVzdCBjb21tZW50aW5nPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOyZuYnNwOyBvbiB0aGUgd2F5IG9mIHdyaXRpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij5TdWU6IFlvdSBtYWtlIGFuIGV4Y2VsbGVudCBwb2ludDogPG86cD4NCjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SSBoYXZlIGFk ZGVkIHRvIHRoZSBmaXJzdCBwYXJ0IHNlY3Rpb24gMy4wIGFmdGVyIHRoZSBmaXJzdCBwYXJhZ3Jh cGg6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDcwQzAiPk5ldy88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOiMwMDcwQzAiPiZsdDt0Jmd0O1RoZXJlIGFyZSBkZXBlbmRlbmNpZXMgaW4gc29tZSBv ZiB0aGUgcmVxdWlyZW1lbnRzIGJlbG93LiZuYnNwOyBGb3INCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6IzAwNzBDMCI+Y29uZmlkZW50aWFsaXR5IChzZWN0aW9uIDMuMykgYW5kIGludGVncml0eSAo c2VjdGlvbiAzLjQpIHRvIGJlIGFjaGlldmVkLCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMw MDcwQzAiPmNsaWVudC1hZ2VudCBtdXN0IGhhdmUgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIChzZWN0 aW9uIDMuMSkgYW5kIHNlY3VyZSB0cmFuc3BvcnQgKHNlY3Rpb24gMy4yKS4mbmJzcDsmbmJzcDsg STJSUyBhbGxvd3MgdGhlIHVzZSBvZiBhbiBpbnNlY3VyZSB0cmFuc3BvcnQgZm9yIHBvcnRpb25z IG9mIGRhdGEgbW9kZWxzIHRoYXQgY2xlYXJseSBpbmRpY2F0ZQ0KIGluc2VjdXJlIHRyYW5zcG9y dC4mbmJzcDsgSWYgaW5zZWN1cmUgdHJhbnNwb3J0IGlzIHVzZWQsIHRoZW4gY29uZmlkZW50aWFs aXR5IGFuZCBpbnRlZ3JpdHkgY2Fubm90IGJlIGFjaGlldmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6IzAwNzBDMCI+Jmx0Oy90Jmd0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PjQpIFRoaXMgaXMganVzdCBhbiBlZGl0LCBidXQgaW4gcGFnZS4xMCwNCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDsmbmJzcDsmbmJzcDsmcXVvdDtSZXF1aXJlbWVudHMgU0VDLVJFUS0xMyBhbmQgU0VDLVJFUS0x NCZxdW90OyBzaG91bGQgYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7ICZxdW90O1JlcXVpcmVtZW50 cyBTRUMtUkVRLTE0IGFuZCBTRUMtUkVRLTE1JnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOiMwMDcwQzAiPi0tLSBUaGFuayB5b3UgZm9yIHRoZSBlZGl0b3JpYWwg Y29tbWVudA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3MsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRvbW9u b3JpIFRha2VkYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+aTJycyBtYWlsaW5nIGxpc3Q8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+PGEgaHJlZj0ibWFpbHRvOmkycnNAaWV0Zi5vcmciPmkycnNAaWV0Zi5vcmc8L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJy cyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzPC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_EB0F2EAC05E9C64D80571F2042700A2A6C7FE8AEC0561I0coenttco_-- From nobody Mon May 23 02:31:09 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCCC12B057; Mon, 23 May 2016 02:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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=-1.426, 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 wgRCWgmlHk1M; Mon, 23 May 2016 02:31:05 -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 A6B0D12B03F; Mon, 23 May 2016 02:31:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKM10611; Mon, 23 May 2016 09:31:01 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 23 May 2016 10:30:55 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.169]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Mon, 23 May 2016 17:30:45 +0800 From: Mingui Zhang To: Alexander Vainshtein , "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" Thread-Topic: RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname Thread-Index: AdGxvD1O5NXHbyN7QyqT5SoYhCMmtADEL2dg Date: Mon, 23 May 2016 09:30:44 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E787CB087E@NKGEML515-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.146.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5742CDD5.016F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.169, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7a3737573de8c211e32f64ef16c67d04 Archived-At: Cc: "'rtg-dir@ietf.org'" , "Zhangxian \(Xian\)" , "trill@ietf.org" , "draft-ietf-trill-multilevel-single-nickname@ietf.org" , "Susan Hares \(shares@ndzh.com\)" , "jon.hudson@gmail.com" Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 09:31:08 -0000 Hi Alexander, Thanks for the review! The multilevel conception itself is abstract and not easily understandable.= However, it was really interesting in designing such a solution. Appreciat= e the review and the time on relevant documents to figure out the whole sch= eme. > ? Nor provides any explanations about the reasons that make single-level= IS-IS > used by TRILL less scalable that single-level IS-IS when it is used for d= istributing IP > reachability The reason comes from the fact that the length of a nickname is different f= rom an IP address. I think this could be addressed in the updated version o= f the draft: https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-mult= ilevel/?include_text=3D1. > * The draft positions itself as an alternative to the Aggregate > Nicknames approach while, from my POV, it is just provides additional det= ails on > one of the possible flavors of this approach The WG used to discuss several ways to address the "Aggregate Nickname" app= roach. One way was to use pseudonode nickname to denote an L1 area. Another= way was to let border RBridges swap L1 and L2 nicknames. However, these po= ssible alternatives were never detailed as the one being reviewed, after th= e WG weighted their issues and complexity.=20 > * The draft is intended for the Standards Track, but it does not = say that > it updates the base TRILL spec (neither in the text nor in metadata) RFC 6325 is the base TRILL spec and it restricts itself to level 1 IS-IS wh= ile the draft being reviewed is talking about how to enable inter-communica= tion between level 1 IS-IS areas with level 2 border RBridges. That also me= ans level 1 RBridges conforms to RFC 6325 remain unchanged. So RFC 6325 sho= uld not appear in the "Updates" metadata? Best regards, Mingui > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Thursday, May 19, 2016 6:59 PM > To: Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com) > Cc: Susan Hares (shares@ndzh.com); jon.hudson@gmail.com; Zhangxian (Xian)= ; > draft-ietf-trill-multilevel-single-nickname@ietf.org; 'rtg-dir@ietf.org'; > trill@ietf.org > Subject: RTG-DIR QA review for draft-ietf-trill-multilevel-single-nicknam= e >=20 > Hi all, > I have been appointed as the QA reviewer for > draft-ietf-trill-multilevel-single-nickname etf-trill-multilevel-single-nickname/?include_text=3D1>. > Before going into the review proper, I would like to make a couple of > introductory statements. >=20 >=20 > 1. I am NOT a TRILL expert and actually never before has been invol= ved > with TRILL. I have been told that this is OK and the ADs are interested i= nto getting > reviews from non-experts. Well, in my case this is what they will get. >=20 > 2. The time frame for providing the review was quite demanding (at = least > for me). This probably affected the review quality and it effectively pre= vented > me from discussing the review with the draft authors privately - I owe th= em a > sincere apology for that. >=20 > 3. The RtgDirDocQa - Rtg Area > Wiki states t= hat the > QA review is usually performed when a draft is going to be adopted as a W= G > document. While it mentions, that a WG document may be also subjected to > such a review at the discretion of the WG Chairs, the initial guidelines = for the QA > reviewer in the Wiki mention only reviewing the draft for a QA adoption. = As a > consequence, I had to create my own list of questions that will try to an= swer > based on what I have found in the Wiki. Here is this list: >=20 > a. Is the draft easily readable and understandable? >=20 > b. Does the draft represent an attempt to solve a real problem? >=20 > c. Are there some serious technical gaps that the authors should tr= y to > fill? >=20 > d. Are there any potential IETF process issues with the draft in its= present > form? > Please note that the question about "a good start for a WG draft" which a= ppears > in the Wiki does not appear on my list (since the draft is already a WG d= ocument). > At the same time I have included the question about solving a real proble= m > (which appeared in the previous version of the Wiki page). The current ve= rsion > only asks if the draft "makes sense" which, from my POV, is something els= e. >=20 >=20 > My answers to these questions follow. >=20 > Is the draft easily readable and understandable? > Of course, "easily readable and understandable" is in the eye of the beho= lder. > But as a non-expert can say that it was quite difficult for me to underst= and what > this draft is really about. > Eventually, I have succeeded to build the following scheme that helped me= to > understand what I am dealing with: >=20 > * The TRILL base > spec: >=20 > o Explicitly restricts TRILL to a single Level 1 IS-IS >=20 > o Explicitly states that the nicknames of RBridges in the Trill packet = header > remain unchanged when the packet traverses the TRILL domain from ingress > (where the TRILL header is pushed on the original Ethernet frame) to egre= ss > (where this header is popped) >=20 > * An Informational Multi-Level > TRILL _text=3D1> WG draft claims that this restriction negatively affects TRILL= scalability: >=20 > o It mentions several scalability issues >=20 > o However, it >=20 > ? Neither mentions any specific scale parameters where these issues beco= me > real >=20 > ? Nor provides any explanations about the reasons that make single-level= IS-IS > used by TRILL less scalable that single-level IS-IS when it is used for d= istributing IP > reachability >=20 > o It claims that some of these issues may be addressed by allowing usag= e of > multi-level IS-IS for TRILL >=20 > o It provides two specific proposals for making multi-level TRILL work: >=20 > o One of these proposals is called "unique nicknames". This proposal: >=20 > ? Does not require any changes in the TRILL data plane >=20 > ? Requires introducing some structure in the nicknames of RBridges in or= der to > guarantee that these names are unique within the TRILL-based campus >=20 > o The other proposal is called "aggregate nicknames". This proposal: >=20 > ? Allows RBridges in different L1 areas of the campus to share nicknames >=20 > ? Requires a change in the TRILL data plane: the nicknames in the TRILL = header > of a packet will be modified by the L12 RBridges >=20 > ? Allows two possible flavors (bot mentioned in the draft): >=20 > * The flavor that uses L1 area nicknames >=20 > * The flavor that uses the nicknames of all L12 RBridges connecte= d to a > given L1 area as its name >=20 > * The Standards Track Single Nickname draft (one that I have been > asked to review) provides details on the second of the above-mentioned fl= avors > of the "Aggregate Nicknames" approach: >=20 > o It also allows sharing the same nickname between RBridges in differen= t L1 > areas >=20 > o It also requires the same change in the TRILL data plane >=20 > o It eliminates the need for allocating nicknames to L1 areas. Instead,= each > such area is identified by the set of nicknames of all L12 RBridges that = connect to > it. > It took me quite some time to build this scheme, and the text in the draf= t was not > very helpful in this. > The following points contributed to "negative readability" from my POV: >=20 > * The draft positions itself as an alternative to the Aggregate > Nicknames approach while, from my POV, it is just provides additional det= ails on > one of the possible flavors of this approach >=20 > * The draft is intended for the Standards Track, but it does not = say that > it updates the base TRILL spec (neither in the text nor in metadata) From nobody Mon May 23 03:13:41 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714B012B025; Mon, 23 May 2016 03:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eci365.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 zH-srSJYyyMr; Mon, 23 May 2016 03:13:33 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0136.outbound.protection.outlook.com [104.47.0.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5284212B020; Mon, 23 May 2016 03:13:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gvt1Ws5NB6z7w8kCY9mYsQiPOqmGPrHjPe8fyIZlKds=; b=bMXPP/SK0z9Cie1WsEhWm6AHm6YtjZOBjLi/xvtdpG3FRKHenD+KD15j4n3+rQ2j0SScLzwVVJftv3P00glCd5oN1yzYRvJptuvYj15yR9UuYvg2xgAxlfi5HswGFs5+MtUe+tUxxbwn3BsnhUBpg6gyBBVyPC2tZpJgKMLx7yI= Received: from HE1PR0301MB2266.eurprd03.prod.outlook.com (10.168.31.153) by HE1PR0301MB2266.eurprd03.prod.outlook.com (10.168.31.153) with Microsoft SMTP Server (TLS) id 15.1.497.12; Mon, 23 May 2016 10:13:30 +0000 Received: from HE1PR0301MB2266.eurprd03.prod.outlook.com ([10.168.31.153]) by HE1PR0301MB2266.eurprd03.prod.outlook.com ([10.168.31.153]) with mapi id 15.01.0497.019; Mon, 23 May 2016 10:13:29 +0000 From: Alexander Vainshtein To: Mingui Zhang Thread-Topic: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname Thread-Index: AQHRtNXbaTHOHWLG4kWRPO8WfT7Nk5/GRpsA Date: Mon, 23 May 2016 10:13:29 +0000 Message-ID: References: <4552F0907735844E9204A62BBDD325E787CB087E@NKGEML515-MBS.china.huawei.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E787CB087E@NKGEML515-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=ecitele.com; x-originating-ip: [147.234.241.1] x-ms-office365-filtering-correlation-id: 028e9287-0968-4332-96f1-08d382f2e381 x-microsoft-exchange-diagnostics: 1; HE1PR0301MB2266; 5:TBwJwLrYve/ZBcT6NEb7t7zFRcjUNTgxnIPnmznuHtFioNMexGePIOJPVjzKmGOFnInnAV8d7lEx0n9aoJeRdnsXC8viTg8cL47AUZL6959cl7Q8D3fDc4vSSRLcOoOWASXz6sR5qvyqoqXcVFK/HQ==; 24:LyXSdmhC82HQzrZ/Yi8BIE1suh/13pGfDdJ7qI9nqKAVtj153fsorSWTo77r2MRQ31vE1kf5sYDXPrhuN2VIqbjhpO7vTo8wfez5RSmKXjg=; 7:aLPO2SYjc0dYcvglQI5i48CdTg0O8WoP1HaRqTmZM4GlAchJU0KxA5n7eyNyR3wj55hBfyqzIIWh0Tpyi8JMa/z1omWt1vMdOiiv/lPdaBCPlOc0sOQ1ZbhLjn+R6QEcvERQS5s55IiW5BO/oAbaa+D05NkL8mJe3/cSR3cjnyHMryuDuOyKl2OfdDRwBR7+ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0301MB2266; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:HE1PR0301MB2266; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0301MB2266; x-forefront-prvs: 0951AB0A30 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(13464003)(377454003)(252514010)(53754006)(76176999)(54356999)(50986999)(66066001)(3280700002)(4326007)(19580395003)(5002640100001)(2906002)(5003600100002)(3660700001)(19300405004)(106116001)(19580405001)(76576001)(6116002)(2900100001)(33656002)(9686002)(19625215002)(10400500002)(86362001)(87936001)(561944003)(16236675004)(74316001)(586003)(5008740100001)(3846002)(92566002)(790700001)(102836003)(8936002)(1220700001)(81166006)(5004730100002)(15975445007)(19617315012)(2950100001)(77096005)(122556002)(230783001)(189998001)(110136002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0301MB2266; H:HE1PR0301MB2266.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0301MB22660CD4C9DA5705802013399D4E0HE1PR0301MB2266_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2016 10:13:29.8582 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0301MB2266 Archived-At: Cc: "'rtg-dir@ietf.org'" , "Zhangxian \(Xian\)" , "trill@ietf.org" , "Jonathan Hardwick \(Jonathan.Hardwick@metaswitch.com\)" , "draft-ietf-trill-multilevel-single-nickname@ietf.org" , "Susan Hares \(shares@ndzh.com\)" , "jon.hudson@gmail.com" Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 10:13:37 -0000 --_000_HE1PR0301MB22660CD4C9DA5705802013399D4E0HE1PR0301MB2266_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mingui hi! Lots of thanks for a prompt response to some of the issues I've raised in t= he review. Please see some comments to you responses inline below. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Mingui Zhang Sent: Monday, May 23, 2016 12:31 PM To: Alexander Vainshtein; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.c= om) Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-= multilevel-single-nickname@ietf.org; Susan Hares (shares@ndzh.com); jon.hud= son@gmail.com Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-si= ngle-nickname Hi Alexander, Thanks for the review! The multilevel conception itself is abstract and not easily understandable. [[Sasha]] Do you refer to the multi-level IS-IS in general or multi-level T= RILL specifically? I am asking because I believe am reasonably well aware o= f the multi-level architecture of IS-IS as used for IP routing. It is somew= hat different from that of OSPF, but I would not call it "abstract and not = easily understandable". And there are quite a few excellent introductions = to the subject (again in the context of IP routing). However, I am definite= ly not a TRILL expert, and have stated that in the review. However, it was really interesting in designing such a solution. Appreciate= the review and the time on relevant documents to figure out the whole sche= me. > ? Nor provides any explanations about the reasons that make > single-level IS-IS used by TRILL less scalable that single-level IS-IS > when it is used for distributing IP reachability The reason comes from the fact that the length of a nickname is different f= rom an IP address. [[Sasha]] I must admit that I do not understand the connection. By this log= ic, IS-IS for CLNS and IPv6 should be much more scalable than IS-IS for IPv= 4, but I have never seen such claims before. Could you please elaborate? Co= uld somebody on the RTG-DIR list to comment on that? I think this could be addressed in the updated version of the draft: https:= //datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/?include_tex= t=3D1. > * The draft positions itself as an alternative to the Aggregate > Nicknames approach while, from my POV, it is just provides additional > details on one of the possible flavors of this approach The WG used to discuss several ways to address the "Aggregate Nickname" app= roach. [[Sasha]] I do not follow the TRILL WG mailing list, so I am not aware of a= ny discussions that have been hold there. I am only speaking about what I c= ould find in the two drafts mentioned in my review. One way was to use pseudonode nickname to denote an L1 area. Another way wa= s to let border RBridges swap L1 and L2 nicknames. [[Sasha]] I was under impression that the Aggregate Nicknames approach alwa= ys implies swapping of ingress and egress nicknames - at least this is what= the Multi-Level Trill draft states, and the Single Nickname draft follows = suit. I also do not understand how using L1 area names (which is a control = plane functionality) could replace the swapping of nicknames (which is a pu= re data plane function). However, these possible alternatives were never detailed as the one being r= eviewed, after the WG weighted their issues and complexity. [[Sasha]] It is all fine, but, from my POV, it does not address the issue I= 've raised, namely that the Single Nickname draft incorrectly positions its= elf as an alternative approach to that of Aggregate Nicknames in the Multi-= Level TRILL draft, and that such incorrect positioning negatively affects a= bility of a non-expert > * The draft is intended for the Standards Track, but it does not = say that > it updates the base TRILL spec (neither in the text nor in metadata) RFC 6325 is the base TRILL spec and it restricts itself to level 1 IS-IS wh= ile the draft being reviewed is talking about how to enable inter-communica= tion between level 1 IS-IS areas with level 2 border RBridges. That also me= ans level 1 RBridges conforms to RFC 6325 remain unchanged. So RFC 6325 sho= uld not appear in the "Updates" metadata? [[Sasha]] It seems that we understand the meaning of the RFC metadata diffe= rently. From my POV if you remove/relax a restriction imposed by an alread= y published Standards Track RFC, this means that you update it, and the met= adata should reflect that. E.g., you can take a look at RFC 4379 that is ma= rked as updating RFC 1122 because it allows transmission of IP packets with= the Destination IP address in the 127/8 subnet - something that RFC 1122 = explicitly prohibits. Again, it would be interesting to hear what the people on the RTG-DIR list = (especially ones that serve now - or have served in the past - as ADs and/o= r WG Chairs) think on that. Best regards, Mingui > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Thursday, May 19, 2016 6:59 PM > To: Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com) > Cc: Susan Hares (shares@ndzh.com); jon.hudson@gma= il.com; Zhangxian > (Xian); draft-ietf-trill-multilevel-single-nickname@ietf.org; > 'rtg-dir@ietf.org'; trill@ietf.org > Subject: RTG-DIR QA review for > draft-ietf-trill-multilevel-single-nickname > > Hi all, > I have been appointed as the QA reviewer for > draft-ietf-trill-multilevel-single-nickname rg/doc/draft-i etf-trill-multilevel-single-nickname/?include_text=3D1>. > Before going into the review proper, I would like to make a couple of > introductory statements. > > > 1. I am NOT a TRILL expert and actually never before has been invol= ved > with TRILL. I have been told that this is OK and the ADs are > interested into getting reviews from non-experts. Well, in my case this i= s what they will get. > > 2. The time frame for providing the review was quite demanding (at = least > for me). This probably affected the review quality and it effectively > prevented me from discussing the review with the draft authors > privately - I owe them a sincere apology for that. > > 3. The RtgDirDocQa - Rtg Area > Wiki > states that the QA review is usually performed when a draft is going > to be adopted as a WG document. While it mentions, that a WG document > may be also subjected to such a review at the discretion of the WG > Chairs, the initial guidelines for the QA reviewer in the Wiki mention > only reviewing the draft for a QA adoption. As a consequence, I had to > create my own list of questions that will try to answer based on what I h= ave found in the Wiki. Here is this list: > > a. Is the draft easily readable and understandable? > > b. Does the draft represent an attempt to solve a real problem? > > c. Are there some serious technical gaps that the authors should tr= y to > fill? > > d. Are there any potential IETF process issues with the draft in its= present > form? > Please note that the question about "a good start for a WG draft" > which appears in the Wiki does not appear on my list (since the draft is = already a WG document). > At the same time I have included the question about solving a real > problem (which appeared in the previous version of the Wiki page). The > current version only asks if the draft "makes sense" which, from my POV, = is something else. > > > My answers to these questions follow. > > Is the draft easily readable and understandable? > Of course, "easily readable and understandable" is in the eye of the beho= lder. > But as a non-expert can say that it was quite difficult for me to > understand what this draft is really about. > Eventually, I have succeeded to build the following scheme that helped > me to understand what I am dealing with: > > * The TRILL base > spec: > > o Explicitly restricts TRILL to a single Level 1 IS-IS > > o Explicitly states that the nicknames of RBridges in the Trill packet = header > remain unchanged when the packet traverses the TRILL domain from > ingress (where the TRILL header is pushed on the original Ethernet > frame) to egress (where this header is popped) > > * An Informational Multi-Level > TRILL evel/?include _text=3D1> WG draft claims that this restriction > negatively affects TRILL scalability: > > o It mentions several scalability issues > > o However, it > > ? Neither mentions any specific scale parameters where these issues > become real > > ? Nor provides any explanations about the reasons that make > single-level IS-IS used by TRILL less scalable that single-level IS-IS > when it is used for distributing IP reachability > > o It claims that some of these issues may be addressed by allowing usag= e of > multi-level IS-IS for TRILL > > o It provides two specific proposals for making multi-level TRILL work: > > o One of these proposals is called "unique nicknames". This proposal: > > ? Does not require any changes in the TRILL data plane > > ? Requires introducing some structure in the nicknames of RBridges in > order to guarantee that these names are unique within the TRILL-based > campus > > o The other proposal is called "aggregate nicknames". This proposal: > > ? Allows RBridges in different L1 areas of the campus to share > nicknames > > ? Requires a change in the TRILL data plane: the nicknames in the > TRILL header of a packet will be modified by the L12 RBridges > > ? Allows two possible flavors (bot mentioned in the draft): > > * The flavor that uses L1 area nicknames > > * The flavor that uses the nicknames of all L12 RBridges connecte= d to a > given L1 area as its name > > * The Standards Track Single Nickname draft (one that I have been > asked to review) provides details on the second of the above-mentioned > flavors of the "Aggregate Nicknames" approach: > > o It also allows sharing the same nickname between RBridges in differen= t L1 > areas > > o It also requires the same change in the TRILL data plane > > o It eliminates the need for allocating nicknames to L1 areas. Instead,= each > such area is identified by the set of nicknames of all L12 RBridges > that connect to it. > It took me quite some time to build this scheme, and the text in the > draft was not very helpful in this. > The following points contributed to "negative readability" from my POV: > > * The draft positions itself as an alternative to the Aggregate > Nicknames approach while, from my POV, it is just provides additional > details on one of the possible flavors of this approach > > * The draft is intended for the Standards Track, but it does not = say that > it updates the base TRILL spec (neither in the text nor in metadata) --_000_HE1PR0301MB22660CD4C9DA5705802013399D4E0HE1PR0301MB2266_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mingui hi!

Lots of thanks for a prompt response to some of t= he issues I've raised in the review.

 

Please see some comments to you responses <= span style=3D"color:#7030A0">inline below.

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-5492= 66302

Email:   Alexander.Vainshtein@ecitele.c= om

 

-----Original Message-----
From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Mingui Zhang Sent: Monday, May 23, 2016 12:31 PM
To: Alexander Vainshtein; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.c= om)
Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-= multilevel-single-nickname@ietf.org; Susan Hares (shares@ndzh.com); jon.hud= son@gmail.com
Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-si= ngle-nickname

 

Hi Alexander,

 

Thanks for the review!

 

The multilevel conception itself is abstract and = not easily understandable.

[[Sasha]] Do = you refer to the multi-level IS-IS in general or multi-level TRILL specific= ally? I am asking because I believe am reasonably well aware of the multi-l= evel architecture of IS-IS as used for IP routing. It is somewhat different from that of OSPF, but I would not ca= ll it “abstract and not easily understandable”.  And there= are quite a few excellent introductions to the subject (again in the conte= xt of IP routing). However, I am definitely not a TRILL expert, and have stated that in the review.

 

However, it was really interesting in designing s= uch a solution. Appreciate the review and the time on relevant documents to= figure out the whole scheme.

 

> ?  Nor provides any explanations about = the reasons that make

> single-level IS-IS used by TRILL less scalab= le that single-level IS-IS

> when it is used for distributing IP reachabi= lity

 

The reason comes from the fact that the length of= a nickname is different from an IP address.

[[Sasha]] I m= ust admit that I do not understand the connection. By this logic, IS-IS for= CLNS and IPv6 should be much more scalable than IS-IS for IPv4, but I have= never seen such claims before. Could you please elaborate? Could somebody on the RTG-DIR list to comment on tha= t?

I think this could be addressed in the updated ve= rsion of the draft: https://datatracker.i= etf.org/doc/draft-ietf-trill-rbridge-multilevel/?include_text=3D1.

 

> *        =  The draft positions itself as an alternative to the Aggregate

> Nicknames approach while, from my POV, it is= just provides additional

> details on one of the possible flavors of th= is approach

 

The WG used to discuss several ways to address th= e "Aggregate Nickname" approach.

[[Sasha]] I d= o not follow the TRILL WG mailing list, so I am not aware of any discussion= s that have been hold there. I am only speaking about what I could find in = the two drafts mentioned in my review.

One way was to use pseudonode nickname to denote = an L1 area. Another way was to let border RBridges swap L1 and L2 nicknames= .

[[Sasha]] I w= as under impression that the Aggregate Nicknames approach always implies sw= apping of ingress and egress nicknames – at least this is what the Mu= lti-Level Trill draft states, and the Single Nickname draft follows suit. I also do not understand how using L1 area na= mes (which is a control plane functionality) could replace the swapping of = nicknames (which is a pure data plane function).<= /p>

However, these possible alternatives were never d= etailed as the one being reviewed, after the WG weighted their issues and c= omplexity.

[[Sasha]] It = is all fine, but, from my POV, it does not address the issue I’ve rai= sed, namely that the Single Nickname draft incorrectly positions itself as an alternative approach to tha= t of Aggregate Nicknames in the Multi-Level TRILL draft, and that such inco= rrect positioning negatively affects ability of a non-expert

 

> *       &= nbsp; The draft is intended for the Standards Track, but it does not say th= at

> it updates the base TRILL spec (neither in t= he text nor in metadata)

 

RFC 6325 is the base TRILL spec and it restricts = itself to level 1 IS-IS while the draft being reviewed is talking about how= to enable inter-communication between level 1 IS-IS areas with level 2 bor= der RBridges. That also means level 1 RBridges conforms to RFC 6325 remain unchanged. So RFC 6325 should not a= ppear in the "Updates" metadata?

[[Sasha]] It = seems that we understand the meaning of the RFC metadata differently. From = my POV if  you remove/relax a restriction imposed by an already publis= hed Standards Track RFC, this means that you update it, and the metadata should reflect that. E.g., you can take a = look at RFC 4379 that is marked as updating RFC 1122 because it allows tran= smission of IP packets with the Destination IP address  in the 127/8 s= ubnet – something that RFC 1122 explicitly prohibits.

Again, it wou= ld be interesting to hear what the people on the RTG-DIR list (especially o= nes that serve now – or have served in the past – as ADs and/or= WG Chairs) think on that.

 

Best regards,

Mingui

 

> -----Original Message-----

> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]

> Sent: Thursday, May 19, 2016 6:59 PM

> To: Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)

> Cc: Susan Hares (shares@ndzh.c= om); jon.hudson@gmail.com; Zhangxian

> (Xian); draft-ietf-trill-mult= ilevel-single-nickname@ietf.org;

> 'rtg-dir@ietf.org'; trill@ietf.= org

> Subject: RTG-DIR QA review for

> draft-ietf-trill-multilevel-single-nickname<= o:p>

>

> Hi all,

> I have been appointed as the QA reviewer for=

> draft-ietf-trill-multilevel-single-nickname&= lt;https://datatracker.ietf.o

> rg/doc/draft-i etf-trill-multilevel-single-n= ickname/?include_text=3D1>.

> Before going into the review proper, I would= like to make a couple of

> introductory statements.

>

>

> 1.       I am = NOT a TRILL expert and actually never before has been involved

> with TRILL. I have been told that this is OK= and the ADs are

> interested into getting reviews from non-exp= erts. Well, in my case this is what they will get.

>

> 2.       The t= ime frame for providing the review was quite demanding (at least=

> for me). This probably affected the review q= uality and it effectively

> prevented me from discussing the review with= the draft authors

> privately - I owe them a sincere apology for= that.

>

> 3.       The R= tgDirDocQa - Rtg Area

> Wiki<https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa>

> states that the QA review is usually perform= ed when a draft is going

> to be adopted as a WG document. While it men= tions, that a WG document

> may be also subjected to such a review at th= e discretion of the WG

> Chairs, the initial guidelines for the QA re= viewer in the Wiki mention

> only reviewing the draft for a QA adoption. = As a consequence, I had to

> create my own list of questions that will tr= y to answer based on what I have found in the Wiki. Here is this list:=

>

> a.       Is th= e draft easily readable and understandable?

>

> b.      Does the dr= aft represent an attempt to solve a real problem?

>

> c.       Are t= here some serious technical gaps that the authors should try to<= /p>

> fill?

>

> d.      Are there a= ny potential IETF process issues with the draft in its present

> form?

> Please note that the question about "a = good start for a WG draft"

> which appears in the Wiki does not appear on= my list (since the draft is already a WG document).

> At the same time I have included the questio= n about solving a real

> problem (which appeared in the previous vers= ion of the Wiki page). The

> current version only asks if the draft "= ;makes sense" which, from my POV, is something else.

>

>

> My answers to these questions follow.

>

> Is the draft easily readable and understanda= ble?

> Of course, "easily readable and underst= andable" is in the eye of the beholder.

> But as a non-expert can say that it was quit= e difficult for me to

> understand what this draft is really about.<= o:p>

> Eventually, I have succeeded to build the fo= llowing scheme that helped

> me to understand what I am dealing with:

>

> *       &= nbsp; The TRILL base

> spec<https://datatracker.ietf.org/doc/rfc6325/?include_text=3D1>:

>

> o   Explicitly restricts TRILL to = a single Level 1 IS-IS

>

> o   Explicitly states that the nic= knames of RBridges in the Trill packet header

> remain unchanged when the packet traverses t= he TRILL domain from

> ingress (where the TRILL header is pushed on= the original Ethernet

> frame) to egress (where this header is poppe= d)

>

> *       &= nbsp; An Informational Multi-Level

> TRILL<https://datatracker.ietf.org/doc/dr= aft-ietf-trill-rbridge-multil

> evel/?include _text=3D1> WG draft claims = that this restriction

> negatively affects TRILL scalability:

>

> o   It mentions several scalabilit= y issues

>

> o   However, it

>

> ?  Neither mentions any specific scale = parameters where these issues

> become real

>

> ?  Nor provides any explanations about = the reasons that make

> single-level IS-IS used by TRILL less scalab= le that single-level IS-IS

> when it is used for distributing IP reachabi= lity

>

> o   It claims that some of these i= ssues may be addressed by allowing usage of

> multi-level IS-IS for TRILL

>

> o   It provides two specific propo= sals for making multi-level TRILL work:

>

> o   One of these proposals is call= ed "unique nicknames". This proposal:

>

> ?   Does not require any changes i= n the TRILL data plane

>

> ?  Requires introducing some structure = in the nicknames of RBridges in

> order to guarantee that these names are uniq= ue within the TRILL-based

> campus

>

> o   The other proposal is called &= quot;aggregate nicknames". This proposal:

>

> ?  Allows RBridges in different L1 area= s of the campus to share

> nicknames

>

> ?  Requires a change in the TRILL data = plane: the nicknames in the

> TRILL header of a packet will be modified by= the L12 RBridges

>

> ?  Allows two possible flavors (bot men= tioned in the draft):

>

> *       &= nbsp; The flavor that uses L1 area nicknames

>

> *       &= nbsp; The flavor that uses the nicknames of all L12 RBridges connected to a=

> given L1 area as its name

>

> *       &= nbsp; The Standards Track Single Nickname draft (one that I have been<= /o:p>

> asked to review) provides details on the sec= ond of the above-mentioned

> flavors of the "Aggregate Nicknames&quo= t; approach:

>

> o   It also allows sharing the sam= e nickname between RBridges in different L1

> areas

>

> o   It also requires the same chan= ge in the TRILL data plane

>

> o   It eliminates the need for all= ocating nicknames to L1 areas. Instead, each

> such area is identified by the set of nickna= mes of all L12 RBridges

> that connect to it.

> It took me quite some time to build this sch= eme, and the text in the

> draft was not very helpful in this.

> The following points contributed to "ne= gative readability" from my POV:

>

> *       &= nbsp; The draft positions itself as an alternative to the Aggregate

> Nicknames approach while, from my POV, it is= just provides additional

> details on one of the possible flavors of th= is approach

>

> *       &= nbsp; The draft is intended for the Standards Track, but it does not say th= at

> it updates the base TRILL spec (neither in t= he text nor in metadata)

 

--_000_HE1PR0301MB22660CD4C9DA5705802013399D4E0HE1PR0301MB2266_-- From nobody Tue May 24 05:41:51 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5C812D664; Tue, 24 May 2016 01:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.636 X-Spam-Level: X-Spam-Status: No, score=-5.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 sKcNR-O1SVHL; Tue, 24 May 2016 01:24:32 -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 34C9E12D0BF; Tue, 24 May 2016 01:24:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CPL11171; Tue, 24 May 2016 08:24:26 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 24 May 2016 09:23:37 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.169]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Tue, 24 May 2016 16:23:25 +0800 From: Mingui Zhang To: Alexander Vainshtein Thread-Topic: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname Thread-Index: AdGxvD1O5NXHbyN7QyqT5SoYhCMmtADEL2dg//+XboD//iaMUA== Date: Tue, 24 May 2016 08:23:25 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E787CB7589@NKGEML515-MBS.china.huawei.com> References: <4552F0907735844E9204A62BBDD325E787CB087E@NKGEML515-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.146.93] Content-Type: multipart/alternative; boundary="_000_4552F0907735844E9204A62BBDD325E787CB7589NKGEML515MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.57440FBA.00F7, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.169, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 55622fc7f9d3705c98059c908b62bad5 Archived-At: X-Mailman-Approved-At: Tue, 24 May 2016 05:41:43 -0700 Cc: "Zhangxian \(Xian\)" , "'rtg-dir@ietf.org'" <'rtg-dir@ietf.org'>, "trill@ietf.org" , Jonathan Hardwick , "draft-ietf-trill-multilevel-single-nickname@ietf.org" , Susan Hares , "jon.hudson@gmail.com" Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 08:24:37 -0000 --_000_4552F0907735844E9204A62BBDD325E787CB7589NKGEML515MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sasha, Thanks for your comments. Please see responses inline below. Thanks, Mingui From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Monday, May 23, 2016 6:13 PM To: Mingui Zhang Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-= multilevel-single-nickname@ietf.org; Susan Hares (shares@ndzh.com); jon.hud= son@gmail.com; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com) Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-si= ngle-nickname Mingui hi! Lots of thanks for a prompt response to some of the issues I've raised in t= he review. Please see some comments to you responses inline below. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Mingui Zhang Sent: Monday, May 23, 2016 12:31 PM To: Alexander Vainshtein; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.c= om) Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares (shares@ndzh.com<= mailto:shares@ndzh.com>); jon.hudson@gmail.com Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-si= ngle-nickname Hi Alexander, Thanks for the review! The multilevel conception itself is abstract and not easily understandable. [[Sasha]] Do you refer to the multi-level IS-IS in general or multi-level T= RILL specifically? I am asking because I believe am reasonably well aware o= f the multi-level architecture of IS-IS as used for IP routing. It is somew= hat different from that of OSPF, but I would not call it "abstract and not = easily understandable". And there are quite a few excellent introductions = to the subject (again in the context of IP routing). However, I am definite= ly not a TRILL expert, and have stated that in the review. [Mingui] Yes, multi-level arch of IS-IS has already been well understood. H= owever, the extending TRILL to multi-levels brings new challenges. As state= d in the informational draft, one issue is on processing the TRILL switch n= icknames and the other issue is on handling multi-destination packet distri= bution trees. In order not to make the specifications "abstract", the draft= carefully designed two walking-through examples in Section 3. If the examp= les were understood, it would be non-abstract as well. ;-) However, it was really interesting in designing such a solution. Appreciate= the review and the time on relevant documents to figure out the whole sche= me. > ? Nor provides any explanations about the reasons that make > single-level IS-IS used by TRILL less scalable that single-level IS-IS > when it is used for distributing IP reachability The reason comes from the fact that the length of a nickname is different f= rom an IP address. [[Sasha]] I must admit that I do not understand the connection. By this log= ic, IS-IS for CLNS and IPv6 should be much more scalable than IS-IS for IPv= 4, but I have never seen such claims before. Could you please elaborate? Co= uld somebody on the RTG-DIR list to comment on that? [Mingui] For a single-level IS-IS instance, the length of the address deter= mines the name space. In the informational draft, Section 1.1 TRILL Scalabi= lity Issues, the following statement is relevant " 5. the limit of the number of TRILL switches, due to the 16-bit nicknam= e space," I think this could be addressed in the updated version of the draft: https:= //datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/?include_tex= t=3D1. > * The draft positions itself as an alternative to the Aggregate > Nicknames approach while, from my POV, it is just provides additional > details on one of the possible flavors of this approach The WG used to discuss several ways to address the "Aggregate Nickname" app= roach. [[Sasha]] I do not follow the TRILL WG mailing list, so I am not aware of a= ny discussions that have been hold there. I am only speaking about what I c= ould find in the two drafts mentioned in my review. [Mingui] Actually, the informational draft had included the information of = those alternatives as well. Please see "Section 2.2.2.2 Swap Nickname Field= Aggregated Nicknames" and read the words about "pseudonode" of Section 2.5= . One way was to use pseudonode nickname to denote an L1 area. Another way wa= s to let border RBridges swap L1 and L2 nicknames. [[Sasha]] I was under impression that the Aggregate Nicknames approach alwa= ys implies swapping of ingress and egress nicknames - at least this is what= the Multi-Level Trill draft states, and the Single Nickname draft follows = suit. [Mingui] Oh, that's not true. The "Single Nickname" draft is definitely dif= ferent from "Swapping Nickname" approach. In the "Single Nickname" draft, t= here is no "ingress swap nickname field" or "egress swap nickname field". I also do not understand how using L1 area names (which is a control plane = functionality) could replace the swapping of nicknames (which is a pure dat= a plane function). [Mingui] There is no "swapping" action in the "Single Nickname" draft. To e= xplain with an example, if the TRILL data packet is transitioned from level= 1 to level 2, the ingress nickname will be rewritten to the L1 area nickna= me. Please also refer to bullet 4 of Section 3.1 in the "Single Nickname" d= raft. However, these possible alternatives were never detailed as the one being r= eviewed, after the WG weighted their issues and complexity. [[Sasha]] It is all fine, but, from my POV, it does not address the issue I= 've raised, namely that the Single Nickname draft incorrectly positions its= elf as an alternative approach to that of Aggregate Nicknames in the Multi-= Level TRILL draft, and that such incorrect positioning negatively affects a= bility of a non-expert [Mingui] I think the above explanation about the difference between "Single= Nickname" and "Swapping Nickname" will clear the confusion. > * The draft is intended for the Standards Track, but it does not = say that > it updates the base TRILL spec (neither in the text nor in metadata) RFC 6325 is the base TRILL spec and it restricts itself to level 1 IS-IS wh= ile the draft being reviewed is talking about how to enable inter-communica= tion between level 1 IS-IS areas with level 2 border RBridges. That also me= ans level 1 RBridges conforms to RFC 6325 remain unchanged. So RFC 6325 sho= uld not appear in the "Updates" metadata? [[Sasha]] It seems that we understand the meaning of the RFC metadata diffe= rently. From my POV if you remove/relax a restriction imposed by an alread= y published Standards Track RFC, this means that you update it, and the met= adata should reflect that. E.g., you can take a look at RFC 4379 that is ma= rked as updating RFC 1122 because it allows transmission of IP packets with= the Destination IP address in the 127/8 subnet - something that RFC 1122 = explicitly prohibits. Again, it would be interesting to hear what the people on the RTG-DIR list = (especially ones that serve now - or have served in the past - as ADs and/o= r WG Chairs) think on that. [Mingui] OK. Thanks for the informational example. I am afraid the relation= ship between the draft and RFC 6325 is slightly different. Since specifica= tions of RFC 6325 would still hold after the draft is published. Best regards, Mingui > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Thursday, May 19, 2016 6:59 PM > To: Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com) > Cc: Susan Hares (shares@ndzh.com); jon.hudson@gma= il.com; Zhangxian > (Xian); draft-ietf-trill-multilevel-single-nickname@ietf.org; > 'rtg-dir@ietf.org'; trill@ietf.org > Subject: RTG-DIR QA review for > draft-ietf-trill-multilevel-single-nickname > > Hi all, > I have been appointed as the QA reviewer for > draft-ietf-trill-multilevel-single-nickname rg/doc/draft-i etf-trill-multilevel-single-nickname/?include_text=3D1>. > Before going into the review proper, I would like to make a couple of > introductory statements. > > > 1. I am NOT a TRILL expert and actually never before has been invol= ved > with TRILL. I have been told that this is OK and the ADs are > interested into getting reviews from non-experts. Well, in my case this i= s what they will get. > > 2. The time frame for providing the review was quite demanding (at = least > for me). This probably affected the review quality and it effectively > prevented me from discussing the review with the draft authors > privately - I owe them a sincere apology for that. > > 3. The RtgDirDocQa - Rtg Area > Wiki > states that the QA review is usually performed when a draft is going > to be adopted as a WG document. While it mentions, that a WG document > may be also subjected to such a review at the discretion of the WG > Chairs, the initial guidelines for the QA reviewer in the Wiki mention > only reviewing the draft for a QA adoption. As a consequence, I had to > create my own list of questions that will try to answer based on what I h= ave found in the Wiki. Here is this list: > > a. Is the draft easily readable and understandable? > > b. Does the draft represent an attempt to solve a real problem? > > c. Are there some serious technical gaps that the authors should tr= y to > fill? > > d. Are there any potential IETF process issues with the draft in its= present > form? > Please note that the question about "a good start for a WG draft" > which appears in the Wiki does not appear on my list (since the draft is = already a WG document). > At the same time I have included the question about solving a real > problem (which appeared in the previous version of the Wiki page). The > current version only asks if the draft "makes sense" which, from my POV, = is something else. > > > My answers to these questions follow. > > Is the draft easily readable and understandable? > Of course, "easily readable and understandable" is in the eye of the beho= lder. > But as a non-expert can say that it was quite difficult for me to > understand what this draft is really about. > Eventually, I have succeeded to build the following scheme that helped > me to understand what I am dealing with: > > * The TRILL base > spec: > > o Explicitly restricts TRILL to a single Level 1 IS-IS > > o Explicitly states that the nicknames of RBridges in the Trill packet = header > remain unchanged when the packet traverses the TRILL domain from > ingress (where the TRILL header is pushed on the original Ethernet > frame) to egress (where this header is popped) > > * An Informational Multi-Level > TRILL evel/?include _text=3D1> WG draft claims that this restriction > negatively affects TRILL scalability: > > o It mentions several scalability issues > > o However, it > > ? Neither mentions any specific scale parameters where these issues > become real > > ? Nor provides any explanations about the reasons that make > single-level IS-IS used by TRILL less scalable that single-level IS-IS > when it is used for distributing IP reachability > > o It claims that some of these issues may be addressed by allowing usag= e of > multi-level IS-IS for TRILL > > o It provides two specific proposals for making multi-level TRILL work: > > o One of these proposals is called "unique nicknames". This proposal: > > ? Does not require any changes in the TRILL data plane > > ? Requires introducing some structure in the nicknames of RBridges in > order to guarantee that these names are unique within the TRILL-based > campus > > o The other proposal is called "aggregate nicknames". This proposal: > > ? Allows RBridges in different L1 areas of the campus to share > nicknames > > ? Requires a change in the TRILL data plane: the nicknames in the > TRILL header of a packet will be modified by the L12 RBridges > > ? Allows two possible flavors (bot mentioned in the draft): > > * The flavor that uses L1 area nicknames > > * The flavor that uses the nicknames of all L12 RBridges connecte= d to a > given L1 area as its name > > * The Standards Track Single Nickname draft (one that I have been > asked to review) provides details on the second of the above-mentioned > flavors of the "Aggregate Nicknames" approach: > > o It also allows sharing the same nickname between RBridges in differen= t L1 > areas > > o It also requires the same change in the TRILL data plane > > o It eliminates the need for allocating nicknames to L1 areas. Instead,= each > such area is identified by the set of nicknames of all L12 RBridges > that connect to it. > It took me quite some time to build this scheme, and the text in the > draft was not very helpful in this. > The following points contributed to "negative readability" from my POV: > > * The draft positions itself as an alternative to the Aggregate > Nicknames approach while, from my POV, it is just provides additional > details on one of the possible flavors of this approach > > * The draft is intended for the Standards Track, but it does not = say that > it updates the base TRILL spec (neither in the text nor in metadata) --_000_4552F0907735844E9204A62BBDD325E787CB7589NKGEML515MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sasha,

 

Thanks for your comments. Please see responses inline below.

 

Thanks,

Mingui

 

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@eci= tele.com]
Sent: Monday, May 23, 2016 6:13 PM
To: Mingui Zhang
Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf= -trill-multilevel-single-nickname@ietf.org; Susan Hares (shares@ndzh.com); = jon.hudson@gmail.com; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)<= br> Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multil= evel-single-nickname

 

Mingui hi!=

Lots of thanks for a prompt = response to some of the issues I've raised in the review.=

 

Please see some comments to = you responses inline below.=

 

Regards,

Sasha

 

Office: +972-39266302

Cell:    = ;  +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 

-----Original Message----- From: rtg-dir [mailto:rtg-dir-b= ounces@ietf.org] On Behalf Of Mingui Zhang
Sent: Monday, May 23, 2016 12:31 PM
To: Alexander Vainshtein; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)
Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; dra= ft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares (shares@ndzh.com); jon.hudson@gmail.com
Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-si= ngle-nickname

 

Hi Alexander,

 

Thanks for the review!<= /o:p>

 

The multilevel conception it= self is abstract and not easily understandable.

[[Sasha]] Do you refer to the multi-level IS-IS in general or multi-level= TRILL specifically? I am asking because I believe am reasonably well aware= of the multi-level architecture of IS-IS as used for IP routing. It is somewhat different from that of OSPF, but I = would not call it “abstract and not easily understandable”. &nb= sp;And there are quite a few excellent introductions to the subject (again = in the context of IP routing). However, I am definitely not a TRILL expert, and have stated that in the review. =

 

[Mingui] Yes, multi-level arch of IS-IS has already been we= ll understood. However, the extending TRILL to multi-levels brings new chal= lenges. As stated in the informational draft, one issue is on processing the TRILL switch nicknames and the other= issue is on handling multi-destination packet distribution trees. In order= not to make the specifications “abstract”, the draft carefully= designed two walking-through examples in Section 3. If the examples were understood, it would be non-abstract as well. ;-)<= o:p>

 

However, it was really inter= esting in designing such a solution. Appreciate the review and the time on = relevant documents to figure out the whole scheme.

 

> ?  Nor provides an= y explanations about the reasons that make

> single-level IS-IS used= by TRILL less scalable that single-level IS-IS

> when it is used for dis= tributing IP reachability

 

The reason comes from the fa= ct that the length of a nickname is different from an IP address.

[[Sasha]] I must admit that I do not understand the connection. By this l= ogic, IS-IS for CLNS and IPv6 should be much more scalable than IS-IS for I= Pv4, but I have never seen such claims before. Could you please elaborate? Could somebody on the RTG-DIR list to = comment on that?

 

[Mingui] For a single-level IS-IS instance, the length of t= he address determines the name space. In the informational draft, Section 1= .1 TRILL Scalability Issues, the following statement is relevant

“   5. the lim= it of the number of TRILL switches, due to the 16-bit nickname space,”= ;

 

 

I think this could be addres= sed in the updated version of the draft: https://datatracker.i= etf.org/doc/draft-ietf-trill-rbridge-multilevel/?include_text=3D1.

 

> *    &nb= sp;    The draft positions itself as an alternative to = the Aggregate

> Nicknames approach whil= e, from my POV, it is just provides additional

> details on one of the p= ossible flavors of this approach

 

The WG used to discuss sever= al ways to address the "Aggregate Nickname" approach.

[[Sasha]] I do not follow the TRILL WG mailing list, so I am not aware of= any discussions that have been hold there. I am only speaking about what I= could find in the two drafts mentioned in my review.

 

[Mingui] Actually, the informational draft had included the= information of those alternatives as well. Please see “Section 2.2.2= .2 Swap Nickname Field Aggregated Nicknames” and read the words about “pseudonode” of Section 2.5.

 

One way was to use pseudonod= e nickname to denote an L1 area. Another way was to let border RBridges swa= p L1 and L2 nicknames.

[[Sasha]] I was under impression that the Aggregate Nicknames approach al= ways implies swapping of ingress and egress nicknames – at least this= is what the Multi-Level Trill draft states, and the Single Nickname draft follows suit.

 

[Mingui] Oh, that’s not true. The “Single Nickn= ame” draft is definitely different from “Swapping Nickname̶= 1; approach. In the “Single Nickname” draft, there is no “= ;ingress swap nickname field” or “egress swap nickname field”.

 

I also do not understand how using L1 area names (which is a control plan= e functionality) could replace the swapping of nicknames (which is a pure d= ata plane function).<= /p>

 

[Mingui] There is no “swapping” action in the &= #8220;Single Nickname” draft. To explain with an example, if the TRIL= L data packet is transitioned from level 1 to level 2, the ingress nickname will be rewritten to the L1 area nickname. Please also refer to b= ullet 4 of Section 3.1 in the “Single Nickname” draft.

 

However, these possible alte= rnatives were never detailed as the one being reviewed, after the WG weight= ed their issues and complexity.

[[Sasha]] It is all fine, but, from my POV, it does not address the issue= I’ve raised, namely that the Single Nickname draft incorrectly posi= tions itself as = an alternative approach to that of Aggregate Nicknames in the Multi-Level T= RILL draft, and that such incorrect positioning negatively affects ability of a non-expert

 

[Mingui] I think the above explanation about the difference= between “Single Nickname” and “Swapping Nickname” = will clear the confusion.

 

> *   &nbs= p;     The draft is intended for the Standards Track, b= ut it does not say that

> it updates the base TRI= LL spec (neither in the text nor in metadata)

 

RFC 6325 is the base TRILL s= pec and it restricts itself to level 1 IS-IS while the draft being reviewed= is talking about how to enable inter-communication between level 1 IS-IS a= reas with level 2 border RBridges. That also means level 1 RBridges conforms to RFC 6325 remain unchanged. So RFC = 6325 should not appear in the "Updates" metadata?

[[Sasha]] It seems that we understand the meaning of the RFC metadata dif= ferently. From my POV if  you remove/relax a restriction imposed by an= already published Standards Track RFC, this means that you update it, and the metadata should reflect that. E.g., you = can take a look at RFC 4379 that is marked as updating RFC 1122 because it = allows transmission of IP packets with the Destination IP address  in = the 127/8 subnet – something that RFC 1122 explicitly prohibits.

Again, it would be interesting to hear what the people on the RTG-DIR lis= t (especially ones that serve now – or have served in the past –= ; as ADs and/or WG Chairs) think on that.

 

[Mingui] OK. Thanks for the informational example. I am afr= aid the relationship between the draft and  RFC 6325 is slightly diffe= rent. Since specifications of RFC 6325 would still hold after the draft is published.

 

Best regards,

Mingui

 

> -----Original Message--= ---

> From: Alexander Vainsht= ein [mailto:Alexander.Vainshtein@ecitele.com= ]

> Sent: Thursday, May 19,= 2016 6:59 PM

> To: Jonathan Hardwick (= Jonathan.Hardwick@metaswitch.com)=

> Cc: Susan Hares (shares@ndzh.com); jon.hudson@gmail.com; Zhangxian

> (Xian); draft-ietf-trill-mult= ilevel-single-nickname@ietf.org;

> 'rtg-dir@ietf.org'; trill@ietf.org=

> Subject: RTG-DIR QA rev= iew for

> draft-ietf-trill-multil= evel-single-nickname

>

> Hi all,

> I have been appointed a= s the QA reviewer for

> draft-ietf-trill-multil= evel-single-nickname<https://datatracker.ietf.o

> rg/doc/draft-i etf-tril= l-multilevel-single-nickname/?include_text=3D1>.

> Before going into the r= eview proper, I would like to make a couple of

> introductory statements= .

>

>

> 1.   &nb= sp;   I am NOT a TRILL expert and actually never before has been = involved

> with TRILL. I have been= told that this is OK and the ADs are

> interested into getting= reviews from non-experts. Well, in my case this is what they will get.

>

> 2.   &nb= sp;   The time frame for providing the review was quite demanding= (at least

> for me). This probably = affected the review quality and it effectively

> prevented me from discu= ssing the review with the draft authors

> privately - I owe them = a sincere apology for that.

>

> 3.   &nb= sp;   The RtgDirDocQa - Rtg Area

> Wiki<https://trac.tools.ietf.org/area/rtg/tra= c/wiki/RtgDirDocQa>

> states that the QA revi= ew is usually performed when a draft is going

> to be adopted as a WG d= ocument. While it mentions, that a WG document

> may be also subjected t= o such a review at the discretion of the WG

> Chairs, the initial gui= delines for the QA reviewer in the Wiki mention

> only reviewing the draf= t for a QA adoption. As a consequence, I had to

> create my own list of q= uestions that will try to answer based on what I have found in the Wiki. He= re is this list:

>

> a.   &nb= sp;   Is the draft easily readable and understandable?=

>

> b.   &nb= sp;  Does the draft represent an attempt to solve a real problem?=

>

> c.   &nb= sp;   Are there some serious technical gaps that the authors shou= ld try to

> fill?=

>

> d.   &nb= sp;  Are there any potential IETF process issues with the draft in its= present

> form?=

> Please note that the qu= estion about "a good start for a WG draft"

> which appears in the Wi= ki does not appear on my list (since the draft is already a WG document).

> At the same time I have= included the question about solving a real

> problem (which appeared= in the previous version of the Wiki page). The

> current version only as= ks if the draft "makes sense" which, from my POV, is something el= se.

>

>

> My answers to these que= stions follow.

>

> Is the draft easily rea= dable and understandable?

> Of course, "easily= readable and understandable" is in the eye of the beholder.

> But as a non-expert can= say that it was quite difficult for me to

> understand what this dr= aft is really about.

> Eventually, I have succ= eeded to build the following scheme that helped

> me to understand what I= am dealing with:

>

> *   &nbs= p;     The TRILL base

> spec<https://datatracker.ietf.org/doc/rfc6325= /?include_text=3D1>:

>

> o   Explicitl= y restricts TRILL to a single Level 1 IS-IS

>

> o   Explicitl= y states that the nicknames of RBridges in the Trill packet header

> remain unchanged when t= he packet traverses the TRILL domain from

> ingress (where the TRIL= L header is pushed on the original Ethernet

> frame) to egress (where= this header is popped)

>

> *   &nbs= p;     An Informational Multi-Level

> TRILL<https://datatr= acker.ietf.org/doc/draft-ietf-trill-rbridge-multil

> evel/?include _text=3D1= > WG draft claims that this restriction

> negatively affects TRIL= L scalability:

>

> o   It mentio= ns several scalability issues

>

> o   However, = it

>

> ?  Neither mention= s any specific scale parameters where these issues

> become real<= /span>

>

> ?  Nor provides an= y explanations about the reasons that make

> single-level IS-IS used= by TRILL less scalable that single-level IS-IS

> when it is used for dis= tributing IP reachability

>

> o   It claims= that some of these issues may be addressed by allowing usage of=

> multi-level IS-IS for T= RILL

>

> o   It provid= es two specific proposals for making multi-level TRILL work:

>

> o   One of th= ese proposals is called "unique nicknames". This proposal:

>

> ?   Does not = require any changes in the TRILL data plane

>

> ?  Requires introd= ucing some structure in the nicknames of RBridges in

> order to guarantee that= these names are unique within the TRILL-based

> campus

>

> o   The other= proposal is called "aggregate nicknames". This proposal:

>

> ?  Allows RBridges= in different L1 areas of the campus to share

> nicknames

>

> ?  Requires a chan= ge in the TRILL data plane: the nicknames in the

> TRILL header of a packe= t will be modified by the L12 RBridges

>

> ?  Allows two poss= ible flavors (bot mentioned in the draft):

>

> *   &nbs= p;     The flavor that uses L1 area nicknames

>

> *   &nbs= p;     The flavor that uses the nicknames of all L12 RB= ridges connected to a

> given L1 area as its na= me

>

> *   &nbs= p;     The Standards Track Single Nickname draft (one t= hat I have been

> asked to review) provid= es details on the second of the above-mentioned

> flavors of the "Ag= gregate Nicknames" approach:

>

> o   It also a= llows sharing the same nickname between RBridges in different L1=

> areas=

>

> o   It also r= equires the same change in the TRILL data plane

>

> o   It elimin= ates the need for allocating nicknames to L1 areas. Instead, each

> such area is identified= by the set of nicknames of all L12 RBridges

> that connect to it.

> It took me quite some t= ime to build this scheme, and the text in the

> draft was not very help= ful in this.

> The following points co= ntributed to "negative readability" from my POV:

>

> *   &nbs= p;     The draft positions itself as an alternative to = the Aggregate

> Nicknames approach whil= e, from my POV, it is just provides additional

> details on one of the p= ossible flavors of this approach

>

> *   &nbs= p;     The draft is intended for the Standards Track, b= ut it does not say that

> it updates the base TRI= LL spec (neither in the text nor in metadata)

 

--_000_4552F0907735844E9204A62BBDD325E787CB7589NKGEML515MBSchi_-- From nobody Tue May 24 05:41:53 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8035E12D15F; Tue, 24 May 2016 03:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eci365.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 0lORerimZj6M; Tue, 24 May 2016 03:45:49 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0784.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::784]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6730512B048; Tue, 24 May 2016 03:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ETWY4W8wlq7OfPIXHqQdmFjX33J6Wd0+oGzBHLajTIY=; b=MVZgpE7d15rI/tOf3B24bQjFmpZDlMW2FthAo1VBKoYLi03KuWL0Vb8ev2LFeKa66evEBXUgMBeilWCVD9MUN6YTcY1wW9PNToNHb2kSkJA3cPPG6ADAXdmAeacO9vxBJH2+aBizkmKtsGuxqfhJrcRqCaSt+zdkqEWdXKEzvaw= Received: from HE1PR0301MB2266.eurprd03.prod.outlook.com (10.168.31.153) by HE1PR0301MB2268.eurprd03.prod.outlook.com (10.168.31.155) with Microsoft SMTP Server (TLS) id 15.1.497.12; Tue, 24 May 2016 10:45:28 +0000 Received: from HE1PR0301MB2266.eurprd03.prod.outlook.com ([10.168.31.153]) by HE1PR0301MB2266.eurprd03.prod.outlook.com ([10.168.31.153]) with mapi id 15.01.0497.022; Tue, 24 May 2016 10:45:28 +0000 From: Alexander Vainshtein To: Mingui Zhang Thread-Topic: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname Thread-Index: AQHRtZZOOYuy+h1UCUGjRJ1qjVLvXZ/H45PQ Date: Tue, 24 May 2016 10:45:28 +0000 Message-ID: References: <4552F0907735844E9204A62BBDD325E787CB087E@NKGEML515-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E787CB7589@NKGEML515-MBS.china.huawei.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E787CB7589@NKGEML515-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=ecitele.com; x-originating-ip: [147.234.241.1] x-ms-office365-filtering-correlation-id: 4a45d92f-7383-4a5d-54cc-08d383c085a6 x-microsoft-exchange-diagnostics: 1; HE1PR0301MB2268; 5:PEGobXshEI1/Kdh02Vaoh97nF5XB4bpzfi2Okze/3/7DydDpUxfPvM2eBFCmPU8n2tBeli3vEaHNCdGAIgnxqX++21CvTT95DS+TUdgfoVHjmdQG+otOweW5c7yiSijJWa8Cp71Xnu5pSNwkR5fYtw==; 24:IJ5Ex2e5GQ2dV7cwmOXcLprQ/bbtg220o8BeevrSG/AkP+osXrWFexqggz/M9slQNNP7txeErmIx/ka/vEap4zRvCiMjBL1T5U2SxheYV6M=; 7:BJCiOpIt9dGnwzlKJOgeehnIkkAHuQUF59xcYuZ1AyT1efHX94dA1IYJ/x1ygYYVRryvGnggDAtcU9hHe+hHreckLykpXU9QhMRMQ8I7uGT5n047uZHV2MIjAGhvV8rQx1xtX6EwhT1rS/iqh2Hq6Ds3aHt4x+ew0WRhSnFxFcGe8wG7FyEp/nd7735o1Kg+ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0301MB2268; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:HE1PR0301MB2268; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0301MB2268; x-forefront-prvs: 09525C61DB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51914003)(13464003)(53754006)(377454003)(252514010)(10400500002)(5890100001)(19625215002)(106116001)(5002640100001)(2900100001)(15975445007)(2950100001)(77096005)(19300405004)(122556002)(586003)(102836003)(1220700001)(790700001)(6116002)(3846002)(2906002)(86362001)(9686002)(3660700001)(4326007)(3280700002)(189998001)(110136002)(19580405001)(19580395003)(92566002)(8936002)(230783001)(81166006)(8676002)(5003600100002)(5008740100001)(19617315012)(5004730100002)(54356999)(87936001)(74316001)(66066001)(50986999)(76176999)(33656002)(76576001)(11100500001)(561944003)(16236675004)(93886004)(559001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0301MB2268; H:HE1PR0301MB2266.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0301MB2266B54FEB022F39BD43D1409D4F0HE1PR0301MB2266_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2016 10:45:28.7195 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0301MB2268 Archived-At: X-Mailman-Approved-At: Tue, 24 May 2016 05:41:49 -0700 Cc: "Zhangxian \(Xian\)" , "'rtg-dir@ietf.org'" <'rtg-dir@ietf.org'>, "trill@ietf.org" , Jonathan Hardwick , "draft-ietf-trill-multilevel-single-nickname@ietf.org" , Susan Hares , "jon.hudson@gmail.com" Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 10:45:58 -0000 --_000_HE1PR0301MB2266B54FEB022F39BD43D1409D4F0HE1PR0301MB2266_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mingui hi! Lots of thanks for a prompt response. A few short comments inline below. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: Mingui Zhang [mailto:zhangmingui@huawei.com] Sent: Tuesday, May 24, 2016 11:23 AM To: Alexander Vainshtein Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-= multilevel-single-nickname@ietf.org; Susan Hares; jon.hudson@gmail.com; Jon= athan Hardwick Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-si= ngle-nickname Hi Sasha, Thanks for your comments. Please see responses inline below. Thanks, Mingui From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Monday, May 23, 2016 6:13 PM To: Mingui Zhang Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares (shares@ndzh.com<= mailto:shares@ndzh.com>); jon.hudson@gmail.com= ; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com) Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-si= ngle-nickname Mingui hi! Lots of thanks for a prompt response to some of the issues I've raised in t= he review. Please see some comments to you responses inline below. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Mingui Zhang Sent: Monday, May 23, 2016 12:31 PM To: Alexander Vainshtein; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.c= om) Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares (shares@ndzh.com<= mailto:shares@ndzh.com>); jon.hudson@gmail.com Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-si= ngle-nickname Hi Alexander, Thanks for the review! The multilevel conception itself is abstract and not easily understandable. [[Sasha]] Do you refer to the multi-level IS-IS in general or multi-level T= RILL specifically? I am asking because I believe am reasonably well aware o= f the multi-level architecture of IS-IS as used for IP routing. It is somew= hat different from that of OSPF, but I would not call it "abstract and not = easily understandable". And there are quite a few excellent introductions = to the subject (again in the context of IP routing). However, I am definite= ly not a TRILL expert, and have stated that in the review. [Mingui] Yes, multi-level arch of IS-IS has already been well understood. H= owever, the extending TRILL to multi-levels brings new challenges. As state= d in the informational draft, one issue is on processing the TRILL switch n= icknames and the other issue is on handling multi-destination packet distri= bution trees. In order not to make the specifications "abstract", the draft= carefully designed two walking-through examples in Section 3. If the examp= les were understood, it would be non-abstract as well. ;-) However, it was really interesting in designing such a solution. Appreciate= the review and the time on relevant documents to figure out the whole sche= me. > ? Nor provides any explanations about the reasons that make > single-level IS-IS used by TRILL less scalable that single-level IS-IS > when it is used for distributing IP reachability The reason comes from the fact that the length of a nickname is different f= rom an IP address. [[Sasha]] I must admit that I do not understand the connection. By this log= ic, IS-IS for CLNS and IPv6 should be much more scalable than IS-IS for IPv= 4, but I have never seen such claims before. Could you please elaborate? Co= uld somebody on the RTG-DIR list to comment on that? [Mingui] For a single-level IS-IS instance, the length of the address deter= mines the name space. In the informational draft, Section 1.1 TRILL Scalabi= lity Issues, the following statement is relevant " 5. the limit of the number of TRILL switches, due to the 16-bit nicknam= e space," [[Sasha]] Do you (or the authors of the multi-level TRILL draft) consider d= eployment scenarios with more than 64K RBridges in a single TRILL campus? I= s this a realistic scenario? I think this could be addressed in the updated version of the draft: https:= //datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/?include_tex= t=3D1. > * The draft positions itself as an alternative to the Aggregate > Nicknames approach while, from my POV, it is just provides additional > details on one of the possible flavors of this approach The WG used to discuss several ways to address the "Aggregate Nickname" app= roach. [[Sasha]] I do not follow the TRILL WG mailing list, so I am not aware of a= ny discussions that have been hold there. I am only speaking about what I c= ould find in the two drafts mentioned in my review. [Mingui] Actually, the informational draft had included the information of = those alternatives as well. Please see "Section 2.2.2.2 Swap Nickname Field= Aggregated Nicknames" and read the words about "pseudonode" of Section 2.5= . One way was to use pseudonode nickname to denote an L1 area. Another way wa= s to let border RBridges swap L1 and L2 nicknames. [[Sasha]] I was under impression that the Aggregate Nicknames approach alwa= ys implies swapping of ingress and egress nicknames - at least this is what= the Multi-Level Trill draft states, and the Single Nickname draft follows = suit. [Mingui] Oh, that's not true. The "Single Nickname" draft is definitely dif= ferent from "Swapping Nickname" approach. In the "Single Nickname" draft, t= here is no "ingress swap nickname field" or "egress swap nickname field". [[Sasha]] Quoting from Section 3.1 of the Dingle Nickname draft (and apolog= ies for a long quotation; the relevant places are highlighted): - S transmits an Ethernet frame with source MAC =3D S and destination MAC =3D D. - RB27 [[Sasha - the ingress RBridge]] encapsulates with a TRILL header= with ingress RBridge =3D 27, and egress RBridge =3D 3 producing a TRILL Data packet. - RB2 and RB20 have announced in the Level 1 IS-IS instance in area {2,20}, that they are attached to all those area nicknames, including {3,30}. Therefore, IS-IS routes the packet to RB2 (or RB20, if RB20 on the least-cost route from RB27 to RB3). - RB2, when transitioning the packet from Level 1 to Level 2, replaces the ingress TRILL switch nickname with its own nickname, so replaces 27 with 2. ... - The packet is forwarded through Level 2, to RB3, which has advertised, in Level 2, its L2 nickname as 3. - RB3, when forwarding into area {3,30}, replaces the egress nickname in the TRILL header with RB44's nickname (44). (The ingress nickname MAY be replaced with an area nickname selected from {2,20}. See Section 4 for the detail of the selection method. Here, suppose nickname 2 is selected.) So, within the destination area, the ingress nickname will be 2 and the egress nickname will be 44. In other words, your draft explicitly states that the area border RBridges = modify the nicknames in the TRILL header of a packet that crosses the Level= 2 domain. How is this different from swapping (save from the name of the o= peration)? I also do not understand how using L1 area names (which is a control plane = functionality) could replace the swapping of nicknames (which is a pure dat= a plane function). [Mingui] There is no "swapping" action in the "Single Nickname" draft. To e= xplain with an example, if the TRILL data packet is transitioned from level= 1 to level 2, the ingress nickname will be rewritten to the L1 area nickna= me. Please also refer to bullet 4 of Section 3.1 in the "Single Nickname" d= raft. [[Sasha]] Please see above. However, these possible alternatives were never detailed as the one being r= eviewed, after the WG weighted their issues and complexity. [[Sasha]] It is all fine, but, from my POV, it does not address the issue I= 've raised, namely that the Single Nickname draft incorrectly positions its= elf as an alternative approach to that of Aggregate Nicknames in the Multi-= Level TRILL draft, and that such incorrect positioning negatively affects a= bility of a non-expert [Mingui] I think the above explanation about the difference between "Single= Nickname" and "Swapping Nickname" will clear the confusion. [[Sasha]] Sorry, but no, it doesn't. > * The draft is intended for the Standards Track, but it does not = say that > it updates the base TRILL spec (neither in the text nor in metadata) RFC 6325 is the base TRILL spec and it restricts itself to level 1 IS-IS wh= ile the draft being reviewed is talking about how to enable inter-communica= tion between level 1 IS-IS areas with level 2 border RBridges. That also me= ans level 1 RBridges conforms to RFC 6325 remain unchanged. So RFC 6325 sho= uld not appear in the "Updates" metadata? [[Sasha]] It seems that we understand the meaning of the RFC metadata diffe= rently. From my POV if you remove/relax a restriction imposed by an alread= y published Standards Track RFC, this means that you update it, and the met= adata should reflect that. E.g., you can take a look at RFC 4379 that is ma= rked as updating RFC 1122 because it allows transmission of IP packets with= the Destination IP address in the 127/8 subnet - something that RFC 1122 = explicitly prohibits. Again, it would be interesting to hear what the people on the RTG-DIR list = (especially ones that serve now - or have served in the past - as ADs and/o= r WG Chairs) think on that. [Mingui] OK. Thanks for the informational example. I am afraid the relation= ship between the draft and RFC 6325 is slightly different. Since specifica= tions of RFC 6325 would still hold after the draft is published. [[Sasha]] Were it otherwise, I would ask why the Single Nickname draft is n= ot marked as obsoleting RFC 6325. Best regards, Mingui > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Thursday, May 19, 2016 6:59 PM > To: Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com) > Cc: Susan Hares (shares@ndzh.com); jon.hudson@gma= il.com; Zhangxian > (Xian); draft-ietf-trill-multilevel-single-nickname@ietf.org; > 'rtg-dir@ietf.org'; trill@ietf.org > Subject: RTG-DIR QA review for > draft-ietf-trill-multilevel-single-nickname > > Hi all, > I have been appointed as the QA reviewer for > draft-ietf-trill-multilevel-single-nickname rg/doc/draft-i etf-trill-multilevel-single-nickname/?include_text=3D1>. > Before going into the review proper, I would like to make a couple of > introductory statements. > > > 1. I am NOT a TRILL expert and actually never before has been invol= ved > with TRILL. I have been told that this is OK and the ADs are > interested into getting reviews from non-experts. Well, in my case this i= s what they will get. > > 2. The time frame for providing the review was quite demanding (at = least > for me). This probably affected the review quality and it effectively > prevented me from discussing the review with the draft authors > privately - I owe them a sincere apology for that. > > 3. The RtgDirDocQa - Rtg Area > Wiki > states that the QA review is usually performed when a draft is going > to be adopted as a WG document. While it mentions, that a WG document > may be also subjected to such a review at the discretion of the WG > Chairs, the initial guidelines for the QA reviewer in the Wiki mention > only reviewing the draft for a QA adoption. As a consequence, I had to > create my own list of questions that will try to answer based on what I h= ave found in the Wiki. Here is this list: > > a. Is the draft easily readable and understandable? > > b. Does the draft represent an attempt to solve a real problem? > > c. Are there some serious technical gaps that the authors should tr= y to > fill? > > d. Are there any potential IETF process issues with the draft in its= present > form? > Please note that the question about "a good start for a WG draft" > which appears in the Wiki does not appear on my list (since the draft is = already a WG document). > At the same time I have included the question about solving a real > problem (which appeared in the previous version of the Wiki page). The > current version only asks if the draft "makes sense" which, from my POV, = is something else. > > > My answers to these questions follow. > > Is the draft easily readable and understandable? > Of course, "easily readable and understandable" is in the eye of the beho= lder. > But as a non-expert can say that it was quite difficult for me to > understand what this draft is really about. > Eventually, I have succeeded to build the following scheme that helped > me to understand what I am dealing with: > > * The TRILL base > spec: > > o Explicitly restricts TRILL to a single Level 1 IS-IS > > o Explicitly states that the nicknames of RBridges in the Trill packet = header > remain unchanged when the packet traverses the TRILL domain from > ingress (where the TRILL header is pushed on the original Ethernet > frame) to egress (where this header is popped) > > * An Informational Multi-Level > TRILL evel/?include _text=3D1> WG draft claims that this restriction > negatively affects TRILL scalability: > > o It mentions several scalability issues > > o However, it > > ? Neither mentions any specific scale parameters where these issues > become real > > ? Nor provides any explanations about the reasons that make > single-level IS-IS used by TRILL less scalable that single-level IS-IS > when it is used for distributing IP reachability > > o It claims that some of these issues may be addressed by allowing usag= e of > multi-level IS-IS for TRILL > > o It provides two specific proposals for making multi-level TRILL work: > > o One of these proposals is called "unique nicknames". This proposal: > > ? Does not require any changes in the TRILL data plane > > ? Requires introducing some structure in the nicknames of RBridges in > order to guarantee that these names are unique within the TRILL-based > campus > > o The other proposal is called "aggregate nicknames". This proposal: > > ? Allows RBridges in different L1 areas of the campus to share > nicknames > > ? Requires a change in the TRILL data plane: the nicknames in the > TRILL header of a packet will be modified by the L12 RBridges > > ? Allows two possible flavors (bot mentioned in the draft): > > * The flavor that uses L1 area nicknames > > * The flavor that uses the nicknames of all L12 RBridges connecte= d to a > given L1 area as its name > > * The Standards Track Single Nickname draft (one that I have been > asked to review) provides details on the second of the above-mentioned > flavors of the "Aggregate Nicknames" approach: > > o It also allows sharing the same nickname between RBridges in differen= t L1 > areas > > o It also requires the same change in the TRILL data plane > > o It eliminates the need for allocating nicknames to L1 areas. Instead,= each > such area is identified by the set of nicknames of all L12 RBridges > that connect to it. > It took me quite some time to build this scheme, and the text in the > draft was not very helpful in this. > The following points contributed to "negative readability" from my POV: > > * The draft positions itself as an alternative to the Aggregate > Nicknames approach while, from my POV, it is just provides additional > details on one of the possible flavors of this approach > > * The draft is intended for the Standards Track, but it does not = say that > it updates the base TRILL spec (neither in the text nor in metadata) --_000_HE1PR0301MB2266B54FEB022F39BD43D1409D4F0HE1PR0301MB2266_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mingui hi!<= /span>

Lots of thanks for a p= rompt response.

 

A few short comments <= /span>inline below.

 

Regards,

Sasha

 

Office: +972-39266= 302

Cell:   = ;   +972-549266302

Email:   Ale= xander.Vainshtein@ecitele.com

 

From: Mingui Zhang [mailto:zhangmingui@huawei= .com]
Sent: Tuesday, May 24, 2016 11:23 AM
To: Alexander Vainshtein
Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf= -trill-multilevel-single-nickname@ietf.org; Susan Hares; jon.hudson@gmail.c= om; Jonathan Hardwick
Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multil= evel-single-nickname

 

Hi Sasha,

 

Thanks for your comments. Please see responses inl= ine below.

 

Thanks,

Mingui

 

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ec= itele.com]
Sent: Monday, May 23, 2016 6:13 PM
To: Mingui Zhang
Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares (shares@ndzh.com); jon.hudson@gmail.com; Jonathan = Hardwick (Jonathan.Hard= wick@metaswitch.com)
Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multil= evel-single-nickname=

 

Mingui= hi!

Lots o= f thanks for a prompt response to some of the issues I've raised in the rev= iew.

 =

Please= see some comments to you responses inline below.=

 =

Regard= s,

Sasha<= o:p>

 =

Office= : +972-39266302

Cell:&= nbsp;     +972-549266302

Email:=    Alexander.Vainshtein@ecitele.com

 =

-----O= riginal Message-----
From: rtg-dir [mailto:rtg-dir-b= ounces@ietf.org] On Behalf Of Mingui Zhang
Sent: Monday, May 23, 2016 12:31 PM
To: Alexander Vainshtein; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)
Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; dra= ft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares (shares@ndzh.com); jon.hudson@gmail.com
Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-si= ngle-nickname

 =

Hi Ale= xander,

 =

Thanks= for the review!

 =

The mu= ltilevel conception itself is abstract and not easily understandable.<= /o:p>

[[Sasha]] Do you refer to the multi-level IS-IS in general or= multi-level TRILL specifically? I am asking because I believe am reasonabl= y well aware of the multi-level architecture of IS-IS as used for IP routing. It is somewhat different from that of OSP= F, but I would not call it “abstract and not easily understandable= 221;.  And there are quite a few excellent introductions to the subjec= t (again in the context of IP routing). However, I am definitely not a TRILL expert, and have stated that in the review. <= /p>

 

[Mingui] Yes, multi-level arch of IS-IS has alr= eady been well understood. However, the extending TRILL to multi-levels bri= ngs new challenges. As stated in the informational draft, one issue is on processing the TRILL switch nicknames= and the other issue is on handling multi-destination packet distribution t= rees. In order not to make the specifications “abstract”, the d= raft carefully designed two walking-through examples in Section 3. If the examples were understood, it would be non-ab= stract as well. ;-)

=  =

Howeve= r, it was really interesting in designing such a solution. Appreciate the r= eview and the time on relevant documents to figure out the whole scheme.

 =

> ?=   Nor provides any explanations about the reasons that make

> s= ingle-level IS-IS used by TRILL less scalable that single-level IS-IS

> w= hen it is used for distributing IP reachability

 =

The re= ason comes from the fact that the length of a nickname is different from an= IP address.

[[Sasha]] I must admit that I do not understand the connectio= n. By this logic, IS-IS for CLNS and IPv6 should be much more scalable than= IS-IS for IPv4, but I have never seen such claims before. Could you please elaborate? Could somebody on the RTG-= DIR list to comment on that?

 

[Mingui] For a single-level IS-IS instance, the= length of the address determines the name space. In the informational draf= t, Section 1.1 TRILL Scalability Issues, the following statement is relevant

“  = ; 5. the limit of the number of TRILL switches, due to the 16-bit nickname = space,”

[[Sasha]] Do you (or the authors of the multi-level TRILL dra= ft) consider deployment scenarios with more than 64K RBridges in a single T= RILL campus? Is this a realistic scenario?

 

 

I thin= k this could be addressed in the updated version of the draft: https://datatracker.i= etf.org/doc/draft-ietf-trill-rbridge-multilevel/?include_text=3D1.

 =

> *=          The draft positions itself= as an alternative to the Aggregate

> N= icknames approach while, from my POV, it is just provides additional

> d= etails on one of the possible flavors of this approach

 =

The WG= used to discuss several ways to address the "Aggregate Nickname"= approach.

[[Sasha]] I do not follow the TRILL WG mailing list, so I am = not aware of any discussions that have been hold there. I am only speaking = about what I could find in the two drafts mentioned in my review.

 

[Mingui] Actually, the informational draft had = included the information of those alternatives as well. Please see “S= ection 2.2.2.2 Swap Nickname Field Aggregated Nicknames” and read the words about “pseudonode” of Sect= ion 2.5. <= /span>

 

One wa= y was to use pseudonode nickname to denote an L1 area. Another way was to l= et border RBridges swap L1 and L2 nicknames.

[[Sasha]] I was under impression that the Aggregate Nicknames= approach always implies swapping of ingress and egress nicknames – a= t least this is what the Multi-Level Trill draft states, and the Single Nickname draft follows suit.

 

[Mingui] Oh, that’s not true. The “= Single Nickname” draft is definitely different from “Swapping N= ickname” approach. In the “Single Nickname” draft, there = is no “ingress swap nickname field” or “egress swap nicknam= e field”.

[[Sasha]] Quoting from Section 3.1 of the Dingle Nickname dra= ft (and apologies for a long quotation; the relevant places are highlighted= ):

    -  S transmits an Et= hernet frame with source MAC =3D S and destination

      MAC =3D D.=

 

   -  RB27 [[Sasha – the ingress RBridge]] encapsulates with a TRILL header with ingress RBridge =3D 27,

      and egress RBridge = =3D 3 producing a TRILL Data packet.

 

   -  RB2 and RB20 have announced in = the Level 1 IS-IS instance in area

      {2,20}, that they are= attached to all those area nicknames,

      including {3,30}. The= refore, IS-IS routes the packet to RB2 (or

      RB20, if RB20 on the = least-cost route from RB27 to RB3).

 

   -  RB2, when transi= tioning the packet from Level 1 to Level 2,

   = ;   replaces the ingress TRILL switch nickname with its own nickn= ame,

  &nbs= p;   so replaces 27 with 2.

…

 

   -  The packet is forwarded through= Level 2, to RB3, which has

      advertised, in Level = 2, its L2 nickname as 3.

 

   -  RB3, when forwarding int= o area {3,30}, replaces the egress

   = ;   nickname in the TRILL header with RB44's nickname (44). (The

   = ;   ingress nickname MAY be replaced with an area nickname select= ed

   = ;   from {2,20}. See Section 4 for the detail of the selection method.

      Here, suppose nicknam= e 2 is selected.) So, within the destination

      area, the ingress nic= kname will be 2 and the egress nickname will

      be 44.

In other words, your draft explicitly states= that the area border RBridges modify the nicknames in the TRILL header of = a packet that crosses the Level 2 domain. How is this different from swapping (save from the name of the operation)?=

I also do not understand how using L1 area names (which is a = control plane functionality) could replace the swapping of nicknames (which= is a pure data plane function).

 

[Mingui] There is no “swapping” act= ion in the “Single Nickname” draft. To explain with an example,= if the TRILL data packet is transitioned from level 1 to level 2, the ingress nickname will be rewritten to the L1 area nickname. Please = also refer to bullet 4 of Section 3.1 in the “Single Nickname” = draft.

[[Sasha]] Please see above.

 

Howeve= r, these possible alternatives were never detailed as the one being reviewe= d, after the WG weighted their issues and complexity.

[[Sasha]] It is all fine, but, from my POV, it does not addre= ss the issue I’ve raised, namely that the Single Nickname draft incorrectly positions itself as an alternative approach to that of Ag= gregate Nicknames in the Multi-Level TRILL draft, and that such incorrect positioning negatively affects abilit= y of a non-expert=

 

[Mingui] I think the above explanation about th= e difference between “Single Nickname” and “Swapping Nick= name” will clear the confusion. <= o:p>

[[Sasha]] Sorry, but no, it doesn’t.<= /i>

 =

> *=          The draft is intended for = the Standards Track, but it does not say that

> i= t updates the base TRILL spec (neither in the text nor in metadata)

 =

RFC 63= 25 is the base TRILL spec and it restricts itself to level 1 IS-IS while th= e draft being reviewed is talking about how to enable inter-communication b= etween level 1 IS-IS areas with level 2 border RBridges. That also means level 1 RBridges conforms to RFC 6325 r= emain unchanged. So RFC 6325 should not appear in the "Updates" m= etadata?

[[Sasha]] It seems that we understand the meaning of the RFC = metadata differently. From my POV if  you remove/relax a restriction i= mposed by an already published Standards Track RFC, this means that you update it, and the metadata should reflect = that. E.g., you can take a look at RFC 4379 that is marked as updating RFC = 1122 because it allows transmission of IP packets with the Destination IP a= ddress  in the 127/8 subnet – something that RFC 1122 explicitly prohibits.

Again, it would be interesting to hear what the people on the= RTG-DIR list (especially ones that serve now – or have served in the= past – as ADs and/or WG Chairs) think on that.

 =

[Mingui] OK. Thanks for the informational examp= le. I am afraid the relationship between the draft and  RFC 6325 is sl= ightly different. Since specifications of RFC 6325 would still hold after the draft is published. <= /b>

[[Sasha]] Were it otherwise, I would ask why the Single Nickn= ame draft is not marked as obsoleting RFC 6325.

 

Best r= egards,

Mingui=

 =

> -= ----Original Message-----

> F= rom: Alexander Vainshtein [mailto:Alexander.= Vainshtein@ecitele.com]

> S= ent: Thursday, May 19, 2016 6:59 PM

> T= o: Jonathan Hardwick (<= span style=3D"color:windowtext;text-decoration:none">Jonathan.Hardwick@meta= switch.com)

> C= c: Susan Hares (shares@ndzh.com); jon.hudson@gmail.com; Zhangxian

> (= Xian); draft-ietf-trill-mult= ilevel-single-nickname@ietf.org;

> '= rtg-dir@ietf.org'; trill@ietf.org

> S= ubject: RTG-DIR QA review for

> d= raft-ietf-trill-multilevel-single-nickname

> <= o:p>

> H= i all,

> I= have been appointed as the QA reviewer for

> d= raft-ietf-trill-multilevel-single-nickname<https://datatracker.ietf.o

> r= g/doc/draft-i etf-trill-multilevel-single-nickname/?include_text=3D1>.

> B= efore going into the review proper, I would like to make a couple of

> i= ntroductory statements.

> <= o:p>

> <= o:p>

> 1= .       I am NOT a TRILL expert and actually = never before has been involved

> w= ith TRILL. I have been told that this is OK and the ADs are

> i= nterested into getting reviews from non-experts. Well, in my case this is w= hat they will get.

> <= o:p>

> 2= .       The time frame for providing the revi= ew was quite demanding (at least

> f= or me). This probably affected the review quality and it effectively

> p= revented me from discussing the review with the draft authors

> p= rivately - I owe them a sincere apology for that.

> <= o:p>

> 3= .       The RtgDirDocQa - Rtg Area=

> W= iki<https://trac.tools= .ietf.org/area/rtg/trac/wiki/RtgDirDocQa>

> s= tates that the QA review is usually performed when a draft is going

> t= o be adopted as a WG document. While it mentions, that a WG document

> m= ay be also subjected to such a review at the discretion of the WG

> C= hairs, the initial guidelines for the QA reviewer in the Wiki mention

> o= nly reviewing the draft for a QA adoption. As a consequence, I had to

> c= reate my own list of questions that will try to answer based on what I have= found in the Wiki. Here is this list:

> <= o:p>

> a= .       Is the draft easily readable and unde= rstandable?

> <= o:p>

> b= .      Does the draft represent an attempt to solv= e a real problem?

> <= o:p>

> c= .       Are there some serious technical gaps= that the authors should try to

> f= ill?

> <= o:p>

> d= .      Are there any potential IETF process issues= with the draft in its present

> f= orm?

> P= lease note that the question about "a good start for a WG draft"

> w= hich appears in the Wiki does not appear on my list (since the draft is alr= eady a WG document).

> A= t the same time I have included the question about solving a real

> p= roblem (which appeared in the previous version of the Wiki page). The

> c= urrent version only asks if the draft "makes sense" which, from m= y POV, is something else.

> <= o:p>

> <= o:p>

> M= y answers to these questions follow.

> <= o:p>

> I= s the draft easily readable and understandable?

> O= f course, "easily readable and understandable" is in the eye of t= he beholder.

> B= ut as a non-expert can say that it was quite difficult for me to

> u= nderstand what this draft is really about.

> E= ventually, I have succeeded to build the following scheme that helped

> m= e to understand what I am dealing with:

> <= o:p>

> *=          The TRILL base<= /span>

> s= pec<https://datatracke= r.ietf.org/doc/rfc6325/?include_text=3D1>:<= /p>

> <= o:p>

> o=    Explicitly restricts TRILL to a single Level 1 IS-IS

> <= o:p>

> o=    Explicitly states that the nicknames of RBridges in the Trill = packet header

> r= emain unchanged when the packet traverses the TRILL domain from

> i= ngress (where the TRILL header is pushed on the original Ethernet

> f= rame) to egress (where this header is popped)

> <= o:p>

> *=          An Informational Multi-Lev= el

> T= RILL<https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multil

> e= vel/?include _text=3D1> WG draft claims that this restriction

> n= egatively affects TRILL scalability:

> <= o:p>

> o=    It mentions several scalability issues

> <= o:p>

> o=    However, it

> <= o:p>

> ?=   Neither mentions any specific scale parameters where these issues

> b= ecome real

> <= o:p>

> ?=   Nor provides any explanations about the reasons that make

> s= ingle-level IS-IS used by TRILL less scalable that single-level IS-IS

> w= hen it is used for distributing IP reachability

> <= o:p>

> o=    It claims that some of these issues may be addressed by allowi= ng usage of

> m= ulti-level IS-IS for TRILL

> <= o:p>

> o=    It provides two specific proposals for making multi-level TRIL= L work:

> <= o:p>

> o=    One of these proposals is called "unique nicknames".= This proposal:

> <= o:p>

> ?=    Does not require any changes in the TRILL data plane

> <= o:p>

> ?=   Requires introducing some structure in the nicknames of RBridges in

> o= rder to guarantee that these names are unique within the TRILL-based

> c= ampus

> <= o:p>

> o=    The other proposal is called "aggregate nicknames". = This proposal:

> <= o:p>

> ?=   Allows RBridges in different L1 areas of the campus to share

> n= icknames

> <= o:p>

> ?=   Requires a change in the TRILL data plane: the nicknames in the

> T= RILL header of a packet will be modified by the L12 RBridges

> <= o:p>

> ?=   Allows two possible flavors (bot mentioned in the draft):=

> <= o:p>

> *=          The flavor that uses L1 ar= ea nicknames

> <= o:p>

> *=          The flavor that uses the n= icknames of all L12 RBridges connected to a

> g= iven L1 area as its name

> <= o:p>

> *=          The Standards Track Single= Nickname draft (one that I have been

> a= sked to review) provides details on the second of the above-mentioned

> f= lavors of the "Aggregate Nicknames" approach:

> <= o:p>

> o=    It also allows sharing the same nickname between RBridges in d= ifferent L1

> a= reas

> <= o:p>

> o=    It also requires the same change in the TRILL data plane<= /o:p>

> <= o:p>

> o=    It eliminates the need for allocating nicknames to L1 areas. I= nstead, each

> s= uch area is identified by the set of nicknames of all L12 RBridges

> t= hat connect to it.

> I= t took me quite some time to build this scheme, and the text in the

> d= raft was not very helpful in this.

> T= he following points contributed to "negative readability" from my= POV:

> <= o:p>

> *=          The draft positions itself= as an alternative to the Aggregate

> N= icknames approach while, from my POV, it is just provides additional

> d= etails on one of the possible flavors of this approach

> <= o:p>

> *=          The draft is intended for = the Standards Track, but it does not say that

> i= t updates the base TRILL spec (neither in the text nor in metadata)

 =

--_000_HE1PR0301MB2266B54FEB022F39BD43D1409D4F0HE1PR0301MB2266_-- From nobody Tue May 24 06:53:47 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F9712D747; Tue, 24 May 2016 06:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] 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 d8bWv6S2NvxY; Tue, 24 May 2016 06:53:41 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 E999612D7C6; Tue, 24 May 2016 06:53:38 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.182.128; From: "Susan Hares" To: "'Tomonori Takeda'" , References: <00c701d1b2a0$ad254f30$076fed90$@ndzh.com> In-Reply-To: Date: Tue, 24 May 2016 09:53:35 -0400 Message-ID: <016501d1b5c3$ab225860$01670920$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0166_01D1B5A2.24132960" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFZkbV8xMTMF+FMKLR7WGNqnq+0AQL2u+8nAWQrjXCglYvzsA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: rtg-dir@ietf.org, draft-ietf-i2rs-protocol-security-requirements.all@ietf.org, i2rs@ietf.org Subject: Re: [RTG-DIR] [i2rs] RTG-DIR QA review: draft-ietf-i2rs-protocol-security-requirements-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 13:53:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0166_01D1B5A2.24132960 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Tomonori: Thanks for noticing my error. I$B!G(Bve released version -06 the change. Sue From: Tomonori Takeda [mailto:tomonori.takeda@ntt.com] Sent: Saturday, May 21, 2016 9:51 AM To: 'Susan Hares'; rtg-ads@ietf.org Cc: rtg-dir@ietf.org; draft-ietf-i2rs-protocol-security-requirements.all@ietf.org; i2rs@ietf.org Subject: RE: [i2rs] RTG-DIR QA review: draft-ietf-i2rs-protocol-security-requirements-04.txt Hi Sue, Thanks for the update. This version looks good to me, except one editorial comment. > 4) This is just an edit, but in page.10, > "Requirements SEC-REQ-13 and SEC-REQ-14" should be > "Requirements SEC-REQ-14 and SEC-REQ-15". > > --- Thank you for the editorial comment Now, text is $B!H(BRequirements SEC-REQ-14 and SEC-REQ-16$B!I(B, but it should be $B!H(BRequirements SEC-REQ-14 and SEC-REQ-15$B!I(B. (Again, this is just an editorial comment.) Thanks, Tomonori Takeda From: Susan Hares [mailto:shares@ndzh.com] Sent: Friday, May 20, 2016 11:06 PM To: Tomonori Takeda$B!JIpEDCNE5!K(B; rtg-ads@ietf.org Cc: rtg-dir@ietf.org; draft-ietf-i2rs-protocol-security-requirements.all@ietf.org; i2rs@ietf.org Subject: RE: [i2rs] RTG-DIR QA review: draft-ietf-i2rs-protocol-security-requirements-04.txt Takeda-san: Thank you for your excellent review. My responses to your comments are below. I$B!G(Bve released a version-05 to address your comments. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Tomonori Takeda Sent: Thursday, May 19, 2016 12:39 PM To: rtg-ads@ietf.org Cc: 'rtg-dir@ietf.org'; 'draft-ietf-i2rs-protocol-security-requirements.all@ietf.org'; i2rs@ietf.org Subject: [i2rs] RTG-DIR QA review: draft-ietf-i2rs-protocol-security-requirements-04.txt Hi, I have been selected as the Routing Directorate QA reviewer for this draft. Document: draft-ietf-i2rs-protocol-security-requirements-04.txt Reviewer: Tomonori Takeda Review Date: May 20, 2016 Intended Status: Standards Track I am not following I2RS work closely, but in the spirit of QA review, this is OK in my understanding. https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa Here are my comments. I think it is very important to have documents dedicated for security for new protocols such as I2RS protocols. Overall, I think the document is well organized and clear what are security requirements for I2RS. Some specific comments. 1) The document is intended to be Standards Track. I do not think it is common for requirement drafts to be Standards Track. Sue: You are correct. This is my error. I should have changed it this morning. 2) In Section 3.1, requirements are mentioned that are set in draft-ietf-i2rs-architecture-15. Some of these requirements are not directly mentioned in draft-ietf-i2rs-architecture-15, but rather implied. For example, draft-ietf-i2rs-architecture-15 mentions identifier for I2RS client, but does not mention identifier for I2RS agent (IMO). Please note that I think requirements mentioned in Section 3.1. makes sense and valid. I am just commenting on the way of writing. Sue: You are correct that the mutual identification implies an identity for the agent. Also in Section 2 of draft-ietf-i2rs-architecture-15 mentions: role or security role: A security role specifies the scope, resources, priorities, etc. that a client or agent has. If a identity has multiple roles in the security system, the identity is permitted to perform any operations any of those roles permit. Multiple identities may use the same security role. 3) I think there is dependency on requirements mentioned in this document. Specifically, if mutual authentication (Section 3.1), secure transport (Section 3.2), and role-based security (Section 3.3) are met, confidentiality (Section 3.3) and integrity (Section 3.4) can be achieved (expect SEC-REQ-16: traceability requirement). Perhaps, it depends on in which aspects security requirements should be written (in terms of mechanisms or in terms of features). Again, I am just commenting on the way of writing. Sue: You make an excellent point: I have added to the first part section 3.0 after the first paragraph: New/ There are dependencies in some of the requirements below. For confidentiality (section 3.3) and integrity (section 3.4) to be achieved, the client-agent must have mutual authentication (section 3.1) and secure transport (section 3.2). I2RS allows the use of an insecure transport for portions of data models that clearly indicate insecure transport. If insecure transport is used, then confidentiality and integrity cannot be achieved. 4) This is just an edit, but in page.10, "Requirements SEC-REQ-13 and SEC-REQ-14" should be "Requirements SEC-REQ-14 and SEC-REQ-15". --- Thank you for the editorial comment Thanks, Tomonori Takeda _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs ------=_NextPart_000_0166_01D1B5A2.24132960 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Tomonori:

 

Thanks for noticing my error.   I=1B$B!G=1B(Bve released = version -06 the change.

 

Sue

 

From:= = Tomonori Takeda [mailto:tomonori.takeda@ntt.com]
Sent: = Saturday, May 21, 2016 9:51 AM
To: 'Susan Hares'; = rtg-ads@ietf.org
Cc: rtg-dir@ietf.org; = draft-ietf-i2rs-protocol-security-requirements.all@ietf.org; = i2rs@ietf.org
Subject: RE: [i2rs] RTG-DIR QA review: = draft-ietf-i2rs-protocol-security-requirements-04.txt

 

Hi Sue,

 

Thanks for the update.

 

This version looks good to me, except one editorial = comment.

 

> 4) This is = just an edit, but in page.10,

>    "Requirements = SEC-REQ-13 and SEC-REQ-14" should be

>    "Requirements SEC-REQ-14 and = SEC-REQ-15".

> =

> --- Thank you for the editorial comment =

 

Now, text is =1B$B!H=1B(BRequirements SEC-REQ-14 and = SEC-REQ-16=1B$B!I=1B(B, but it should be =1B$B!H=1B(BRequirements = SEC-REQ-14 and SEC-REQ-15=1B$B!I=1B(B.

(Again, this is just an editorial comment.)

 

Thanks,

Tomonori Takeda

 

From:= = Susan Hares [mailto:shares@ndzh.com] =
Sent: Friday, May 20, 2016 11:06 PM
To: Tomonori = Takeda=1B$B!JIpEDCNE5!K=1B(B; rtg-ads@ietf.org
Cc: rtg-dir@ietf.org; draft-ietf-i2rs-protocol-security-requirements.all@ietf.org; i2rs@ietf.org
Subject: RE: = [i2rs] RTG-DIR QA review: = draft-ietf-i2rs-protocol-security-requirements-04.txt

 

Takeda-san:

 

Thank = you for your excellent review.  My responses to your comments are = below.  I=1B$B!G=1B(Bve released a version-05 to address your = comments.

 

Sue

 

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

From: i2rs [mailto:i2rs-bounces@ietf.org] = On Behalf Of Tomonori Takeda

Sent: = Thursday, May 19, 2016 12:39 PM

To: rtg-ads@ietf.org

Cc: 'rtg-dir@ietf.org'; = 'draft-ietf-i2rs-protocol-security-requirements.all@ietf.org'; i2rs@ietf.org

Subject: [i2rs] RTG-DIR QA review: = draft-ietf-i2rs-protocol-security-requirements-04.txt

 

Hi,

 

I have = been selected as the Routing Directorate QA reviewer for this = draft.

 

Document: = draft-ietf-i2rs-protocol-security-requirements-04.txt

Reviewer: Tomonori Takeda

Review Date: May 20, 2016

Intended Status: Standards Track

 

I am = not following I2RS work closely, but in the spirit of QA review, this is = OK in my understanding.

https= ://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa

<= p class=3DMsoPlainText> 

Here = are my comments.

 

I = think it is very important to have documents dedicated for security for = new protocols such as I2RS protocols.

Overall, I think the document is well organized and = clear what are security requirements for I2RS.

 

Some = specific comments.

 

1) The = document is intended to be Standards Track. I do not think it is common = for requirement drafts to be Standards Track.

 

Sue: = You are correct.  This is my error. I should have changed it this = morning.

 

2) In Section 3.1, requirements are mentioned that = are set in draft-ietf-i2rs-architecture-15.

   Some of these requirements are = not directly mentioned in draft-ietf-i2rs-architecture-15, =

   but rather = implied.

 

   For example, = draft-ietf-i2rs-architecture-15 mentions identifier for I2RS = client,

   but does not = mention identifier for I2RS agent (IMO).

   Please note that I think requirements = mentioned in Section 3.1. makes sense and valid.

   I am just commenting on the way of = writing.

 

Sue: You are correct = that the mutual identification implies an identity for the agent. =

Also in Section 2 of = draft-ietf-i2rs-architecture-15 mentions:

   role or security = role:   A security role specifies the = scope,

      resources, = priorities, etc. that a client or agent has.  If = a

      identity has = multiple roles in the security system, the = identity

      is permitted to = perform any operations any of those roles = permit.

      Multiple = identities may use the same security role.

 

 

3) I = think there is dependency on requirements mentioned in this = document.

   = Specifically, if mutual authentication (Section 3.1), secure transport = (Section 3.2),

   and = role-based security (Section 3.3) are met, confidentiality (Section 3.3) = and

   integrity = (Section 3.4) can be achieved (expect SEC-REQ-16: traceability = requirement).

 

   Perhaps, it depends on in which = aspects security requirements should be written

   (in terms of mechanisms or in terms of = features). Again, I am just commenting

   on the way of = writing.

 

Sue: You make an excellent point:

I have added to the first part section 3.0 after = the first paragraph:

New/

<t>There are = dependencies in some of the requirements below.  For =

confidentiality (section 3.3) and integrity = (section 3.4) to be achieved, the

client-agent must = have mutual authentication (section 3.1) and secure transport (section = 3.2).   I2RS allows the use of an insecure transport for = portions of data models that clearly indicate insecure transport.  = If insecure transport is used, then confidentiality and integrity cannot = be achieved.

</t>

4) This is just an edit, but in page.10, =

   "Requirements SEC-REQ-13 and = SEC-REQ-14" should be

   "Requirements SEC-REQ-14 and = SEC-REQ-15".

 

--- Thank you for the editorial comment =

 

Thanks,

Tomonori Takeda

 

_______________________________________________=

i2rs mailing list

i2rs@ietf.org

https://www.ietf.org/= mailman/listinfo/i2rs

------=_NextPart_000_0166_01D1B5A2.24132960-- From nobody Tue May 24 07:51:40 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629EB12D85C; Tue, 24 May 2016 07:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.948 X-Spam-Level: X-Spam-Status: No, score=-15.948 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=-1.426, 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 P9_SLCi3lB_k; Tue, 24 May 2016 07:51:36 -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 D626F12D867; Tue, 24 May 2016 07:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27408; q=dns/txt; s=iport; t=1464101492; x=1465311092; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=QdxorxvFsFk9U7m5UJeYie3jCA1OQNzWgq2T/z7Ul+Y=; b=YSHNc1qxkx82GvyGgevYclIkQ24fEeU7V/JI4iPPu3uOyay1B7Kc3l3v HCOeQ1b1x8FNGqRwUKtmHuBAnV7Ke04WvsJdD2bUFOB5unFDvsuZdvtkq AO42NqQ+qN+wkwQ+OCIkADVxrOhABoFwDnaVg00YoZZO5+37kb7+zgDVc o=; X-Files: draft-smirnov-ospf-xaf-te-06a.txt : 17080 X-IronPort-AV: E=Sophos;i="5.26,360,1459814400"; d="txt'?scan'208";a="677344285" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 May 2016 14:51:30 +0000 Received: from as-lnx.cisco.com (ams-asmirnov-nitro5.cisco.com [10.55.206.134]) (authenticated bits=0) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4OEpTLP014912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 24 May 2016 14:51:29 GMT Message-ID: <57446A6C.6020603@cisco.com> Date: Tue, 24 May 2016 16:51:24 +0200 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: IJsbrand Wijnands , "" References: <887E0412-D057-4404-ACED-69F7B162AEC5@cisco.com> In-Reply-To: <887E0412-D057-4404-ACED-69F7B162AEC5@cisco.com> Content-Type: multipart/mixed; boundary="------------030009060800060304040704" X-Authenticated-User: asmirnov Archived-At: Cc: rtg-dir@ietf.org, draft-smirnov-ospf-xaf-te@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-smirnov-ospf-xaf-te X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 14:51:39 -0000 This is a multi-part message in MIME format. --------------030009060800060304040704 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Ice, thanks for your review comments. Please find updated text attached to this email. If changes are OK then I will publish them in a new revision. > Does this also solve the use-case for P2MP TE LSPs? > If it does, maybe its good to mention this. I do think it has > consequences as it requires an IPv4/IPv6 explicit NULL label, if you > want to share IPv4 and IPv6 traffic over the same P2MP LSP. The method described in this document can be used to compute cross-AF mapping of egress LSR for sub-LSPs of a P2MP LSP. I've added a sentence mentioning this. The document concentrates on path computation aspects specific to OSPF. Data plane considerations are not specific to OSPF, so I don't think this document is a good place to have a text about how to forward cross-AF traffic thru P2MP LSP. > Section 3. "For example, suppose the OSPFv2 instance …” > > This paragraph could benefit from a rewrite as I find it hard to > follow what the intention is. I would also advise not to use real IP > addresses as an example since the actual value does not matter. > Better to say IPv4_1, IPv4_2,.. IMO. I rewrote the paragraph. Hopefully the text is clearer now. Having in the example IP addresses from the documentation range is very explicit in showing what information is put into TLVs. So I left in the text IP addresses but reduced their number from 3 to 2. I hope this also will make the example more straightforward to follow. > The acronym “ASON” is used in this document, but it is not spelled > out what it stands for. Fixed. Anton On 05/20/2016 02:31 PM, IJsbrand Wijnands wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or 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 ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. > > Document: draft-smirnov-ospf-xaf-te > Reviewer: IJsbrand Wijnands > Review Date: 20-05-2016 > Intended Status: Standards Track > > Summary: > > This document is basically ready for publication, but has nits that should be considered prior to publication. > > Comments: > > This document is well written and the use-case is very clear and useful to solve. Does this also solve the use-case for P2MP TE LSPs? If it does, maybe its good to mention this. I do think it has consequences as it requires an IPv4/IPv6 explicit NULL label, if you want to share IPv4 and IPv6 traffic over the same P2MP LSP. > > > Major Issues: > No major issues found. > > Minor Issues: > > Section 3. > "For example, suppose the OSPFv2 instance …” > > This paragraph could benefit from a rewrite as I find it hard to follow what the intention is. I would also advise not to use real IP addresses as an example since the actual value does not matter. Better to say IPv4_1, IPv4_2,.. IMO. > > Nits: > > The acronym “ASON” is used in this document, but it is not spelled out what it stands for. > > Thx, > > Ice. > --------------030009060800060304040704 Content-Type: text/plain; charset=UTF-8; name="draft-smirnov-ospf-xaf-te-06a.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-smirnov-ospf-xaf-te-06a.txt" CgoKCk9TUEYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgQS4gU21pcm5vdgpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBLiBSZXRhbmEKVXBkYXRlczogNTc4 NiAoaWYgYXBwcm92ZWQpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4g QmFybmVzCkludGVuZGVkIHN0YXR1czogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAg ICAgICAgQ2lzY28gU3lzdGVtcywgSW5jLgpFeHBpcmVzOiBOb3ZlbWJlciAyNSwgMjAxNiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNYXkgMjQsIDIwMTYKCgpPU1BGIFJv dXRpbmcgd2l0aCBDcm9zcy1BZGRyZXNzIEZhbWlseSBNUExTIFRyYWZmaWMgRW5naW5lZXJp bmcgVHVubmVscwogICAgICAgICAgICAgICAgICAgICAgZHJhZnQtc21pcm5vdi1vc3BmLXhh Zi10ZS0wNQoKQWJzdHJhY3QKCiAgIFdoZW4gdXNpbmcgVHJhZmZpYyBFbmdpbmVlcmluZyAo VEUpIGluIGEgZHVhbC1zdGFjayBJUHY0L0lQdjYgbmV0d29yawogICB0aGUgTXVsdGlwcm90 b2NvbCBMYWJlbCBTd2l0Y2hpbmcgKE1QTFMpIFRFIExhYmVsIFN3aXRjaGVkIFBhdGhzCiAg IChMU1ApIGluZnJhc3RydWN0dXJlIG1heSBiZSBkdXBsaWNhdGVkLCBldmVuIGlmIHRoZSBk ZXN0aW5hdGlvbiBJUHY0CiAgIGFuZCBJUHY2IGFkZHJlc3NlcyBiZWxvbmcgdG8gdGhlIHNh bWUgcmVtb3RlIHJvdXRlci4gIEluIG9yZGVyIHRvCiAgIGFjaGlldmUgYW4gaW50ZWdyYXRl ZCBNUExTIFRFIExTUCBpbmZyYXN0cnVjdHVyZSwgT1NQRiByb3V0ZXMgbXVzdCBiZQogICBj b21wdXRlZCBvdmVyIE1QTFMgVEUgdHVubmVscyBjcmVhdGVkIHVzaW5nIGluZm9ybWF0aW9u IHByb3BhZ2F0ZWQgaW4KICAgYW5vdGhlciBPU1BGIGluc3RhbmNlLiAgVGhpcyBpcyBzb2x2 ZWQgYnkgYWR2ZXJ0aXNpbmcgY3Jvc3MtYWRkcmVzcwogICBmYW1pbHkgKFgtQUYpIE9TUEYg VEUgaW5mb3JtYXRpb24uCgogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhbiB1cGRhdGUg dG8gUkZDNTc4NiB0aGF0IGFsbG93cyBmb3IgdGhlIGVhc3kKICAgaWRlbnRpZmljYXRpb24g b2YgYSByb3V0ZXIncyBsb2NhbCBYLUFGIElQIGFkZHJlc3Nlcy4KClN0YXR1cyBvZiBUaGlz IE1lbW8KCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29u Zm9ybWFuY2Ugd2l0aCB0aGUKICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4K CiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVy bmV0IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVy IGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIElu dGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtCiAgIERyYWZ0 cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLgoK ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4 aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9y IG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55CiAgIHRpbWUuICBJdCBpcyBp bmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1h dGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNz LiIKCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gTm92ZW1iZXIgMjUs IDIwMTYuCgpDb3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmlnaHQgKGMpIDIwMTYgSUVURiBU cnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUKICAgZG9jdW1lbnQgYXV0 aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuCgogICBUaGlzIGRvY3VtZW50IGlzIHN1Ympl Y3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsCiAgIFByb3Zpc2lvbnMg UmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMKCgoKU21pcm5vdiwgZXQgYWwuICAgICAgICAg RXhwaXJlcyBOb3ZlbWJlciAyNSwgMjAxNiAgICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50 ZXJuZXQtRHJhZnQgICAgIE9TUEYgUm91dGluZyB3aXRoIENyb3NzLUFGIE1QTFMgVEUgICAg ICAgICAgIE1heSAyMDE2CgoKICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2Ut aW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMg ZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cwogICBjYXJlZnVsbHks IGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJl c3BlY3QKICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQg ZnJvbSB0aGlzIGRvY3VtZW50IG11c3QKICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNl bnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mCiAgIHRoZSBUcnVzdCBM ZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcwog ICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuCgpUYWJsZSBvZiBD b250ZW50cwoKICAgMS4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAyCiAgIDIuICBSZXF1aXJlbWVudHMgTGFuZ3Vh Z2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMwogICAzLiAg T3BlcmF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgIDMKICAgNC4gIEJhY2t3YXJkIENvbXBhdGliaWxpdHkgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1CiAgIDUuICBTZWN1cml0eSBDb25zaWRl cmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNgogICA2 LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgIDYKICAgNy4gIEFja25vd2xlZGdlbWVudHMgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2CiAgIDguICBSZWZlcmVuY2VzICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNgog ICAgIDguMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgIDYKICAgICA4LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3CiAgIEF1dGhvcnMnIEFkZHJl c3NlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAg NwoKMS4gIEludHJvZHVjdGlvbgoKICAgVEUgRXh0ZW5zaW9ucyB0byBPU1BGdjIgW1JGQzM2 MzBdIGFuZCB0byBPU1BGdjMgW1JGQzUzMjldIGhhdmUgYmVlbgogICBkZXNjcmliZWQgdG8g c3VwcG9ydCBpbnRyYS1hcmVhIFRFIGluIElQdjQgYW5kIElQdjYgbmV0d29ya3MsCiAgIHJl c3BlY3RpdmVseS4gIEluIGJvdGggY2FzZXMgdGhlIFRFIGRhdGFiYXNlIHByb3ZpZGVzIGEg dGlnaHQKICAgY291cGxpbmcgYmV0d2VlbiB0aGUgcm91dGVkIHByb3RvY29sIGFuZCBURSBz aWduYWxpbmcgaW5mb3JtYXRpb24gaW4KICAgaXQuICBJbiBvdGhlciB3b3JkcywgYW55IHVz ZSBvZiB0aGUgVEUgbGluayBzdGF0ZSBkYXRhYmFzZSBpcyBsaW1pdGVkCiAgIHRvIElQdjQg Zm9yIE9TUEZ2MiBbUkZDMjMyOF0gYW5kIElQdjYgZm9yIE9TUEZ2MyBbUkZDNTM0MF0uCgog ICBJbiBhIGR1YWwgc3RhY2sgbmV0d29yayBpdCBtYXkgYmUgZGVzaXJhYmxlIHRvIHNldCB1 cCBjb21tb24gTVBMUyBURQogICBMU1BzIHRvIGNhcnJ5IHRyYWZmaWMgZGVzdGluZWQgdG8g YWRkcmVzc2VzIGZyb20gZGlmZmVyZW50IGFkZHJlc3MKICAgZmFtaWxpZXMgb24gYSByb3V0 ZXIuICBUaGUgdXNlIG9mIGNvbW1vbiBMU1BzIGVhc2VzIHBvdGVudGlhbAogICBzY2FsYWJp bGl0eSBhbmQgbWFuYWdlbWVudCBjb25jZXJucyBieSBoYWx2aW5nIHRoZSBudW1iZXIgb2Yg TFNQcyBpbgogICB0aGUgbmV0d29yay4gIEJlc2lkZXMsIGl0IGFsbG93cyBvcGVyYXRvcnMg dG8gZ3JvdXAgdHJhZmZpYyBiYXNlZCBvbgogICBidXNpbmVzcyBjaGFyYWN0ZXJpc3RpY3Mg YW5kL29yIGFwcGxpY2F0aW9ucyBvciBjbGFzcyBvZiBzZXJ2aWNlLCBub3QKICAgY29uc3Ry YWluZWQgYnkgdGhlIG5ldHdvcmsgcHJvdG9jb2wgd2hpY2ggY2FycmllcyBpdC4KCiAgIEZv ciBleGFtcGxlLCBhbiBMU1AgY3JlYXRlZCBiYXNlZCBvbiBNUExTIFRFIGluZm9ybWF0aW9u IHByb3BhZ2F0ZWQKICAgYnkgT1NQRnYyIGluc3RhbmNlIGNhbiBiZSBkZWZpbmVkIHRvIGNh cnJ5IGJvdGggSVB2NCBhbmQgSVB2NgogICB0cmFmZmljLCBpbnN0ZWFkIG9mIGhhdmluZyBi b3RoIE9TUEZ2MiBhbmQgT1NQRnYzIHRvIHByb3Zpc2lvbiBhCiAgIHNlcGFyYXRlIExTUCBm b3IgZWFjaCBhZGRyZXNzIGZhbWlseS4gIEV2ZW4gaWYgaW4gc29tZSBjYXNlcyB0aGUKICAg YWRkcmVzcyBmYW1pbHktc3BlY2lmaWMgdHJhZmZpYyBpcyB0byBiZSBzZXBhcmF0ZWQsIHRo ZSBjYWxjdWxhdGlvbgogICBmcm9tIGEgY29tbW9uIGRhdGFiYXNlIG1heSBwcm92ZSBvcGVy YXRpb25hbGx5IGJlbmVmaWNpYWwuCgogICBBIHJlcXVpcmVtZW50IHdoZW4gY3JlYXRpbmcg YSBjb21tb24gTVBMUyBURSBpbmZyYXN0cnVjdHVyZSBpcyB0aGUKICAgYWJpbGl0eSB0byBy ZWxpYWJseSBtYXAgdGhlIFgtQUYgZmFtaWx5IGFkZHJlc3NlcyB0byB0aGUKCgoKU21pcm5v diwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyNSwgMjAxNiAgICAgICAgICAg ICAgIFtQYWdlIDJdCgwKSW50ZXJuZXQtRHJhZnQgICAgIE9TUEYgUm91dGluZyB3aXRoIENy b3NzLUFGIE1QTFMgVEUgICAgICAgICAgIE1heSAyMDE2CgoKICAgY29ycmVzcG9uZGluZyBh ZHZlcnRpc2luZyB0YWlsLWVuZCByb3V0ZXIuICBUaGlzIG1hcHBpbmcgaXMgYQogICBjaGFs bGVuZ2UgYmVjYXVzZSB0aGUgTFNBcyBjb250YWluaW5nIHRoZSByb3V0aW5nIGluZm9ybWF0 aW9uIGFyZQogICBjYXJyaWVkIGluIG9uZSBPU1BGIGluc3RhbmNlIHdoaWxlIHRoZSBURSBj YWxjdWxhdGlvbiBtYXkgYmUgZG9uZQogICB1c2luZyBhIFRFIGRhdGFiYXNlIGZyb20gYSBk aWZmZXJlbnQgaW5zdGFuY2UuCgogICBBIHNpbXBsZSBzb2x1dGlvbiB0byB0aGlzIHByb2Js ZW0gaXMgdG8gcmVseSBvbiB0aGUgUm91dGVyIElEIHRvCiAgIGlkZW50aWZ5IGEgbm9kZSBp biB0aGUgY29ycmVzcG9uZGluZyBPU1BGdjIgYW5kIE9TUEZ2MyBkYXRhYmFzZXMuCiAgIFRo aXMgc29sdXRpb24gd291bGQgbWFuZGF0ZSBib3RoIGluc3RhbmNlcyBvbiB0aGUgc2FtZSBy b3V0ZXIgdG8gYmUKICAgY29uZmlndXJlZCB3aXRoIHRoZSBzYW1lIFJvdXRlciBJRC4gIEhv d2V2ZXIsIHJlbHlpbmcgb24gdGhlCiAgIGNvcnJlY3RuZXNzIG9mIHRoZSBjb25maWd1cmF0 aW9uIHB1dHMgYWRkaXRpb25hbCBidXJkZW4gb24gbmV0d29yawogICBtYW5hZ2VtZW50IGFu ZCBhZGRzIGNvc3QgdG8gdGhlIG9wZXJhdGlvbiBvZiB0aGUgbmV0d29yay4gIFRoZQogICBu ZXR3b3JrIGJlY29tZXMgZXZlbiBtb3JlIGRpZmZpY3VsdCB0byBtYW5hZ2UgaWYgT1NQRnYy IGFuZCBPU1BGdjMKICAgdG9wb2xvZ2llcyBkbyBub3QgbWF0Y2ggZXhhY3RseSwgZm9yIGV4 YW1wbGUgaWYgYXJlYSBib3JkZXJzIGFyZQogICBkcmF3biBkaWZmZXJlbnRseSBpbiB0aGUg dHdvIHByb3RvY29scy4gIEFsc28sIGlmIHRoZSByb3V0aW5nCiAgIHByb2Nlc3NlcyBkbyBm YWxsIG91dCBvZiBzeW5jIChoYXZpbmcgZGlmZmVyZW50IFJvdXRlciBJRHMsIGV2ZW4gaWYK ICAgZm9yIGxvY2FsIGFkbWluaXN0cmF0aXZlIHJlYXNvbnMpLCB0aGVyZSBpcyBubyBkZWZp bmVkIHdheSBmb3Igb3RoZXIKICAgcm91dGVycyB0byBkaXNjb3ZlciBzdWNoIG1pc2FsaWdu bWVudCBhbmQgdG8gdGFrZSBhbnkgY29ycmVjdGl2ZQogICBtZWFzdXJlcyAoc3VjaCBhcyB0 byBhdm9pZCByb3V0aW5nIHRocm91Z2ggYWZmZWN0ZWQgVEUgdHVubmVscyBvcgogICBpc3N1 aW5nIHdhcm5pbmcgdG8gbmV0d29yayBtYW5hZ2VtZW50KS4gIFRoZSB1c2Ugb2YgbWlzYWxp Z25lZCByb3V0ZXIKICAgSURzIG1heSByZXN1bHQgaW4gZGVsaXZlcmluZyB0aGUgdHJhZmZp YyB0byB0aGUgd3JvbmcgdGFpbC1lbmQKICAgcm91dGVyLCB3aGljaCBjb3VsZCBsZWFkIHRv IHN1Ym9wdGltYWwgcm91dGluZyBvciBldmVuIHRyYWZmaWMgbG9vcHMuCgogICBUaGlzIGRv Y3VtZW50IGRlc2NyaWJlcyBhbiB1cGRhdGUgdG8gW1JGQzU3ODZdIHRoYXQgYWxsb3dzIGZv ciB0aGUKICAgZWFzeSBpZGVudGlmaWNhdGlvbiBvZiBhIHJvdXRlcidzIGxvY2FsIFgtQUYg SVAgYWRkcmVzc2VzLiAgUm91dGVycwogICB1c2luZyB0aGUgTm9kZSBBdHRyaWJ1dGUgVExW IFtSRkM1Nzg2XSBjYW4gaW5jbHVkZSBub24tVEUgZW5hYmxlZAogICBpbnRlcmZhY2UgYWRk cmVzc2VzIGluIHRoZWlyIE9TUEYgVEUgYWR2ZXJ0aXNlbWVudHMsIGFuZCBhbHNvIHVzZSB0 aGUKICAgc2FtZSBzdWItVExWcyB0byBjYXJyeSBYLUFGIGluZm9ybWF0aW9uLCBmYWNpbGl0 YXRpbmcgdGhlIG1hcHBpbmcKICAgbWVudGlvbmVkIGFib3ZlLgoKICAgVGhlIG1ldGhvZCBk ZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCBjYW4gYWxzbyBiZSB1c2VkIHRvIGNvbXB1dGUK ICAgWC1BRiBtYXBwaW5nIG9mIGVncmVzcyBMU1IgZm9yIHN1Yi1MU1BzIG9mIGEgUG9pbnQt dG8tTXVsdGlwb2ludCBMU1AKICAgKHNlZSBbUkZDNDQ2MV0pLiAgQ29uc2lkZXJhdGlvbnMg b2YgdXNpbmcgUG9pbnQtdG8tTXVsdGlwb2ludCBNUExTIFRFCiAgIGZvciBYLUFGIHRyYWZm aWMgZm9yd2FyZGluZyBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzCiAgIHNwZWNpZmlj YXRpb24uCgoyLiAgUmVxdWlyZW1lbnRzIExhbmd1YWdlCgogICBUaGUga2V5IHdvcmRzICJN VVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAg ICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9Q VElPTkFMIiBpbiB0aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBk ZXNjcmliZWQgaW4gW1JGQzIxMTldLgoKMy4gIE9wZXJhdGlvbgoKICAgW1JGQzU3ODZdIGRl ZmluZWQgdGhlIE5vZGUgSVB2NCBMb2NhbCBBZGRyZXNzIGFuZCBOb2RlIElQdjYgTG9jYWwK ICAgQWRkcmVzcyBzdWItVExWcyBvZiB0aGUgTm9kZSBBdHRyaWJ1dGUgVExWIGZvciBhIHJv dXRlciB0byBhZHZlcnRpc2UKICAgYWRkaXRpb25hbCBsb2NhbCBJUHY0IGFuZCBJUHY2IGFk ZHJlc3Nlcy4gIFRvIHNvbHZlIHRoZSBwcm9ibGVtCiAgIG91dGxpbmVkIGluIFtSRkM1Nzg2 XSBPU1BGdjIgd291bGQgYWR2ZXJ0aXNlIGFuZCB1c2Ugb25seSBJUHY0CiAgIGFkZHJlc3Nl cyBhbmQgT1NQRnYzIHdvdWxkIGFkdmVydGlzZSBhbmQgdXNlIG9ubHkgSVB2NiBhZGRyZXNz ZXMuCgoKClNtaXJub3YsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjUsIDIw MTYgICAgICAgICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAgICBPU1BGIFJv dXRpbmcgd2l0aCBDcm9zcy1BRiBNUExTIFRFICAgICAgICAgICBNYXkgMjAxNgoKCiAgIFRo aXMgZG9jdW1lbnQgdXBkYXRlcyBbUkZDNTc4Nl0gc28gdGhhdCBhIHJvdXRlciBjYW4gYWxz byBhbm5vdW5jZQogICBvbmUgb3IgbW9yZSBsb2NhbCBYLUFGIGFkZHJlc3NlcyB1c2luZyB0 aGUgY29ycmVzcG9uZGluZyBMb2NhbAogICBBZGRyZXNzIHN1Yi1UTFYuICBJbiBvdGhlciB3 b3JkcywgdG8gaW1wbGVtZW50IHRoZSBYLUFGIHJvdXRpbmcKICAgdGVjaG5pcXVlIHByb3Bv c2VkIGluIHRoaXMgZG9jdW1lbnQsIE9TUEZ2MiB3aWxsIGFkdmVydGlzZSB0aGUgTm9kZQog ICBJUHY2IExvY2FsIEFkZHJlc3Mgc3ViLVRMViBhbmQgT1NQRnYzIHdpbGwgYWR2ZXJ0aXNl IHRoZSBOb2RlIElQdjQKICAgTG9jYWwgQWRkcmVzcyBzdWItVExWLCBwb3NzaWJseSBpbiBh ZGRpdGlvbiB0byBhZHZlcnRpc2luZyBvdGhlciBJUAogICBhZGRyZXNzZXMgYXMgZG9jdW1l bnRlZCBieSBbUkZDNTc4Nl0uCgogICBBIG5vZGUgdGhhdCBpbXBsZW1lbnRzIFgtQUYgcm91 dGluZyBTSE9VTEQgYWR2ZXJ0aXNlIGluIHRoZQogICBjb3JyZXNwb25kaW5nIE5vZGUgTG9j YWwgQWRkcmVzcyBzdWItVExWIGFsbCBYLUFGIElQIGFkZHJlc3NlcyBsb2NhbAogICB0byB0 aGUgcm91dGVyIHRoYXQgY2FuIGJlIHVzZWQgYnkgQ29uc3RyYWluZWQgU1BGIChDU1BGKSB0 byBjYWxjdWxhdGUKICAgTVBMUyBURSBMU1BzLiAgSW4gZ2VuZXJhbCwgT1NQRiBTSE9VTEQg YWR2ZXJ0aXNlIHRoZSBJUCBhZGRyZXNzCiAgIGxpc3RlZCBpbiB0aGUgUm91dGVyIEFkZHJl c3MgVExWIG9mIHRoZSBYLUFGIGluc3RhbmNlIG1haW50YWluaW5nCiAgIE1QTFMgVEUgZGF0 YWJhc2UgcGx1cyBhbnkgYWRkaXRpb25hbCBsb2NhbCBhZGRyZXNzZXMgYWR2ZXJ0aXNlZCBi eQogICB0aGUgWC1BRiBPU1BGIGluc3RhbmNlIGluIGl0cyBOb2RlIExvY2FsIEFkZHJlc3Mg c3ViLVRMVi4KICAgSW1wbGVtZW50YXRpb24gTUFZIGFkdmVydGlzZSBvdGhlciBsb2NhbCBY LUFGIGFkZHJlc3Nlcy4KCiAgIElmIHRoZSBOb2RlIEF0dHJpYnV0ZSBUTFYgY2FycmllcyBi b3RoIHRoZSBOb2RlIElQdjQgTG9jYWwgQWRkcmVzcwogICBzdWItVExWIGFuZCB0aGUgTm9k ZSBJUHY2IExvY2FsIEFkZHJlc3Mgc3ViLVRMViwgdGhlbiB0aGUgWC1BRgogICBjb21wb25l bnQgbXVzdCBiZSBjb25zaWRlcmVkIGZvciB0aGUgY29uc29saWRhdGVkIGNhbGN1bGF0aW9u IG9mIE1QTFMKICAgVEUgTFNQcy4gIEJvdGggaW5zdGFuY2VzIG1heSBjYXJyeSB0aGUgcmVx dWlyZWQgaW5mb3JtYXRpb24sIGl0IGlzCiAgIGxlZnQgdG8gbG9jYWwgY29uZmlndXJhdGlv biB0byBkZXRlcm1pbmUgd2hpY2ggZGF0YWJhc2UgaXMgdXNlZC4KCiAgIE9uIEFyZWEgQm9y ZGVyIFJvdXRlcnMgKEFCUiksIGVhY2ggYWR2ZXJ0aXNlZCBYLUFGIElQIGFkZHJlc3MgTVVT VCBiZQogICBhZHZlcnRpc2VkIGludG8gYXQgbW9zdCBvbmUgYXJlYS4gIElmIE9TUEZ2MiBh bmQgT1NQRnYzIGFyZWEgYm9yZGVycwogICBtYXRjaCAoaS5lLiBmb3IgZWFjaCBpbnRlcmZh Y2UgYXJlYSBudW1iZXIgZm9yIE9TUEZ2MiBhbmQgT1NQRnYzCiAgIGluc3RhbmNlcyBpcyBu dW1lcmljYWxseSBlcXVhbCksIHRoZW4gdGhlIFgtQUYgYWRkcmVzc2VzIE1VU1QgYmUKICAg YWR2ZXJ0aXNlZCBpbnRvIHRoZSBzYW1lIGFyZWEgaW4gYm90aCBpbnN0YW5jZXMuICBUaGlz IGFsbG93cyBvdGhlcgogICBBQlJzIGNvbm5lY3RlZCB0byB0aGUgc2FtZSBzZXQgb2YgYXJl YXMgdG8ga25vdyB3aXRoIHdoaWNoIGFyZWEgdG8KICAgYXNzb2NpYXRlIE1QTFMgVEUgdHVu bmVscy4KCiAgIER1cmluZyB0aGUgWC1BRiByb3V0aW5nIGNhbGN1bGF0aW9uLCBYLUFGIElQ IGFkZHJlc3NlcyBhcmUgdXNlZCB0bwogICBtYXAgbG9jYWxseSBjcmVhdGVkIExTUHMgdG8g dGFpbC1lbmQgcm91dGVycyBpbiB0aGUgTFNEQi4gIFRoZQogICBtYXBwaW5nIGFsZ29yaXRo bSBjYW4gYmUgZGVzY3JpYmVkIGFzOgoKICAgICAgV2FsayB0aGUgbGlzdCBvZiBhbGwgTVBM UyBURSB0dW5uZWxzIGZvciB3aGljaCB0aGUgY29tcHV0aW5nCiAgICAgIHJvdXRlciBpcyBh IGhlYWQtZW5kLiAgRm9yIGVhY2ggTVBMUyBURSB0dW5uZWwgVDoKCiAgIDEuICBJZiBUJ3Mg ZGVzdGluYXRpb24gSVAgYWRkcmVzcyBpcyBmcm9tIHRoZSBzYW1lIGFkZHJlc3MgZmFtaWx5 IGFzCiAgICAgICB0aGUgY29tcHV0aW5nIE9TUEYgaW5zdGFuY2UsIHRoZW4gdGhlIHR1bm5l bCBtdXN0IGhhdmUgYmVlbgogICAgICAgc2lnbmFsZWQgYmFzZWQgb24gTVBMUyBURSBpbmZv cm1hdGlvbiBwcm9wYWdhdGVkIGluIHRoZSBzYW1lIE9TUEYKICAgICAgIGluc3RhbmNlLiAg UHJvY2VzcyB0aGUgdHVubmVsIGFzIHBlciBbUkZDMzYzMF0gb3IgW1JGQzUzMjldLgoKICAg Mi4gIE90aGVyd2lzZSBpdCBpcyBhIFgtQUYgTVBMUyBURSB0dW5uZWwuICBOb3RlIHR1bm5l bCdzIGRlc3RpbmF0aW9uCiAgICAgICBJUCBhZGRyZXNzLgoKICAgMy4gIFdhbGsgdGhlIFgt QUYgSVAgYWRkcmVzc2VzIGluIHRoZSBMU0RCcyBvZiBhbGwgY29ubmVjdGVkIGFyZWFzLgog ICAgICAgSWYgYSBtYXRjaGluZyBJUCBhZGRyZXNzIGlzIGZvdW5kLCBhZHZlcnRpc2VkIGJ5 IHJvdXRlciBSIGluIGFyZWEKCgoKU21pcm5vdiwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBO b3ZlbWJlciAyNSwgMjAxNiAgICAgICAgICAgICAgIFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJh ZnQgICAgIE9TUEYgUm91dGluZyB3aXRoIENyb3NzLUFGIE1QTFMgVEUgICAgICAgICAgIE1h eSAyMDE2CgoKICAgICAgIEEsIHRoZW4gbWFyayB0aGUgdHVubmVsIFQgYXMgYmVsb25naW5n IHRvIGFyZWEgQSBhbmQgdGVybWluYXRpbmcKICAgICAgIG9uIHRhaWwtZW5kIHJvdXRlciBS LiAgQXNzaWduIGFuIGludHJhLWFyZWEgU1BGIGNvc3QgdG8gcmVhY2gKICAgICAgIHJvdXRl ciBSIHdpdGhpbiBhcmVhIEEgYXMgdGhlIElHUCBjb3N0IG9mIHR1bm5lbCBULgoKICAgQWZ0 ZXIgY29tcGxldGluZyB0aGlzIGNhbGN1bGF0aW9uLCBlYWNoIFRFIHR1bm5lbCBpcyBhc3Nv Y2lhdGVkIHdpdGgKICAgYW4gYXJlYSBhbmQgdGFpbC1lbmQgcm91dGVyIGluIHRlcm1zIG9m IHRoZSByb3V0aW5nIExTREIgb2YgdGhlCiAgIGNvbXB1dGluZyBPU1BGIGluc3RhbmNlIGFu ZCBoYXMgYSBtZXRyaWMuCgogICBOb3RlIHRoYXQgZm9yIGNsYXJpdHkgb2YgZGVzY3JpcHRp b24gdGhlIG1hcHBpbmcgYWxnb3JpdGhtIGlzCiAgIHNwZWNpZmllZCBhcyBhIHNpbmdsZSBj YWxjdWxhdGlvbi4gIEFjdHVhbCBpbXBsZW1lbnRhdGlvbnMgZm9yIHRoZQogICBlZmZpY2ll bmN5IG1heSBjaG9vc2UgdG8gc3VwcG9ydCBlcXVpdmFsZW50IG1hcHBpbmcgZnVuY3Rpb25h bGl0eQogICB3aXRob3V0IGltcGxlbWVudGluZyB0aGUgYWxnb3JpdGhtIGV4YWN0bHkgYXMg aXQgaXMgZGVzY3JpYmVkLgoKICAgQXMgYW4gZXhhbXBsZSBsZXRzIGNvbnNpZGVyIGEgcm91 dGVyIGluIGR1YWwtc3RhY2sgbmV0d29yayBydW5uaW5nCiAgIE9TUEZ2MiBhbmQgT1NQRnYz IGZvciBJUHY0IGFuZCBJUHY2IHJvdXRpbmcgY29ycmVzcG9uZGluZ2x5LiAgU3VwcG9zZQog ICBPU1BGdjIgaW5zdGFuY2UgaXMgdXNlZCB0byBwcm9wYWdhdGUgTVBMUyBURSBpbmZvcm1h dGlvbiBhbmQgdGhlCiAgIHJvdXRlciBpcyBjb25maWd1cmVkIHRvIGFjY2VwdCBURSBMU1Bz IHRlcm1pbmF0aW5nIGF0IGxvY2FsIGFkZHJlc3NlcwogICAxOTguNTEuMTAwLjEgYW5kIDE5 OC41MS4xMDAuMi4gIFRoZW4gdGhlIHJvdXRlciB3aWxsIGFkdmVydGlzZSBpbnRvCiAgIE9T UEZ2MiBpbnN0YW5jZSBJUHY0IGFkZHJlc3MgMTk4LjUxLjEwMC4xIGluIHRoZSBSb3V0ZXIg QWRkcmVzcyBUTFYsCiAgIGFkZGl0aW9uYWwgbG9jYWwgSVB2NCBhZGRyZXNzIDE5OC41MS4x MDAuMiBpbiB0aGUgTm9kZSBJUHY0IExvY2FsCiAgIEFkZHJlc3Mgc3ViLVRMViwgcGx1cyBv dGhlciBUcmFmZmljIEVuZ2luZWVyaW5nIFRMVnMgYXMgcmVxdWlyZWQgYnkKICAgW1JGQzM2 MzBdLiAgSWYgT1NQRnYzIGluc3RhbmNlIGluIHRoZSBuZXR3b3JrIGlzIGVuYWJsZWQgZm9y IFgtQUYgVEUKICAgcm91dGluZyAodGhhdCBpcywgdG8gdXNlIGZvciBJUHY2IHJvdXRpbmcg TVBMUyBURSBMU1BzIGNvbXB1dGVkIGJ5CiAgIE9TUEZ2MiksIHRoZW4gdGhlIE9TUEZ2MyBp bnN0YW5jZSBvZiB0aGUgcm91dGVyIHdpbGwgYWR2ZXJ0aXNlIHRoZQogICBOb2RlIElQdjQg TG9jYWwgQWRkcmVzcyBzdWItVExWIGxpc3RpbmcgbG9jYWwgSVB2NCBhZGRyZXNzZXMKICAg MTk4LjUxLjEwMC4xIGFuZCAxOTguNTEuMTAwLjIuICBPdGhlciByb3V0ZXJzIGluIHRoZSBP U1BGdjMgbmV0d29yawogICB3aWxsIHVzZSB0aGlzIGluZm9ybWF0aW9uIHRvIHJlbGlhYmx5 IGlkZW50aWZ5IHRoaXMgcm91dGVyIGFzIGVncmVzcwogICBMU1IgZm9yIE1QTFMgVEUgTFNQ cyB0ZXJtaW5hdGluZyBhdCBlaXRoZXIgMTk4LjUxLjEwMC4xIG9yCiAgIDE5OC41MS4xMDAu Mi4KCjQuICBCYWNrd2FyZCBDb21wYXRpYmlsaXR5CgogICBOb2RlIEF0dHJpYnV0ZSBUTFYg YW5kIE5vZGUgTG9jYWwgQWRkcmVzcyBzdWItVExWcyBhbmQgdGhlaXIgdXNhZ2UKICAgYXJl IGRlZmluZWQgaW4gW1JGQzU3ODZdIGFuZCB1cGRhdGVkIGJ5IFtSRkM2ODI3XS4gIFdheSBv ZiB1c2luZwogICB0aGVzZSBUTFZzIGFzIHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50IGlz IGZ1bGx5IGJhY2t3YXJkIGNvbXBhdGlibGUKICAgd2l0aCBwcmV2aW91cyBzdGFuZGFyZCBk b2N1bWVudHMuCgogICBBbiBpbXBsZW1lbnRhdGlvbiBwcm9jZXNzaW5nIE5vZGUgQXR0cmli dXRlIFRMViBNVVNUIGludGVycHJldCBpdHMKICAgY29udGVudCBhcyBmb2xsb3dzOgoKICAg byAgSWYgdGhlIE5vZGUgQXR0cmlidXRlIFRMViBjb250YWlucyBMb2NhbCBURSBSb3V0ZXIg SUQgc3ViLVRMViB0aGVuCiAgICAgIHRoaXMgTm9kZSBBdHRyaWJ1dGUgVExWIE1VU1QgYmUg dHJlYXRlZCBhcyBjYXJyeWluZyByb3V0aW5nCiAgICAgIGluZm9ybWF0aW9uIGZvciBBU09O IChBdXRvbWF0aWNhbGx5IFN3aXRjaGVkIE9wdGljYWwgTmV0d29yaykgYW5kCiAgICAgIHBy b2Nlc3NlZCBhcyBzcGVjaWZpZWQgaW4gW1JGQzY4MjddLgoKICAgbyAgT3RoZXJ3aXNlIE5v ZGUgQXR0cmlidXRlIFRMViBjb250YWlucyBvbmUgb3IgbW9yZSBpbnN0YW5jZShzKSBvZgog ICAgICBOb2RlIElQdjQgTG9jYWwgQWRkcmVzcyBhbmQvb3IgTm9kZSBJUHY2IExvY2FsIEFk ZHJlc3Mgc3ViLVRMVnMuCgoKCgpTbWlybm92LCBldCBhbC4gICAgICAgICBFeHBpcmVzIE5v dmVtYmVyIDI1LCAyMDE2ICAgICAgICAgICAgICAgW1BhZ2UgNV0KDApJbnRlcm5ldC1EcmFm dCAgICAgT1NQRiBSb3V0aW5nIHdpdGggQ3Jvc3MtQUYgTVBMUyBURSAgICAgICAgICAgTWF5 IDIwMTYKCgogICAgICBNZWFuaW5nIG9mIGVhY2ggTG9jYWwgQWRkcmVzcyBzdWItVExWIGhh cyB0byBiZSBpZGVudGlmaWVkCiAgICAgIHNlcGFyYXRlbHkuCgogICAgICAqICBJZiBOb2Rl IExvY2FsIEFkZHJlc3Mgc3ViLVRMViBiZWxvbmdzIHRvIHRoZSBzYW1lIGFkZHJlc3MKICAg ICAgICAgZmFtaWx5IGFzIGluc3RhbmNlIG9mIE9TUEYgcHJvdG9jb2wgYWR2ZXJ0aXNpbmcg aXQgdGhlbiBhZGRyZXNzCiAgICAgICAgIGNhcnJpZWQgaW4gdGhlIHN1Yi1UTFYgTVVTVCBi ZSB0cmVhdGVkIGFzIGRlc2NyaWJlZCBpbgogICAgICAgICBbUkZDNTc4Nl0uCgogICAgICAq ICBPdGhlcndpc2UgdGhlIGFkZHJlc3MgaXMgdXNlZCBmb3IgWC1BRiB0dW5uZWwgdGFpbC1l bmQgbWFwcGluZwogICAgICAgICBhcyBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1lbnQuCgo1LiAg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIFRoaXMgZG9jdW1lbnQgaW50cm9kdWNlcyBu byBuZXcgc2VjdXJpdHkgY29uY2VybnMuICBTZWN1cml0eQogICBjb25zaWRlcmF0aW9ucyBv ZiB1c2luZyBOb2RlIEF0dHJpYnV0ZSBUTFYgYXJlIGRpc2N1c3NlZCBpbgogICBbUkZDNTc4 Nl0uCgo2LiAgSUFOQSBDb25zaWRlcmF0aW9ucwoKICAgVGhpcyBkb2N1bWVudCBoYXMgbm8g SUFOQSBhY3Rpb25zLgoKNy4gIEFja25vd2xlZGdlbWVudHMKCiAgIFRoZSBhdXRob3JzIHdv dWxkIGxpa2UgdG8gdGhhbmsgUGV0ZXIgUHNlbmFrIGFuZCBFcmljIE9zYm9ybmUgZm9yCiAg IGVhcmx5IGRpc2N1c3Npb25zIGFuZCBBY2VlIExpbmRlbSBmb3IgZGlzY3Vzc2luZyBjb21w YXRpYmlsaXR5IHdpdGgKICAgQVNPTiBleHRlbnNpb25zLgoKICAgV2Ugd291bGQgYWxzbyBs aWtlIHRvIHRoYW5rIHRoZSBhdXRob3JzIG9mIFJGQzU3ODYgZm9yIGxheWluZyBkb3duCiAg IHRoZSBmb3VuZGF0aW9uIGZvciB0aGlzIHdvcmsuCgo4LiAgUmVmZXJlbmNlcwoKOC4xLiAg Tm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkg d29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlCiAgICAgICAgICAgICAgUmVxdWly ZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwKICAgICAgICAgICAgICBET0kgMTAu MTc0ODcvUkZDMjExOSwgTWFyY2ggMTk5NywKICAgICAgICAgICAgICA8aHR0cDovL3d3dy5y ZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzIxMTk+LgoKICAgW1JGQzU3ODZdICBBZ2dhcndhbCwg Ui4gYW5kIEsuIEtvbXBlbGxhLCAiQWR2ZXJ0aXNpbmcgYSBSb3V0ZXIncwogICAgICAgICAg ICAgIExvY2FsIEFkZHJlc3NlcyBpbiBPU1BGIFRyYWZmaWMgRW5naW5lZXJpbmcgKFRFKQog ICAgICAgICAgICAgIEV4dGVuc2lvbnMiLCBSRkMgNTc4NiwgRE9JIDEwLjE3NDg3L1JGQzU3 ODYsIE1hcmNoIDIwMTAsCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5v cmcvaW5mby9yZmM1Nzg2Pi4KCgoKCgoKCgpTbWlybm92LCBldCBhbC4gICAgICAgICBFeHBp cmVzIE5vdmVtYmVyIDI1LCAyMDE2ICAgICAgICAgICAgICAgW1BhZ2UgNl0KDApJbnRlcm5l dC1EcmFmdCAgICAgT1NQRiBSb3V0aW5nIHdpdGggQ3Jvc3MtQUYgTVBMUyBURSAgICAgICAg ICAgTWF5IDIwMTYKCgo4LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbUkZDMjMy OF0gIE1veSwgSi4sICJPU1BGIFZlcnNpb24gMiIsIFNURCA1NCwgUkZDIDIzMjgsCiAgICAg ICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzIzMjgsIEFwcmlsIDE5OTgsCiAgICAgICAgICAg ICAgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmMyMzI4Pi4KCiAgIFtSRkMz NjMwXSAgS2F0eiwgRC4sIEtvbXBlbGxhLCBLLiwgYW5kIEQuIFlldW5nLCAiVHJhZmZpYyBF bmdpbmVlcmluZwogICAgICAgICAgICAgIChURSkgRXh0ZW5zaW9ucyB0byBPU1BGIFZlcnNp b24gMiIsIFJGQyAzNjMwLAogICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkMzNjMwLCBT ZXB0ZW1iZXIgMjAwMywKICAgICAgICAgICAgICA8aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9y Zy9pbmZvL3JmYzM2MzA+LgoKICAgW1JGQzQ0NjFdICBZYXN1a2F3YSwgUy4sIEVkLiwgIlNp Z25hbGluZyBSZXF1aXJlbWVudHMgZm9yIFBvaW50LXRvLQogICAgICAgICAgICAgIE11bHRp cG9pbnQgVHJhZmZpYy1FbmdpbmVlcmVkIE1QTFMgTGFiZWwgU3dpdGNoZWQgUGF0aHMKICAg ICAgICAgICAgICAoTFNQcykiLCBSRkMgNDQ2MSwgRE9JIDEwLjE3NDg3L1JGQzQ0NjEsIEFw cmlsIDIwMDYsCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5m by9yZmM0NDYxPi4KCiAgIFtSRkM1MzI5XSAgSXNoaWd1cm8sIEsuLCBNYW5yYWwsIFYuLCBE YXZleSwgQS4sIGFuZCBBLiBMaW5kZW0sIEVkLiwKICAgICAgICAgICAgICAiVHJhZmZpYyBF bmdpbmVlcmluZyBFeHRlbnNpb25zIHRvIE9TUEYgVmVyc2lvbiAzIiwKICAgICAgICAgICAg ICBSRkMgNTMyOSwgRE9JIDEwLjE3NDg3L1JGQzUzMjksIFNlcHRlbWJlciAyMDA4LAogICAg ICAgICAgICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNTMyOT4uCgog ICBbUkZDNTM0MF0gIENvbHR1biwgUi4sIEZlcmd1c29uLCBELiwgTW95LCBKLiwgYW5kIEEu IExpbmRlbSwgIk9TUEYKICAgICAgICAgICAgICBmb3IgSVB2NiIsIFJGQyA1MzQwLCBET0kg MTAuMTc0ODcvUkZDNTM0MCwgSnVseSAyMDA4LAogICAgICAgICAgICAgIDxodHRwOi8vd3d3 LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNTM0MD4uCgogICBbUkZDNjgyN10gIE1hbGlzLCBB LiwgRWQuLCBMaW5kZW0sIEEuLCBFZC4sIGFuZCBELiBQYXBhZGltaXRyaW91LAogICAgICAg ICAgICAgIEVkLiwgIkF1dG9tYXRpY2FsbHkgU3dpdGNoZWQgT3B0aWNhbCBOZXR3b3JrIChB U09OKQogICAgICAgICAgICAgIFJvdXRpbmcgZm9yIE9TUEZ2MiBQcm90b2NvbHMiLCBSRkMg NjgyNywKICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDNjgyNywgSmFudWFyeSAyMDEz LAogICAgICAgICAgICAgIDxodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNjgy Nz4uCgpBdXRob3JzJyBBZGRyZXNzZXMKCiAgIEFudG9uIFNtaXJub3YKICAgQ2lzY28gU3lz dGVtcywgSW5jLgogICBEZSBrbGVldGxhYW4gNmEKICAgRGllZ2VtICAxODMxCiAgIEJlbGdp dW0KCiAgIEVtYWlsOiBhc0BjaXNjby5jb20KCgoKCgoKCgoKCgpTbWlybm92LCBldCBhbC4g ICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDI1LCAyMDE2ICAgICAgICAgICAgICAgW1BhZ2Ug N10KDApJbnRlcm5ldC1EcmFmdCAgICAgT1NQRiBSb3V0aW5nIHdpdGggQ3Jvc3MtQUYgTVBM UyBURSAgICAgICAgICAgTWF5IDIwMTYKCgogICBBbHZhcm8gUmV0YW5hCiAgIENpc2NvIFN5 c3RlbXMsIEluYy4KICAgNzAyNSBLaXQgQ3JlZWsgUmQuCiAgIFJlc2VhcmNoIFRyaWFuZ2xl IFBhcmssIE5DICAyNzcwOQogICBVU0EKCiAgIEVtYWlsOiBhcmV0YW5hQGNpc2NvLmNvbQoK CiAgIE1pY2hhZWwgQmFybmVzCiAgIENpc2NvIFN5c3RlbXMsIEluYy4KICAgNTEwIE1jQ2Fy dGh5IEJsdmQuCiAgIE1pbHBpdGFzLCBDQSAgOTUwMzUKICAgVVNBCgogICBFbWFpbDogbWpi YXJuZXNAY2lzY28uY29tCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKU21p cm5vdiwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyNSwgMjAxNiAgICAgICAg ICAgICAgIFtQYWdlIDhdCg== --------------030009060800060304040704-- From nobody Wed May 25 01:08:37 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8761A12D0B9; Wed, 25 May 2016 01:08:36 -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, 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 T3QWe3ZKsMze; Wed, 25 May 2016 01:08:34 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AE1912B05A; Wed, 25 May 2016 01:08:33 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-be-57455d7f0ca5 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 48.3B.18043.F7D55475; Wed, 25 May 2016 10:08:31 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.74]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0294.000; Wed, 25 May 2016 10:08:30 +0200 From: Daniele Ceccarelli To: Mach Chen , " (rtg-ads@ietf.org)" Thread-Topic: RtgDir review: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06 Thread-Index: AdGe+Z/lFOzQc8O7SFSbqLe7ce8oewAG1OFwA2v05+AAAARS8AJlk/Fw Date: Wed, 25 May 2016 08:08:29 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48162EBD1D@ESESSMB301.ericsson.se> References: In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM2K7gW59rGu4wYapwhZzpyxgsriwVthi zb91TBYn5/xgtliw5im7A6tHy5G3rB5Llvxk8vhy+TNbAHMUl01Kak5mWWqRvl0CV8a6P6uY Cq7FVBzYf465gXFJVBcjJ4eEgInEjNWf2SFsMYkL99azdTFycQgJHGGUOLJ9HiNIQkhgMaPE tw+CXYwcHGwCVhJPDvmAhEUEkiTmzV0O1ssscJ5RYslscxBbWMBDYv79E6wQNZ4SR9ZPZ4Sw 3SRWzV8MVs8ioCqx9eVEJhCbV8BX4ujbrewQexcyStz+thOsgVMgTKJ/53w2EJtRQFZiwu5F jBDLxCVuPZnPBHG0gMSSPeeZIWxRiZeP/7FC2IoSV6cvZwK5mVlAU2L9Ln2IVkWJKd0P2SH2 CkqcnPmEZQKj2CwkU2chdMxC0jELSccCRpZVjKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIER dnDLb6sdjAefOx5iFOBgVOLhfXDOJVyINbGsuDL3EKMEB7OSCO++ENdwId6UxMqq1KL8+KLS nNTiQ4zSHCxK4rz+LxXDhQTSE0tSs1NTC1KLYLJMHJxSDYytpd2WaWYtmtNV9bka7qy7pBQu +bbGwH7XqgzRiI9cRRukpyy3dFAxn9i9NeTHKX/l711nNm3ZyHft7v//i39O+HdmanZCdIFh v9TJM8/VP0ko3LWY+Xi+79UUk/jdlc2nn9+u2nPTkDVj4neripfyURr3W7Ou9PH/OLVhv38e 01/PZdtKAvKVWIozEg21mIuKEwFStCcwrAIAAA== Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-pals-mpls-tp-pw-over-bidir-lsp.all@tools.ietf.org" , "pals@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 08:08:36 -0000 SGkgTWFjaCwNCg0KVGhhbmtzIGZvciB0aGUgdXBkYXRlLiANClRoZXJlIGlzIGp1c3Qgb25lIG91 dHN0YW5kaW5nIHBvaW50Og0KDQo+IOKAoiBTZWN0aW9uIDIuMTog4oCcTERQIExhYmVsIE1hcHBp bmcgbWVzc2FnZeKAnSBtaXNzaW5nIHJlZmVyZW5jZS4gQW5kIHdoeSANCj4gdGhlIFR5cGUgZmll bGQgc3RhcnRzIHdpdGggMSBhbmQgMD8NCg0KVGhhbmtzIGZvciBhZGRpbmcgdGhlIHJlZmVyZW5j ZSBidXQgSSBzdGlsbCBkb24ndCBnZXQgd2h5IHRoZSBUeXBlIGZpZWxkIHN0YXJ0cyB3aXRoIDEg YW5kIDAuIA0KT25lIG1vcmUgY29tbWVudCB0aGF0IEkgbG9zdCBkdXJpbmcgdGhlIGZpcnN0IGl0 ZXJhdGlvbjogd2h5IGRvIHlvdSBkZWZpbmUgdGhlICJmbGFnIiBmaWVsZCBpbiBmaWd1cmUgMyBh bmQgdGhlbiBiZWxvdyBoYXZlIGEgZnVydGhlciBmaWd1cmUgc2hvd2luZyBDLCBTLCBUIGFuZCB0 aGUgbXVzdCBiZSB6ZXJvIGZpZWxkPyBJJ2QgZGlyZWN0bHkgcHV0IHRoZSBDLFMsVCBhbmQgbXVz dCBiZSB6ZXJvIGZpZWxkcyBpbiBwbGFjZSBvZiB0aGUgRmxhZyBmaWVsZCBpbiBmaWd1cmUgMy4g SXQgaGVscHMgd2l0aCByZWFkYWJpbGl0eSBJTUhPLg0KDQoNCkJSDQpEYW5pZWxlDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFjaCBDaGVuIFttYWlsdG86bWFjaC5j aGVuQGh1YXdlaS5jb21dDQo+IFNlbnQ6IHZlbmVyZMOsIDEzIG1hZ2dpbyAyMDE2IDA5OjI1DQo+ IFRvOiBEYW5pZWxlIENlY2NhcmVsbGkgPGRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb20+ OyA8cnRnLWFkc0BpZXRmLm9yZz4NCj4gKHJ0Zy1hZHNAaWV0Zi5vcmcpIDxydGctYWRzQGlldGYu b3JnPg0KPiBDYzogcnRnLWRpckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtcHct b3Zlci1iaWRpci0NCj4gbHNwLmFsbEB0b29scy5pZXRmLm9yZzsgcGFsc0BpZXRmLm9yZw0KPiBT dWJqZWN0OiBSRTogUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtcHctb3Zl ci1iaWRpci1sc3AtMDYNCj4gDQo+IEhpIERhbmllbGUsDQo+IA0KPiBUaGFua3MgZm9yIHRoZSBk ZXRhaWxlZCByZXZpZXcgYW5kIHZhbHVhYmxlIGNvbW1lbnRzIQ0KPiANCj4gUGxlYXNlIHNlZSBt eSByZXNwb25zZXMgaW5saW5lLi4uDQo+IA0KPiBJIGFsc28gYXR0YWNoZWQgYSBkaWZmIHRoYXQg c2hvd3MgdGhlIHVwZGF0ZXMgdGhhdCB0cnkgdG8gYWRkcmVzcyB5b3VyDQo+IGNvbW1lbnRzLiBJ ZiB5b3UgYXJlIE9LIHdpdGggdGhlIHVwZGF0ZXMsIEkgd2lsbCBzdWJtaXQgaXQgdGhlbi4NCj4g DQo+IFRoYW5rcywNCj4gTWFjaA0KPiANCj4gPiBGcm9tOiBEYW5pZWxlIENlY2NhcmVsbGkNCj4g PiBTZW50OiBsdW5lZMOsIDI1IGFwcmlsZSAyMDE2IDE5OjA0DQo+ID4gVG86IDxydGctYWRzQGll dGYub3JnPiAocnRnLWFkc0BpZXRmLm9yZykNCj4gPiBDYzogJ3J0Zy1kaXJAaWV0Zi5vcmcnOyAn ZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtcHctb3Zlci1iaWRpci1sc3AuYWxsQGlldGYub3JnJw0K PiA+IFN1YmplY3Q6IFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtcGFscy1tcGxzLXRwLXB3LW92 ZXItYmlkaXItbHNwLTA2DQo+ID4NCj4gPiBIZWxsbywNCj4gPiBJIGhhdmUgYmVlbiBzZWxlY3Rl ZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhpcw0KPiA+IGRyYWZ0 LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3IN Cj4gPiByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkgcGFzcyB0aHJvdWdoIElFVEYgbGFz dCBjYWxsIGFuZCBJRVNHIHJldmlldywNCj4gYW5kIHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVl c3QuDQo+ID4gVGhlIHB1cnBvc2Ugb2YgdGhlIHJldmlldyBpcyB0byBwcm92aWRlIGFzc2lzdGFu Y2UgdG8gdGhlIFJvdXRpbmcgQURzLg0KPiA+IEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRo ZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlDQo+ID4gaHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0Rpcg0KPiA+IEFsdGhvdWdoIHRoZXNlIGNv bW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURzLA0KPiA+ IGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0 aCBhbnkgb3RoZXINCj4gPiBJRVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZl LCBhbmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbQ0KPiA+IHRocm91Z2ggZGlzY3Vzc2lvbiBvciBi eSB1cGRhdGluZyB0aGUgZHJhZnQuDQo+ID4gRG9jdW1lbnQ6wqBkcmFmdC1pZXRmLXBhbHMtbXBs cy10cC1wdy1vdmVyLWJpZGlyLWxzcC0wNg0KPiA+IFJldmlld2VyOiBEYW5pZWxlIENlY2NhcmVs bGkNCj4gPiBSZXZpZXcgRGF0ZTogQXByaWwgMjUgMjAxNg0KPiA+IElFVEYgTEMgRW5kIERhdGU6 IC0NCj4gPiBJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkIFRyYWNrDQo+ID4gU3VtbWFyeToNCj4g PiDigKIgSSBoYXZlIHNvbWUgbWlub3IgY29uY2VybnMgYWJvdXQgdGhpcyBkb2N1bWVudCB0aGF0 IEkgdGhpbmsgc2hvdWxkDQo+ID4gYmUgcmVzb2x2ZWQgYmVmb3JlIHB1YmxpY2F0aW9uLg0KPiA+ IENvbW1lbnRzOg0KPiA+IOKAoiBXaGF0IHRoZSBkcmFmdHMgaXMgcHJvcG9zaW5nIGFzIHByb3Rv Y29sIG1vZGlmaWNhdGlvbiBpcyBjbGVhciBhbmQNCj4gPiBhbHNvIHRoZSBvcGVyYXRpb24gc2Vj dGlvbiBhcmUgcHJldHR5IHN0cmFpZ2hmb3J3YXJkLiBXaGF0IG5lZWRzIHRvIGJlDQo+ID4gaW1w cm92ZWQgaXMgdGhlIGludHJvZHVjdGlvbiBwYXJ0LCB3aGljaCBzaG91bGQgYmUgcmV2aWV3ZWQg YnkgYQ0KPiA+IG5hdGl2ZSBFbmdsaXNoIHNwZWFrZXIuIEFsc28gdGhlIElBTkEgc2VjdGlvbiBz aG91bGQgYmUgbWFkZSBjbGVhcmVyLg0KPiANCj4gVGhhbmtzIGZvciB5b3VyIHN1Z2dlc3Rpb24s IEkgYXNzdW1lIHRoZSBSRkMgZWRpdG9yIHdpbGwgZG8gYW5vdGhlciByZXZpZXcNCj4gb25jZSB0 aGUgZG9jdW1lbnQgcHJvZ3Jlc3NlZCB0byB0aGF0IHN0YWdlLg0KPiANCj4gPiBNYWpvciBJc3N1 ZXM6DQo+ID4g4oCiIE5vIG1ham9yIGlzc3VlcyBmb3VuZA0KPiA+IE1pbm9yIElzc3VlczoNCj4g PiDigKIgQWJzdHJhY3Q6IOKAnEluIGFkZGl0aW9uLCB0aGUgdXNlciB0cmFmZmljIG1heSB0cmF2 ZXJzZSB0aHJvdWdoDQo+ID4gbXVsdGlwbGUgdHJhbnNwb3J0IG5ldHdvcmtzLuKAnSBNYXliZSBp cyB3b3J0aCBlbGFib3JhdGluZyBhIGJpdCB0aGlzDQo+ID4gc2VudGVuY2Ugc2F5aW5nIHRoYXQg dGhlIGV4dGVuc2lvbnMgZGVmaW5lZCBpbiB0aGlzIGRyYWZ0IGFwcGx5IGJvdGggdG8gU1MtDQo+ IFBXIGFuZCBNUy1QVy4NCj4gDQo+IEhvdyBhYm91dCB0aGlzOg0KPiANCj4gIk1hbnkgdHJhbnNw b3J0IHNlcnZpY2VzIHJlcXVpcmUgdGhhdCB1c2VyIHRyYWZmaWMsIGluIHRoZSBmb3JtIG9mDQo+ IFBzZXVkb3dpcmVzIChQVyksIGJlIGRlbGl2ZXJlZCBvbiBhIHNpbmdsZSBjby1yb3V0ZWQgYmlk aXJlY3Rpb25hbCB0dW5uZWwgb3INCj4gdHdvIHR1bm5lbHMgdGhhdCBzaGFyZSB0aGUgc2FtZSBy b3V0ZXMuIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhbiBvcHRpb25hbA0KPiBleHRlbnNpb24gdG8g TERQIHRoYXQgZW5hYmxlcyB0aGUgYmluZGluZyBiZXR3ZWVuIFBXcyBhbmQgdGhlIHVuZGVybHlp bmcNCj4gVEUgdHVubmVscy4gVGhlIGV4dGVuc2lvbiBhcHBsaWVzIHRvIGJvdGggU1MtUFcgYW5k IE1TLVBXLiINCj4gDQo+ID4g4oCiIEluIHRoZSBhYnN0cmFjdCBpdCBpcyBzYWlkIHRoYXQgYSBQ VyBpcyBsaW5rZWQgdG8gYW4gTFNQIGJ1dCB0aGVuIGluDQo+ID4gdGhlIGludHJvIGl0IGlzIHNh aWQgdGhhdCB0aGUgUFcgYmluZGluZyBpcyB0byBhIHR1bm5lbC4gQ2FuIHlvdQ0KPiA+IGNsYXJp ZnkgdGhpcz8gSeKAmWQgc2F5IHRoYXQgaXQgc2hvdWxkIGJlIGxpbmtlZCB0byBhIHR1bm5lbCwg cmlnaHQ/DQo+IA0KPiBZZXMsIGl0J3MgYmV0dGVyIHRvIHVzZSB0dW5uZWwsIEkgaGF2ZSB1cGRh dGVkIHRoZSBhYnN0cmFjdCB0byBtYWtlIEFic3RyYWN0DQo+IGFuZCBJbnRyb2R1Y3Rpb24gaGF2 ZSB0aGUgY29uc2lzdGVudCB1c2FnZS4gUGxlYXNlIHNlZSBhYm92ZSB0aGUgbmV3IHRleHQNCj4g Zm9yIEFic3RyYWN0Lg0KPiANCj4gPiDigKIgSW50cm86wqDCoCDigJxQVy10by1QU04gVHVubmVs IGJpbmRpbmcgaGFzIGJlY29tZSBpbmNyZWFzaW5nbHkgY29tbW9uDQo+ID4gYW5kIGltcG9ydGFu dCBpbiBtYW55IGRlcGxveW1lbnQgc2NlbmFyaW9z4oCdLiBJIGd1ZXNzIHlvdSBtZWFuIGFuDQo+ ID4gYXV0b21hdGljIGJpbmRpbmcgZG9uZSB2aWEgYSBzaWduYWxpbmcgcHJvdG9jb2w/DQo+IA0K PiBObywgdGhpcyBzZW50ZW5jZSBqdXN0IGJyaW5ncyB0aGUgcmVxdWlyZW1lbnRzIG9mIGV4cGxp Y2l0IFBXIHRvIFBTTiB0dW5uZWwNCj4gYmluZGluZywgd2hhdGV2ZXIgaXQgaXMgYXV0b21hdGlj IHNpZ25hbGluZyBvciBtYW51YWwgY29uZmlndXJhdGlvbi4NCj4gDQo+ID4g4oCiIFdoYXQgZG8g eW91IG1lYW4gd2l0aCDigJxtYXkgdHJhdmVyc2UgdGhyb3VnaCBkaWZmZXJlbnQgcm91dGVz4oCd PyBJDQo+ID4gc3VnZ2VzdCBsZWF2aW5nIOKAnG1heSB0cmF2ZXJzZSBtdWx0aXBsZSBuZXR3b3Jr cyBvciBkb21haW5zLg0KPiANCj4gSGVyZSB0aGUgInJvdXRlcyIgbWVhbnMgInBhdGhzIi4NCj4g DQo+IEhvdyBhYm91dDogIi4uLm1heSB0cmF2ZXJzZSB0aHJvdWdoIGRpZmZlcmVudCBwYXRocyBv ciBuZXR3b3JrcyI/DQo+IA0KPiA+IOKAoiBJbnRybyBhbmQgRmlndXJlIDE6IGNvdWxkIGJlIGV4 YW1wbGUgYmUgbWFkZSBhIGJpdCBtb3JlIGdlbmVyaWMgd2l0aA0KPiA+IGEgbmV0d29yayBiZXR3 ZWVuIHRoZSBQRXM/IFdpdGggZGlyZWN0bHkgY29ubmVjdGVkIFBFcyBpdCBkb2VzbuKAmXQgc2Vl bQ0KPiA+IGEgcmVhbGlzdGljIGFuZCBnZW5lcmljIGVub3VnaCBleGFtcGxlLg0KPiANCj4gDQo+ ID4g4oCiIEludHJvOiBzdWdnZXN0IHJlbW92aW5nIOKAnEFzIG1lbnRpb25lZCBhYm92ZeKAnS4N Cj4gDQo+IE9LLg0KPiANCj4gPiDigKIgwqBUaGUgbmFtZSBvZiB0aGUgZHJhZnQgZXhwbGljaXRs eSBtZW50aW9ucyBNUExTLVRQIGJ1dCBpbiB0aGUgcmVzdA0KPiA+IG9mIHRoZSBkcmFmdCB0aGVy ZSBpcyBubyBtZW50aW9uIG9mIGl0LCBqdXN0IHRoZSBtdWNoIG1vcmUgZ2VuZXJhbA0KPiA+IFBh Y2tldCBTd2l0Y2hpbmcgTmV0d29yayB0ZXJtIGlzIHVzZWQuDQo+IA0KPiBJbmRlZWQsIHRoYXQn cyB0aGUgaW50ZW50aW9uLiBUaGlzIHdvcmsgd2FzIHRyaWdnZXJlZCBieSB0aGUgZGlzY3Vzc2lv biBvZg0KPiBNUExTLVRQLiBCdXQgd2l0aCB0aGUgcHJvZ3Jlc3Mgb2YgdGhpcyBkcmFmdCBhbmQg ZGlzY3Vzc2lvbiB3aXRoaW4gdGhlIFdHLA0KPiB0aGVyZSBpcyBhIGNvbnNlbnN1cyB0aGF0IHRo aXMgdGVjaG5pcXVlIGlzIGEgZ2VuZXJhbCBzb2x1dGlvbiB0aGF0IGNhbiBhY3R1YWxseQ0KPiBh cHBseSB0byBib3RoIFRQIGFuZCBub24tVFAgY2FzZXMuDQo+IA0KPiA+IOKAoiBTZWN0aW9uIDI6 wqDCoCDigJxUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBuZXcgb3B0aW9uYWwgVExWLCBQU04gVHVu bmVsDQo+ID4gQmluZGluZyBUTFYsIHRvIGNvbW11bmljYXRlIHR1bm5lbC9MU1BzIHNlbGVjdGlv biBhbmQgYmluZGluZyByZXF1ZXN0cw0KPiBiZXR3ZWVuIFBFcy4NCj4gPiDigJwgVGhlIGJpbmRp bmcgcmVxdWVzdCBpcyBiZXR3ZWVuIFBFcz8gT3IgYmV0d2VlbiBhbiBQVyBhbmQgYSBUdW5uZWwN Cj4gPiAob3IgTFNQPykgYmV0d2VlbiB0d28gUEVzPw0KPiANCj4gQmV0d2VlbiBQRXMgb2YgYW4g UFcuDQo+IA0KPiA+IOKAoiBTZWN0aW9uIDI6IFN0cmljdCBiaW5kaW5nIHZzIENvLXJvdXRlZCBi aW5kaW5nOiBmcm9tIHRoZSBkZXNjcmlwdGlvbg0KPiA+IGl0IHNlZW1zIHRoYXQgdGhlIGZpcnN0 IG9uZSBpcyBzdHJpY3QgYW5kIHRoZSBzZWNvbmQgb25lIGlzIOKAnGxvb3Nl4oCdDQo+ID4gKGlu IHRoZSBzZW5zZSB0aGF0IHRoZSBQRSBjYW4gYWNjZXB0IHRoZSByZXF1ZXN0IG9yIG5vdCkuIERv buKAmXQgYm90aCBhcHBseQ0KPiB0byBjby1yb3V0ZWQgTFNQcz8NCj4gDQo+IFllcywgYm90aCBj YW4gYXBwbHkgdG8gY28tcm91dGVkIExTUHMuIEJ1dCBmb3IgInN0cmljdCIgbW9kZSwgaWYgdGhl IGVncmVzcyBQRQ0KPiBtdXN0IGJpbmQgdG8gdGhlIHNwZWNpZmllZCB0dW5uZWwgYnkgdGhlIGlu Z3Jlc3MgUEUsIG90aGVyd2lzZSwgdGhlIGJpbmRpbmcNCj4gd2lsbCBub3Qgc3VjY2Vzcy4gVGhl ICJjby1yb3V0ZWQiIG1vZGUgZ2l2ZXMgdGhlIGVncmVzcyBQRSB0aGUgdXNlDQo+IGFsdGVybmF0 aXZlIHR1bm5lbC4NCj4gDQo+ID4g4oCiIFNlY3Rpb24gMjog4oCdVGhlIHRlcm1pbm9sb2d5ICJM U1AiIGlzwqAgaWRlbnRpY2FsIHRvIHRoZSAiTFNQIHR1bm5lbCINCj4gPiBkZWZpbmVkIGluIFNl Y3Rpb24gMi4xIG9mIFtSRkMzMjA5XSzCoCB3aGljaCBpcyB1bmlxdWVseSBpZGVudGlmaWVkIGJ5 DQo+ID4gdGhlIFNFU1NJT04gb2JqZWN0IHRvZ2V0aGVyIHdpdGjCoCBTRU5ERVJfVEVNUExBVEUg KG9yIEZJTFRFUl9TUEVDKQ0KPiA+IG9iamVjdCB0aGF0IGNvbnNpc3RzIG9mIExTUCBJRCBhbmQg VHVubmVsIGVuZHBvaW50IGFkZHJlc3Mu4oCdIFdoeSBpcw0KPiA+IHRoZSBkcmFmdCBjb25zaWRl cmluZyBvbmx5IHNpZ25hbGVkIExTUHM/IERvZXNu4oCZdCBpdCBhcHBseSBhbHNvIHRvIGNlbnRy YWxseQ0KPiBwcm92aXNpb25lZCBvbmVzPyAoZS5nLiBOTVMgb3IgU0ROKS4NCj4gDQo+IFRoZSBt YWluIHB1cnBvc2UgaGVyZSBpcyB0byBnaXZlIGEgcmVmZXJlbmNlIHRvIHRoZSB0ZXJtIG9mICJM U1AiIGFuZA0KPiAidHVubmVsIiwgaGVuY2UgdG8gZWxpbWluYXRlIHRoZSBjb25mdXNpb24gb2Yg d2hlbiB1c2UgdGhlc2UgaW4gdGhlDQo+IGZvbGxvd2luZyBzZWN0aW9ucy4gQXMgZm9yIHRoZSBO TVMgYW5kIFNETiBiYXNlZCBURSBMU1AvVHVubmVsLCB0ZWNobmljYWxseSwNCj4gaXQgY2FuIGFw cGx5IHRvIGFzIHdlbGwgb25seSBpZiB0aGUgVEUgTFNQL1R1bm5lbCBoYXMgdGhlIExTUCBudW1i ZXIsIG5vZGUgSUQNCj4gZXRjLiBpbmZvcm1hdGlvbi4NCj4gDQo+ID4g4oCiIFNlY3Rpb24gMi4x OiDigJxMRFAgTGFiZWwgTWFwcGluZyBtZXNzYWdl4oCdIG1pc3NpbmcgcmVmZXJlbmNlLiBBbmQg d2h5DQo+ID4gdGhlIFR5cGUgZmllbGQgc3RhcnRzIHdpdGggMSBhbmQgMD8NCj4gDQo+IEdvb2Qg Y2F0Y2gsIHdpbGwgYWRkIGEgcmVmZXJlbmNlIGhlcmUuDQo+IA0KPiANCj4gPiBOaXRzOg0KPiA+ IOKAoiBBYnN0cmFjdCBzLyB0cmF2ZXJzZSB0aHJvdWdoIG11bHRpcGxlLyB0cmF2ZXJzZSBtdWx0 aXBsZSDigKIgSW50cm9kdWN0aW9uOg0KPiA+IOKAnFBzZXVkb3dpcmUgKFBXKSBFbXVsYXRpb24g RWRnZS10by1FZGdlIChQV0UzKeKAnS4gSSBzdWdnZXN0IHJlbW92aW5nDQo+ID4gKFBXKSwgaXTi gJlzIGFscmVhZHkgaW5jbHVkZWQgaW50byBQV0UzLg0KPiANCj4gT0suDQo+ID4g4oCiIEludHJv OiBzLyBhIGJpZGlyZWN0aW9uYWwgY2lyY3VpdHMvIGEgYmlkaXJlY3Rpb25hbCBjaXJjdWl0DQo+ IA0KPiBPSy4NCj4gDQo+IOKAoiBJbnRybzogc3VnZ2VzdA0KPiA+IHJlcGhyYXNpbmc6IOKAnEJp ZGlyZWN0aW9uYWwgTFNQcyBzaGFyZSBmYXRlIGFuZCBzaW1wbGlmeSB0aGUgcm91dGluZyBvZg0K PiA+IGEgcHJvdGVjdGlvbiBwYXRoIGFsc28gY29uc2lzdGluZyBvZiBiaWRpcmVjdGlvbmFswqDC oCBMU1BzIGJlY2F1c2UNCj4gPiB3b3JraW5nIGFuZCBwcm90ZWN0aW9uIHBhdGhzIGhhdmUgdG8g YmUgZGlzam9pbnQu4oCdDQo+IA0KPiBPSy4NCj4gDQo+ID4g4oCiIEludHJvOiBzLyB0aGVyZSBh cmUgYSBsYXJnZSBudW1iZXIvIHRoZXJlIGlzIGEgbGFyZ2UgbnVtYmVyDQo+IA0KPiBPSy4NCj4g DQo+IOKAoiBJbnRybzpzL3RvIGJlDQo+ID4gY2FycmllZC9hcmUgY2FycmllZA0KPiANCj4gT0su DQo+IA0KPiDigKIgSW50cm86cy90aGVyZSBhcmUgYSBudW1iZXIvdGhlcmUgaXMgYSBudW1iZXIN Cj4gDQo+IE9LLg0KPiANCj4g4oCiIEludHJvOiBzLw0KPiA+IHRyYWZmaWMgYmVsb25ncy90cmFm ZmljIGJlbG9uZ2luZw0KPiANCj4gT0suDQo+IA0KPiDigKIgSW50cm86IChzdWdnZXN0aW9uKSBz LyhQRTEtUDMtUEUyKS8NCj4gPiAoUEUyLVAzLVBFMSkgc2luY2Ugd2UgYXJlIHNwZWFraW5nIGFi b3V0IGRpcmVjdGlvbmFsaXR5IGl0IG1ha2VzIG1vcmUNCj4gPiBzZW5zZSB0byBsaXN0IHRoZSBu b2RlcyBvZiB0aGUgcGF0aCBpbiB0aGUgcmV2ZXJzZSBkaXJlY3Rpb24uDQo+IA0KPiBPSy4NCj4g DQo+ID4g4oCiIEludHJvOiBzLyBUaGUgc2ltaWxhciBwcm9ibGVtcy9BIHNpbWlsYXIgcHJvYmxl bQ0KPiANCj4gT0suDQo+IA0KPiA+4oCiIEludHJvOiBzLyB3b24ndC9kb2VzIG5vdA0KPiANCj4g T0suDQo+ID7igKJJbnRybzogcy8gSW4gdGhpcyBkb2N1bWVudCwgaXQgaW50cm9kdWNlcy9UaGlz IGRvY3VtZW50IGludHJvZHVjZXMgQlINCj4gPkRhbmllbGUNCj4gDQo+IE9LLg0KPiANCj4gPg0K DQo= From nobody Wed May 25 02:02:21 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCD412D0BF; Wed, 25 May 2016 02:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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=-1.426, SPF_PASS=-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 u_xLLJR3z0Cf; Wed, 25 May 2016 02:02:17 -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 8229F12D151; Wed, 25 May 2016 02:02:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKR99864; Wed, 25 May 2016 09:02:12 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 25 May 2016 10:02:08 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.42]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0235.001; Wed, 25 May 2016 17:01:48 +0800 From: Mach Chen To: Daniele Ceccarelli , " (rtg-ads@ietf.org)" Thread-Topic: RtgDir review: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06 Thread-Index: AdGe+Z/lFOzQc8O7SFSbqLe7ce8oewAG1OFwA2v05+AAAARS8AJlk/FwAAHw8kA= Date: Wed, 25 May 2016 09:01:48 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE48162EBD1D@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48162EBD1D@ESESSMB301.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.135] 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.0A090202.57456A15.005A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.42, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c1bd2077fdb78ac4453c9ffedee5bcb7 Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-pals-mpls-tp-pw-over-bidir-lsp.all@tools.ietf.org" , "pals@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 09:02:20 -0000 SGkgRGFuaWVsZSwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEYW5p ZWxlIENlY2NhcmVsbGkgW21haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tXQ0K PiBTZW50OiBXZWRuZXNkYXksIE1heSAyNSwgMjAxNiA0OjA4IFBNDQo+IFRvOiBNYWNoIENoZW47 IDxydGctYWRzQGlldGYub3JnPiAocnRnLWFkc0BpZXRmLm9yZykNCj4gQ2M6IHJ0Zy1kaXJAaWV0 Zi5vcmc7IGRyYWZ0LWlldGYtcGFscy1tcGxzLXRwLXB3LW92ZXItYmlkaXItbHNwLmFsbEB0b29s cy5pZXRmLm9yZzsNCj4gcGFsc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogUnRnRGlyIHJldmll dzogZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtcHctb3Zlci1iaWRpci1sc3AtMDYNCj4gDQo+IEhp IE1hY2gsDQo+IA0KPiBUaGFua3MgZm9yIHRoZSB1cGRhdGUuDQo+IFRoZXJlIGlzIGp1c3Qgb25l IG91dHN0YW5kaW5nIHBvaW50Og0KPiANCj4gPiDigKIgU2VjdGlvbiAyLjE6IOKAnExEUCBMYWJl bCBNYXBwaW5nIG1lc3NhZ2XigJ0gbWlzc2luZyByZWZlcmVuY2UuIEFuZCB3aHkNCj4gPiB0aGUg VHlwZSBmaWVsZCBzdGFydHMgd2l0aCAxIGFuZCAwPw0KPiBUaGFua3MgZm9yIGFkZGluZyB0aGUg cmVmZXJlbmNlIGJ1dCBJIHN0aWxsIGRvbid0IGdldCB3aHkgdGhlIFR5cGUgZmllbGQgc3RhcnRz DQo+IHdpdGggMSBhbmQgMC4NCg0KVGhlIGZpcnN0IHR3byBiaXRzIGFyZSBVLWJpdCBhbmQgRi1i aXQsIHdoaWNoIGFyZSBkZWZpbmVkIGluIFNlY3Rpb24gMy4zIG9mIFJGQzUwMzYuIEhvdyBhYm91 dCBhZGRpbmcgdGhlIGZvbGxvdyB0ZXh0Og0KDQpGb3IgdGhpcyBUTFYsIHRoZSBVbmtub3duIFRM ViBiaXQgKFUtYml0KSAoU2VjdGlvbiAzLjMgb2YgUkZDNTAzNikgaXMgc2V0IHRvIDEsIGFuZCB0 aGUgRm9yd2FyZGluZyB1bmtub3duIGJpdCAoRi1iaXQpIChTZWN0aW9uIDMuMyBvZiBSRkM1MDM2 KSBpcyBzZXQgdG8gMC4NCg0KPiBPbmUgbW9yZSBjb21tZW50IHRoYXQgSSBsb3N0IGR1cmluZyB0 aGUgZmlyc3QgaXRlcmF0aW9uOiB3aHkgZG8geW91IGRlZmluZSB0aGUNCj4gImZsYWciIGZpZWxk IGluIGZpZ3VyZSAzIGFuZCB0aGVuIGJlbG93IGhhdmUgYSBmdXJ0aGVyIGZpZ3VyZSBzaG93aW5n IEMsIFMsIFQgYW5kDQo+IHRoZSBtdXN0IGJlIHplcm8gZmllbGQ/IEknZCBkaXJlY3RseSBwdXQg dGhlIEMsUyxUIGFuZCBtdXN0IGJlIHplcm8gZmllbGRzIGluIHBsYWNlDQo+IG9mIHRoZSBGbGFn IGZpZWxkIGluIGZpZ3VyZSAzLiBJdCBoZWxwcyB3aXRoIHJlYWRhYmlsaXR5IElNSE8uDQoNCk9L LCB3aWxsIHB1dCB0aGVtIGJhY2sgdG8gdGhlIFRMViBhbmQgcmVtb3ZlIHRoZSBmbGFncyBmaWd1 cmUuDQoNCg0KSG9wZSBhYm92ZSBhZGRyZXNzIHlvdXIgY29tbWVudHMhDQoNClRoYW5rcywNCk1h Y2gNCj4gDQo+IA0KPiBCUg0KPiBEYW5pZWxlDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4gRnJvbTogTWFjaCBDaGVuIFttYWlsdG86bWFjaC5jaGVuQGh1YXdlaS5jb21d DQo+ID4gU2VudDogdmVuZXJkw6wgMTMgbWFnZ2lvIDIwMTYgMDk6MjUNCj4gPiBUbzogRGFuaWVs ZSBDZWNjYXJlbGxpIDxkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tPjsNCj4gPiA8cnRn LWFkc0BpZXRmLm9yZz4NCj4gPiAocnRnLWFkc0BpZXRmLm9yZykgPHJ0Zy1hZHNAaWV0Zi5vcmc+ DQo+ID4gQ2M6IHJ0Zy1kaXJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtcGFscy1tcGxzLXRwLXB3LW92 ZXItYmlkaXItDQo+ID4gbHNwLmFsbEB0b29scy5pZXRmLm9yZzsgcGFsc0BpZXRmLm9yZw0KPiA+ IFN1YmplY3Q6IFJFOiBSdGdEaXIgcmV2aWV3Og0KPiA+IGRyYWZ0LWlldGYtcGFscy1tcGxzLXRw LXB3LW92ZXItYmlkaXItbHNwLTA2DQo+ID4NCj4gPiBIaSBEYW5pZWxlLA0KPiA+DQo+ID4gVGhh bmtzIGZvciB0aGUgZGV0YWlsZWQgcmV2aWV3IGFuZCB2YWx1YWJsZSBjb21tZW50cyENCj4gPg0K PiA+IFBsZWFzZSBzZWUgbXkgcmVzcG9uc2VzIGlubGluZS4uLg0KPiA+DQo+ID4gSSBhbHNvIGF0 dGFjaGVkIGEgZGlmZiB0aGF0IHNob3dzIHRoZSB1cGRhdGVzIHRoYXQgdHJ5IHRvIGFkZHJlc3Mg eW91cg0KPiA+IGNvbW1lbnRzLiBJZiB5b3UgYXJlIE9LIHdpdGggdGhlIHVwZGF0ZXMsIEkgd2ls bCBzdWJtaXQgaXQgdGhlbi4NCj4gPg0KPiA+IFRoYW5rcywNCj4gPiBNYWNoDQo+ID4NCj4gPiA+ IEZyb206IERhbmllbGUgQ2VjY2FyZWxsaQ0KPiA+ID4gU2VudDogbHVuZWTDrCAyNSBhcHJpbGUg MjAxNiAxOTowNA0KPiA+ID4gVG86IDxydGctYWRzQGlldGYub3JnPiAocnRnLWFkc0BpZXRmLm9y ZykNCj4gPiA+IENjOiAncnRnLWRpckBpZXRmLm9yZyc7ICdkcmFmdC1pZXRmLXBhbHMtbXBscy10 cC1wdy1vdmVyLWJpZGlyLWxzcC5hbGxAaWV0Zi5vcmcnDQo+ID4gPiBTdWJqZWN0OiBSdGdEaXIg cmV2aWV3OiBkcmFmdC1pZXRmLXBhbHMtbXBscy10cC1wdy1vdmVyLWJpZGlyLWxzcC0wNg0KPiA+ ID4NCj4gPiA+IEhlbGxvLA0KPiA+ID4gSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRp bmcgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMNCj4gPiA+IGRyYWZ0LiBUaGUgUm91dGlu ZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3INCj4gPiA+IHJvdXRp bmctcmVsYXRlZCBkcmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5k IElFU0cNCj4gPiA+IHJldmlldywNCj4gPiBhbmQgc29tZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVz dC4NCj4gPiA+IFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3Rh bmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4NCj4gPiA+IEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0 IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlDQo+ID4gPiBodHRwOi8vdHJhYy50 b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyDQo+ID4gPiBBbHRob3VnaCB0 aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nDQo+ ID4gPiBBRHMsIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0g YWxvbmcgd2l0aCBhbnkNCj4gPiA+IG90aGVyIElFVEYgTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQg eW91IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8NCj4gPiA+IHJlc29sdmUgdGhlbSB0aHJvdWdoIGRp c2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0Lg0KPiA+ID4gRG9jdW1lbnQ6wqBkcmFm dC1pZXRmLXBhbHMtbXBscy10cC1wdy1vdmVyLWJpZGlyLWxzcC0wNg0KPiA+ID4gUmV2aWV3ZXI6 IERhbmllbGUgQ2VjY2FyZWxsaQ0KPiA+ID4gUmV2aWV3IERhdGU6IEFwcmlsIDI1IDIwMTYNCj4g PiA+IElFVEYgTEMgRW5kIERhdGU6IC0NCj4gPiA+IEludGVuZGVkIFN0YXR1czogU3RhbmRhcmQg VHJhY2sNCj4gPiA+IFN1bW1hcnk6DQo+ID4gPiDigKIgSSBoYXZlIHNvbWUgbWlub3IgY29uY2Vy bnMgYWJvdXQgdGhpcyBkb2N1bWVudCB0aGF0IEkgdGhpbmsgc2hvdWxkDQo+ID4gPiBiZSByZXNv bHZlZCBiZWZvcmUgcHVibGljYXRpb24uDQo+ID4gPiBDb21tZW50czoNCj4gPiA+IOKAoiBXaGF0 IHRoZSBkcmFmdHMgaXMgcHJvcG9zaW5nIGFzIHByb3RvY29sIG1vZGlmaWNhdGlvbiBpcyBjbGVh ciBhbmQNCj4gPiA+IGFsc28gdGhlIG9wZXJhdGlvbiBzZWN0aW9uIGFyZSBwcmV0dHkgc3RyYWln aGZvcndhcmQuIFdoYXQgbmVlZHMgdG8NCj4gPiA+IGJlIGltcHJvdmVkIGlzIHRoZSBpbnRyb2R1 Y3Rpb24gcGFydCwgd2hpY2ggc2hvdWxkIGJlIHJldmlld2VkIGJ5IGENCj4gPiA+IG5hdGl2ZSBF bmdsaXNoIHNwZWFrZXIuIEFsc28gdGhlIElBTkEgc2VjdGlvbiBzaG91bGQgYmUgbWFkZSBjbGVh cmVyLg0KPiA+DQo+ID4gVGhhbmtzIGZvciB5b3VyIHN1Z2dlc3Rpb24sIEkgYXNzdW1lIHRoZSBS RkMgZWRpdG9yIHdpbGwgZG8gYW5vdGhlcg0KPiA+IHJldmlldyBvbmNlIHRoZSBkb2N1bWVudCBw cm9ncmVzc2VkIHRvIHRoYXQgc3RhZ2UuDQo+ID4NCj4gPiA+IE1ham9yIElzc3VlczoNCj4gPiA+ IOKAoiBObyBtYWpvciBpc3N1ZXMgZm91bmQNCj4gPiA+IE1pbm9yIElzc3VlczoNCj4gPiA+IOKA oiBBYnN0cmFjdDog4oCcSW4gYWRkaXRpb24sIHRoZSB1c2VyIHRyYWZmaWMgbWF5IHRyYXZlcnNl IHRocm91Z2gNCj4gPiA+IG11bHRpcGxlIHRyYW5zcG9ydCBuZXR3b3Jrcy7igJ0gTWF5YmUgaXMg d29ydGggZWxhYm9yYXRpbmcgYSBiaXQgdGhpcw0KPiA+ID4gc2VudGVuY2Ugc2F5aW5nIHRoYXQg dGhlIGV4dGVuc2lvbnMgZGVmaW5lZCBpbiB0aGlzIGRyYWZ0IGFwcGx5IGJvdGgNCj4gPiA+IHRv IFNTLQ0KPiA+IFBXIGFuZCBNUy1QVy4NCj4gPg0KPiA+IEhvdyBhYm91dCB0aGlzOg0KPiA+DQo+ ID4gIk1hbnkgdHJhbnNwb3J0IHNlcnZpY2VzIHJlcXVpcmUgdGhhdCB1c2VyIHRyYWZmaWMsIGlu IHRoZSBmb3JtIG9mDQo+ID4gUHNldWRvd2lyZXMgKFBXKSwgYmUgZGVsaXZlcmVkIG9uIGEgc2lu Z2xlIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsDQo+ID4gdHVubmVsIG9yIHR3byB0dW5uZWxzIHRo YXQgc2hhcmUgdGhlIHNhbWUgcm91dGVzLiBUaGlzIGRvY3VtZW50DQo+ID4gZGVmaW5lcyBhbiBv cHRpb25hbCBleHRlbnNpb24gdG8gTERQIHRoYXQgZW5hYmxlcyB0aGUgYmluZGluZyBiZXR3ZWVu DQo+ID4gUFdzIGFuZCB0aGUgdW5kZXJseWluZyBURSB0dW5uZWxzLiBUaGUgZXh0ZW5zaW9uIGFw cGxpZXMgdG8gYm90aCBTUy1QVyBhbmQNCj4gTVMtUFcuIg0KPiA+DQo+ID4gPiDigKIgSW4gdGhl IGFic3RyYWN0IGl0IGlzIHNhaWQgdGhhdCBhIFBXIGlzIGxpbmtlZCB0byBhbiBMU1AgYnV0IHRo ZW4NCj4gPiA+IGluIHRoZSBpbnRybyBpdCBpcyBzYWlkIHRoYXQgdGhlIFBXIGJpbmRpbmcgaXMg dG8gYSB0dW5uZWwuIENhbiB5b3UNCj4gPiA+IGNsYXJpZnkgdGhpcz8gSeKAmWQgc2F5IHRoYXQg aXQgc2hvdWxkIGJlIGxpbmtlZCB0byBhIHR1bm5lbCwgcmlnaHQ/DQo+ID4NCj4gPiBZZXMsIGl0 J3MgYmV0dGVyIHRvIHVzZSB0dW5uZWwsIEkgaGF2ZSB1cGRhdGVkIHRoZSBhYnN0cmFjdCB0byBt YWtlDQo+ID4gQWJzdHJhY3QgYW5kIEludHJvZHVjdGlvbiBoYXZlIHRoZSBjb25zaXN0ZW50IHVz YWdlLiBQbGVhc2Ugc2VlIGFib3ZlDQo+ID4gdGhlIG5ldyB0ZXh0IGZvciBBYnN0cmFjdC4NCj4g Pg0KPiA+ID4g4oCiIEludHJvOsKgwqAg4oCcUFctdG8tUFNOIFR1bm5lbCBiaW5kaW5nIGhhcyBi ZWNvbWUgaW5jcmVhc2luZ2x5IGNvbW1vbg0KPiA+ID4gYW5kIGltcG9ydGFudCBpbiBtYW55IGRl cGxveW1lbnQgc2NlbmFyaW9z4oCdLiBJIGd1ZXNzIHlvdSBtZWFuIGFuDQo+ID4gPiBhdXRvbWF0 aWMgYmluZGluZyBkb25lIHZpYSBhIHNpZ25hbGluZyBwcm90b2NvbD8NCj4gPg0KPiA+IE5vLCB0 aGlzIHNlbnRlbmNlIGp1c3QgYnJpbmdzIHRoZSByZXF1aXJlbWVudHMgb2YgZXhwbGljaXQgUFcg dG8gUFNODQo+ID4gdHVubmVsIGJpbmRpbmcsIHdoYXRldmVyIGl0IGlzIGF1dG9tYXRpYyBzaWdu YWxpbmcgb3IgbWFudWFsIGNvbmZpZ3VyYXRpb24uDQo+ID4NCj4gPiA+IOKAoiBXaGF0IGRvIHlv dSBtZWFuIHdpdGgg4oCcbWF5IHRyYXZlcnNlIHRocm91Z2ggZGlmZmVyZW50IHJvdXRlc+KAnT8g SQ0KPiA+ID4gc3VnZ2VzdCBsZWF2aW5nIOKAnG1heSB0cmF2ZXJzZSBtdWx0aXBsZSBuZXR3b3Jr cyBvciBkb21haW5zLg0KPiA+DQo+ID4gSGVyZSB0aGUgInJvdXRlcyIgbWVhbnMgInBhdGhzIi4N Cj4gPg0KPiA+IEhvdyBhYm91dDogIi4uLm1heSB0cmF2ZXJzZSB0aHJvdWdoIGRpZmZlcmVudCBw YXRocyBvciBuZXR3b3JrcyI/DQo+ID4NCj4gPiA+IOKAoiBJbnRybyBhbmQgRmlndXJlIDE6IGNv dWxkIGJlIGV4YW1wbGUgYmUgbWFkZSBhIGJpdCBtb3JlIGdlbmVyaWMNCj4gPiA+IHdpdGggYSBu ZXR3b3JrIGJldHdlZW4gdGhlIFBFcz8gV2l0aCBkaXJlY3RseSBjb25uZWN0ZWQgUEVzIGl0DQo+ ID4gPiBkb2VzbuKAmXQgc2VlbSBhIHJlYWxpc3RpYyBhbmQgZ2VuZXJpYyBlbm91Z2ggZXhhbXBs ZS4NCj4gPg0KPiA+DQo+ID4gPiDigKIgSW50cm86IHN1Z2dlc3QgcmVtb3Zpbmcg4oCcQXMgbWVu dGlvbmVkIGFib3Zl4oCdLg0KPiA+DQo+ID4gT0suDQo+ID4NCj4gPiA+IOKAoiDCoFRoZSBuYW1l IG9mIHRoZSBkcmFmdCBleHBsaWNpdGx5IG1lbnRpb25zIE1QTFMtVFAgYnV0IGluIHRoZSByZXN0 DQo+ID4gPiBvZiB0aGUgZHJhZnQgdGhlcmUgaXMgbm8gbWVudGlvbiBvZiBpdCwganVzdCB0aGUg bXVjaCBtb3JlIGdlbmVyYWwNCj4gPiA+IFBhY2tldCBTd2l0Y2hpbmcgTmV0d29yayB0ZXJtIGlz IHVzZWQuDQo+ID4NCj4gPiBJbmRlZWQsIHRoYXQncyB0aGUgaW50ZW50aW9uLiBUaGlzIHdvcmsg d2FzIHRyaWdnZXJlZCBieSB0aGUNCj4gPiBkaXNjdXNzaW9uIG9mIE1QTFMtVFAuIEJ1dCB3aXRo IHRoZSBwcm9ncmVzcyBvZiB0aGlzIGRyYWZ0IGFuZA0KPiA+IGRpc2N1c3Npb24gd2l0aGluIHRo ZSBXRywgdGhlcmUgaXMgYSBjb25zZW5zdXMgdGhhdCB0aGlzIHRlY2huaXF1ZSBpcw0KPiA+IGEg Z2VuZXJhbCBzb2x1dGlvbiB0aGF0IGNhbiBhY3R1YWxseSBhcHBseSB0byBib3RoIFRQIGFuZCBu b24tVFAgY2FzZXMuDQo+ID4NCj4gPiA+IOKAoiBTZWN0aW9uIDI6wqDCoCDigJxUaGlzIGRvY3Vt ZW50IGRlZmluZXMgYSBuZXcgb3B0aW9uYWwgVExWLCBQU04gVHVubmVsDQo+ID4gPiBCaW5kaW5n IFRMViwgdG8gY29tbXVuaWNhdGUgdHVubmVsL0xTUHMgc2VsZWN0aW9uIGFuZCBiaW5kaW5nDQo+ ID4gPiByZXF1ZXN0cw0KPiA+IGJldHdlZW4gUEVzLg0KPiA+ID4g4oCcIFRoZSBiaW5kaW5nIHJl cXVlc3QgaXMgYmV0d2VlbiBQRXM/IE9yIGJldHdlZW4gYW4gUFcgYW5kIGEgVHVubmVsDQo+ID4g PiAob3IgTFNQPykgYmV0d2VlbiB0d28gUEVzPw0KPiA+DQo+ID4gQmV0d2VlbiBQRXMgb2YgYW4g UFcuDQo+ID4NCj4gPiA+IOKAoiBTZWN0aW9uIDI6IFN0cmljdCBiaW5kaW5nIHZzIENvLXJvdXRl ZCBiaW5kaW5nOiBmcm9tIHRoZQ0KPiA+ID4gZGVzY3JpcHRpb24gaXQgc2VlbXMgdGhhdCB0aGUg Zmlyc3Qgb25lIGlzIHN0cmljdCBhbmQgdGhlIHNlY29uZCBvbmUgaXMNCj4g4oCcbG9vc2XigJ0N Cj4gPiA+IChpbiB0aGUgc2Vuc2UgdGhhdCB0aGUgUEUgY2FuIGFjY2VwdCB0aGUgcmVxdWVzdCBv ciBub3QpLiBEb27igJl0IGJvdGgNCj4gPiA+IGFwcGx5DQo+ID4gdG8gY28tcm91dGVkIExTUHM/ DQo+ID4NCj4gPiBZZXMsIGJvdGggY2FuIGFwcGx5IHRvIGNvLXJvdXRlZCBMU1BzLiBCdXQgZm9y ICJzdHJpY3QiIG1vZGUsIGlmIHRoZQ0KPiA+IGVncmVzcyBQRSBtdXN0IGJpbmQgdG8gdGhlIHNw ZWNpZmllZCB0dW5uZWwgYnkgdGhlIGluZ3Jlc3MgUEUsDQo+ID4gb3RoZXJ3aXNlLCB0aGUgYmlu ZGluZyB3aWxsIG5vdCBzdWNjZXNzLiBUaGUgImNvLXJvdXRlZCIgbW9kZSBnaXZlcw0KPiA+IHRo ZSBlZ3Jlc3MgUEUgdGhlIHVzZSBhbHRlcm5hdGl2ZSB0dW5uZWwuDQo+ID4NCj4gPiA+IOKAoiBT ZWN0aW9uIDI6IOKAnVRoZSB0ZXJtaW5vbG9neSAiTFNQIiBpc8KgIGlkZW50aWNhbCB0byB0aGUg IkxTUCB0dW5uZWwiDQo+ID4gPiBkZWZpbmVkIGluIFNlY3Rpb24gMi4xIG9mIFtSRkMzMjA5XSzC oCB3aGljaCBpcyB1bmlxdWVseSBpZGVudGlmaWVkDQo+ID4gPiBieSB0aGUgU0VTU0lPTiBvYmpl Y3QgdG9nZXRoZXIgd2l0aMKgIFNFTkRFUl9URU1QTEFURSAob3INCj4gPiA+IEZJTFRFUl9TUEVD KSBvYmplY3QgdGhhdCBjb25zaXN0cyBvZiBMU1AgSUQgYW5kIFR1bm5lbCBlbmRwb2ludA0KPiA+ ID4gYWRkcmVzcy7igJ0gV2h5IGlzIHRoZSBkcmFmdCBjb25zaWRlcmluZyBvbmx5IHNpZ25hbGVk IExTUHM/IERvZXNu4oCZdA0KPiA+ID4gaXQgYXBwbHkgYWxzbyB0byBjZW50cmFsbHkNCj4gPiBw cm92aXNpb25lZCBvbmVzPyAoZS5nLiBOTVMgb3IgU0ROKS4NCj4gPg0KPiA+IFRoZSBtYWluIHB1 cnBvc2UgaGVyZSBpcyB0byBnaXZlIGEgcmVmZXJlbmNlIHRvIHRoZSB0ZXJtIG9mICJMU1AiIGFu ZA0KPiA+ICJ0dW5uZWwiLCBoZW5jZSB0byBlbGltaW5hdGUgdGhlIGNvbmZ1c2lvbiBvZiB3aGVu IHVzZSB0aGVzZSBpbiB0aGUNCj4gPiBmb2xsb3dpbmcgc2VjdGlvbnMuIEFzIGZvciB0aGUgTk1T IGFuZCBTRE4gYmFzZWQgVEUgTFNQL1R1bm5lbCwNCj4gPiB0ZWNobmljYWxseSwgaXQgY2FuIGFw cGx5IHRvIGFzIHdlbGwgb25seSBpZiB0aGUgVEUgTFNQL1R1bm5lbCBoYXMgdGhlDQo+ID4gTFNQ IG51bWJlciwgbm9kZSBJRCBldGMuIGluZm9ybWF0aW9uLg0KPiA+DQo+ID4gPiDigKIgU2VjdGlv biAyLjE6IOKAnExEUCBMYWJlbCBNYXBwaW5nIG1lc3NhZ2XigJ0gbWlzc2luZyByZWZlcmVuY2Uu IEFuZA0KPiA+ID4gd2h5IHRoZSBUeXBlIGZpZWxkIHN0YXJ0cyB3aXRoIDEgYW5kIDA/DQo+ID4N Cj4gPiBHb29kIGNhdGNoLCB3aWxsIGFkZCBhIHJlZmVyZW5jZSBoZXJlLg0KPiA+DQo+ID4NCj4g PiA+IE5pdHM6DQo+ID4gPiDigKIgQWJzdHJhY3Qgcy8gdHJhdmVyc2UgdGhyb3VnaCBtdWx0aXBs ZS8gdHJhdmVyc2UgbXVsdGlwbGUg4oCiIEludHJvZHVjdGlvbjoNCj4gPiA+IOKAnFBzZXVkb3dp cmUgKFBXKSBFbXVsYXRpb24gRWRnZS10by1FZGdlIChQV0UzKeKAnS4gSSBzdWdnZXN0IHJlbW92 aW5nDQo+ID4gPiAoUFcpLCBpdOKAmXMgYWxyZWFkeSBpbmNsdWRlZCBpbnRvIFBXRTMuDQo+ID4N Cj4gPiBPSy4NCj4gPiA+IOKAoiBJbnRybzogcy8gYSBiaWRpcmVjdGlvbmFsIGNpcmN1aXRzLyBh IGJpZGlyZWN0aW9uYWwgY2lyY3VpdA0KPiA+DQo+ID4gT0suDQo+ID4NCj4gPiDigKIgSW50cm86 IHN1Z2dlc3QNCj4gPiA+IHJlcGhyYXNpbmc6IOKAnEJpZGlyZWN0aW9uYWwgTFNQcyBzaGFyZSBm YXRlIGFuZCBzaW1wbGlmeSB0aGUgcm91dGluZw0KPiA+ID4gb2YgYSBwcm90ZWN0aW9uIHBhdGgg YWxzbyBjb25zaXN0aW5nIG9mIGJpZGlyZWN0aW9uYWzCoMKgIExTUHMgYmVjYXVzZQ0KPiA+ID4g d29ya2luZyBhbmQgcHJvdGVjdGlvbiBwYXRocyBoYXZlIHRvIGJlIGRpc2pvaW50LuKAnQ0KPiA+ DQo+ID4gT0suDQo+ID4NCj4gPiA+IOKAoiBJbnRybzogcy8gdGhlcmUgYXJlIGEgbGFyZ2UgbnVt YmVyLyB0aGVyZSBpcyBhIGxhcmdlIG51bWJlcg0KPiA+DQo+ID4gT0suDQo+ID4NCj4gPiDigKIg SW50cm86cy90byBiZQ0KPiA+ID4gY2FycmllZC9hcmUgY2FycmllZA0KPiA+DQo+ID4gT0suDQo+ ID4NCj4gPiDigKIgSW50cm86cy90aGVyZSBhcmUgYSBudW1iZXIvdGhlcmUgaXMgYSBudW1iZXIN Cj4gPg0KPiA+IE9LLg0KPiA+DQo+ID4g4oCiIEludHJvOiBzLw0KPiA+ID4gdHJhZmZpYyBiZWxv bmdzL3RyYWZmaWMgYmVsb25naW5nDQo+ID4NCj4gPiBPSy4NCj4gPg0KPiA+IOKAoiBJbnRybzog KHN1Z2dlc3Rpb24pIHMvKFBFMS1QMy1QRTIpLw0KPiA+ID4gKFBFMi1QMy1QRTEpIHNpbmNlIHdl IGFyZSBzcGVha2luZyBhYm91dCBkaXJlY3Rpb25hbGl0eSBpdCBtYWtlcw0KPiA+ID4gbW9yZSBz ZW5zZSB0byBsaXN0IHRoZSBub2RlcyBvZiB0aGUgcGF0aCBpbiB0aGUgcmV2ZXJzZSBkaXJlY3Rp b24uDQo+ID4NCj4gPiBPSy4NCj4gPg0KPiA+ID4g4oCiIEludHJvOiBzLyBUaGUgc2ltaWxhciBw cm9ibGVtcy9BIHNpbWlsYXIgcHJvYmxlbQ0KPiA+DQo+ID4gT0suDQo+ID4NCj4gPiA+4oCiIElu dHJvOiBzLyB3b24ndC9kb2VzIG5vdA0KPiA+DQo+ID4gT0suDQo+ID4gPuKAokludHJvOiBzLyBJ biB0aGlzIGRvY3VtZW50LCBpdCBpbnRyb2R1Y2VzL1RoaXMgZG9jdW1lbnQgaW50cm9kdWNlcw0K PiA+ID5CUiBEYW5pZWxlDQo+ID4NCj4gPiBPSy4NCj4gPg0KPiA+ID4NCg0K From nobody Wed May 25 02:21:58 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5646A12D546; Wed, 25 May 2016 02:21:53 -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, 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 0qI4JeIfl-9I; Wed, 25 May 2016 02:21:51 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1460912B032; Wed, 25 May 2016 02:21:49 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-79-57456eabb8b3 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id AA.6C.18043.BAE65475; Wed, 25 May 2016 11:21:47 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.74]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0294.000; Wed, 25 May 2016 11:20:47 +0200 From: Daniele Ceccarelli To: Mach Chen , " (rtg-ads@ietf.org)" Thread-Topic: RtgDir review: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06 Thread-Index: AdGe+Z/lFOzQc8O7SFSbqLe7ce8oewAG1OFwA2v05+AAAARS8AJlk/FwAAHw8kAAAKspgA== Date: Wed, 25 May 2016 09:20:46 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48162EBF6F@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE48162EBD1D@ESESSMB301.ericsson.se> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM2K7hO7qPNdwgwVXLSzmTlnAZHFhrbDF mn/rmCxOzvnBbLFgzVN2B1aPliNvWT2WLPnJ5PHl8me2AOYoLpuU1JzMstQifbsErowjS58y FfyrrDg3eQtzA+Obsi5GTg4JAROJ23dmsEHYYhIX7q0Hsrk4hASOMErcOvifGcJZzCjxvP0X kMPBwSZgJfHkkA9Ig4hAksS8ucvZQWxmgfOMEktmm4PYwgIeEvPvn2CFqPGUOLJ+OiOEHSbx 58whdpAxLAKqEh8/Z4KEeQV8JXZ9ng21aiOTxM2Nj1lAEpxA9f+2r2MGsRkFZCUm7F7ECLFL XOLWk/lMEEcLSCzZc54ZwhaVePn4HyuErShxdfpyJpBdzAKaEut36UO0KkpM6X7IDrFXUOLk zCcsExjFZiGZOguhYxaSjllIOhYwsqxiFC1OLS7OTTcy0kstykwuLs7P08tLLdnECIywg1t+ W+1gPPjc8RCjAAejEg/vg3Mu4UKsiWXFlbmHGCU4mJVEeO1yXMOFeFMSK6tSi/Lji0pzUosP MUpzsCiJ8/q/VAwXEkhPLEnNTk0tSC2CyTJxcEo1MMorxslVaoT6dGTY/mszZFz7nJND6trm hu53zW/2GF9XVrp+ze7tQhPhO5fbnmh0ePzeafzMK2nfqm9mB96cWy50905flGb4oQ9Gy2+f Llx9/ME0+yXNa19P+7mt8jxH6vtjbFdqXP69uvZx5mbLylseWmX711n0pyiF/d30lkHH6rme UOqTTcpKLMUZiYZazEXFiQCA3KXirAIAAA== Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-pals-mpls-tp-pw-over-bidir-lsp.all@tools.ietf.org" , "pals@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 09:21:53 -0000 SGkgTWFjaCwNCg0KT2ssIGxldCBtZSB0cnkgdG8gc3VtbWFyaXplLg0KDQpUaGUgZHJhZnQgZGVm aW5lcyBhIG5ldyBUTFYgZm9yIHRoZSBMRFAgTWFwcGluZyBNZXNzYWdlIChSRkMgNTAzNiBzZWN0 aW9uIDMuNS43KSB3aGljaCBJIGd1ZXNzIHdvdWxkIGVuZCB1cCBpbiB0aGUgIm9wdGlvbmFsIHBh cmFtZXRlcnMiIGZpZWxkICh0aGUgdGV4dCBzYXlzOiAiY29udGFpbnMgMCBvciBtb3JlIHBhcmFt ZXRlcnMsIGVhY2ggZW5jb2RlZCBhcyBhIFRMViIpLg0KVGhlbiBzZWN0aW9uIDMuMyBtYW5kYXRl cyBob3cgdG8gYnVpbGQgdGhvc2UgVExWcyAoVSwgRiBhbmQgc28gb24pLg0KDQpJZiBteSB1bmRl cnN0YW5kaW5nIGNvcnJlY3Q/IElmIHllcyBJIHN1Z2dlc3QgdG8gc3RhdGUgaXQgaW4gdGhlIHRl eHQgYW5kIHBvc3NpYmx5IGFkZCB3aHkgdGhlIFUgYml0IGlzIGFsd2F5cyAxIGluIHlvdXIgY2Fz ZSBhbmQgdGhlIEYgYml0IGlzIGFsd2F5cyAwLg0KDQpUaGFua3MgZm9yIHRoZSBleHBsYW5hdGlv bg0KRGFuaWVsZQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1hY2gg Q2hlbiBbbWFpbHRvOm1hY2guY2hlbkBodWF3ZWkuY29tXQ0KPiBTZW50OiBtZXJjb2xlZMOsIDI1 IG1hZ2dpbyAyMDE2IDExOjAyDQo+IFRvOiBEYW5pZWxlIENlY2NhcmVsbGkgPGRhbmllbGUuY2Vj Y2FyZWxsaUBlcmljc3Nvbi5jb20+OyA8cnRnLWFkc0BpZXRmLm9yZz4NCj4gKHJ0Zy1hZHNAaWV0 Zi5vcmcpIDxydGctYWRzQGlldGYub3JnPg0KPiBDYzogcnRnLWRpckBpZXRmLm9yZzsgZHJhZnQt aWV0Zi1wYWxzLW1wbHMtdHAtcHctb3Zlci1iaWRpci0NCj4gbHNwLmFsbEB0b29scy5pZXRmLm9y ZzsgcGFsc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogUnRnRGlyIHJldmlldzogZHJhZnQtaWV0 Zi1wYWxzLW1wbHMtdHAtcHctb3Zlci1iaWRpci1sc3AtMDYNCj4gDQo+IEhpIERhbmllbGUsDQo+ IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogRGFuaWVsZSBDZWNj YXJlbGxpIFttYWlsdG86ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbV0NCj4gPiBTZW50 OiBXZWRuZXNkYXksIE1heSAyNSwgMjAxNiA0OjA4IFBNDQo+ID4gVG86IE1hY2ggQ2hlbjsgPHJ0 Zy1hZHNAaWV0Zi5vcmc+IChydGctYWRzQGlldGYub3JnKQ0KPiA+IENjOiBydGctZGlyQGlldGYu b3JnOw0KPiA+IGRyYWZ0LWlldGYtcGFscy1tcGxzLXRwLXB3LW92ZXItYmlkaXItbHNwLmFsbEB0 b29scy5pZXRmLm9yZzsNCj4gPiBwYWxzQGlldGYub3JnDQo+ID4gU3ViamVjdDogUkU6IFJ0Z0Rp ciByZXZpZXc6DQo+ID4gZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtcHctb3Zlci1iaWRpci1sc3At MDYNCj4gPg0KPiA+IEhpIE1hY2gsDQo+ID4NCj4gPiBUaGFua3MgZm9yIHRoZSB1cGRhdGUuDQo+ ID4gVGhlcmUgaXMganVzdCBvbmUgb3V0c3RhbmRpbmcgcG9pbnQ6DQo+ID4NCj4gPiA+IOKAoiBT ZWN0aW9uIDIuMTog4oCcTERQIExhYmVsIE1hcHBpbmcgbWVzc2FnZeKAnSBtaXNzaW5nIHJlZmVy ZW5jZS4gQW5kDQo+ID4gPiB3aHkgdGhlIFR5cGUgZmllbGQgc3RhcnRzIHdpdGggMSBhbmQgMD8N Cj4gPiBUaGFua3MgZm9yIGFkZGluZyB0aGUgcmVmZXJlbmNlIGJ1dCBJIHN0aWxsIGRvbid0IGdl dCB3aHkgdGhlIFR5cGUNCj4gPiBmaWVsZCBzdGFydHMgd2l0aCAxIGFuZCAwLg0KPiANCj4gVGhl IGZpcnN0IHR3byBiaXRzIGFyZSBVLWJpdCBhbmQgRi1iaXQsIHdoaWNoIGFyZSBkZWZpbmVkIGlu IFNlY3Rpb24gMy4zIG9mDQo+IFJGQzUwMzYuIEhvdyBhYm91dCBhZGRpbmcgdGhlIGZvbGxvdyB0 ZXh0Og0KPiANCj4gRm9yIHRoaXMgVExWLCB0aGUgVW5rbm93biBUTFYgYml0IChVLWJpdCkgKFNl Y3Rpb24gMy4zIG9mIFJGQzUwMzYpIGlzIHNldCB0byAxLA0KPiBhbmQgdGhlIEZvcndhcmRpbmcg dW5rbm93biBiaXQgKEYtYml0KSAoU2VjdGlvbiAzLjMgb2YgUkZDNTAzNikgaXMgc2V0IHRvIDAu DQo+IA0KPiA+IE9uZSBtb3JlIGNvbW1lbnQgdGhhdCBJIGxvc3QgZHVyaW5nIHRoZSBmaXJzdCBp dGVyYXRpb246IHdoeSBkbyB5b3UNCj4gPiBkZWZpbmUgdGhlICJmbGFnIiBmaWVsZCBpbiBmaWd1 cmUgMyBhbmQgdGhlbiBiZWxvdyBoYXZlIGEgZnVydGhlcg0KPiA+IGZpZ3VyZSBzaG93aW5nIEMs IFMsIFQgYW5kIHRoZSBtdXN0IGJlIHplcm8gZmllbGQ/IEknZCBkaXJlY3RseSBwdXQNCj4gPiB0 aGUgQyxTLFQgYW5kIG11c3QgYmUgemVybyBmaWVsZHMgaW4gcGxhY2Ugb2YgdGhlIEZsYWcgZmll bGQgaW4gZmlndXJlIDMuIEl0DQo+IGhlbHBzIHdpdGggcmVhZGFiaWxpdHkgSU1ITy4NCj4gDQo+ IE9LLCB3aWxsIHB1dCB0aGVtIGJhY2sgdG8gdGhlIFRMViBhbmQgcmVtb3ZlIHRoZSBmbGFncyBm aWd1cmUuDQo+IA0KPiANCj4gSG9wZSBhYm92ZSBhZGRyZXNzIHlvdXIgY29tbWVudHMhDQo+IA0K PiBUaGFua3MsDQo+IE1hY2gNCj4gPg0KPiA+DQo+ID4gQlINCj4gPiBEYW5pZWxlDQo+ID4NCj4g PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBNYWNoIENoZW4gW21h aWx0bzptYWNoLmNoZW5AaHVhd2VpLmNvbV0NCj4gPiA+IFNlbnQ6IHZlbmVyZMOsIDEzIG1hZ2dp byAyMDE2IDA5OjI1DQo+ID4gPiBUbzogRGFuaWVsZSBDZWNjYXJlbGxpIDxkYW5pZWxlLmNlY2Nh cmVsbGlAZXJpY3Nzb24uY29tPjsNCj4gPiA+IDxydGctYWRzQGlldGYub3JnPg0KPiA+ID4gKHJ0 Zy1hZHNAaWV0Zi5vcmcpIDxydGctYWRzQGlldGYub3JnPg0KPiA+ID4gQ2M6IHJ0Zy1kaXJAaWV0 Zi5vcmc7IGRyYWZ0LWlldGYtcGFscy1tcGxzLXRwLXB3LW92ZXItYmlkaXItDQo+ID4gPiBsc3Au YWxsQHRvb2xzLmlldGYub3JnOyBwYWxzQGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBSRTogUnRn RGlyIHJldmlldzoNCj4gPiA+IGRyYWZ0LWlldGYtcGFscy1tcGxzLXRwLXB3LW92ZXItYmlkaXIt bHNwLTA2DQo+ID4gPg0KPiA+ID4gSGkgRGFuaWVsZSwNCj4gPiA+DQo+ID4gPiBUaGFua3MgZm9y IHRoZSBkZXRhaWxlZCByZXZpZXcgYW5kIHZhbHVhYmxlIGNvbW1lbnRzIQ0KPiA+ID4NCj4gPiA+ IFBsZWFzZSBzZWUgbXkgcmVzcG9uc2VzIGlubGluZS4uLg0KPiA+ID4NCj4gPiA+IEkgYWxzbyBh dHRhY2hlZCBhIGRpZmYgdGhhdCBzaG93cyB0aGUgdXBkYXRlcyB0aGF0IHRyeSB0byBhZGRyZXNz DQo+ID4gPiB5b3VyIGNvbW1lbnRzLiBJZiB5b3UgYXJlIE9LIHdpdGggdGhlIHVwZGF0ZXMsIEkg d2lsbCBzdWJtaXQgaXQgdGhlbi4NCj4gPiA+DQo+ID4gPiBUaGFua3MsDQo+ID4gPiBNYWNoDQo+ ID4gPg0KPiA+ID4gPiBGcm9tOiBEYW5pZWxlIENlY2NhcmVsbGkNCj4gPiA+ID4gU2VudDogbHVu ZWTDrCAyNSBhcHJpbGUgMjAxNiAxOTowNA0KPiA+ID4gPiBUbzogPHJ0Zy1hZHNAaWV0Zi5vcmc+ IChydGctYWRzQGlldGYub3JnKQ0KPiA+ID4gPiBDYzogJ3J0Zy1kaXJAaWV0Zi5vcmcnOyAnZHJh ZnQtaWV0Zi1wYWxzLW1wbHMtdHAtcHctb3Zlci1iaWRpci0NCj4gbHNwLmFsbEBpZXRmLm9yZycN Cj4gPiA+ID4gU3ViamVjdDogUnRnRGlyIHJldmlldzoNCj4gPiA+ID4gZHJhZnQtaWV0Zi1wYWxz LW1wbHMtdHAtcHctb3Zlci1iaWRpci1sc3AtMDYNCj4gPiA+ID4NCj4gPiA+ID4gSGVsbG8sDQo+ ID4gPiA+IEkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJl dmlld2VyIGZvciB0aGlzDQo+ID4gPiA+IGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBz ZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3INCj4gPiA+ID4gcm91dGluZy1yZWxhdGVkIGRy YWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQNCj4gPiA+ID4gSUVT RyByZXZpZXcsDQo+ID4gPiBhbmQgc29tZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVzdC4NCj4gPiA+ ID4gVGhlIHB1cnBvc2Ugb2YgdGhlIHJldmlldyBpcyB0byBwcm92aWRlIGFzc2lzdGFuY2UgdG8g dGhlIFJvdXRpbmcgQURzLg0KPiA+ID4gPiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUg Um91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZQ0KPiA+ID4gPiBodHRwOi8vdHJhYy50b29s cy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyDQo+ID4gPiA+IEFsdGhvdWdoIHRo ZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcNCj4g PiA+ID4gQURzLCBpdCB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVt IGFsb25nIHdpdGggYW55DQo+ID4gPiA+IG90aGVyIElFVEYgTGFzdCBDYWxsIGNvbW1lbnRzIHRo YXQgeW91IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8NCj4gPiA+ID4gcmVzb2x2ZSB0aGVtIHRocm91 Z2ggZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuDQo+ID4gPiA+IERvY3VtZW50 OsKgZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtcHctb3Zlci1iaWRpci1sc3AtMDYNCj4gPiA+ID4g UmV2aWV3ZXI6IERhbmllbGUgQ2VjY2FyZWxsaQ0KPiA+ID4gPiBSZXZpZXcgRGF0ZTogQXByaWwg MjUgMjAxNg0KPiA+ID4gPiBJRVRGIExDIEVuZCBEYXRlOiAtDQo+ID4gPiA+IEludGVuZGVkIFN0 YXR1czogU3RhbmRhcmQgVHJhY2sNCj4gPiA+ID4gU3VtbWFyeToNCj4gPiA+ID4g4oCiIEkgaGF2 ZSBzb21lIG1pbm9yIGNvbmNlcm5zIGFib3V0IHRoaXMgZG9jdW1lbnQgdGhhdCBJIHRoaW5rDQo+ ID4gPiA+IHNob3VsZCBiZSByZXNvbHZlZCBiZWZvcmUgcHVibGljYXRpb24uDQo+ID4gPiA+IENv bW1lbnRzOg0KPiA+ID4gPiDigKIgV2hhdCB0aGUgZHJhZnRzIGlzIHByb3Bvc2luZyBhcyBwcm90 b2NvbCBtb2RpZmljYXRpb24gaXMgY2xlYXINCj4gPiA+ID4gYW5kIGFsc28gdGhlIG9wZXJhdGlv biBzZWN0aW9uIGFyZSBwcmV0dHkgc3RyYWlnaGZvcndhcmQuIFdoYXQNCj4gPiA+ID4gbmVlZHMg dG8gYmUgaW1wcm92ZWQgaXMgdGhlIGludHJvZHVjdGlvbiBwYXJ0LCB3aGljaCBzaG91bGQgYmUN Cj4gPiA+ID4gcmV2aWV3ZWQgYnkgYSBuYXRpdmUgRW5nbGlzaCBzcGVha2VyLiBBbHNvIHRoZSBJ QU5BIHNlY3Rpb24gc2hvdWxkIGJlDQo+IG1hZGUgY2xlYXJlci4NCj4gPiA+DQo+ID4gPiBUaGFu a3MgZm9yIHlvdXIgc3VnZ2VzdGlvbiwgSSBhc3N1bWUgdGhlIFJGQyBlZGl0b3Igd2lsbCBkbyBh bm90aGVyDQo+ID4gPiByZXZpZXcgb25jZSB0aGUgZG9jdW1lbnQgcHJvZ3Jlc3NlZCB0byB0aGF0 IHN0YWdlLg0KPiA+ID4NCj4gPiA+ID4gTWFqb3IgSXNzdWVzOg0KPiA+ID4gPiDigKIgTm8gbWFq b3IgaXNzdWVzIGZvdW5kDQo+ID4gPiA+IE1pbm9yIElzc3VlczoNCj4gPiA+ID4g4oCiIEFic3Ry YWN0OiDigJxJbiBhZGRpdGlvbiwgdGhlIHVzZXIgdHJhZmZpYyBtYXkgdHJhdmVyc2UgdGhyb3Vn aA0KPiA+ID4gPiBtdWx0aXBsZSB0cmFuc3BvcnQgbmV0d29ya3Mu4oCdIE1heWJlIGlzIHdvcnRo IGVsYWJvcmF0aW5nIGEgYml0DQo+ID4gPiA+IHRoaXMgc2VudGVuY2Ugc2F5aW5nIHRoYXQgdGhl IGV4dGVuc2lvbnMgZGVmaW5lZCBpbiB0aGlzIGRyYWZ0DQo+ID4gPiA+IGFwcGx5IGJvdGggdG8g U1MtDQo+ID4gPiBQVyBhbmQgTVMtUFcuDQo+ID4gPg0KPiA+ID4gSG93IGFib3V0IHRoaXM6DQo+ ID4gPg0KPiA+ID4gIk1hbnkgdHJhbnNwb3J0IHNlcnZpY2VzIHJlcXVpcmUgdGhhdCB1c2VyIHRy YWZmaWMsIGluIHRoZSBmb3JtIG9mDQo+ID4gPiBQc2V1ZG93aXJlcyAoUFcpLCBiZSBkZWxpdmVy ZWQgb24gYSBzaW5nbGUgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwNCj4gPiA+IHR1bm5lbCBvciB0 d28gdHVubmVscyB0aGF0IHNoYXJlIHRoZSBzYW1lIHJvdXRlcy4gVGhpcyBkb2N1bWVudA0KPiA+ ID4gZGVmaW5lcyBhbiBvcHRpb25hbCBleHRlbnNpb24gdG8gTERQIHRoYXQgZW5hYmxlcyB0aGUg YmluZGluZw0KPiA+ID4gYmV0d2VlbiBQV3MgYW5kIHRoZSB1bmRlcmx5aW5nIFRFIHR1bm5lbHMu IFRoZSBleHRlbnNpb24gYXBwbGllcyB0bw0KPiA+ID4gYm90aCBTUy1QVyBhbmQNCj4gPiBNUy1Q Vy4iDQo+ID4gPg0KPiA+ID4gPiDigKIgSW4gdGhlIGFic3RyYWN0IGl0IGlzIHNhaWQgdGhhdCBh IFBXIGlzIGxpbmtlZCB0byBhbiBMU1AgYnV0DQo+ID4gPiA+IHRoZW4gaW4gdGhlIGludHJvIGl0 IGlzIHNhaWQgdGhhdCB0aGUgUFcgYmluZGluZyBpcyB0byBhIHR1bm5lbC4NCj4gPiA+ID4gQ2Fu IHlvdSBjbGFyaWZ5IHRoaXM/IEnigJlkIHNheSB0aGF0IGl0IHNob3VsZCBiZSBsaW5rZWQgdG8g YSB0dW5uZWwsIHJpZ2h0Pw0KPiA+ID4NCj4gPiA+IFllcywgaXQncyBiZXR0ZXIgdG8gdXNlIHR1 bm5lbCwgSSBoYXZlIHVwZGF0ZWQgdGhlIGFic3RyYWN0IHRvIG1ha2UNCj4gPiA+IEFic3RyYWN0 IGFuZCBJbnRyb2R1Y3Rpb24gaGF2ZSB0aGUgY29uc2lzdGVudCB1c2FnZS4gUGxlYXNlIHNlZQ0K PiA+ID4gYWJvdmUgdGhlIG5ldyB0ZXh0IGZvciBBYnN0cmFjdC4NCj4gPiA+DQo+ID4gPiA+IOKA oiBJbnRybzrCoMKgIOKAnFBXLXRvLVBTTiBUdW5uZWwgYmluZGluZyBoYXMgYmVjb21lIGluY3Jl YXNpbmdseQ0KPiA+ID4gPiBjb21tb24gYW5kIGltcG9ydGFudCBpbiBtYW55IGRlcGxveW1lbnQg c2NlbmFyaW9z4oCdLiBJIGd1ZXNzIHlvdQ0KPiA+ID4gPiBtZWFuIGFuIGF1dG9tYXRpYyBiaW5k aW5nIGRvbmUgdmlhIGEgc2lnbmFsaW5nIHByb3RvY29sPw0KPiA+ID4NCj4gPiA+IE5vLCB0aGlz IHNlbnRlbmNlIGp1c3QgYnJpbmdzIHRoZSByZXF1aXJlbWVudHMgb2YgZXhwbGljaXQgUFcgdG8g UFNODQo+ID4gPiB0dW5uZWwgYmluZGluZywgd2hhdGV2ZXIgaXQgaXMgYXV0b21hdGljIHNpZ25h bGluZyBvciBtYW51YWwgY29uZmlndXJhdGlvbi4NCj4gPiA+DQo+ID4gPiA+IOKAoiBXaGF0IGRv IHlvdSBtZWFuIHdpdGgg4oCcbWF5IHRyYXZlcnNlIHRocm91Z2ggZGlmZmVyZW50IHJvdXRlc+KA nT8gSQ0KPiA+ID4gPiBzdWdnZXN0IGxlYXZpbmcg4oCcbWF5IHRyYXZlcnNlIG11bHRpcGxlIG5l dHdvcmtzIG9yIGRvbWFpbnMuDQo+ID4gPg0KPiA+ID4gSGVyZSB0aGUgInJvdXRlcyIgbWVhbnMg InBhdGhzIi4NCj4gPiA+DQo+ID4gPiBIb3cgYWJvdXQ6ICIuLi5tYXkgdHJhdmVyc2UgdGhyb3Vn aCBkaWZmZXJlbnQgcGF0aHMgb3IgbmV0d29ya3MiPw0KPiA+ID4NCj4gPiA+ID4g4oCiIEludHJv IGFuZCBGaWd1cmUgMTogY291bGQgYmUgZXhhbXBsZSBiZSBtYWRlIGEgYml0IG1vcmUgZ2VuZXJp Yw0KPiA+ID4gPiB3aXRoIGEgbmV0d29yayBiZXR3ZWVuIHRoZSBQRXM/IFdpdGggZGlyZWN0bHkg Y29ubmVjdGVkIFBFcyBpdA0KPiA+ID4gPiBkb2VzbuKAmXQgc2VlbSBhIHJlYWxpc3RpYyBhbmQg Z2VuZXJpYyBlbm91Z2ggZXhhbXBsZS4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gPiDigKIgSW50cm86 IHN1Z2dlc3QgcmVtb3Zpbmcg4oCcQXMgbWVudGlvbmVkIGFib3Zl4oCdLg0KPiA+ID4NCj4gPiA+ IE9LLg0KPiA+ID4NCj4gPiA+ID4g4oCiIMKgVGhlIG5hbWUgb2YgdGhlIGRyYWZ0IGV4cGxpY2l0 bHkgbWVudGlvbnMgTVBMUy1UUCBidXQgaW4gdGhlDQo+ID4gPiA+IHJlc3Qgb2YgdGhlIGRyYWZ0 IHRoZXJlIGlzIG5vIG1lbnRpb24gb2YgaXQsIGp1c3QgdGhlIG11Y2ggbW9yZQ0KPiA+ID4gPiBn ZW5lcmFsIFBhY2tldCBTd2l0Y2hpbmcgTmV0d29yayB0ZXJtIGlzIHVzZWQuDQo+ID4gPg0KPiA+ ID4gSW5kZWVkLCB0aGF0J3MgdGhlIGludGVudGlvbi4gVGhpcyB3b3JrIHdhcyB0cmlnZ2VyZWQg YnkgdGhlDQo+ID4gPiBkaXNjdXNzaW9uIG9mIE1QTFMtVFAuIEJ1dCB3aXRoIHRoZSBwcm9ncmVz cyBvZiB0aGlzIGRyYWZ0IGFuZA0KPiA+ID4gZGlzY3Vzc2lvbiB3aXRoaW4gdGhlIFdHLCB0aGVy ZSBpcyBhIGNvbnNlbnN1cyB0aGF0IHRoaXMgdGVjaG5pcXVlDQo+ID4gPiBpcyBhIGdlbmVyYWwg c29sdXRpb24gdGhhdCBjYW4gYWN0dWFsbHkgYXBwbHkgdG8gYm90aCBUUCBhbmQgbm9uLVRQIGNh c2VzLg0KPiA+ID4NCj4gPiA+ID4g4oCiIFNlY3Rpb24gMjrCoMKgIOKAnFRoaXMgZG9jdW1lbnQg ZGVmaW5lcyBhIG5ldyBvcHRpb25hbCBUTFYsIFBTTg0KPiA+ID4gPiBUdW5uZWwgQmluZGluZyBU TFYsIHRvIGNvbW11bmljYXRlIHR1bm5lbC9MU1BzIHNlbGVjdGlvbiBhbmQNCj4gPiA+ID4gYmlu ZGluZyByZXF1ZXN0cw0KPiA+ID4gYmV0d2VlbiBQRXMuDQo+ID4gPiA+IOKAnCBUaGUgYmluZGlu ZyByZXF1ZXN0IGlzIGJldHdlZW4gUEVzPyBPciBiZXR3ZWVuIGFuIFBXIGFuZCBhDQo+ID4gPiA+ IFR1bm5lbCAob3IgTFNQPykgYmV0d2VlbiB0d28gUEVzPw0KPiA+ID4NCj4gPiA+IEJldHdlZW4g UEVzIG9mIGFuIFBXLg0KPiA+ID4NCj4gPiA+ID4g4oCiIFNlY3Rpb24gMjogU3RyaWN0IGJpbmRp bmcgdnMgQ28tcm91dGVkIGJpbmRpbmc6IGZyb20gdGhlDQo+ID4gPiA+IGRlc2NyaXB0aW9uIGl0 IHNlZW1zIHRoYXQgdGhlIGZpcnN0IG9uZSBpcyBzdHJpY3QgYW5kIHRoZSBzZWNvbmQNCj4gPiA+ ID4gb25lIGlzDQo+ID4g4oCcbG9vc2XigJ0NCj4gPiA+ID4gKGluIHRoZSBzZW5zZSB0aGF0IHRo ZSBQRSBjYW4gYWNjZXB0IHRoZSByZXF1ZXN0IG9yIG5vdCkuIERvbuKAmXQNCj4gPiA+ID4gYm90 aCBhcHBseQ0KPiA+ID4gdG8gY28tcm91dGVkIExTUHM/DQo+ID4gPg0KPiA+ID4gWWVzLCBib3Ro IGNhbiBhcHBseSB0byBjby1yb3V0ZWQgTFNQcy4gQnV0IGZvciAic3RyaWN0IiBtb2RlLCBpZiB0 aGUNCj4gPiA+IGVncmVzcyBQRSBtdXN0IGJpbmQgdG8gdGhlIHNwZWNpZmllZCB0dW5uZWwgYnkg dGhlIGluZ3Jlc3MgUEUsDQo+ID4gPiBvdGhlcndpc2UsIHRoZSBiaW5kaW5nIHdpbGwgbm90IHN1 Y2Nlc3MuIFRoZSAiY28tcm91dGVkIiBtb2RlIGdpdmVzDQo+ID4gPiB0aGUgZWdyZXNzIFBFIHRo ZSB1c2UgYWx0ZXJuYXRpdmUgdHVubmVsLg0KPiA+ID4NCj4gPiA+ID4g4oCiIFNlY3Rpb24gMjog 4oCdVGhlIHRlcm1pbm9sb2d5ICJMU1AiIGlzwqAgaWRlbnRpY2FsIHRvIHRoZSAiTFNQIHR1bm5l bCINCj4gPiA+ID4gZGVmaW5lZCBpbiBTZWN0aW9uIDIuMSBvZiBbUkZDMzIwOV0swqAgd2hpY2gg aXMgdW5pcXVlbHkgaWRlbnRpZmllZA0KPiA+ID4gPiBieSB0aGUgU0VTU0lPTiBvYmplY3QgdG9n ZXRoZXIgd2l0aMKgIFNFTkRFUl9URU1QTEFURSAob3INCj4gPiA+ID4gRklMVEVSX1NQRUMpIG9i amVjdCB0aGF0IGNvbnNpc3RzIG9mIExTUCBJRCBhbmQgVHVubmVsIGVuZHBvaW50DQo+ID4gPiA+ IGFkZHJlc3Mu4oCdIFdoeSBpcyB0aGUgZHJhZnQgY29uc2lkZXJpbmcgb25seSBzaWduYWxlZCBM U1BzPyBEb2VzbuKAmXQNCj4gPiA+ID4gaXQgYXBwbHkgYWxzbyB0byBjZW50cmFsbHkNCj4gPiA+ IHByb3Zpc2lvbmVkIG9uZXM/IChlLmcuIE5NUyBvciBTRE4pLg0KPiA+ID4NCj4gPiA+IFRoZSBt YWluIHB1cnBvc2UgaGVyZSBpcyB0byBnaXZlIGEgcmVmZXJlbmNlIHRvIHRoZSB0ZXJtIG9mICJM U1AiDQo+ID4gPiBhbmQgInR1bm5lbCIsIGhlbmNlIHRvIGVsaW1pbmF0ZSB0aGUgY29uZnVzaW9u IG9mIHdoZW4gdXNlIHRoZXNlIGluDQo+ID4gPiB0aGUgZm9sbG93aW5nIHNlY3Rpb25zLiBBcyBm b3IgdGhlIE5NUyBhbmQgU0ROIGJhc2VkIFRFIExTUC9UdW5uZWwsDQo+ID4gPiB0ZWNobmljYWxs eSwgaXQgY2FuIGFwcGx5IHRvIGFzIHdlbGwgb25seSBpZiB0aGUgVEUgTFNQL1R1bm5lbCBoYXMN Cj4gPiA+IHRoZSBMU1AgbnVtYmVyLCBub2RlIElEIGV0Yy4gaW5mb3JtYXRpb24uDQo+ID4gPg0K PiA+ID4gPiDigKIgU2VjdGlvbiAyLjE6IOKAnExEUCBMYWJlbCBNYXBwaW5nIG1lc3NhZ2XigJ0g bWlzc2luZyByZWZlcmVuY2UuIEFuZA0KPiA+ID4gPiB3aHkgdGhlIFR5cGUgZmllbGQgc3RhcnRz IHdpdGggMSBhbmQgMD8NCj4gPiA+DQo+ID4gPiBHb29kIGNhdGNoLCB3aWxsIGFkZCBhIHJlZmVy ZW5jZSBoZXJlLg0KPiA+ID4NCj4gPiA+DQo+ID4gPiA+IE5pdHM6DQo+ID4gPiA+IOKAoiBBYnN0 cmFjdCBzLyB0cmF2ZXJzZSB0aHJvdWdoIG11bHRpcGxlLyB0cmF2ZXJzZSBtdWx0aXBsZSDigKIN Cj4gSW50cm9kdWN0aW9uOg0KPiA+ID4gPiDigJxQc2V1ZG93aXJlIChQVykgRW11bGF0aW9uIEVk Z2UtdG8tRWRnZSAoUFdFMynigJ0uIEkgc3VnZ2VzdA0KPiA+ID4gPiByZW1vdmluZyAoUFcpLCBp dOKAmXMgYWxyZWFkeSBpbmNsdWRlZCBpbnRvIFBXRTMuDQo+ID4gPg0KPiA+ID4gT0suDQo+ID4g PiA+IOKAoiBJbnRybzogcy8gYSBiaWRpcmVjdGlvbmFsIGNpcmN1aXRzLyBhIGJpZGlyZWN0aW9u YWwgY2lyY3VpdA0KPiA+ID4NCj4gPiA+IE9LLg0KPiA+ID4NCj4gPiA+IOKAoiBJbnRybzogc3Vn Z2VzdA0KPiA+ID4gPiByZXBocmFzaW5nOiDigJxCaWRpcmVjdGlvbmFsIExTUHMgc2hhcmUgZmF0 ZSBhbmQgc2ltcGxpZnkgdGhlDQo+ID4gPiA+IHJvdXRpbmcgb2YgYSBwcm90ZWN0aW9uIHBhdGgg YWxzbyBjb25zaXN0aW5nIG9mIGJpZGlyZWN0aW9uYWwNCj4gPiA+ID4gTFNQcyBiZWNhdXNlIHdv cmtpbmcgYW5kIHByb3RlY3Rpb24gcGF0aHMgaGF2ZSB0byBiZSBkaXNqb2ludC7igJ0NCj4gPiA+ DQo+ID4gPiBPSy4NCj4gPiA+DQo+ID4gPiA+IOKAoiBJbnRybzogcy8gdGhlcmUgYXJlIGEgbGFy Z2UgbnVtYmVyLyB0aGVyZSBpcyBhIGxhcmdlIG51bWJlcg0KPiA+ID4NCj4gPiA+IE9LLg0KPiA+ ID4NCj4gPiA+IOKAoiBJbnRybzpzL3RvIGJlDQo+ID4gPiA+IGNhcnJpZWQvYXJlIGNhcnJpZWQN Cj4gPiA+DQo+ID4gPiBPSy4NCj4gPiA+DQo+ID4gPiDigKIgSW50cm86cy90aGVyZSBhcmUgYSBu dW1iZXIvdGhlcmUgaXMgYSBudW1iZXINCj4gPiA+DQo+ID4gPiBPSy4NCj4gPiA+DQo+ID4gPiDi gKIgSW50cm86IHMvDQo+ID4gPiA+IHRyYWZmaWMgYmVsb25ncy90cmFmZmljIGJlbG9uZ2luZw0K PiA+ID4NCj4gPiA+IE9LLg0KPiA+ID4NCj4gPiA+IOKAoiBJbnRybzogKHN1Z2dlc3Rpb24pIHMv KFBFMS1QMy1QRTIpLw0KPiA+ID4gPiAoUEUyLVAzLVBFMSkgc2luY2Ugd2UgYXJlIHNwZWFraW5n IGFib3V0IGRpcmVjdGlvbmFsaXR5IGl0IG1ha2VzDQo+ID4gPiA+IG1vcmUgc2Vuc2UgdG8gbGlz dCB0aGUgbm9kZXMgb2YgdGhlIHBhdGggaW4gdGhlIHJldmVyc2UgZGlyZWN0aW9uLg0KPiA+ID4N Cj4gPiA+IE9LLg0KPiA+ID4NCj4gPiA+ID4g4oCiIEludHJvOiBzLyBUaGUgc2ltaWxhciBwcm9i bGVtcy9BIHNpbWlsYXIgcHJvYmxlbQ0KPiA+ID4NCj4gPiA+IE9LLg0KPiA+ID4NCj4gPiA+ID7i gKIgSW50cm86IHMvIHdvbid0L2RvZXMgbm90DQo+ID4gPg0KPiA+ID4gT0suDQo+ID4gPiA+4oCi SW50cm86IHMvIEluIHRoaXMgZG9jdW1lbnQsIGl0IGludHJvZHVjZXMvVGhpcyBkb2N1bWVudCBp bnRyb2R1Y2VzDQo+ID4gPiA+QlIgRGFuaWVsZQ0KPiA+ID4NCj4gPiA+IE9LLg0KPiA+ID4NCj4g PiA+ID4NCg0K From nobody Wed May 25 02:47:17 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1747F12D64D; Wed, 25 May 2016 02:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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=-1.426, 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 YUBN581riXPO; Wed, 25 May 2016 02:47:14 -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 65F1012D649; Wed, 25 May 2016 02:47:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKS08428; Wed, 25 May 2016 09:47:06 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 25 May 2016 10:47:04 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.42]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0235.001; Wed, 25 May 2016 17:46:59 +0800 From: Mach Chen To: Daniele Ceccarelli , " (rtg-ads@ietf.org)" Thread-Topic: RtgDir review: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06 Thread-Index: AdGe+Z/lFOzQc8O7SFSbqLe7ce8oewAG1OFwA2v05+AAAARS8AJlk/FwAAHw8kAAAKspgAABGaww Date: Wed, 25 May 2016 09:46:59 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE48162EBD1D@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE48162EBF6F@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48162EBF6F@ESESSMB301.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.135] 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.0A090205.5745749A.00B2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.42, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c1bd2077fdb78ac4453c9ffedee5bcb7 Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-pals-mpls-tp-pw-over-bidir-lsp.all@tools.ietf.org" , "pals@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 09:47:17 -0000 SGkgRGFuaWVsZSwNCg0KWWVzLCB5b3VyIHVuZGVyc3RhbmRpbmcgaXMgcmlnaHQuIEhvdyBhYm91 dCBhZGQgdGhlIGZvbGxvd2luZyB0ZXh0Og0KDQpUaGUgVS1iaXQgYW5kIEYtYml0IGFyZSBkZWZp bmVkIFNlY3Rpb24gMy4zIFJGQzUwMzYuIFNpbmNlIHRoZSBQU04gVHVubmVsIEJpbmRpbmcgVExW IGlzIGFuIG9wdGlvbmFsIFRMViwgdGhlIFUtYml0IE1VU1QgYmUgc2V0IHRvIDEgc28gdGhhdCBh IHJlY2VpdmVyIE1VU1Qgc2lsZW50bHkgaWdub3JlIHRoaXMgVExWIGlmIHVua25vd24gdG8gaXQs IGFuZCBjb250aW51ZSBwcm9jZXNzaW5nIHRoZSByZXN0IG9mIHRoZSBtZXNzYWdlLiANCkEgcmVj ZWl2ZXIgb2YgdGhpcyBUTFYgaXMgbm90IGFsbG93ZWQgdG8gZm9yd2FyZCB0aGUgVExWIGZ1cnRo ZXIgd2hlbiBpdCBkb2VzIG5vdCBrbm93IHRoZSBUTFYuIFNvLCB0aGUgRi1iaXQgTVVTVCBiZSBz ZXQgdG8gMC4NCg0KVGhhbmtzLA0KTWFjaCANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBEYW5pZWxlIENlY2NhcmVsbGkgW21haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlA ZXJpY3Nzb24uY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIE1heSAyNSwgMjAxNiA1OjIxIFBNDQo+ IFRvOiBNYWNoIENoZW47IDxydGctYWRzQGlldGYub3JnPiAocnRnLWFkc0BpZXRmLm9yZykNCj4g Q2M6IHJ0Zy1kaXJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtcGFscy1tcGxzLXRwLXB3LW92ZXItYmlk aXItbHNwLmFsbEB0b29scy5pZXRmLm9yZzsNCj4gcGFsc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBS RTogUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtcHctb3Zlci1iaWRpci1s c3AtMDYNCj4gDQo+IEhpIE1hY2gsDQo+IA0KPiBPaywgbGV0IG1lIHRyeSB0byBzdW1tYXJpemUu DQo+IA0KPiBUaGUgZHJhZnQgZGVmaW5lcyBhIG5ldyBUTFYgZm9yIHRoZSBMRFAgTWFwcGluZyBN ZXNzYWdlIChSRkMgNTAzNiBzZWN0aW9uDQo+IDMuNS43KSB3aGljaCBJIGd1ZXNzIHdvdWxkIGVu ZCB1cCBpbiB0aGUgIm9wdGlvbmFsIHBhcmFtZXRlcnMiIGZpZWxkICh0aGUgdGV4dA0KPiBzYXlz OiAiY29udGFpbnMgMCBvciBtb3JlIHBhcmFtZXRlcnMsIGVhY2ggZW5jb2RlZCBhcyBhIFRMViIp Lg0KPiBUaGVuIHNlY3Rpb24gMy4zIG1hbmRhdGVzIGhvdyB0byBidWlsZCB0aG9zZSBUTFZzIChV LCBGIGFuZCBzbyBvbikuDQo+IA0KPiBJZiBteSB1bmRlcnN0YW5kaW5nIGNvcnJlY3Q/IElmIHll cyBJIHN1Z2dlc3QgdG8gc3RhdGUgaXQgaW4gdGhlIHRleHQgYW5kIHBvc3NpYmx5DQo+IGFkZCB3 aHkgdGhlIFUgYml0IGlzIGFsd2F5cyAxIGluIHlvdXIgY2FzZSBhbmQgdGhlIEYgYml0IGlzIGFs d2F5cyAwLg0KPiANCj4gVGhhbmtzIGZvciB0aGUgZXhwbGFuYXRpb24NCj4gRGFuaWVsZQ0KPiAN Cj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IE1hY2ggQ2hlbiBbbWFp bHRvOm1hY2guY2hlbkBodWF3ZWkuY29tXQ0KPiA+IFNlbnQ6IG1lcmNvbGVkw6wgMjUgbWFnZ2lv IDIwMTYgMTE6MDINCj4gPiBUbzogRGFuaWVsZSBDZWNjYXJlbGxpIDxkYW5pZWxlLmNlY2NhcmVs bGlAZXJpY3Nzb24uY29tPjsNCj4gPiA8cnRnLWFkc0BpZXRmLm9yZz4NCj4gPiAocnRnLWFkc0Bp ZXRmLm9yZykgPHJ0Zy1hZHNAaWV0Zi5vcmc+DQo+ID4gQ2M6IHJ0Zy1kaXJAaWV0Zi5vcmc7IGRy YWZ0LWlldGYtcGFscy1tcGxzLXRwLXB3LW92ZXItYmlkaXItDQo+ID4gbHNwLmFsbEB0b29scy5p ZXRmLm9yZzsgcGFsc0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJFOiBSdGdEaXIgcmV2aWV3Og0K PiA+IGRyYWZ0LWlldGYtcGFscy1tcGxzLXRwLXB3LW92ZXItYmlkaXItbHNwLTA2DQo+ID4NCj4g PiBIaSBEYW5pZWxlLA0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ ID4gRnJvbTogRGFuaWVsZSBDZWNjYXJlbGxpIFttYWlsdG86ZGFuaWVsZS5jZWNjYXJlbGxpQGVy aWNzc29uLmNvbV0NCj4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDI1LCAyMDE2IDQ6MDggUE0N Cj4gPiA+IFRvOiBNYWNoIENoZW47IDxydGctYWRzQGlldGYub3JnPiAocnRnLWFkc0BpZXRmLm9y ZykNCj4gPiA+IENjOiBydGctZGlyQGlldGYub3JnOw0KPiA+ID4gZHJhZnQtaWV0Zi1wYWxzLW1w bHMtdHAtcHctb3Zlci1iaWRpci1sc3AuYWxsQHRvb2xzLmlldGYub3JnOw0KPiA+ID4gcGFsc0Bp ZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogUkU6IFJ0Z0RpciByZXZpZXc6DQo+ID4gPiBkcmFmdC1p ZXRmLXBhbHMtbXBscy10cC1wdy1vdmVyLWJpZGlyLWxzcC0wNg0KPiA+ID4NCj4gPiA+IEhpIE1h Y2gsDQo+ID4gPg0KPiA+ID4gVGhhbmtzIGZvciB0aGUgdXBkYXRlLg0KPiA+ID4gVGhlcmUgaXMg anVzdCBvbmUgb3V0c3RhbmRpbmcgcG9pbnQ6DQo+ID4gPg0KPiA+ID4gPiDigKIgU2VjdGlvbiAy LjE6IOKAnExEUCBMYWJlbCBNYXBwaW5nIG1lc3NhZ2XigJ0gbWlzc2luZyByZWZlcmVuY2UuIEFu ZA0KPiA+ID4gPiB3aHkgdGhlIFR5cGUgZmllbGQgc3RhcnRzIHdpdGggMSBhbmQgMD8NCj4gPiA+ IFRoYW5rcyBmb3IgYWRkaW5nIHRoZSByZWZlcmVuY2UgYnV0IEkgc3RpbGwgZG9uJ3QgZ2V0IHdo eSB0aGUgVHlwZQ0KPiA+ID4gZmllbGQgc3RhcnRzIHdpdGggMSBhbmQgMC4NCj4gPg0KPiA+IFRo ZSBmaXJzdCB0d28gYml0cyBhcmUgVS1iaXQgYW5kIEYtYml0LCB3aGljaCBhcmUgZGVmaW5lZCBp biBTZWN0aW9uDQo+ID4gMy4zIG9mIFJGQzUwMzYuIEhvdyBhYm91dCBhZGRpbmcgdGhlIGZvbGxv dyB0ZXh0Og0KPiA+DQo+ID4gRm9yIHRoaXMgVExWLCB0aGUgVW5rbm93biBUTFYgYml0IChVLWJp dCkgKFNlY3Rpb24gMy4zIG9mIFJGQzUwMzYpIGlzDQo+ID4gc2V0IHRvIDEsIGFuZCB0aGUgRm9y d2FyZGluZyB1bmtub3duIGJpdCAoRi1iaXQpIChTZWN0aW9uIDMuMyBvZiBSRkM1MDM2KSBpcw0K PiBzZXQgdG8gMC4NCj4gPg0KPiA+ID4gT25lIG1vcmUgY29tbWVudCB0aGF0IEkgbG9zdCBkdXJp bmcgdGhlIGZpcnN0IGl0ZXJhdGlvbjogd2h5IGRvIHlvdQ0KPiA+ID4gZGVmaW5lIHRoZSAiZmxh ZyIgZmllbGQgaW4gZmlndXJlIDMgYW5kIHRoZW4gYmVsb3cgaGF2ZSBhIGZ1cnRoZXINCj4gPiA+ IGZpZ3VyZSBzaG93aW5nIEMsIFMsIFQgYW5kIHRoZSBtdXN0IGJlIHplcm8gZmllbGQ/IEknZCBk aXJlY3RseSBwdXQNCj4gPiA+IHRoZSBDLFMsVCBhbmQgbXVzdCBiZSB6ZXJvIGZpZWxkcyBpbiBw bGFjZSBvZiB0aGUgRmxhZyBmaWVsZCBpbg0KPiA+ID4gZmlndXJlIDMuIEl0DQo+ID4gaGVscHMg d2l0aCByZWFkYWJpbGl0eSBJTUhPLg0KPiA+DQo+ID4gT0ssIHdpbGwgcHV0IHRoZW0gYmFjayB0 byB0aGUgVExWIGFuZCByZW1vdmUgdGhlIGZsYWdzIGZpZ3VyZS4NCj4gPg0KPiA+DQo+ID4gSG9w ZSBhYm92ZSBhZGRyZXNzIHlvdXIgY29tbWVudHMhDQo+ID4NCj4gPiBUaGFua3MsDQo+ID4gTWFj aA0KPiA+ID4NCj4gPiA+DQo+ID4gPiBCUg0KPiA+ID4gRGFuaWVsZQ0KPiA+ID4NCj4gPiA+ID4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gRnJvbTogTWFjaCBDaGVuIFttYWls dG86bWFjaC5jaGVuQGh1YXdlaS5jb21dDQo+ID4gPiA+IFNlbnQ6IHZlbmVyZMOsIDEzIG1hZ2dp byAyMDE2IDA5OjI1DQo+ID4gPiA+IFRvOiBEYW5pZWxlIENlY2NhcmVsbGkgPGRhbmllbGUuY2Vj Y2FyZWxsaUBlcmljc3Nvbi5jb20+Ow0KPiA+ID4gPiA8cnRnLWFkc0BpZXRmLm9yZz4NCj4gPiA+ ID4gKHJ0Zy1hZHNAaWV0Zi5vcmcpIDxydGctYWRzQGlldGYub3JnPg0KPiA+ID4gPiBDYzogcnRn LWRpckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtcHctb3Zlci1iaWRpci0NCj4g PiA+ID4gbHNwLmFsbEB0b29scy5pZXRmLm9yZzsgcGFsc0BpZXRmLm9yZw0KPiA+ID4gPiBTdWJq ZWN0OiBSRTogUnRnRGlyIHJldmlldzoNCj4gPiA+ID4gZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAt cHctb3Zlci1iaWRpci1sc3AtMDYNCj4gPiA+ID4NCj4gPiA+ID4gSGkgRGFuaWVsZSwNCj4gPiA+ ID4NCj4gPiA+ID4gVGhhbmtzIGZvciB0aGUgZGV0YWlsZWQgcmV2aWV3IGFuZCB2YWx1YWJsZSBj b21tZW50cyENCj4gPiA+ID4NCj4gPiA+ID4gUGxlYXNlIHNlZSBteSByZXNwb25zZXMgaW5saW5l Li4uDQo+ID4gPiA+DQo+ID4gPiA+IEkgYWxzbyBhdHRhY2hlZCBhIGRpZmYgdGhhdCBzaG93cyB0 aGUgdXBkYXRlcyB0aGF0IHRyeSB0byBhZGRyZXNzDQo+ID4gPiA+IHlvdXIgY29tbWVudHMuIElm IHlvdSBhcmUgT0sgd2l0aCB0aGUgdXBkYXRlcywgSSB3aWxsIHN1Ym1pdCBpdCB0aGVuLg0KPiA+ ID4gPg0KPiA+ID4gPiBUaGFua3MsDQo+ID4gPiA+IE1hY2gNCj4gPiA+ID4NCj4gPiA+ID4gPiBG cm9tOiBEYW5pZWxlIENlY2NhcmVsbGkNCj4gPiA+ID4gPiBTZW50OiBsdW5lZMOsIDI1IGFwcmls ZSAyMDE2IDE5OjA0DQo+ID4gPiA+ID4gVG86IDxydGctYWRzQGlldGYub3JnPiAocnRnLWFkc0Bp ZXRmLm9yZykNCj4gPiA+ID4gPiBDYzogJ3J0Zy1kaXJAaWV0Zi5vcmcnOyAnZHJhZnQtaWV0Zi1w YWxzLW1wbHMtdHAtcHctb3Zlci1iaWRpci0NCj4gPiBsc3AuYWxsQGlldGYub3JnJw0KPiA+ID4g PiA+IFN1YmplY3Q6IFJ0Z0RpciByZXZpZXc6DQo+ID4gPiA+ID4gZHJhZnQtaWV0Zi1wYWxzLW1w bHMtdHAtcHctb3Zlci1iaWRpci1sc3AtMDYNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEhlbGxvLA0K PiA+ID4gPiA+IEkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvcg0KPiA+ID4gPiA+IHRoaXMgZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVjdG9y YXRlIHNlZWtzIHRvIHJldmlldyBhbGwgcm91dGluZw0KPiA+ID4gPiA+IG9yIHJvdXRpbmctcmVs YXRlZCBkcmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwNCj4gPiA+ID4g PiBhbmQgSUVTRyByZXZpZXcsDQo+ID4gPiA+IGFuZCBzb21ldGltZXMgb24gc3BlY2lhbCByZXF1 ZXN0Lg0KPiA+ID4gPiA+IFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBh c3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4NCj4gPiA+ID4gPiBGb3IgbW9yZSBpbmZvcm1h dGlvbiBhYm91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZQ0KPiA+ID4gPiA+ IGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCj4g PiA+ID4gPiBBbHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNl IG9mIHRoZSBSb3V0aW5nDQo+ID4gPiA+ID4gQURzLCBpdCB3b3VsZCBiZSBoZWxwZnVsIGlmIHlv dSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGgNCj4gPiA+ID4gPiBhbnkgb3RoZXIgSUVU RiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZQ0KPiA+ID4g PiA+IHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhl IGRyYWZ0Lg0KPiA+ID4gPiA+IERvY3VtZW50OsKgZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtcHct b3Zlci1iaWRpci1sc3AtMDYNCj4gPiA+ID4gPiBSZXZpZXdlcjogRGFuaWVsZSBDZWNjYXJlbGxp DQo+ID4gPiA+ID4gUmV2aWV3IERhdGU6IEFwcmlsIDI1IDIwMTYNCj4gPiA+ID4gPiBJRVRGIExD IEVuZCBEYXRlOiAtDQo+ID4gPiA+ID4gSW50ZW5kZWQgU3RhdHVzOiBTdGFuZGFyZCBUcmFjaw0K PiA+ID4gPiA+IFN1bW1hcnk6DQo+ID4gPiA+ID4g4oCiIEkgaGF2ZSBzb21lIG1pbm9yIGNvbmNl cm5zIGFib3V0IHRoaXMgZG9jdW1lbnQgdGhhdCBJIHRoaW5rDQo+ID4gPiA+ID4gc2hvdWxkIGJl IHJlc29sdmVkIGJlZm9yZSBwdWJsaWNhdGlvbi4NCj4gPiA+ID4gPiBDb21tZW50czoNCj4gPiA+ ID4gPiDigKIgV2hhdCB0aGUgZHJhZnRzIGlzIHByb3Bvc2luZyBhcyBwcm90b2NvbCBtb2RpZmlj YXRpb24gaXMgY2xlYXINCj4gPiA+ID4gPiBhbmQgYWxzbyB0aGUgb3BlcmF0aW9uIHNlY3Rpb24g YXJlIHByZXR0eSBzdHJhaWdoZm9yd2FyZC4gV2hhdA0KPiA+ID4gPiA+IG5lZWRzIHRvIGJlIGlt cHJvdmVkIGlzIHRoZSBpbnRyb2R1Y3Rpb24gcGFydCwgd2hpY2ggc2hvdWxkIGJlDQo+ID4gPiA+ ID4gcmV2aWV3ZWQgYnkgYSBuYXRpdmUgRW5nbGlzaCBzcGVha2VyLiBBbHNvIHRoZSBJQU5BIHNl Y3Rpb24NCj4gPiA+ID4gPiBzaG91bGQgYmUNCj4gPiBtYWRlIGNsZWFyZXIuDQo+ID4gPiA+DQo+ ID4gPiA+IFRoYW5rcyBmb3IgeW91ciBzdWdnZXN0aW9uLCBJIGFzc3VtZSB0aGUgUkZDIGVkaXRv ciB3aWxsIGRvDQo+ID4gPiA+IGFub3RoZXIgcmV2aWV3IG9uY2UgdGhlIGRvY3VtZW50IHByb2dy ZXNzZWQgdG8gdGhhdCBzdGFnZS4NCj4gPiA+ID4NCj4gPiA+ID4gPiBNYWpvciBJc3N1ZXM6DQo+ ID4gPiA+ID4g4oCiIE5vIG1ham9yIGlzc3VlcyBmb3VuZA0KPiA+ID4gPiA+IE1pbm9yIElzc3Vl czoNCj4gPiA+ID4gPiDigKIgQWJzdHJhY3Q6IOKAnEluIGFkZGl0aW9uLCB0aGUgdXNlciB0cmFm ZmljIG1heSB0cmF2ZXJzZSB0aHJvdWdoDQo+ID4gPiA+ID4gbXVsdGlwbGUgdHJhbnNwb3J0IG5l dHdvcmtzLuKAnSBNYXliZSBpcyB3b3J0aCBlbGFib3JhdGluZyBhIGJpdA0KPiA+ID4gPiA+IHRo aXMgc2VudGVuY2Ugc2F5aW5nIHRoYXQgdGhlIGV4dGVuc2lvbnMgZGVmaW5lZCBpbiB0aGlzIGRy YWZ0DQo+ID4gPiA+ID4gYXBwbHkgYm90aCB0byBTUy0NCj4gPiA+ID4gUFcgYW5kIE1TLVBXLg0K PiA+ID4gPg0KPiA+ID4gPiBIb3cgYWJvdXQgdGhpczoNCj4gPiA+ID4NCj4gPiA+ID4gIk1hbnkg dHJhbnNwb3J0IHNlcnZpY2VzIHJlcXVpcmUgdGhhdCB1c2VyIHRyYWZmaWMsIGluIHRoZSBmb3Jt IG9mDQo+ID4gPiA+IFBzZXVkb3dpcmVzIChQVyksIGJlIGRlbGl2ZXJlZCBvbiBhIHNpbmdsZSBj by1yb3V0ZWQgYmlkaXJlY3Rpb25hbA0KPiA+ID4gPiB0dW5uZWwgb3IgdHdvIHR1bm5lbHMgdGhh dCBzaGFyZSB0aGUgc2FtZSByb3V0ZXMuIFRoaXMgZG9jdW1lbnQNCj4gPiA+ID4gZGVmaW5lcyBh biBvcHRpb25hbCBleHRlbnNpb24gdG8gTERQIHRoYXQgZW5hYmxlcyB0aGUgYmluZGluZw0KPiA+ ID4gPiBiZXR3ZWVuIFBXcyBhbmQgdGhlIHVuZGVybHlpbmcgVEUgdHVubmVscy4gVGhlIGV4dGVu c2lvbiBhcHBsaWVzDQo+ID4gPiA+IHRvIGJvdGggU1MtUFcgYW5kDQo+ID4gPiBNUy1QVy4iDQo+ ID4gPiA+DQo+ID4gPiA+ID4g4oCiIEluIHRoZSBhYnN0cmFjdCBpdCBpcyBzYWlkIHRoYXQgYSBQ VyBpcyBsaW5rZWQgdG8gYW4gTFNQIGJ1dA0KPiA+ID4gPiA+IHRoZW4gaW4gdGhlIGludHJvIGl0 IGlzIHNhaWQgdGhhdCB0aGUgUFcgYmluZGluZyBpcyB0byBhIHR1bm5lbC4NCj4gPiA+ID4gPiBD YW4geW91IGNsYXJpZnkgdGhpcz8gSeKAmWQgc2F5IHRoYXQgaXQgc2hvdWxkIGJlIGxpbmtlZCB0 byBhIHR1bm5lbCwgcmlnaHQ/DQo+ID4gPiA+DQo+ID4gPiA+IFllcywgaXQncyBiZXR0ZXIgdG8g dXNlIHR1bm5lbCwgSSBoYXZlIHVwZGF0ZWQgdGhlIGFic3RyYWN0IHRvDQo+ID4gPiA+IG1ha2Ug QWJzdHJhY3QgYW5kIEludHJvZHVjdGlvbiBoYXZlIHRoZSBjb25zaXN0ZW50IHVzYWdlLiBQbGVh c2UNCj4gPiA+ID4gc2VlIGFib3ZlIHRoZSBuZXcgdGV4dCBmb3IgQWJzdHJhY3QuDQo+ID4gPiA+ DQo+ID4gPiA+ID4g4oCiIEludHJvOsKgwqAg4oCcUFctdG8tUFNOIFR1bm5lbCBiaW5kaW5nIGhh cyBiZWNvbWUgaW5jcmVhc2luZ2x5DQo+ID4gPiA+ID4gY29tbW9uIGFuZCBpbXBvcnRhbnQgaW4g bWFueSBkZXBsb3ltZW50IHNjZW5hcmlvc+KAnS4gSSBndWVzcyB5b3UNCj4gPiA+ID4gPiBtZWFu IGFuIGF1dG9tYXRpYyBiaW5kaW5nIGRvbmUgdmlhIGEgc2lnbmFsaW5nIHByb3RvY29sPw0KPiA+ ID4gPg0KPiA+ID4gPiBObywgdGhpcyBzZW50ZW5jZSBqdXN0IGJyaW5ncyB0aGUgcmVxdWlyZW1l bnRzIG9mIGV4cGxpY2l0IFBXIHRvDQo+ID4gPiA+IFBTTiB0dW5uZWwgYmluZGluZywgd2hhdGV2 ZXIgaXQgaXMgYXV0b21hdGljIHNpZ25hbGluZyBvciBtYW51YWwNCj4gY29uZmlndXJhdGlvbi4N Cj4gPiA+ID4NCj4gPiA+ID4gPiDigKIgV2hhdCBkbyB5b3UgbWVhbiB3aXRoIOKAnG1heSB0cmF2 ZXJzZSB0aHJvdWdoIGRpZmZlcmVudCByb3V0ZXPigJ0/DQo+ID4gPiA+ID4gSSBzdWdnZXN0IGxl YXZpbmcg4oCcbWF5IHRyYXZlcnNlIG11bHRpcGxlIG5ldHdvcmtzIG9yIGRvbWFpbnMuDQo+ID4g PiA+DQo+ID4gPiA+IEhlcmUgdGhlICJyb3V0ZXMiIG1lYW5zICJwYXRocyIuDQo+ID4gPiA+DQo+ ID4gPiA+IEhvdyBhYm91dDogIi4uLm1heSB0cmF2ZXJzZSB0aHJvdWdoIGRpZmZlcmVudCBwYXRo cyBvciBuZXR3b3JrcyI/DQo+ID4gPiA+DQo+ID4gPiA+ID4g4oCiIEludHJvIGFuZCBGaWd1cmUg MTogY291bGQgYmUgZXhhbXBsZSBiZSBtYWRlIGEgYml0IG1vcmUNCj4gPiA+ID4gPiBnZW5lcmlj IHdpdGggYSBuZXR3b3JrIGJldHdlZW4gdGhlIFBFcz8gV2l0aCBkaXJlY3RseSBjb25uZWN0ZWQN Cj4gPiA+ID4gPiBQRXMgaXQgZG9lc27igJl0IHNlZW0gYSByZWFsaXN0aWMgYW5kIGdlbmVyaWMg ZW5vdWdoIGV4YW1wbGUuDQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+ID4g4oCiIEludHJvOiBz dWdnZXN0IHJlbW92aW5nIOKAnEFzIG1lbnRpb25lZCBhYm92ZeKAnS4NCj4gPiA+ID4NCj4gPiA+ ID4gT0suDQo+ID4gPiA+DQo+ID4gPiA+ID4g4oCiIMKgVGhlIG5hbWUgb2YgdGhlIGRyYWZ0IGV4 cGxpY2l0bHkgbWVudGlvbnMgTVBMUy1UUCBidXQgaW4gdGhlDQo+ID4gPiA+ID4gcmVzdCBvZiB0 aGUgZHJhZnQgdGhlcmUgaXMgbm8gbWVudGlvbiBvZiBpdCwganVzdCB0aGUgbXVjaCBtb3JlDQo+ ID4gPiA+ID4gZ2VuZXJhbCBQYWNrZXQgU3dpdGNoaW5nIE5ldHdvcmsgdGVybSBpcyB1c2VkLg0K PiA+ID4gPg0KPiA+ID4gPiBJbmRlZWQsIHRoYXQncyB0aGUgaW50ZW50aW9uLiBUaGlzIHdvcmsg d2FzIHRyaWdnZXJlZCBieSB0aGUNCj4gPiA+ID4gZGlzY3Vzc2lvbiBvZiBNUExTLVRQLiBCdXQg d2l0aCB0aGUgcHJvZ3Jlc3Mgb2YgdGhpcyBkcmFmdCBhbmQNCj4gPiA+ID4gZGlzY3Vzc2lvbiB3 aXRoaW4gdGhlIFdHLCB0aGVyZSBpcyBhIGNvbnNlbnN1cyB0aGF0IHRoaXMgdGVjaG5pcXVlDQo+ ID4gPiA+IGlzIGEgZ2VuZXJhbCBzb2x1dGlvbiB0aGF0IGNhbiBhY3R1YWxseSBhcHBseSB0byBi b3RoIFRQIGFuZCBub24tVFAgY2FzZXMuDQo+ID4gPiA+DQo+ID4gPiA+ID4g4oCiIFNlY3Rpb24g MjrCoMKgIOKAnFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5ldyBvcHRpb25hbCBUTFYsIFBTTg0K PiA+ID4gPiA+IFR1bm5lbCBCaW5kaW5nIFRMViwgdG8gY29tbXVuaWNhdGUgdHVubmVsL0xTUHMg c2VsZWN0aW9uIGFuZA0KPiA+ID4gPiA+IGJpbmRpbmcgcmVxdWVzdHMNCj4gPiA+ID4gYmV0d2Vl biBQRXMuDQo+ID4gPiA+ID4g4oCcIFRoZSBiaW5kaW5nIHJlcXVlc3QgaXMgYmV0d2VlbiBQRXM/ IE9yIGJldHdlZW4gYW4gUFcgYW5kIGENCj4gPiA+ID4gPiBUdW5uZWwgKG9yIExTUD8pIGJldHdl ZW4gdHdvIFBFcz8NCj4gPiA+ID4NCj4gPiA+ID4gQmV0d2VlbiBQRXMgb2YgYW4gUFcuDQo+ID4g PiA+DQo+ID4gPiA+ID4g4oCiIFNlY3Rpb24gMjogU3RyaWN0IGJpbmRpbmcgdnMgQ28tcm91dGVk IGJpbmRpbmc6IGZyb20gdGhlDQo+ID4gPiA+ID4gZGVzY3JpcHRpb24gaXQgc2VlbXMgdGhhdCB0 aGUgZmlyc3Qgb25lIGlzIHN0cmljdCBhbmQgdGhlIHNlY29uZA0KPiA+ID4gPiA+IG9uZSBpcw0K PiA+ID4g4oCcbG9vc2XigJ0NCj4gPiA+ID4gPiAoaW4gdGhlIHNlbnNlIHRoYXQgdGhlIFBFIGNh biBhY2NlcHQgdGhlIHJlcXVlc3Qgb3Igbm90KS4gRG9u4oCZdA0KPiA+ID4gPiA+IGJvdGggYXBw bHkNCj4gPiA+ID4gdG8gY28tcm91dGVkIExTUHM/DQo+ID4gPiA+DQo+ID4gPiA+IFllcywgYm90 aCBjYW4gYXBwbHkgdG8gY28tcm91dGVkIExTUHMuIEJ1dCBmb3IgInN0cmljdCIgbW9kZSwgaWYN Cj4gPiA+ID4gdGhlIGVncmVzcyBQRSBtdXN0IGJpbmQgdG8gdGhlIHNwZWNpZmllZCB0dW5uZWwg YnkgdGhlIGluZ3Jlc3MgUEUsDQo+ID4gPiA+IG90aGVyd2lzZSwgdGhlIGJpbmRpbmcgd2lsbCBu b3Qgc3VjY2Vzcy4gVGhlICJjby1yb3V0ZWQiIG1vZGUNCj4gPiA+ID4gZ2l2ZXMgdGhlIGVncmVz cyBQRSB0aGUgdXNlIGFsdGVybmF0aXZlIHR1bm5lbC4NCj4gPiA+ID4NCj4gPiA+ID4gPiDigKIg U2VjdGlvbiAyOiDigJ1UaGUgdGVybWlub2xvZ3kgIkxTUCIgaXPCoCBpZGVudGljYWwgdG8gdGhl ICJMU1AgdHVubmVsIg0KPiA+ID4gPiA+IGRlZmluZWQgaW4gU2VjdGlvbiAyLjEgb2YgW1JGQzMy MDldLMKgIHdoaWNoIGlzIHVuaXF1ZWx5DQo+ID4gPiA+ID4gaWRlbnRpZmllZCBieSB0aGUgU0VT U0lPTiBvYmplY3QgdG9nZXRoZXIgd2l0aMKgIFNFTkRFUl9URU1QTEFURQ0KPiA+ID4gPiA+IChv cg0KPiA+ID4gPiA+IEZJTFRFUl9TUEVDKSBvYmplY3QgdGhhdCBjb25zaXN0cyBvZiBMU1AgSUQg YW5kIFR1bm5lbCBlbmRwb2ludA0KPiA+ID4gPiA+IGFkZHJlc3Mu4oCdIFdoeSBpcyB0aGUgZHJh ZnQgY29uc2lkZXJpbmcgb25seSBzaWduYWxlZCBMU1BzPw0KPiA+ID4gPiA+IERvZXNu4oCZdCBp dCBhcHBseSBhbHNvIHRvIGNlbnRyYWxseQ0KPiA+ID4gPiBwcm92aXNpb25lZCBvbmVzPyAoZS5n LiBOTVMgb3IgU0ROKS4NCj4gPiA+ID4NCj4gPiA+ID4gVGhlIG1haW4gcHVycG9zZSBoZXJlIGlz IHRvIGdpdmUgYSByZWZlcmVuY2UgdG8gdGhlIHRlcm0gb2YgIkxTUCINCj4gPiA+ID4gYW5kICJ0 dW5uZWwiLCBoZW5jZSB0byBlbGltaW5hdGUgdGhlIGNvbmZ1c2lvbiBvZiB3aGVuIHVzZSB0aGVz ZQ0KPiA+ID4gPiBpbiB0aGUgZm9sbG93aW5nIHNlY3Rpb25zLiBBcyBmb3IgdGhlIE5NUyBhbmQg U0ROIGJhc2VkIFRFDQo+ID4gPiA+IExTUC9UdW5uZWwsIHRlY2huaWNhbGx5LCBpdCBjYW4gYXBw bHkgdG8gYXMgd2VsbCBvbmx5IGlmIHRoZSBURQ0KPiA+ID4gPiBMU1AvVHVubmVsIGhhcyB0aGUg TFNQIG51bWJlciwgbm9kZSBJRCBldGMuIGluZm9ybWF0aW9uLg0KPiA+ID4gPg0KPiA+ID4gPiA+ IOKAoiBTZWN0aW9uIDIuMTog4oCcTERQIExhYmVsIE1hcHBpbmcgbWVzc2FnZeKAnSBtaXNzaW5n IHJlZmVyZW5jZS4NCj4gPiA+ID4gPiBBbmQgd2h5IHRoZSBUeXBlIGZpZWxkIHN0YXJ0cyB3aXRo IDEgYW5kIDA/DQo+ID4gPiA+DQo+ID4gPiA+IEdvb2QgY2F0Y2gsIHdpbGwgYWRkIGEgcmVmZXJl bmNlIGhlcmUuDQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+ID4gTml0czoNCj4gPiA+ID4gPiDi gKIgQWJzdHJhY3Qgcy8gdHJhdmVyc2UgdGhyb3VnaCBtdWx0aXBsZS8gdHJhdmVyc2UgbXVsdGlw bGUg4oCiDQo+ID4gSW50cm9kdWN0aW9uOg0KPiA+ID4gPiA+IOKAnFBzZXVkb3dpcmUgKFBXKSBF bXVsYXRpb24gRWRnZS10by1FZGdlIChQV0UzKeKAnS4gSSBzdWdnZXN0DQo+ID4gPiA+ID4gcmVt b3ZpbmcgKFBXKSwgaXTigJlzIGFscmVhZHkgaW5jbHVkZWQgaW50byBQV0UzLg0KPiA+ID4gPg0K PiA+ID4gPiBPSy4NCj4gPiA+ID4gPiDigKIgSW50cm86IHMvIGEgYmlkaXJlY3Rpb25hbCBjaXJj dWl0cy8gYSBiaWRpcmVjdGlvbmFsIGNpcmN1aXQNCj4gPiA+ID4NCj4gPiA+ID4gT0suDQo+ID4g PiA+DQo+ID4gPiA+IOKAoiBJbnRybzogc3VnZ2VzdA0KPiA+ID4gPiA+IHJlcGhyYXNpbmc6IOKA nEJpZGlyZWN0aW9uYWwgTFNQcyBzaGFyZSBmYXRlIGFuZCBzaW1wbGlmeSB0aGUNCj4gPiA+ID4g PiByb3V0aW5nIG9mIGEgcHJvdGVjdGlvbiBwYXRoIGFsc28gY29uc2lzdGluZyBvZiBiaWRpcmVj dGlvbmFsDQo+ID4gPiA+ID4gTFNQcyBiZWNhdXNlIHdvcmtpbmcgYW5kIHByb3RlY3Rpb24gcGF0 aHMgaGF2ZSB0byBiZSBkaXNqb2ludC7igJ0NCj4gPiA+ID4NCj4gPiA+ID4gT0suDQo+ID4gPiA+ DQo+ID4gPiA+ID4g4oCiIEludHJvOiBzLyB0aGVyZSBhcmUgYSBsYXJnZSBudW1iZXIvIHRoZXJl IGlzIGEgbGFyZ2UgbnVtYmVyDQo+ID4gPiA+DQo+ID4gPiA+IE9LLg0KPiA+ID4gPg0KPiA+ID4g PiDigKIgSW50cm86cy90byBiZQ0KPiA+ID4gPiA+IGNhcnJpZWQvYXJlIGNhcnJpZWQNCj4gPiA+ ID4NCj4gPiA+ID4gT0suDQo+ID4gPiA+DQo+ID4gPiA+IOKAoiBJbnRybzpzL3RoZXJlIGFyZSBh IG51bWJlci90aGVyZSBpcyBhIG51bWJlcg0KPiA+ID4gPg0KPiA+ID4gPiBPSy4NCj4gPiA+ID4N Cj4gPiA+ID4g4oCiIEludHJvOiBzLw0KPiA+ID4gPiA+IHRyYWZmaWMgYmVsb25ncy90cmFmZmlj IGJlbG9uZ2luZw0KPiA+ID4gPg0KPiA+ID4gPiBPSy4NCj4gPiA+ID4NCj4gPiA+ID4g4oCiIElu dHJvOiAoc3VnZ2VzdGlvbikgcy8oUEUxLVAzLVBFMikvDQo+ID4gPiA+ID4gKFBFMi1QMy1QRTEp IHNpbmNlIHdlIGFyZSBzcGVha2luZyBhYm91dCBkaXJlY3Rpb25hbGl0eSBpdCBtYWtlcw0KPiA+ ID4gPiA+IG1vcmUgc2Vuc2UgdG8gbGlzdCB0aGUgbm9kZXMgb2YgdGhlIHBhdGggaW4gdGhlIHJl dmVyc2UgZGlyZWN0aW9uLg0KPiA+ID4gPg0KPiA+ID4gPiBPSy4NCj4gPiA+ID4NCj4gPiA+ID4g PiDigKIgSW50cm86IHMvIFRoZSBzaW1pbGFyIHByb2JsZW1zL0Egc2ltaWxhciBwcm9ibGVtDQo+ ID4gPiA+DQo+ID4gPiA+IE9LLg0KPiA+ID4gPg0KPiA+ID4gPiA+4oCiIEludHJvOiBzLyB3b24n dC9kb2VzIG5vdA0KPiA+ID4gPg0KPiA+ID4gPiBPSy4NCj4gPiA+ID4gPuKAokludHJvOiBzLyBJ biB0aGlzIGRvY3VtZW50LCBpdCBpbnRyb2R1Y2VzL1RoaXMgZG9jdW1lbnQNCj4gPiA+ID4gPmlu dHJvZHVjZXMgQlIgRGFuaWVsZQ0KPiA+ID4gPg0KPiA+ID4gPiBPSy4NCj4gPiA+ID4NCj4gPiA+ ID4gPg0KDQo= From nobody Wed May 25 03:03:21 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D8B12D901; Wed, 25 May 2016 03:03:18 -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, 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 Ik1yQ1M_J97J; Wed, 25 May 2016 03:03:15 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 546FE12D897; Wed, 25 May 2016 03:03:14 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-b4-5745785e6e5d Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 89.C6.18043.E5875475; Wed, 25 May 2016 12:03:10 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.74]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0294.000; Wed, 25 May 2016 12:03:03 +0200 From: Daniele Ceccarelli To: Mach Chen , " (rtg-ads@ietf.org)" Thread-Topic: RtgDir review: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06 Thread-Index: AdGe+Z/lFOzQc8O7SFSbqLe7ce8oewAG1OFwA2v05+AAAARS8AJlk/FwAAHw8kAAAKspgAABGawwAACm3lA= Date: Wed, 25 May 2016 10:03:04 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48162EC0EA@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE48162EBD1D@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE48162EBF6F@ESESSMB301.ericsson.se> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2K7h25chWu4QccSUYu5UxYwWVxYK2yx 5t86JouTc34wWyxY85TdgdWj5chbVo8lS34yeXy5/JktgDmKyyYlNSezLLVI3y6BK6Pl2z/W gr5pjBX/+mezNDAumMTYxcjJISFgItF87AALhC0mceHeerYuRi4OIYEjjBK3/r1hgXAWM0r0 bX7O1MXIwcEmYCXx5JAPSIOIQJLEvLnL2UFsZoHzjBJLZpuD2MICHhLz759ghajxlDiyfjoj SCtI/fIVNSBhFgFVieXtE8FKeAV8JTpvvobae5BZ4srhVWwgCU6BMImjV+eDzWcUkJWYsHsR I8QucYlbT+YzQRwtILFkz3lmCFtU4uXjf6wQtqLE1enLwU5mFtCUWL9LH6JVUWJK90N2iL2C EidnPmGZwCg2C8nUWQgds5B0zELSsYCRZRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZGYJQd 3PLbagfjweeOhxgFOBiVeHgfnHMJF2JNLCuuzD3EKMHBrCTC61buGi7Em5JYWZValB9fVJqT WnyIUZqDRUmc1/+lYriQQHpiSWp2ampBahFMlomDU6qB0X7rvmemKyYW3Ds4J/uN2aY1IgdY vzOWr6y+EuLHv/Awc6ujmEBr+dlTNeyNSw2uvS4KCAk88/3I8or6NzoHwrYZHxS+mbRu/33h NWWfzDU+3FwS6nxqCXtGqJzlvzn/wk2mZCqdDV1p4nClaMeJjLsPL3Nu8rj8fV/elV2bhLis A3K2MZ2uXqDEUpyRaKjFXFScCADqCZW9rgIAAA== Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-pals-mpls-tp-pw-over-bidir-lsp.all@tools.ietf.org" , "pals@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 10:03:18 -0000 VGhhdCdzIHBlcmZlY3QhDQoNCkJSDQpEYW5pZWxlDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogTWFjaCBDaGVuIFttYWlsdG86bWFjaC5jaGVuQGh1YXdlaS5jb21dDQo+ IFNlbnQ6IG1lcmNvbGVkw6wgMjUgbWFnZ2lvIDIwMTYgMTE6NDcNCj4gVG86IERhbmllbGUgQ2Vj Y2FyZWxsaSA8ZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbT47IDxydGctYWRzQGlldGYu b3JnPg0KPiAocnRnLWFkc0BpZXRmLm9yZykgPHJ0Zy1hZHNAaWV0Zi5vcmc+DQo+IENjOiBydGct ZGlyQGlldGYub3JnOyBkcmFmdC1pZXRmLXBhbHMtbXBscy10cC1wdy1vdmVyLWJpZGlyLQ0KPiBs c3AuYWxsQHRvb2xzLmlldGYub3JnOyBwYWxzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBSdGdE aXIgcmV2aWV3OiBkcmFmdC1pZXRmLXBhbHMtbXBscy10cC1wdy1vdmVyLWJpZGlyLWxzcC0wNg0K PiANCj4gSGkgRGFuaWVsZSwNCj4gDQo+IFllcywgeW91ciB1bmRlcnN0YW5kaW5nIGlzIHJpZ2h0 LiBIb3cgYWJvdXQgYWRkIHRoZSBmb2xsb3dpbmcgdGV4dDoNCj4gDQo+IFRoZSBVLWJpdCBhbmQg Ri1iaXQgYXJlIGRlZmluZWQgU2VjdGlvbiAzLjMgUkZDNTAzNi4gU2luY2UgdGhlIFBTTiBUdW5u ZWwNCj4gQmluZGluZyBUTFYgaXMgYW4gb3B0aW9uYWwgVExWLCB0aGUgVS1iaXQgTVVTVCBiZSBz ZXQgdG8gMSBzbyB0aGF0IGEgcmVjZWl2ZXINCj4gTVVTVCBzaWxlbnRseSBpZ25vcmUgdGhpcyBU TFYgaWYgdW5rbm93biB0byBpdCwgYW5kIGNvbnRpbnVlIHByb2Nlc3NpbmcgdGhlDQo+IHJlc3Qg b2YgdGhlIG1lc3NhZ2UuDQo+IEEgcmVjZWl2ZXIgb2YgdGhpcyBUTFYgaXMgbm90IGFsbG93ZWQg dG8gZm9yd2FyZCB0aGUgVExWIGZ1cnRoZXIgd2hlbiBpdCBkb2VzDQo+IG5vdCBrbm93IHRoZSBU TFYuIFNvLCB0aGUgRi1iaXQgTVVTVCBiZSBzZXQgdG8gMC4NCj4gDQo+IFRoYW5rcywNCj4gTWFj aA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IERhbmllbGUg Q2VjY2FyZWxsaSBbbWFpbHRvOmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb21dDQo+ID4g U2VudDogV2VkbmVzZGF5LCBNYXkgMjUsIDIwMTYgNToyMSBQTQ0KPiA+IFRvOiBNYWNoIENoZW47 IDxydGctYWRzQGlldGYub3JnPiAocnRnLWFkc0BpZXRmLm9yZykNCj4gPiBDYzogcnRnLWRpckBp ZXRmLm9yZzsNCj4gPiBkcmFmdC1pZXRmLXBhbHMtbXBscy10cC1wdy1vdmVyLWJpZGlyLWxzcC5h bGxAdG9vbHMuaWV0Zi5vcmc7DQo+ID4gcGFsc0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJFOiBS dGdEaXIgcmV2aWV3Og0KPiA+IGRyYWZ0LWlldGYtcGFscy1tcGxzLXRwLXB3LW92ZXItYmlkaXIt bHNwLTA2DQo+ID4NCj4gPiBIaSBNYWNoLA0KPiA+DQo+ID4gT2ssIGxldCBtZSB0cnkgdG8gc3Vt bWFyaXplLg0KPiA+DQo+ID4gVGhlIGRyYWZ0IGRlZmluZXMgYSBuZXcgVExWIGZvciB0aGUgTERQ IE1hcHBpbmcgTWVzc2FnZSAoUkZDIDUwMzYNCj4gPiBzZWN0aW9uDQo+ID4gMy41LjcpIHdoaWNo IEkgZ3Vlc3Mgd291bGQgZW5kIHVwIGluIHRoZSAib3B0aW9uYWwgcGFyYW1ldGVycyIgZmllbGQN Cj4gPiAodGhlIHRleHQNCj4gPiBzYXlzOiAiY29udGFpbnMgMCBvciBtb3JlIHBhcmFtZXRlcnMs IGVhY2ggZW5jb2RlZCBhcyBhIFRMViIpLg0KPiA+IFRoZW4gc2VjdGlvbiAzLjMgbWFuZGF0ZXMg aG93IHRvIGJ1aWxkIHRob3NlIFRMVnMgKFUsIEYgYW5kIHNvIG9uKS4NCj4gPg0KPiA+IElmIG15 IHVuZGVyc3RhbmRpbmcgY29ycmVjdD8gSWYgeWVzIEkgc3VnZ2VzdCB0byBzdGF0ZSBpdCBpbiB0 aGUgdGV4dA0KPiA+IGFuZCBwb3NzaWJseSBhZGQgd2h5IHRoZSBVIGJpdCBpcyBhbHdheXMgMSBp biB5b3VyIGNhc2UgYW5kIHRoZSBGIGJpdCBpcw0KPiBhbHdheXMgMC4NCj4gPg0KPiA+IFRoYW5r cyBmb3IgdGhlIGV4cGxhbmF0aW9uDQo+ID4gRGFuaWVsZQ0KPiA+DQo+ID4gPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogTWFjaCBDaGVuIFttYWlsdG86bWFjaC5jaGVu QGh1YXdlaS5jb21dDQo+ID4gPiBTZW50OiBtZXJjb2xlZMOsIDI1IG1hZ2dpbyAyMDE2IDExOjAy DQo+ID4gPiBUbzogRGFuaWVsZSBDZWNjYXJlbGxpIDxkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nz b24uY29tPjsNCj4gPiA+IDxydGctYWRzQGlldGYub3JnPg0KPiA+ID4gKHJ0Zy1hZHNAaWV0Zi5v cmcpIDxydGctYWRzQGlldGYub3JnPg0KPiA+ID4gQ2M6IHJ0Zy1kaXJAaWV0Zi5vcmc7IGRyYWZ0 LWlldGYtcGFscy1tcGxzLXRwLXB3LW92ZXItYmlkaXItDQo+ID4gPiBsc3AuYWxsQHRvb2xzLmll dGYub3JnOyBwYWxzQGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBSRTogUnRnRGlyIHJldmlldzoN Cj4gPiA+IGRyYWZ0LWlldGYtcGFscy1tcGxzLXRwLXB3LW92ZXItYmlkaXItbHNwLTA2DQo+ID4g Pg0KPiA+ID4gSGkgRGFuaWVsZSwNCj4gPiA+DQo+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4gPiA+IEZyb206IERhbmllbGUgQ2VjY2FyZWxsaSBbbWFpbHRvOmRhbmllbGUu Y2VjY2FyZWxsaUBlcmljc3Nvbi5jb21dDQo+ID4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDI1 LCAyMDE2IDQ6MDggUE0NCj4gPiA+ID4gVG86IE1hY2ggQ2hlbjsgPHJ0Zy1hZHNAaWV0Zi5vcmc+ IChydGctYWRzQGlldGYub3JnKQ0KPiA+ID4gPiBDYzogcnRnLWRpckBpZXRmLm9yZzsNCj4gPiA+ ID4gZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtcHctb3Zlci1iaWRpci1sc3AuYWxsQHRvb2xzLmll dGYub3JnOw0KPiA+ID4gPiBwYWxzQGlldGYub3JnDQo+ID4gPiA+IFN1YmplY3Q6IFJFOiBSdGdE aXIgcmV2aWV3Og0KPiA+ID4gPiBkcmFmdC1pZXRmLXBhbHMtbXBscy10cC1wdy1vdmVyLWJpZGly LWxzcC0wNg0KPiA+ID4gPg0KPiA+ID4gPiBIaSBNYWNoLA0KPiA+ID4gPg0KPiA+ID4gPiBUaGFu a3MgZm9yIHRoZSB1cGRhdGUuDQo+ID4gPiA+IFRoZXJlIGlzIGp1c3Qgb25lIG91dHN0YW5kaW5n IHBvaW50Og0KPiA+ID4gPg0KPiA+ID4gPiA+IOKAoiBTZWN0aW9uIDIuMTog4oCcTERQIExhYmVs IE1hcHBpbmcgbWVzc2FnZeKAnSBtaXNzaW5nIHJlZmVyZW5jZS4NCj4gPiA+ID4gPiBBbmQgd2h5 IHRoZSBUeXBlIGZpZWxkIHN0YXJ0cyB3aXRoIDEgYW5kIDA/DQo+ID4gPiA+IFRoYW5rcyBmb3Ig YWRkaW5nIHRoZSByZWZlcmVuY2UgYnV0IEkgc3RpbGwgZG9uJ3QgZ2V0IHdoeSB0aGUgVHlwZQ0K PiA+ID4gPiBmaWVsZCBzdGFydHMgd2l0aCAxIGFuZCAwLg0KPiA+ID4NCj4gPiA+IFRoZSBmaXJz dCB0d28gYml0cyBhcmUgVS1iaXQgYW5kIEYtYml0LCB3aGljaCBhcmUgZGVmaW5lZCBpbiBTZWN0 aW9uDQo+ID4gPiAzLjMgb2YgUkZDNTAzNi4gSG93IGFib3V0IGFkZGluZyB0aGUgZm9sbG93IHRl eHQ6DQo+ID4gPg0KPiA+ID4gRm9yIHRoaXMgVExWLCB0aGUgVW5rbm93biBUTFYgYml0IChVLWJp dCkgKFNlY3Rpb24gMy4zIG9mIFJGQzUwMzYpDQo+ID4gPiBpcyBzZXQgdG8gMSwgYW5kIHRoZSBG b3J3YXJkaW5nIHVua25vd24gYml0IChGLWJpdCkgKFNlY3Rpb24gMy4zIG9mDQo+ID4gPiBSRkM1 MDM2KSBpcw0KPiA+IHNldCB0byAwLg0KPiA+ID4NCj4gPiA+ID4gT25lIG1vcmUgY29tbWVudCB0 aGF0IEkgbG9zdCBkdXJpbmcgdGhlIGZpcnN0IGl0ZXJhdGlvbjogd2h5IGRvDQo+ID4gPiA+IHlv dSBkZWZpbmUgdGhlICJmbGFnIiBmaWVsZCBpbiBmaWd1cmUgMyBhbmQgdGhlbiBiZWxvdyBoYXZl IGENCj4gPiA+ID4gZnVydGhlciBmaWd1cmUgc2hvd2luZyBDLCBTLCBUIGFuZCB0aGUgbXVzdCBi ZSB6ZXJvIGZpZWxkPyBJJ2QNCj4gPiA+ID4gZGlyZWN0bHkgcHV0IHRoZSBDLFMsVCBhbmQgbXVz dCBiZSB6ZXJvIGZpZWxkcyBpbiBwbGFjZSBvZiB0aGUNCj4gPiA+ID4gRmxhZyBmaWVsZCBpbiBm aWd1cmUgMy4gSXQNCj4gPiA+IGhlbHBzIHdpdGggcmVhZGFiaWxpdHkgSU1ITy4NCj4gPiA+DQo+ ID4gPiBPSywgd2lsbCBwdXQgdGhlbSBiYWNrIHRvIHRoZSBUTFYgYW5kIHJlbW92ZSB0aGUgZmxh Z3MgZmlndXJlLg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBIb3BlIGFib3ZlIGFkZHJlc3MgeW91ciBj b21tZW50cyENCj4gPiA+DQo+ID4gPiBUaGFua3MsDQo+ID4gPiBNYWNoDQo+ID4gPiA+DQo+ID4g PiA+DQo+ID4gPiA+IEJSDQo+ID4gPiA+IERhbmllbGUNCj4gPiA+ID4NCj4gPiA+ID4gPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+IEZyb206IE1hY2ggQ2hlbiBbbWFpbHRv Om1hY2guY2hlbkBodWF3ZWkuY29tXQ0KPiA+ID4gPiA+IFNlbnQ6IHZlbmVyZMOsIDEzIG1hZ2dp byAyMDE2IDA5OjI1DQo+ID4gPiA+ID4gVG86IERhbmllbGUgQ2VjY2FyZWxsaSA8ZGFuaWVsZS5j ZWNjYXJlbGxpQGVyaWNzc29uLmNvbT47DQo+ID4gPiA+ID4gPHJ0Zy1hZHNAaWV0Zi5vcmc+DQo+ ID4gPiA+ID4gKHJ0Zy1hZHNAaWV0Zi5vcmcpIDxydGctYWRzQGlldGYub3JnPg0KPiA+ID4gPiA+ IENjOiBydGctZGlyQGlldGYub3JnOyBkcmFmdC1pZXRmLXBhbHMtbXBscy10cC1wdy1vdmVyLWJp ZGlyLQ0KPiA+ID4gPiA+IGxzcC5hbGxAdG9vbHMuaWV0Zi5vcmc7IHBhbHNAaWV0Zi5vcmcNCj4g PiA+ID4gPiBTdWJqZWN0OiBSRTogUnRnRGlyIHJldmlldzoNCj4gPiA+ID4gPiBkcmFmdC1pZXRm LXBhbHMtbXBscy10cC1wdy1vdmVyLWJpZGlyLWxzcC0wNg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4g SGkgRGFuaWVsZSwNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFRoYW5rcyBmb3IgdGhlIGRldGFpbGVk IHJldmlldyBhbmQgdmFsdWFibGUgY29tbWVudHMhDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBQbGVh c2Ugc2VlIG15IHJlc3BvbnNlcyBpbmxpbmUuLi4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEkgYWxz byBhdHRhY2hlZCBhIGRpZmYgdGhhdCBzaG93cyB0aGUgdXBkYXRlcyB0aGF0IHRyeSB0bw0KPiA+ ID4gPiA+IGFkZHJlc3MgeW91ciBjb21tZW50cy4gSWYgeW91IGFyZSBPSyB3aXRoIHRoZSB1cGRh dGVzLCBJIHdpbGwgc3VibWl0DQo+IGl0IHRoZW4uDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBUaGFu a3MsDQo+ID4gPiA+ID4gTWFjaA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBGcm9tOiBEYW5pZWxl IENlY2NhcmVsbGkNCj4gPiA+ID4gPiA+IFNlbnQ6IGx1bmVkw6wgMjUgYXByaWxlIDIwMTYgMTk6 MDQNCj4gPiA+ID4gPiA+IFRvOiA8cnRnLWFkc0BpZXRmLm9yZz4gKHJ0Zy1hZHNAaWV0Zi5vcmcp DQo+ID4gPiA+ID4gPiBDYzogJ3J0Zy1kaXJAaWV0Zi5vcmcnOw0KPiA+ID4gPiA+ID4gJ2RyYWZ0 LWlldGYtcGFscy1tcGxzLXRwLXB3LW92ZXItYmlkaXItDQo+ID4gPiBsc3AuYWxsQGlldGYub3Jn Jw0KPiA+ID4gPiA+ID4gU3ViamVjdDogUnRnRGlyIHJldmlldzoNCj4gPiA+ID4gPiA+IGRyYWZ0 LWlldGYtcGFscy1tcGxzLXRwLXB3LW92ZXItYmlkaXItbHNwLTA2DQo+ID4gPiA+ID4gPg0KPiA+ ID4gPiA+ID4gSGVsbG8sDQo+ID4gPiA+ID4gPiBJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUg Um91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3INCj4gPiA+ID4gPiA+IHRoaXMgZHJhZnQu IFRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtzIHRvIHJldmlldyBhbGwNCj4gPiA+ID4gPiA+ IHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJ RVRGDQo+ID4gPiA+ID4gPiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LA0KPiA+ID4gPiA+IGFu ZCBzb21ldGltZXMgb24gc3BlY2lhbCByZXF1ZXN0Lg0KPiA+ID4gPiA+ID4gVGhlIHB1cnBvc2Ug b2YgdGhlIHJldmlldyBpcyB0byBwcm92aWRlIGFzc2lzdGFuY2UgdG8gdGhlIFJvdXRpbmcNCj4g QURzLg0KPiA+ID4gPiA+ID4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcg RGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUNCj4gPiA+ID4gPiA+IGh0dHA6Ly90cmFjLnRvb2xzLmll dGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCj4gPiA+ID4gPiA+IEFsdGhvdWdoIHRo ZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlDQo+ID4gPiA+ID4g PiBSb3V0aW5nIEFEcywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIg dGhlbQ0KPiA+ID4gPiA+ID4gYWxvbmcgd2l0aCBhbnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29t bWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwNCj4gPiA+ID4gPiA+IGFuZCBzdHJpdmUgdG8gcmVzb2x2 ZSB0aGVtIHRocm91Z2ggZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUNCj4gZHJhZnQuDQo+ ID4gPiA+ID4gPiBEb2N1bWVudDrCoGRyYWZ0LWlldGYtcGFscy1tcGxzLXRwLXB3LW92ZXItYmlk aXItbHNwLTA2DQo+ID4gPiA+ID4gPiBSZXZpZXdlcjogRGFuaWVsZSBDZWNjYXJlbGxpDQo+ID4g PiA+ID4gPiBSZXZpZXcgRGF0ZTogQXByaWwgMjUgMjAxNg0KPiA+ID4gPiA+ID4gSUVURiBMQyBF bmQgRGF0ZTogLQ0KPiA+ID4gPiA+ID4gSW50ZW5kZWQgU3RhdHVzOiBTdGFuZGFyZCBUcmFjaw0K PiA+ID4gPiA+ID4gU3VtbWFyeToNCj4gPiA+ID4gPiA+IOKAoiBJIGhhdmUgc29tZSBtaW5vciBj b25jZXJucyBhYm91dCB0aGlzIGRvY3VtZW50IHRoYXQgSSB0aGluaw0KPiA+ID4gPiA+ID4gc2hv dWxkIGJlIHJlc29sdmVkIGJlZm9yZSBwdWJsaWNhdGlvbi4NCj4gPiA+ID4gPiA+IENvbW1lbnRz Og0KPiA+ID4gPiA+ID4g4oCiIFdoYXQgdGhlIGRyYWZ0cyBpcyBwcm9wb3NpbmcgYXMgcHJvdG9j b2wgbW9kaWZpY2F0aW9uIGlzDQo+ID4gPiA+ID4gPiBjbGVhciBhbmQgYWxzbyB0aGUgb3BlcmF0 aW9uIHNlY3Rpb24gYXJlIHByZXR0eQ0KPiA+ID4gPiA+ID4gc3RyYWlnaGZvcndhcmQuIFdoYXQg bmVlZHMgdG8gYmUgaW1wcm92ZWQgaXMgdGhlIGludHJvZHVjdGlvbg0KPiA+ID4gPiA+ID4gcGFy dCwgd2hpY2ggc2hvdWxkIGJlIHJldmlld2VkIGJ5IGEgbmF0aXZlIEVuZ2xpc2ggc3BlYWtlci4N Cj4gPiA+ID4gPiA+IEFsc28gdGhlIElBTkEgc2VjdGlvbiBzaG91bGQgYmUNCj4gPiA+IG1hZGUg Y2xlYXJlci4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFRoYW5rcyBmb3IgeW91ciBzdWdnZXN0aW9u LCBJIGFzc3VtZSB0aGUgUkZDIGVkaXRvciB3aWxsIGRvDQo+ID4gPiA+ID4gYW5vdGhlciByZXZp ZXcgb25jZSB0aGUgZG9jdW1lbnQgcHJvZ3Jlc3NlZCB0byB0aGF0IHN0YWdlLg0KPiA+ID4gPiA+ DQo+ID4gPiA+ID4gPiBNYWpvciBJc3N1ZXM6DQo+ID4gPiA+ID4gPiDigKIgTm8gbWFqb3IgaXNz dWVzIGZvdW5kDQo+ID4gPiA+ID4gPiBNaW5vciBJc3N1ZXM6DQo+ID4gPiA+ID4gPiDigKIgQWJz dHJhY3Q6IOKAnEluIGFkZGl0aW9uLCB0aGUgdXNlciB0cmFmZmljIG1heSB0cmF2ZXJzZQ0KPiA+ ID4gPiA+ID4gdGhyb3VnaCBtdWx0aXBsZSB0cmFuc3BvcnQgbmV0d29ya3Mu4oCdIE1heWJlIGlz IHdvcnRoDQo+ID4gPiA+ID4gPiBlbGFib3JhdGluZyBhIGJpdCB0aGlzIHNlbnRlbmNlIHNheWlu ZyB0aGF0IHRoZSBleHRlbnNpb25zDQo+ID4gPiA+ID4gPiBkZWZpbmVkIGluIHRoaXMgZHJhZnQg YXBwbHkgYm90aCB0byBTUy0NCj4gPiA+ID4gPiBQVyBhbmQgTVMtUFcuDQo+ID4gPiA+ID4NCj4g PiA+ID4gPiBIb3cgYWJvdXQgdGhpczoNCj4gPiA+ID4gPg0KPiA+ID4gPiA+ICJNYW55IHRyYW5z cG9ydCBzZXJ2aWNlcyByZXF1aXJlIHRoYXQgdXNlciB0cmFmZmljLCBpbiB0aGUgZm9ybQ0KPiA+ ID4gPiA+IG9mIFBzZXVkb3dpcmVzIChQVyksIGJlIGRlbGl2ZXJlZCBvbiBhIHNpbmdsZSBjby1y b3V0ZWQNCj4gPiA+ID4gPiBiaWRpcmVjdGlvbmFsIHR1bm5lbCBvciB0d28gdHVubmVscyB0aGF0 IHNoYXJlIHRoZSBzYW1lIHJvdXRlcy4NCj4gPiA+ID4gPiBUaGlzIGRvY3VtZW50IGRlZmluZXMg YW4gb3B0aW9uYWwgZXh0ZW5zaW9uIHRvIExEUCB0aGF0IGVuYWJsZXMNCj4gPiA+ID4gPiB0aGUg YmluZGluZyBiZXR3ZWVuIFBXcyBhbmQgdGhlIHVuZGVybHlpbmcgVEUgdHVubmVscy4gVGhlDQo+ ID4gPiA+ID4gZXh0ZW5zaW9uIGFwcGxpZXMgdG8gYm90aCBTUy1QVyBhbmQNCj4gPiA+ID4gTVMt UFcuIg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiDigKIgSW4gdGhlIGFic3RyYWN0IGl0IGlzIHNh aWQgdGhhdCBhIFBXIGlzIGxpbmtlZCB0byBhbiBMU1AgYnV0DQo+ID4gPiA+ID4gPiB0aGVuIGlu IHRoZSBpbnRybyBpdCBpcyBzYWlkIHRoYXQgdGhlIFBXIGJpbmRpbmcgaXMgdG8gYSB0dW5uZWwu DQo+ID4gPiA+ID4gPiBDYW4geW91IGNsYXJpZnkgdGhpcz8gSeKAmWQgc2F5IHRoYXQgaXQgc2hv dWxkIGJlIGxpbmtlZCB0byBhIHR1bm5lbCwgcmlnaHQ/DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBZ ZXMsIGl0J3MgYmV0dGVyIHRvIHVzZSB0dW5uZWwsIEkgaGF2ZSB1cGRhdGVkIHRoZSBhYnN0cmFj dCB0bw0KPiA+ID4gPiA+IG1ha2UgQWJzdHJhY3QgYW5kIEludHJvZHVjdGlvbiBoYXZlIHRoZSBj b25zaXN0ZW50IHVzYWdlLiBQbGVhc2UNCj4gPiA+ID4gPiBzZWUgYWJvdmUgdGhlIG5ldyB0ZXh0 IGZvciBBYnN0cmFjdC4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g4oCiIEludHJvOsKgwqAg4oCc UFctdG8tUFNOIFR1bm5lbCBiaW5kaW5nIGhhcyBiZWNvbWUgaW5jcmVhc2luZ2x5DQo+ID4gPiA+ ID4gPiBjb21tb24gYW5kIGltcG9ydGFudCBpbiBtYW55IGRlcGxveW1lbnQgc2NlbmFyaW9z4oCd LiBJIGd1ZXNzDQo+ID4gPiA+ID4gPiB5b3UgbWVhbiBhbiBhdXRvbWF0aWMgYmluZGluZyBkb25l IHZpYSBhIHNpZ25hbGluZyBwcm90b2NvbD8NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IE5vLCB0aGlz IHNlbnRlbmNlIGp1c3QgYnJpbmdzIHRoZSByZXF1aXJlbWVudHMgb2YgZXhwbGljaXQgUFcgdG8N Cj4gPiA+ID4gPiBQU04gdHVubmVsIGJpbmRpbmcsIHdoYXRldmVyIGl0IGlzIGF1dG9tYXRpYyBz aWduYWxpbmcgb3IgbWFudWFsDQo+ID4gY29uZmlndXJhdGlvbi4NCj4gPiA+ID4gPg0KPiA+ID4g PiA+ID4g4oCiIFdoYXQgZG8geW91IG1lYW4gd2l0aCDigJxtYXkgdHJhdmVyc2UgdGhyb3VnaCBk aWZmZXJlbnQgcm91dGVz4oCdPw0KPiA+ID4gPiA+ID4gSSBzdWdnZXN0IGxlYXZpbmcg4oCcbWF5 IHRyYXZlcnNlIG11bHRpcGxlIG5ldHdvcmtzIG9yIGRvbWFpbnMuDQo+ID4gPiA+ID4NCj4gPiA+ ID4gPiBIZXJlIHRoZSAicm91dGVzIiBtZWFucyAicGF0aHMiLg0KPiA+ID4gPiA+DQo+ID4gPiA+ ID4gSG93IGFib3V0OiAiLi4ubWF5IHRyYXZlcnNlIHRocm91Z2ggZGlmZmVyZW50IHBhdGhzIG9y IG5ldHdvcmtzIj8NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g4oCiIEludHJvIGFuZCBGaWd1cmUg MTogY291bGQgYmUgZXhhbXBsZSBiZSBtYWRlIGEgYml0IG1vcmUNCj4gPiA+ID4gPiA+IGdlbmVy aWMgd2l0aCBhIG5ldHdvcmsgYmV0d2VlbiB0aGUgUEVzPyBXaXRoIGRpcmVjdGx5DQo+ID4gPiA+ ID4gPiBjb25uZWN0ZWQgUEVzIGl0IGRvZXNu4oCZdCBzZWVtIGEgcmVhbGlzdGljIGFuZCBnZW5l cmljIGVub3VnaA0KPiBleGFtcGxlLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ IOKAoiBJbnRybzogc3VnZ2VzdCByZW1vdmluZyDigJxBcyBtZW50aW9uZWQgYWJvdmXigJ0uDQo+ ID4gPiA+ID4NCj4gPiA+ID4gPiBPSy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g4oCiIMKgVGhl IG5hbWUgb2YgdGhlIGRyYWZ0IGV4cGxpY2l0bHkgbWVudGlvbnMgTVBMUy1UUCBidXQgaW4NCj4g PiA+ID4gPiA+IHRoZSByZXN0IG9mIHRoZSBkcmFmdCB0aGVyZSBpcyBubyBtZW50aW9uIG9mIGl0 LCBqdXN0IHRoZSBtdWNoDQo+ID4gPiA+ID4gPiBtb3JlIGdlbmVyYWwgUGFja2V0IFN3aXRjaGlu ZyBOZXR3b3JrIHRlcm0gaXMgdXNlZC4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEluZGVlZCwgdGhh dCdzIHRoZSBpbnRlbnRpb24uIFRoaXMgd29yayB3YXMgdHJpZ2dlcmVkIGJ5IHRoZQ0KPiA+ID4g PiA+IGRpc2N1c3Npb24gb2YgTVBMUy1UUC4gQnV0IHdpdGggdGhlIHByb2dyZXNzIG9mIHRoaXMg ZHJhZnQgYW5kDQo+ID4gPiA+ID4gZGlzY3Vzc2lvbiB3aXRoaW4gdGhlIFdHLCB0aGVyZSBpcyBh IGNvbnNlbnN1cyB0aGF0IHRoaXMNCj4gPiA+ID4gPiB0ZWNobmlxdWUgaXMgYSBnZW5lcmFsIHNv bHV0aW9uIHRoYXQgY2FuIGFjdHVhbGx5IGFwcGx5IHRvIGJvdGggVFAgYW5kDQo+IG5vbi1UUCBj YXNlcy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g4oCiIFNlY3Rpb24gMjrCoMKgIOKAnFRoaXMg ZG9jdW1lbnQgZGVmaW5lcyBhIG5ldyBvcHRpb25hbCBUTFYsIFBTTg0KPiA+ID4gPiA+ID4gVHVu bmVsIEJpbmRpbmcgVExWLCB0byBjb21tdW5pY2F0ZSB0dW5uZWwvTFNQcyBzZWxlY3Rpb24gYW5k DQo+ID4gPiA+ID4gPiBiaW5kaW5nIHJlcXVlc3RzDQo+ID4gPiA+ID4gYmV0d2VlbiBQRXMuDQo+ ID4gPiA+ID4gPiDigJwgVGhlIGJpbmRpbmcgcmVxdWVzdCBpcyBiZXR3ZWVuIFBFcz8gT3IgYmV0 d2VlbiBhbiBQVyBhbmQgYQ0KPiA+ID4gPiA+ID4gVHVubmVsIChvciBMU1A/KSBiZXR3ZWVuIHR3 byBQRXM/DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBCZXR3ZWVuIFBFcyBvZiBhbiBQVy4NCj4gPiA+ ID4gPg0KPiA+ID4gPiA+ID4g4oCiIFNlY3Rpb24gMjogU3RyaWN0IGJpbmRpbmcgdnMgQ28tcm91 dGVkIGJpbmRpbmc6IGZyb20gdGhlDQo+ID4gPiA+ID4gPiBkZXNjcmlwdGlvbiBpdCBzZWVtcyB0 aGF0IHRoZSBmaXJzdCBvbmUgaXMgc3RyaWN0IGFuZCB0aGUNCj4gPiA+ID4gPiA+IHNlY29uZCBv bmUgaXMNCj4gPiA+ID4g4oCcbG9vc2XigJ0NCj4gPiA+ID4gPiA+IChpbiB0aGUgc2Vuc2UgdGhh dCB0aGUgUEUgY2FuIGFjY2VwdCB0aGUgcmVxdWVzdCBvciBub3QpLg0KPiA+ID4gPiA+ID4gRG9u 4oCZdCBib3RoIGFwcGx5DQo+ID4gPiA+ID4gdG8gY28tcm91dGVkIExTUHM/DQo+ID4gPiA+ID4N Cj4gPiA+ID4gPiBZZXMsIGJvdGggY2FuIGFwcGx5IHRvIGNvLXJvdXRlZCBMU1BzLiBCdXQgZm9y ICJzdHJpY3QiIG1vZGUsIGlmDQo+ID4gPiA+ID4gdGhlIGVncmVzcyBQRSBtdXN0IGJpbmQgdG8g dGhlIHNwZWNpZmllZCB0dW5uZWwgYnkgdGhlIGluZ3Jlc3MNCj4gPiA+ID4gPiBQRSwgb3RoZXJ3 aXNlLCB0aGUgYmluZGluZyB3aWxsIG5vdCBzdWNjZXNzLiBUaGUgImNvLXJvdXRlZCINCj4gPiA+ ID4gPiBtb2RlIGdpdmVzIHRoZSBlZ3Jlc3MgUEUgdGhlIHVzZSBhbHRlcm5hdGl2ZSB0dW5uZWwu DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IOKAoiBTZWN0aW9uIDI6IOKAnVRoZSB0ZXJtaW5vbG9n eSAiTFNQIiBpc8KgIGlkZW50aWNhbCB0byB0aGUgIkxTUCB0dW5uZWwiDQo+ID4gPiA+ID4gPiBk ZWZpbmVkIGluIFNlY3Rpb24gMi4xIG9mIFtSRkMzMjA5XSzCoCB3aGljaCBpcyB1bmlxdWVseQ0K PiA+ID4gPiA+ID4gaWRlbnRpZmllZCBieSB0aGUgU0VTU0lPTiBvYmplY3QgdG9nZXRoZXIgd2l0 aA0KPiA+ID4gPiA+ID4gU0VOREVSX1RFTVBMQVRFIChvcg0KPiA+ID4gPiA+ID4gRklMVEVSX1NQ RUMpIG9iamVjdCB0aGF0IGNvbnNpc3RzIG9mIExTUCBJRCBhbmQgVHVubmVsDQo+ID4gPiA+ID4g PiBlbmRwb2ludCBhZGRyZXNzLuKAnSBXaHkgaXMgdGhlIGRyYWZ0IGNvbnNpZGVyaW5nIG9ubHkg c2lnbmFsZWQgTFNQcz8NCj4gPiA+ID4gPiA+IERvZXNu4oCZdCBpdCBhcHBseSBhbHNvIHRvIGNl bnRyYWxseQ0KPiA+ID4gPiA+IHByb3Zpc2lvbmVkIG9uZXM/IChlLmcuIE5NUyBvciBTRE4pLg0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhlIG1haW4gcHVycG9zZSBoZXJlIGlzIHRvIGdpdmUgYSBy ZWZlcmVuY2UgdG8gdGhlIHRlcm0gb2YgIkxTUCINCj4gPiA+ID4gPiBhbmQgInR1bm5lbCIsIGhl bmNlIHRvIGVsaW1pbmF0ZSB0aGUgY29uZnVzaW9uIG9mIHdoZW4gdXNlIHRoZXNlDQo+ID4gPiA+ ID4gaW4gdGhlIGZvbGxvd2luZyBzZWN0aW9ucy4gQXMgZm9yIHRoZSBOTVMgYW5kIFNETiBiYXNl ZCBURQ0KPiA+ID4gPiA+IExTUC9UdW5uZWwsIHRlY2huaWNhbGx5LCBpdCBjYW4gYXBwbHkgdG8g YXMgd2VsbCBvbmx5IGlmIHRoZSBURQ0KPiA+ID4gPiA+IExTUC9UdW5uZWwgaGFzIHRoZSBMU1Ag bnVtYmVyLCBub2RlIElEIGV0Yy4gaW5mb3JtYXRpb24uDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ IOKAoiBTZWN0aW9uIDIuMTog4oCcTERQIExhYmVsIE1hcHBpbmcgbWVzc2FnZeKAnSBtaXNzaW5n IHJlZmVyZW5jZS4NCj4gPiA+ID4gPiA+IEFuZCB3aHkgdGhlIFR5cGUgZmllbGQgc3RhcnRzIHdp dGggMSBhbmQgMD8NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEdvb2QgY2F0Y2gsIHdpbGwgYWRkIGEg cmVmZXJlbmNlIGhlcmUuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gTml0czoN Cj4gPiA+ID4gPiA+IOKAoiBBYnN0cmFjdCBzLyB0cmF2ZXJzZSB0aHJvdWdoIG11bHRpcGxlLyB0 cmF2ZXJzZSBtdWx0aXBsZSDigKINCj4gPiA+IEludHJvZHVjdGlvbjoNCj4gPiA+ID4gPiA+IOKA nFBzZXVkb3dpcmUgKFBXKSBFbXVsYXRpb24gRWRnZS10by1FZGdlIChQV0UzKeKAnS4gSSBzdWdn ZXN0DQo+ID4gPiA+ID4gPiByZW1vdmluZyAoUFcpLCBpdOKAmXMgYWxyZWFkeSBpbmNsdWRlZCBp bnRvIFBXRTMuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBPSy4NCj4gPiA+ID4gPiA+IOKAoiBJbnRy bzogcy8gYSBiaWRpcmVjdGlvbmFsIGNpcmN1aXRzLyBhIGJpZGlyZWN0aW9uYWwgY2lyY3VpdA0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gT0suDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiDigKIgSW50cm86 IHN1Z2dlc3QNCj4gPiA+ID4gPiA+IHJlcGhyYXNpbmc6IOKAnEJpZGlyZWN0aW9uYWwgTFNQcyBz aGFyZSBmYXRlIGFuZCBzaW1wbGlmeSB0aGUNCj4gPiA+ID4gPiA+IHJvdXRpbmcgb2YgYSBwcm90 ZWN0aW9uIHBhdGggYWxzbyBjb25zaXN0aW5nIG9mIGJpZGlyZWN0aW9uYWwNCj4gPiA+ID4gPiA+ IExTUHMgYmVjYXVzZSB3b3JraW5nIGFuZCBwcm90ZWN0aW9uIHBhdGhzIGhhdmUgdG8gYmUgZGlz am9pbnQu4oCdDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBPSy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ ID4g4oCiIEludHJvOiBzLyB0aGVyZSBhcmUgYSBsYXJnZSBudW1iZXIvIHRoZXJlIGlzIGEgbGFy Z2UgbnVtYmVyDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBPSy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ IOKAoiBJbnRybzpzL3RvIGJlDQo+ID4gPiA+ID4gPiBjYXJyaWVkL2FyZSBjYXJyaWVkDQo+ID4g PiA+ID4NCj4gPiA+ID4gPiBPSy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IOKAoiBJbnRybzpzL3Ro ZXJlIGFyZSBhIG51bWJlci90aGVyZSBpcyBhIG51bWJlcg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4g T0suDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiDigKIgSW50cm86IHMvDQo+ID4gPiA+ID4gPiB0cmFm ZmljIGJlbG9uZ3MvdHJhZmZpYyBiZWxvbmdpbmcNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IE9LLg0K PiA+ID4gPiA+DQo+ID4gPiA+ID4g4oCiIEludHJvOiAoc3VnZ2VzdGlvbikgcy8oUEUxLVAzLVBF MikvDQo+ID4gPiA+ID4gPiAoUEUyLVAzLVBFMSkgc2luY2Ugd2UgYXJlIHNwZWFraW5nIGFib3V0 IGRpcmVjdGlvbmFsaXR5IGl0DQo+ID4gPiA+ID4gPiBtYWtlcyBtb3JlIHNlbnNlIHRvIGxpc3Qg dGhlIG5vZGVzIG9mIHRoZSBwYXRoIGluIHRoZSByZXZlcnNlDQo+IGRpcmVjdGlvbi4NCj4gPiA+ ID4gPg0KPiA+ID4gPiA+IE9LLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiDigKIgSW50cm86IHMv IFRoZSBzaW1pbGFyIHByb2JsZW1zL0Egc2ltaWxhciBwcm9ibGVtDQo+ID4gPiA+ID4NCj4gPiA+ ID4gPiBPSy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ID7igKIgSW50cm86IHMvIHdvbid0L2RvZXMg bm90DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBPSy4NCj4gPiA+ID4gPiA+4oCiSW50cm86IHMvIElu IHRoaXMgZG9jdW1lbnQsIGl0IGludHJvZHVjZXMvVGhpcyBkb2N1bWVudA0KPiA+ID4gPiA+ID5p bnRyb2R1Y2VzIEJSIERhbmllbGUNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IE9LLg0KPiA+ID4gPiA+ DQo+ID4gPiA+ID4gPg0KDQo= From nobody Wed May 25 05:29:34 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1177012D579; Tue, 24 May 2016 20:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_KAM_HTML_FONT_INVALID=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 Zept_3B81Uus; Tue, 24 May 2016 20:07:13 -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 5A7EA12D1C0; Tue, 24 May 2016 20:07:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKR47019; Wed, 25 May 2016 03:07:08 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 25 May 2016 04:07:04 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.169]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Wed, 25 May 2016 11:06:51 +0800 From: Mingui Zhang To: Alexander Vainshtein Thread-Topic: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname Thread-Index: AdGxvD1O5NXHbyN7QyqT5SoYhCMmtADEL2dg//+XboD//iaMUIADdLkA//57BIA= Date: Wed, 25 May 2016 03:06:51 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E787CB9054@NKGEML515-MBS.china.huawei.com> References: <4552F0907735844E9204A62BBDD325E787CB087E@NKGEML515-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E787CB7589@NKGEML515-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.146.93] Content-Type: multipart/alternative; boundary="_000_4552F0907735844E9204A62BBDD325E787CB9054NKGEML515MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.574516DD.00AD, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.169, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e4f706f8ab575f392bb28868bf99aae7 Archived-At: X-Mailman-Approved-At: Wed, 25 May 2016 05:29:31 -0700 Cc: "Zhangxian \(Xian\)" , "'rtg-dir@ietf.org'" <'rtg-dir@ietf.org'>, "trill@ietf.org" , Jonathan Hardwick , "draft-ietf-trill-multilevel-single-nickname@ietf.org" , Susan Hares , "jon.hudson@gmail.com" Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 03:07:18 -0000 --_000_4552F0907735844E9204A62BBDD325E787CB9054NKGEML515MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sasha, Thanks for the comments. [[Sasha]] Do you (or the authors of the multi-level TRILL draft) consider d= eployment scenarios with more than 64K RBridges in a single TRILL campus? I= s this a realistic scenario? [Mingui] We can also doubt whether a domain with more that 2^32 IP routers = is a realistic scenario. The fact is that a single campus is usually not al= lowed to use up the entire 64K namespace. Please consider the scenario that= lots of TRILL campuses are to be interconnected. [[Sasha]] In other words, your draft explicitly states that the area border= RBridges modify the nicknames in the TRILL header of a packet that crosses= the Level 2 domain. How is this different from swapping (save from the nam= e of the operation)? [Mingui] As I said, there is no "swap nickname field" conception in the dra= ft. Yes, the border RBridge needs to modify the nickname but it does not h= ave to modify it through the "swapping" operation. Instead, the border RBri= dge "replaces" the nickname in the TRILL data packets with its own nickname= (rather than a nickname in the "swap nickname field" provided by the origi= nating RBridge). Why authors prefer the replacing operation than the swappi= ng operation? Because the swapping operation requires a new TRILL header (t= wo additional 16-bit fields) which has not been standardized yet. As for the "Updates" metadata, let's see if people on the RTG-DIR list woul= d give directions. Best regards, Mingui From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Tuesday, May 24, 2016 6:45 PM To: Mingui Zhang Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-= multilevel-single-nickname@ietf.org; Susan Hares; jon.hudson@gmail.com; Jon= athan Hardwick Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-si= ngle-nickname Mingui hi! Lots of thanks for a prompt response. A few short comments inline below. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: Mingui Zhang [mailto:zhangmingui@huawei.com] Sent: Tuesday, May 24, 2016 11:23 AM To: Alexander Vainshtein Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares; jon.hudson@gmail= .com; Jonathan Hardwick Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-si= ngle-nickname Hi Sasha, Thanks for your comments. Please see responses inline below. Thanks, Mingui From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Monday, May 23, 2016 6:13 PM To: Mingui Zhang Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares (shares@ndzh.com<= mailto:shares@ndzh.com>); jon.hudson@gmail.com= ; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com) Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-si= ngle-nickname Mingui hi! Lots of thanks for a prompt response to some of the issues I've raised in t= he review. Please see some comments to you responses inline below. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Mingui Zhang Sent: Monday, May 23, 2016 12:31 PM To: Alexander Vainshtein; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.c= om) Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares (shares@ndzh.com<= mailto:shares@ndzh.com>); jon.hudson@gmail.com Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-si= ngle-nickname Hi Alexander, Thanks for the review! The multilevel conception itself is abstract and not easily understandable. [[Sasha]] Do you refer to the multi-level IS-IS in general or multi-level T= RILL specifically? I am asking because I believe am reasonably well aware o= f the multi-level architecture of IS-IS as used for IP routing. It is somew= hat different from that of OSPF, but I would not call it "abstract and not = easily understandable". And there are quite a few excellent introductions = to the subject (again in the context of IP routing). However, I am definite= ly not a TRILL expert, and have stated that in the review. [Mingui] Yes, multi-level arch of IS-IS has already been well understood. H= owever, the extending TRILL to multi-levels brings new challenges. As state= d in the informational draft, one issue is on processing the TRILL switch n= icknames and the other issue is on handling multi-destination packet distri= bution trees. In order not to make the specifications "abstract", the draft= carefully designed two walking-through examples in Section 3. If the examp= les were understood, it would be non-abstract as well. ;-) However, it was really interesting in designing such a solution. Appreciate= the review and the time on relevant documents to figure out the whole sche= me. > ? Nor provides any explanations about the reasons that make > single-level IS-IS used by TRILL less scalable that single-level IS-IS > when it is used for distributing IP reachability The reason comes from the fact that the length of a nickname is different f= rom an IP address. [[Sasha]] I must admit that I do not understand the connection. By this log= ic, IS-IS for CLNS and IPv6 should be much more scalable than IS-IS for IPv= 4, but I have never seen such claims before. Could you please elaborate? Co= uld somebody on the RTG-DIR list to comment on that? [Mingui] For a single-level IS-IS instance, the length of the address deter= mines the name space. In the informational draft, Section 1.1 TRILL Scalabi= lity Issues, the following statement is relevant " 5. the limit of the number of TRILL switches, due to the 16-bit nicknam= e space," [[Sasha]] Do you (or the authors of the multi-level TRILL draft) consider d= eployment scenarios with more than 64K RBridges in a single TRILL campus? I= s this a realistic scenario? I think this could be addressed in the updated version of the draft: https:= //datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/?include_tex= t=3D1. > * The draft positions itself as an alternative to the Aggregate > Nicknames approach while, from my POV, it is just provides additional > details on one of the possible flavors of this approach The WG used to discuss several ways to address the "Aggregate Nickname" app= roach. [[Sasha]] I do not follow the TRILL WG mailing list, so I am not aware of a= ny discussions that have been hold there. I am only speaking about what I c= ould find in the two drafts mentioned in my review. [Mingui] Actually, the informational draft had included the information of = those alternatives as well. Please see "Section 2.2.2.2 Swap Nickname Field= Aggregated Nicknames" and read the words about "pseudonode" of Section 2.5= . One way was to use pseudonode nickname to denote an L1 area. Another way wa= s to let border RBridges swap L1 and L2 nicknames. [[Sasha]] I was under impression that the Aggregate Nicknames approach alwa= ys implies swapping of ingress and egress nicknames - at least this is what= the Multi-Level Trill draft states, and the Single Nickname draft follows = suit. [Mingui] Oh, that's not true. The "Single Nickname" draft is definitely dif= ferent from "Swapping Nickname" approach. In the "Single Nickname" draft, t= here is no "ingress swap nickname field" or "egress swap nickname field". [[Sasha]] Quoting from Section 3.1 of the Dingle Nickname draft (and apolog= ies for a long quotation; the relevant places are highlighted): - S transmits an Ethernet frame with source MAC =3D S and destination MAC =3D D. - RB27 [[Sasha - the ingress RBridge]] encapsulates with a TRILL header= with ingress RBridge =3D 27, and egress RBridge =3D 3 producing a TRILL Data packet. - RB2 and RB20 have announced in the Level 1 IS-IS instance in area {2,20}, that they are attached to all those area nicknames, including {3,30}. Therefore, IS-IS routes the packet to RB2 (or RB20, if RB20 on the least-cost route from RB27 to RB3). - RB2, when transitioning the packet from Level 1 to Level 2, replaces the ingress TRILL switch nickname with its own nickname, so replaces 27 with 2. ... - The packet is forwarded through Level 2, to RB3, which has advertised, in Level 2, its L2 nickname as 3. - RB3, when forwarding into area {3,30}, replaces the egress nickname in the TRILL header with RB44's nickname (44). (The ingress nickname MAY be replaced with an area nickname selected from {2,20}. See Section 4 for the detail of the selection method. Here, suppose nickname 2 is selected.) So, within the destination area, the ingress nickname will be 2 and the egress nickname will be 44. In other words, your draft explicitly states that the area border RBridges = modify the nicknames in the TRILL header of a packet that crosses the Level= 2 domain. How is this different from swapping (save from the name of the o= peration)? I also do not understand how using L1 area names (which is a control plane = functionality) could replace the swapping of nicknames (which is a pure dat= a plane function). [Mingui] There is no "swapping" action in the "Single Nickname" draft. To e= xplain with an example, if the TRILL data packet is transitioned from level= 1 to level 2, the ingress nickname will be rewritten to the L1 area nickna= me. Please also refer to bullet 4 of Section 3.1 in the "Single Nickname" d= raft. [[Sasha]] Please see above. However, these possible alternatives were never detailed as the one being r= eviewed, after the WG weighted their issues and complexity. [[Sasha]] It is all fine, but, from my POV, it does not address the issue I= 've raised, namely that the Single Nickname draft incorrectly positions its= elf as an alternative approach to that of Aggregate Nicknames in the Multi-= Level TRILL draft, and that such incorrect positioning negatively affects a= bility of a non-expert [Mingui] I think the above explanation about the difference between "Single= Nickname" and "Swapping Nickname" will clear the confusion. [[Sasha]] Sorry, but no, it doesn't. > * The draft is intended for the Standards Track, but it does not = say that > it updates the base TRILL spec (neither in the text nor in metadata) RFC 6325 is the base TRILL spec and it restricts itself to level 1 IS-IS wh= ile the draft being reviewed is talking about how to enable inter-communica= tion between level 1 IS-IS areas with level 2 border RBridges. That also me= ans level 1 RBridges conforms to RFC 6325 remain unchanged. So RFC 6325 sho= uld not appear in the "Updates" metadata? [[Sasha]] It seems that we understand the meaning of the RFC metadata diffe= rently. From my POV if you remove/relax a restriction imposed by an alread= y published Standards Track RFC, this means that you update it, and the met= adata should reflect that. E.g., you can take a look at RFC 4379 that is ma= rked as updating RFC 1122 because it allows transmission of IP packets with= the Destination IP address in the 127/8 subnet - something that RFC 1122 = explicitly prohibits. Again, it would be interesting to hear what the people on the RTG-DIR list = (especially ones that serve now - or have served in the past - as ADs and/o= r WG Chairs) think on that. [Mingui] OK. Thanks for the informational example. I am afraid the relation= ship between the draft and RFC 6325 is slightly different. Since specifica= tions of RFC 6325 would still hold after the draft is published. [[Sasha]] Were it otherwise, I would ask why the Single Nickname draft is n= ot marked as obsoleting RFC 6325. Best regards, Mingui > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Thursday, May 19, 2016 6:59 PM > To: Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com) > Cc: Susan Hares (shares@ndzh.com); jon.hudson@gma= il.com; Zhangxian > (Xian); draft-ietf-trill-multilevel-single-nickname@ietf.org; > 'rtg-dir@ietf.org'; trill@ietf.org > Subject: RTG-DIR QA review for > draft-ietf-trill-multilevel-single-nickname > > Hi all, > I have been appointed as the QA reviewer for > draft-ietf-trill-multilevel-single-nickname rg/doc/draft-i etf-trill-multilevel-single-nickname/?include_text=3D1>. > Before going into the review proper, I would like to make a couple of > introductory statements. > > > 1. I am NOT a TRILL expert and actually never before has been invol= ved > with TRILL. I have been told that this is OK and the ADs are > interested into getting reviews from non-experts. Well, in my case this i= s what they will get. > > 2. The time frame for providing the review was quite demanding (at = least > for me). This probably affected the review quality and it effectively > prevented me from discussing the review with the draft authors > privately - I owe them a sincere apology for that. > > 3. The RtgDirDocQa - Rtg Area > Wiki > states that the QA review is usually performed when a draft is going > to be adopted as a WG document. While it mentions, that a WG document > may be also subjected to such a review at the discretion of the WG > Chairs, the initial guidelines for the QA reviewer in the Wiki mention > only reviewing the draft for a QA adoption. As a consequence, I had to > create my own list of questions that will try to answer based on what I h= ave found in the Wiki. Here is this list: > > a. Is the draft easily readable and understandable? > > b. Does the draft represent an attempt to solve a real problem? > > c. Are there some serious technical gaps that the authors should tr= y to > fill? > > d. Are there any potential IETF process issues with the draft in its= present > form? > Please note that the question about "a good start for a WG draft" > which appears in the Wiki does not appear on my list (since the draft is = already a WG document). > At the same time I have included the question about solving a real > problem (which appeared in the previous version of the Wiki page). The > current version only asks if the draft "makes sense" which, from my POV, = is something else. > > > My answers to these questions follow. > > Is the draft easily readable and understandable? > Of course, "easily readable and understandable" is in the eye of the beho= lder. > But as a non-expert can say that it was quite difficult for me to > understand what this draft is really about. > Eventually, I have succeeded to build the following scheme that helped > me to understand what I am dealing with: > > * The TRILL base > spec: > > o Explicitly restricts TRILL to a single Level 1 IS-IS > > o Explicitly states that the nicknames of RBridges in the Trill packet = header > remain unchanged when the packet traverses the TRILL domain from > ingress (where the TRILL header is pushed on the original Ethernet > frame) to egress (where this header is popped) > > * An Informational Multi-Level > TRILL evel/?include _text=3D1> WG draft claims that this restriction > negatively affects TRILL scalability: > > o It mentions several scalability issues > > o However, it > > ? Neither mentions any specific scale parameters where these issues > become real > > ? Nor provides any explanations about the reasons that make > single-level IS-IS used by TRILL less scalable that single-level IS-IS > when it is used for distributing IP reachability > > o It claims that some of these issues may be addressed by allowing usag= e of > multi-level IS-IS for TRILL > > o It provides two specific proposals for making multi-level TRILL work: > > o One of these proposals is called "unique nicknames". This proposal: > > ? Does not require any changes in the TRILL data plane > > ? Requires introducing some structure in the nicknames of RBridges in > order to guarantee that these names are unique within the TRILL-based > campus > > o The other proposal is called "aggregate nicknames". This proposal: > > ? Allows RBridges in different L1 areas of the campus to share > nicknames > > ? Requires a change in the TRILL data plane: the nicknames in the > TRILL header of a packet will be modified by the L12 RBridges > > ? Allows two possible flavors (bot mentioned in the draft): > > * The flavor that uses L1 area nicknames > > * The flavor that uses the nicknames of all L12 RBridges connecte= d to a > given L1 area as its name > > * The Standards Track Single Nickname draft (one that I have been > asked to review) provides details on the second of the above-mentioned > flavors of the "Aggregate Nicknames" approach: > > o It also allows sharing the same nickname between RBridges in differen= t L1 > areas > > o It also requires the same change in the TRILL data plane > > o It eliminates the need for allocating nicknames to L1 areas. Instead,= each > such area is identified by the set of nicknames of all L12 RBridges > that connect to it. > It took me quite some time to build this scheme, and the text in the > draft was not very helpful in this. > The following points contributed to "negative readability" from my POV: > > * The draft positions itself as an alternative to the Aggregate > Nicknames approach while, from my POV, it is just provides additional > details on one of the possible flavors of this approach > > * The draft is intended for the Standards Track, but it does not = say that > it updates the base TRILL spec (neither in the text nor in metadata) --_000_4552F0907735844E9204A62BBDD325E787CB9054NKGEML515MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sasha,

 

Thanks for the comments.

 

[[Sasha]] Do you (or the authors of the multi-level TRILL draft) consider= deployment scenarios with more than 64K RBridges in a single TRILL campus?= Is this a realistic scenario?

[Mingui] We can also doubt whether a domain with more that 2^32 I= P routers is a realistic scenario. The fact is that a single campus is usua= lly not allowed to use up the entire 64K namespace. Please consider the scenario that lots of TRILL campuses are to= be interconnected.

 

[[Sasha]] In other words, your draft explicitly states that the area border RBridges= modify the nicknames in the TRILL header of a packet that crosses the Leve= l 2 domain. How is this different from swapping (save from the name of the operation)?<= /p>

[Mingui] As I said, there is no “swap nickname field” conception in the draft.  Yes, the border RBridge needs to modify the= nickname but it does not have to modify it through the “swappingR= 21; operation. Instead, the border RBridge “replaces” the nickn= ame in the TRILL data packets with its own nickname (rather than a nickname in the “swap nickname field” provided by the origin= ating RBridge). Why authors prefer the replacing operation than the swappin= g operation? Because the swapping operation requires a new TRILL header (tw= o additional 16-bit fields) which has not been standardized yet.

 

As for the “Updates” metadata, let’s see if peo= ple on the RTG-DIR list would give directions.

 

Best regards,

Mingui

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@eci= tele.com]
Sent: Tuesday, May 24, 2016 6:45 PM
To: Mingui Zhang
Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf= -trill-multilevel-single-nickname@ietf.org; Susan Hares; jon.hudson@gmail.c= om; Jonathan Hardwick
Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multil= evel-single-nickname

 

Mingui = hi!

Lots of= thanks for a prompt response.

&n= bsp;

A few s= hort comments inline below.<= /p>

&n= bsp;

Regards= ,

Sasha

&n= bsp;

Office:= +972-39266302

Cell:&n= bsp;     +972-549266302

Email:&= nbsp;  Alexander.Vainshtein@ecitele.com

&n= bsp;

From: Mingui Zhang [mailto:= zhangmingui@huawei.com]
Sent: Tuesday, May 24, 2016 11:23 AM
To: Alexander Vainshtein
Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares; jon.hudson@gmail.com; Jonathan Hardwick
Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multil= evel-single-nickname

 

Hi Sasha,

 

Thanks for your comments. Please see responses inline below.

 

Thanks,

Mingui

 

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Monday, May 23, 2016 6:13 PM
To: Mingui Zhang
Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares (shares@ndzh.com); jon.hudson@gmail.com; Jonathan = Hardwick (Jonathan.Hard= wick@metaswitch.com)
Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multil= evel-single-nickname

 

Mingui hi!=

Lots of thanks for a prompt = response to some of the issues I've raised in the review.=

 

Please see some comments to = you responses inline below.=

 

Regards,

Sasha

 

Office: +972-39266302

Cell:    = ;  +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 

-----Original Message----- From: rtg-dir [mailto:rtg-dir-b= ounces@ietf.org] On Behalf Of Mingui Zhang
Sent: Monday, May 23, 2016 12:31 PM
To: Alexander Vainshtein; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)
Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; dra= ft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares (shares@ndzh.com); jon.hudson@gmail.com
Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-si= ngle-nickname

 

Hi Alexander,

 

Thanks for the review!<= /o:p>

 

The multilevel conception it= self is abstract and not easily understandable.

[[Sasha]] Do you refer to the multi-level IS-IS in general or multi-level= TRILL specifically? I am asking because I believe am reasonably well aware= of the multi-level architecture of IS-IS as used for IP routing. It is somewhat different from that of OSPF, but I = would not call it “abstract and not easily understandable”. &nb= sp;And there are quite a few excellent introductions to the subject (again = in the context of IP routing). However, I am definitely not a TRILL expert, and have stated that in the review.

 

[Mingui] Yes, multi-level arch of IS-IS has already been we= ll understood. However, the extending TRILL to multi-levels brings new chal= lenges. As stated in the informational draft, one issue is on processing the TRILL switch nicknames and the other= issue is on handling multi-destination packet distribution trees. In order= not to make the specifications “abstract”, the draft carefully= designed two walking-through examples in Section 3. If the examples were understood, it would be non-abstract as well. ;-)<= /span>

 <= span lang=3D"EN-US">

However, it was really inter= esting in designing such a solution. Appreciate the review and the time on = relevant documents to figure out the whole scheme.

 

> ?  Nor provides an= y explanations about the reasons that make

> single-level IS-IS used= by TRILL less scalable that single-level IS-IS

> when it is used for dis= tributing IP reachability

 

The reason comes from the fa= ct that the length of a nickname is different from an IP address.

[[Sasha]] I must admit that I do not understand the connection. By this l= ogic, IS-IS for CLNS and IPv6 should be much more scalable than IS-IS for I= Pv4, but I have never seen such claims before. Could you please elaborate? Could somebody on the RTG-DIR list to = comment on that?

 

[Mingui] For a single-level IS-IS instance, the length of t= he address determines the name space. In the informational draft, Section 1= .1 TRILL Scalability Issues, the following statement is relevant

“   5. the lim= it of the number of TRILL switches, due to the 16-bit nickname space,”= ;<= /span>

[[Sasha]] Do you (or the authors of the multi-level TRILL draft) consider= deployment scenarios with more than 64K RBridges in a single TRILL campus?= Is this a realistic scenario?

 

 

I think this could be addres= sed in the updated version of the draft: https://datatracker.i= etf.org/doc/draft-ietf-trill-rbridge-multilevel/?include_text=3D1.

 

> *    &nb= sp;    The draft positions itself as an alternative to = the Aggregate

> Nicknames approach whil= e, from my POV, it is just provides additional

> details on one of the p= ossible flavors of this approach

 

The WG used to discuss sever= al ways to address the "Aggregate Nickname" approach.

[[Sasha]] I do not follow the TRILL WG mailing list, so I am not aware of= any discussions that have been hold there. I am only speaking about what I= could find in the two drafts mentioned in my review.

 

[Mingui] Actually, the informational draft had included the= information of those alternatives as well. Please see “Section 2.2.2= .2 Swap Nickname Field Aggregated Nicknames” and read the words about “pseudonode” of Section 2.5. <= /b>

 

One way was to use pseudonod= e nickname to denote an L1 area. Another way was to let border RBridges swa= p L1 and L2 nicknames.

[[Sasha]] I was under impression that the Aggregate Nicknames approach al= ways implies swapping of ingress and egress nicknames – at least this= is what the Multi-Level Trill draft states, and the Single Nickname draft follows suit.

 

[Mingui] Oh, that’s not true. The “Single Nickn= ame” draft is definitely different from “Swapping Nickname̶= 1; approach. In the “Single Nickname” draft, there is no “= ;ingress swap nickname field” or “egress swap nickname field”.<= /b>

[[Sasha]] Quoting from Section 3.1 of the Dingle Nickname draft (and apol= ogies for a long quotation; the relevant places are highlighted):

    -  S transmits an Ethernet frame with sour= ce MAC =3D S and destination

      MAC =3D D.

 

   -  RB27 [[Sasha – the ingress RBridge]]<= /b> encapsulates with a TRILL header with ingress RBridge =3D 27,

      and egress RBridge =3D 3 producing a TRILL = Data packet.

 

   -  RB2 and RB20 have announced in the Level 1 IS-IS inst= ance in area

      {2,20}, that they are attached to all those= area nicknames,

      including {3,30}. Therefore, IS-IS routes t= he packet to RB2 (or

      RB20, if RB20 on the least-cost route from = RB27 to RB3).

 

   -  RB2, when transitioning the packet from Level 1 to Level 2,

     = ; replaces the ingress TRILL switch nickname with its own nickname,

    &nbs= p; so replaces 27 with 2.

…

 

   -  The packet is forwarded through Level 2, to RB3, whic= h has

      advertised, in Level 2, its L2 nickname as = 3.

 

   -  RB3, when forwarding into area {3,30}, replaces the egress

     = ; nickname in the TRILL header with RB44's nickname (44). (The

     = ; ingress nickname MAY be replaced with an area nickname selected

     = ; from {2,20}. See Section 4 for the detail of = the selection method.

      Here, suppose nickname 2 is selected.) So, = within the destination

      area, the ingress nickname will be 2 and th= e egress nickname will

      be 44.

In other words, your draft explicitly states that the ar= ea border RBridges modify the nicknames in the TRILL header of a packet tha= t crosses the Level 2 domain. How is this different from swapping (save from the name of the operation)?<= /span>

 

I also do not understand how using L1 area names (which is a control plan= e functionality) could replace the swapping of nicknames (which is a pure d= ata plane function).<= /p>

 

[Mingui] There is no “swapping” action in the &= #8220;Single Nickname” draft. To explain with an example, if the TRIL= L data packet is transitioned from level 1 to level 2, the ingress nickname will be rewritten to the L1 area nickname. Please also refer to b= ullet 4 of Section 3.1 in the “Single Nickname” draft.=

[[Sasha]] Please see above.

 

However, these possible alte= rnatives were never detailed as the one being reviewed, after the WG weight= ed their issues and complexity.

[[Sasha]] It is all fine, but, from my POV, it does not address the issue= I’ve raised, namely that the Single Nickname draft incorrectly posi= tions itself as = an alternative approach to that of Aggregate Nicknames in the Multi-Level T= RILL draft, and that such incorrect positioning negatively affects ability of a non-expert

 

[Mingui] I think the above explanation about the difference= between “Single Nickname” and “Swapping Nickname” = will clear the confusion.

[[Sasha]] Sorry, but no, it doesn’t.

 

> *   &nbs= p;     The draft is intended for the Standards Track, b= ut it does not say that

> it updates the base TRI= LL spec (neither in the text nor in metadata)

 

RFC 6325 is the base TRILL s= pec and it restricts itself to level 1 IS-IS while the draft being reviewed= is talking about how to enable inter-communication between level 1 IS-IS a= reas with level 2 border RBridges. That also means level 1 RBridges conforms to RFC 6325 remain unchanged. So RFC = 6325 should not appear in the "Updates" metadata?

[[Sasha]] It seems that we understand the meaning of the RFC metadata dif= ferently. From my POV if  you remove/relax a restriction imposed by an= already published Standards Track RFC, this means that you update it, and the metadata should reflect that. E.g., you = can take a look at RFC 4379 that is marked as updating RFC 1122 because it = allows transmission of IP packets with the Destination IP address  in = the 127/8 subnet – something that RFC 1122 explicitly prohibits.<= /span>

Again, it would be interesting to hear what the people on the RTG-DIR lis= t (especially ones that serve now – or have served in the past –= ; as ADs and/or WG Chairs) think on that.

&nbs= p;

[Mingui] OK. Thanks for the informational example. I am afr= aid the relationship between the draft and  RFC 6325 is slightly diffe= rent. Since specifications of RFC 6325 would still hold after the draft is published.

[[Sasha]] Were it otherwise, I would ask why the Single Nickname draft is= not marked as obsoleting RFC 6325.

 

Best regards,

Mingui

 

> -----Original Message--= ---

> From: Alexander Vainsht= ein [mailto:Alexander.Vainshtein@ecitele.com= ]

> Sent: Thursday, May 19,= 2016 6:59 PM

> To: Jonathan Hardwick (= Jonathan.Hardwick@metaswitch.com)=

> Cc: Susan Hares (shares@ndzh.com); jon.hudson@gmail.com; Zhangxian

> (Xian); draft-ietf-trill-mult= ilevel-single-nickname@ietf.org;

> 'rtg-dir@ietf.org'; trill@ietf.org=

> Subject: RTG-DIR QA rev= iew for

> draft-ietf-trill-multil= evel-single-nickname

>

> Hi all,

> I have been appointed a= s the QA reviewer for

> draft-ietf-trill-multil= evel-single-nickname<https://datatracker.ietf.o

> rg/doc/draft-i etf-tril= l-multilevel-single-nickname/?include_text=3D1>.

> Before going into the r= eview proper, I would like to make a couple of

> introductory statements= .

>

>

> 1.   &nb= sp;   I am NOT a TRILL expert and actually never before has been = involved

> with TRILL. I have been= told that this is OK and the ADs are

> interested into getting= reviews from non-experts. Well, in my case this is what they will get.

>

> 2.   &nb= sp;   The time frame for providing the review was quite demanding= (at least

> for me). This probably = affected the review quality and it effectively

> prevented me from discu= ssing the review with the draft authors

> privately - I owe them = a sincere apology for that.

>

> 3.   &nb= sp;   The RtgDirDocQa - Rtg Area

> Wiki<https://trac.tools.ietf.org/area/rtg/tra= c/wiki/RtgDirDocQa>

> states that the QA revi= ew is usually performed when a draft is going

> to be adopted as a WG d= ocument. While it mentions, that a WG document

> may be also subjected t= o such a review at the discretion of the WG

> Chairs, the initial gui= delines for the QA reviewer in the Wiki mention

> only reviewing the draf= t for a QA adoption. As a consequence, I had to

> create my own list of q= uestions that will try to answer based on what I have found in the Wiki. He= re is this list:

>

> a.   &nb= sp;   Is the draft easily readable and understandable?=

>

> b.   &nb= sp;  Does the draft represent an attempt to solve a real problem?=

>

> c.   &nb= sp;   Are there some serious technical gaps that the authors shou= ld try to

> fill?=

>

> d.   &nb= sp;  Are there any potential IETF process issues with the draft in its= present

> form?=

> Please note that the qu= estion about "a good start for a WG draft"

> which appears in the Wi= ki does not appear on my list (since the draft is already a WG document).

> At the same time I have= included the question about solving a real

> problem (which appeared= in the previous version of the Wiki page). The

> current version only as= ks if the draft "makes sense" which, from my POV, is something el= se.

>

>

> My answers to these que= stions follow.

>

> Is the draft easily rea= dable and understandable?

> Of course, "easily= readable and understandable" is in the eye of the beholder.

> But as a non-expert can= say that it was quite difficult for me to

> understand what this dr= aft is really about.

> Eventually, I have succ= eeded to build the following scheme that helped

> me to understand what I= am dealing with:

>

> *   &nbs= p;     The TRILL base

> spec<https://datatracker.ietf.org/doc/rfc6325= /?include_text=3D1>:

>

> o   Explicitl= y restricts TRILL to a single Level 1 IS-IS

>

> o   Explicitl= y states that the nicknames of RBridges in the Trill packet header

> remain unchanged when t= he packet traverses the TRILL domain from

> ingress (where the TRIL= L header is pushed on the original Ethernet

> frame) to egress (where= this header is popped)

>

> *   &nbs= p;     An Informational Multi-Level

> TRILL<https://datatr= acker.ietf.org/doc/draft-ietf-trill-rbridge-multil

> evel/?include _text=3D1= > WG draft claims that this restriction

> negatively affects TRIL= L scalability:

>

> o   It mentio= ns several scalability issues

>

> o   However, = it

>

> ?  Neither mention= s any specific scale parameters where these issues

> become real<= /span>

>

> ?  Nor provides an= y explanations about the reasons that make

> single-level IS-IS used= by TRILL less scalable that single-level IS-IS

> when it is used for dis= tributing IP reachability

>

> o   It claims= that some of these issues may be addressed by allowing usage of=

> multi-level IS-IS for T= RILL

>

> o   It provid= es two specific proposals for making multi-level TRILL work:

>

> o   One of th= ese proposals is called "unique nicknames". This proposal:

>

> ?   Does not = require any changes in the TRILL data plane

>

> ?  Requires introd= ucing some structure in the nicknames of RBridges in

> order to guarantee that= these names are unique within the TRILL-based

> campus

>

> o   The other= proposal is called "aggregate nicknames". This proposal:

>

> ?  Allows RBridges= in different L1 areas of the campus to share

> nicknames

>

> ?  Requires a chan= ge in the TRILL data plane: the nicknames in the

> TRILL header of a packe= t will be modified by the L12 RBridges

>

> ?  Allows two poss= ible flavors (bot mentioned in the draft):

>

> *   &nbs= p;     The flavor that uses L1 area nicknames

>

> *   &nbs= p;     The flavor that uses the nicknames of all L12 RB= ridges connected to a

> given L1 area as its na= me

>

> *   &nbs= p;     The Standards Track Single Nickname draft (one t= hat I have been

> asked to review) provid= es details on the second of the above-mentioned

> flavors of the "Ag= gregate Nicknames" approach:

>

> o   It also a= llows sharing the same nickname between RBridges in different L1=

> areas=

>

> o   It also r= equires the same change in the TRILL data plane

>

> o   It elimin= ates the need for allocating nicknames to L1 areas. Instead, each

> such area is identified= by the set of nicknames of all L12 RBridges

> that connect to it.

> It took me quite some t= ime to build this scheme, and the text in the

> draft was not very help= ful in this.

> The following points co= ntributed to "negative readability" from my POV:

>

> *   &nbs= p;     The draft positions itself as an alternative to = the Aggregate

> Nicknames approach whil= e, from my POV, it is just provides additional

> details on one of the p= ossible flavors of this approach

>

> *   &nbs= p;     The draft is intended for the Standards Track, b= ut it does not say that

> it updates the base TRI= LL spec (neither in the text nor in metadata)

 

--_000_4552F0907735844E9204A62BBDD325E787CB9054NKGEML515MBSchi_-- From nobody Wed May 25 05:29:36 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2183012D1D1; Wed, 25 May 2016 05:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eci365.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 A-2UuEd9dnAK; Wed, 25 May 2016 05:23:40 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0137.outbound.protection.outlook.com [104.47.2.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9B0312B03C; Wed, 25 May 2016 05:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gwI1Yu/XP+uUX8RE92EZVU/yx/s6wFt7OTlwEHPt2v4=; b=GK4FzLJoto/Dk5Ae5cvDSzVeH99OaDavlpqDUbln5NtBkpvUUKRqORh4Q8oOrzOpwMAFSwMMP+62e9V1f5egNLgc3bAyc57EREPu+ucuJwWkNWPuYira1seirXivO1tt6KupsWurTA9Lu5S3oZzyecqt34sdh64PMMnugyM528s= Received: from HE1PR0301MB2266.eurprd03.prod.outlook.com (10.168.31.153) by HE1PR0301MB2266.eurprd03.prod.outlook.com (10.168.31.153) with Microsoft SMTP Server (TLS) id 15.1.497.12; Wed, 25 May 2016 12:23:36 +0000 Received: from HE1PR0301MB2266.eurprd03.prod.outlook.com ([10.168.31.153]) by HE1PR0301MB2266.eurprd03.prod.outlook.com ([10.168.31.153]) with mapi id 15.01.0497.022; Wed, 25 May 2016 12:23:36 +0000 From: Alexander Vainshtein To: Mingui Zhang Thread-Topic: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname Thread-Index: AQHRtZZOOYuy+h1UCUGjRJ1qjVLvXZ/H45PQgAEWN4CAAJSMMA== Date: Wed, 25 May 2016 12:23:36 +0000 Message-ID: References: <4552F0907735844E9204A62BBDD325E787CB087E@NKGEML515-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E787CB7589@NKGEML515-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E787CB9054@NKGEML515-MBS.china.huawei.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E787CB9054@NKGEML515-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=ecitele.com; x-originating-ip: [147.234.241.1] x-ms-office365-filtering-correlation-id: 720d0f6b-c308-45a9-890e-08d384976558 x-microsoft-exchange-diagnostics: 1; HE1PR0301MB2266; 5:Z0WQpBefndcdsFyqiIKwCWZsr7ICZzxqvhVAABOXqiaqdkFWqC4T4aXiWAxUMSRo29nYkf1ftENo/gO6ztcB2x6Tlj7UW2CSlWLBXPtaYwfi6sNPnrk8pC8oKi5PXDoVa1F5Qlh/xMrZ2WHkZ/WifQ==; 24:9PsExaNjiHKrvy1ukNHP3ipiel7NfAhGX+LPC3WtvCUQJNkSkIkOnzFUXq6Hsh1QpbI6Fb/b+qv4383mWXthZpLAmGTzsO40C9Vc3L8NCCM=; 7:5V9tnBbKY1utAxDvp4CA+U26OIp+KcdvntMFjNH8THZEOqOJ4zRM69x1YCIC+6M5QchKH2/a1mtGRz92KnHzjm6ZFspgp/d7QxUol9rPgqSw9g0Ao0+M/gqQreX0/GLswX0F02ly98xcltQ/guz5aCTbVQO7QghehR9Ux1illKFQFYj39XrOvxsR4z6iFHjT x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0301MB2266; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:HE1PR0301MB2266; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0301MB2266; x-forefront-prvs: 09538D3531 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51914003)(13464003)(377454003)(252514010)(53754006)(9686002)(5003600100002)(561944003)(74316001)(106116001)(33656002)(87936001)(5890100001)(9326002)(11100500001)(15975445007)(586003)(19617315012)(66066001)(110136002)(2900100001)(3280700002)(2950100001)(189998001)(5004730100002)(3660700001)(77096005)(230783001)(54356999)(93886004)(19580405001)(122556002)(86362001)(76176999)(50986999)(19580395003)(102836003)(5002640100001)(4326007)(1220700001)(3846002)(6116002)(19625215002)(8936002)(790700001)(2906002)(8676002)(19300405004)(10400500002)(5008740100001)(92566002)(76576001)(16236675004)(81166006)(559001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0301MB2266; H:HE1PR0301MB2266.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0301MB2266387BBFD233A622BF5A319D400HE1PR0301MB2266_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2016 12:23:36.3819 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0301MB2266 Archived-At: X-Mailman-Approved-At: Wed, 25 May 2016 05:29:31 -0700 Cc: "Zhangxian \(Xian\)" , "'rtg-dir@ietf.org'" <'rtg-dir@ietf.org'>, "trill@ietf.org" , Jonathan Hardwick , "draft-ietf-trill-multilevel-single-nickname@ietf.org" , Susan Hares , "jon.hudson@gmail.com" Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 12:23:47 -0000 --_000_HE1PR0301MB2266387BBFD233A622BF5A319D400HE1PR0301MB2266_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mingui, I will try to summarize our agreements and disagreements. 1. The scale of TRILL deployments: a. I have not seen any specific numbers or references to any specific= topologies that could really make single-level TRILL not scalable enough -= neither in the TRILL drafts I've read nor in our discussions so far b. Regarding your reference to multiple interconnected TRILL-based ca= mpuses in your last email: I do not think that TRILL is an alternative to o= r competes with Internet c. I have also noticed that, once upon a time (4 years ago) there wa= s an attempt to use BGP with TRILL. I wonder why this draft has been left t= o expire because, from my POV, BGP is greatly preferable to multi-level IS-= IS when it comes to scalability issues 2. Nickname Re-write vs Nickname Swapping: Looks like a clear case of= misunderstanding between us, probably due to the fact that I am not a TRIL= L expert: a. I have used the term "swapping" in the same way it is used in MPLS= (e.g., see RFC 3031 discussing label swapping). In other words, from my PO= V "nickname swapping" and "nickname re-write" were synonyms b. It seems that some yet to be standardized extension of TRILL consid= ers some dedicated nickname swapping mechanism that carries new nicknames i= n some extension of the TRILL header. In this parlance "nickname re-write"= and "nickname swapping" are different c. I think that we now safely consider this discussion issue as close= d 3. Metadata: a. I fully agree that we should hear from other RTG-DIR members on wh= at exactly (if at all) should be specified to clarify the relationship betw= een the Single Nickname draft and RFC 6325 b. I can only add that, AFAIK, the Multi-Level TRILL draft, being posi= tioned as an Informational, can neither update nor obsolete RFC 6325 (which= is Standards Track). So there is no issue with its metadata being empty. There is one issue in my original review that we have not discussed at all = - namely, the behavior implied by the Single Nickname draft when a new bord= er RBridge is added to a certain area. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: Mingui Zhang [mailto:zhangmingui@huawei.com] Sent: Wednesday, May 25, 2016 6:07 AM To: Alexander Vainshtein Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-= multilevel-single-nickname@ietf.org; Susan Hares; jon.hudson@gmail.com; Jon= athan Hardwick Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-si= ngle-nickname Hi Sasha, Thanks for the comments. [[Sasha]] Do you (or the authors of the multi-level TRILL draft) consider d= eployment scenarios with more than 64K RBridges in a single TRILL campus? I= s this a realistic scenario? [Mingui] We can also doubt whether a domain with more that 2^32 IP routers = is a realistic scenario. The fact is that a single campus is usually not al= lowed to use up the entire 64K namespace. Please consider the scenario that= lots of TRILL campuses are to be interconnected. [[Sasha]] In other words, your draft explicitly states that the area border= RBridges modify the nicknames in the TRILL header of a packet that crosses= the Level 2 domain. How is this different from swapping (save from the nam= e of the operation)? [Mingui] As I said, there is no "swap nickname field" conception in the dra= ft. Yes, the border RBridge needs to modify the nickname but it does not h= ave to modify it through the "swapping" operation. Instead, the border RBri= dge "replaces" the nickname in the TRILL data packets with its own nickname= (rather than a nickname in the "swap nickname field" provided by the origi= nating RBridge). Why authors prefer the replacing operation than the swappi= ng operation? Because the swapping operation requires a new TRILL header (t= wo additional 16-bit fields) which has not been standardized yet. As for the "Updates" metadata, let's see if people on the RTG-DIR list woul= d give directions. Best regards, Mingui From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Tuesday, May 24, 2016 6:45 PM To: Mingui Zhang Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares; jon.hudson@gmail= .com; Jonathan Hardwick Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-si= ngle-nickname Mingui hi! Lots of thanks for a prompt response. A few short comments inline below. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: Mingui Zhang [mailto:zhangmingui@huawei.com] Sent: Tuesday, May 24, 2016 11:23 AM To: Alexander Vainshtein Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares; jon.hudson@gmail= .com; Jonathan Hardwick Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-si= ngle-nickname Hi Sasha, Thanks for your comments. Please see responses inline below. Thanks, Mingui From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Monday, May 23, 2016 6:13 PM To: Mingui Zhang Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares (shares@ndzh.com<= mailto:shares@ndzh.com>); jon.hudson@gmail.com= ; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com) Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-si= ngle-nickname Mingui hi! Lots of thanks for a prompt response to some of the issues I've raised in t= he review. Please see some comments to you responses inline below. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Mingui Zhang Sent: Monday, May 23, 2016 12:31 PM To: Alexander Vainshtein; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.c= om) Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares (shares@ndzh.com<= mailto:shares@ndzh.com>); jon.hudson@gmail.com Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-si= ngle-nickname Hi Alexander, Thanks for the review! The multilevel conception itself is abstract and not easily understandable. [[Sasha]] Do you refer to the multi-level IS-IS in general or multi-level T= RILL specifically? I am asking because I believe am reasonably well aware o= f the multi-level architecture of IS-IS as used for IP routing. It is somew= hat different from that of OSPF, but I would not call it "abstract and not = easily understandable". And there are quite a few excellent introductions = to the subject (again in the context of IP routing). However, I am definite= ly not a TRILL expert, and have stated that in the review. [Mingui] Yes, multi-level arch of IS-IS has already been well understood. H= owever, the extending TRILL to multi-levels brings new challenges. As state= d in the informational draft, one issue is on processing the TRILL switch n= icknames and the other issue is on handling multi-destination packet distri= bution trees. In order not to make the specifications "abstract", the draft= carefully designed two walking-through examples in Section 3. If the examp= les were understood, it would be non-abstract as well. ;-) However, it was really interesting in designing such a solution. Appreciate= the review and the time on relevant documents to figure out the whole sche= me. > ? Nor provides any explanations about the reasons that make > single-level IS-IS used by TRILL less scalable that single-level IS-IS > when it is used for distributing IP reachability The reason comes from the fact that the length of a nickname is different f= rom an IP address. [[Sasha]] I must admit that I do not understand the connection. By this log= ic, IS-IS for CLNS and IPv6 should be much more scalable than IS-IS for IPv= 4, but I have never seen such claims before. Could you please elaborate? Co= uld somebody on the RTG-DIR list to comment on that? [Mingui] For a single-level IS-IS instance, the length of the address deter= mines the name space. In the informational draft, Section 1.1 TRILL Scalabi= lity Issues, the following statement is relevant " 5. the limit of the number of TRILL switches, due to the 16-bit nicknam= e space," [[Sasha]] Do you (or the authors of the multi-level TRILL draft) consider d= eployment scenarios with more than 64K RBridges in a single TRILL campus? I= s this a realistic scenario? I think this could be addressed in the updated version of the draft: https:= //datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/?include_tex= t=3D1. > * The draft positions itself as an alternative to the Aggregate > Nicknames approach while, from my POV, it is just provides additional > details on one of the possible flavors of this approach The WG used to discuss several ways to address the "Aggregate Nickname" app= roach. [[Sasha]] I do not follow the TRILL WG mailing list, so I am not aware of a= ny discussions that have been hold there. I am only speaking about what I c= ould find in the two drafts mentioned in my review. [Mingui] Actually, the informational draft had included the information of = those alternatives as well. Please see "Section 2.2.2.2 Swap Nickname Field= Aggregated Nicknames" and read the words about "pseudonode" of Section 2.5= . One way was to use pseudonode nickname to denote an L1 area. Another way wa= s to let border RBridges swap L1 and L2 nicknames. [[Sasha]] I was under impression that the Aggregate Nicknames approach alwa= ys implies swapping of ingress and egress nicknames - at least this is what= the Multi-Level Trill draft states, and the Single Nickname draft follows = suit. [Mingui] Oh, that's not true. The "Single Nickname" draft is definitely dif= ferent from "Swapping Nickname" approach. In the "Single Nickname" draft, t= here is no "ingress swap nickname field" or "egress swap nickname field". [[Sasha]] Quoting from Section 3.1 of the Dingle Nickname draft (and apolog= ies for a long quotation; the relevant places are highlighted): - S transmits an Ethernet frame with source MAC =3D S and destination MAC =3D D. - RB27 [[Sasha - the ingress RBridge]] encapsulates with a TRILL header= with ingress RBridge =3D 27, and egress RBridge =3D 3 producing a TRILL Data packet. - RB2 and RB20 have announced in the Level 1 IS-IS instance in area {2,20}, that they are attached to all those area nicknames, including {3,30}. Therefore, IS-IS routes the packet to RB2 (or RB20, if RB20 on the least-cost route from RB27 to RB3). - RB2, when transitioning the packet from Level 1 to Level 2, replaces the ingress TRILL switch nickname with its own nickname, so replaces 27 with 2. ... - The packet is forwarded through Level 2, to RB3, which has advertised, in Level 2, its L2 nickname as 3. - RB3, when forwarding into area {3,30}, replaces the egress nickname in the TRILL header with RB44's nickname (44). (The ingress nickname MAY be replaced with an area nickname selected from {2,20}. See Section 4 for the detail of the selection method. Here, suppose nickname 2 is selected.) So, within the destination area, the ingress nickname will be 2 and the egress nickname will be 44. In other words, your draft explicitly states that the area border RBridges = modify the nicknames in the TRILL header of a packet that crosses the Level= 2 domain. How is this different from swapping (save from the name of the o= peration)? I also do not understand how using L1 area names (which is a control plane = functionality) could replace the swapping of nicknames (which is a pure dat= a plane function). [Mingui] There is no "swapping" action in the "Single Nickname" draft. To e= xplain with an example, if the TRILL data packet is transitioned from level= 1 to level 2, the ingress nickname will be rewritten to the L1 area nickna= me. Please also refer to bullet 4 of Section 3.1 in the "Single Nickname" d= raft. [[Sasha]] Please see above. However, these possible alternatives were never detailed as the one being r= eviewed, after the WG weighted their issues and complexity. [[Sasha]] It is all fine, but, from my POV, it does not address the issue I= 've raised, namely that the Single Nickname draft incorrectly positions its= elf as an alternative approach to that of Aggregate Nicknames in the Multi-= Level TRILL draft, and that such incorrect positioning negatively affects a= bility of a non-expert [Mingui] I think the above explanation about the difference between "Single= Nickname" and "Swapping Nickname" will clear the confusion. [[Sasha]] Sorry, but no, it doesn't. > * The draft is intended for the Standards Track, but it does not = say that > it updates the base TRILL spec (neither in the text nor in metadata) RFC 6325 is the base TRILL spec and it restricts itself to level 1 IS-IS wh= ile the draft being reviewed is talking about how to enable inter-communica= tion between level 1 IS-IS areas with level 2 border RBridges. That also me= ans level 1 RBridges conforms to RFC 6325 remain unchanged. So RFC 6325 sho= uld not appear in the "Updates" metadata? [[Sasha]] It seems that we understand the meaning of the RFC metadata diffe= rently. From my POV if you remove/relax a restriction imposed by an alread= y published Standards Track RFC, this means that you update it, and the met= adata should reflect that. E.g., you can take a look at RFC 4379 that is ma= rked as updating RFC 1122 because it allows transmission of IP packets with= the Destination IP address in the 127/8 subnet - something that RFC 1122 = explicitly prohibits. Again, it would be interesting to hear what the people on the RTG-DIR list = (especially ones that serve now - or have served in the past - as ADs and/o= r WG Chairs) think on that. [Mingui] OK. Thanks for the informational example. I am afraid the relation= ship between the draft and RFC 6325 is slightly different. Since specifica= tions of RFC 6325 would still hold after the draft is published. [[Sasha]] Were it otherwise, I would ask why the Single Nickname draft is n= ot marked as obsoleting RFC 6325. Best regards, Mingui > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Thursday, May 19, 2016 6:59 PM > To: Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com) > Cc: Susan Hares (shares@ndzh.com); jon.hudson@gma= il.com; Zhangxian > (Xian); draft-ietf-trill-multilevel-single-nickname@ietf.org; > 'rtg-dir@ietf.org'; trill@ietf.org > Subject: RTG-DIR QA review for > draft-ietf-trill-multilevel-single-nickname > > Hi all, > I have been appointed as the QA reviewer for > draft-ietf-trill-multilevel-single-nickname rg/doc/draft-i etf-trill-multilevel-single-nickname/?include_text=3D1>. > Before going into the review proper, I would like to make a couple of > introductory statements. > > > 1. I am NOT a TRILL expert and actually never before has been invol= ved > with TRILL. I have been told that this is OK and the ADs are > interested into getting reviews from non-experts. Well, in my case this i= s what they will get. > > 2. The time frame for providing the review was quite demanding (at = least > for me). This probably affected the review quality and it effectively > prevented me from discussing the review with the draft authors > privately - I owe them a sincere apology for that. > > 3. The RtgDirDocQa - Rtg Area > Wiki > states that the QA review is usually performed when a draft is going > to be adopted as a WG document. While it mentions, that a WG document > may be also subjected to such a review at the discretion of the WG > Chairs, the initial guidelines for the QA reviewer in the Wiki mention > only reviewing the draft for a QA adoption. As a consequence, I had to > create my own list of questions that will try to answer based on what I h= ave found in the Wiki. Here is this list: > > a. Is the draft easily readable and understandable? > > b. Does the draft represent an attempt to solve a real problem? > > c. Are there some serious technical gaps that the authors should tr= y to > fill? > > d. Are there any potential IETF process issues with the draft in its= present > form? > Please note that the question about "a good start for a WG draft" > which appears in the Wiki does not appear on my list (since the draft is = already a WG document). > At the same time I have included the question about solving a real > problem (which appeared in the previous version of the Wiki page). The > current version only asks if the draft "makes sense" which, from my POV, = is something else. > > > My answers to these questions follow. > > Is the draft easily readable and understandable? > Of course, "easily readable and understandable" is in the eye of the beho= lder. > But as a non-expert can say that it was quite difficult for me to > understand what this draft is really about. > Eventually, I have succeeded to build the following scheme that helped > me to understand what I am dealing with: > > * The TRILL base > spec: > > o Explicitly restricts TRILL to a single Level 1 IS-IS > > o Explicitly states that the nicknames of RBridges in the Trill packet = header > remain unchanged when the packet traverses the TRILL domain from > ingress (where the TRILL header is pushed on the original Ethernet > frame) to egress (where this header is popped) > > * An Informational Multi-Level > TRILL evel/?include _text=3D1> WG draft claims that this restriction > negatively affects TRILL scalability: > > o It mentions several scalability issues > > o However, it > > ? Neither mentions any specific scale parameters where these issues > become real > > ? Nor provides any explanations about the reasons that make > single-level IS-IS used by TRILL less scalable that single-level IS-IS > when it is used for distributing IP reachability > > o It claims that some of these issues may be addressed by allowing usag= e of > multi-level IS-IS for TRILL > > o It provides two specific proposals for making multi-level TRILL work: > > o One of these proposals is called "unique nicknames". This proposal: > > ? Does not require any changes in the TRILL data plane > > ? Requires introducing some structure in the nicknames of RBridges in > order to guarantee that these names are unique within the TRILL-based > campus > > o The other proposal is called "aggregate nicknames". This proposal: > > ? Allows RBridges in different L1 areas of the campus to share > nicknames > > ? Requires a change in the TRILL data plane: the nicknames in the > TRILL header of a packet will be modified by the L12 RBridges > > ? Allows two possible flavors (bot mentioned in the draft): > > * The flavor that uses L1 area nicknames > > * The flavor that uses the nicknames of all L12 RBridges connecte= d to a > given L1 area as its name > > * The Standards Track Single Nickname draft (one that I have been > asked to review) provides details on the second of the above-mentioned > flavors of the "Aggregate Nicknames" approach: > > o It also allows sharing the same nickname between RBridges in differen= t L1 > areas > > o It also requires the same change in the TRILL data plane > > o It eliminates the need for allocating nicknames to L1 areas. Instead,= each > such area is identified by the set of nicknames of all L12 RBridges > that connect to it. > It took me quite some time to build this scheme, and the text in the > draft was not very helpful in this. > The following points contributed to "negative readability" from my POV: > > * The draft positions itself as an alternative to the Aggregate > Nicknames approach while, from my POV, it is just provides additional > details on one of the possible flavors of this approach > > * The draft is intended for the Standards Track, but it does not = say that > it updates the base TRILL spec (neither in the text nor in metadata) --_000_HE1PR0301MB2266387BBFD233A622BF5A319D400HE1PR0301MB2266_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mingui,<= /span>

I will try to summariz= e our agreements and disagreements.

1.&= nbsp;      The scale of TRILL deployments:

a. &nbs= p;     I have not seen any specific numbers or references to any specif= ic topologies that could really make single-level TRILL not scalable enough= – neither in the TRILL drafts I’ve read nor in our discussions so far

b. &nbs= p;    Regarding your  reference to multiple interconnected TRILL-= based campuses in your last email: I do not think that TRILL is an alternat= ive to or competes with Internet

c. &nbs= p;     I have also noticed that, once upon a time (4 years ago)  t= here was an attempt to use BGP with TRILL. I wonder why this draft has been= left to expire because, from my POV, BGP is greatly preferable to multi-level IS-IS when it comes to scalability is= sues

2.&= nbsp;      Nickname Re-write vs Nickname Swapping: Looks like a clear case of misunderstanding between us= , probably due to the fact that I am not a TRILL expert:

a. &nbs= p;     I have used the term “swapping” in the same way it i= s used in MPLS (e.g., see RFC 3031 discussing label swapping). In other wor= ds, from my POV “nickname swapping” and “nickname re-write” were synonyms

b. &nbs= p;    It seems that some yet to be standardized extension of TRILL con= siders some dedicated nickname swapping mechanism that carries new nickname= s in some extension of the TRILL header.  In this parlance “nickname re-write” and “nickname= swapping” are different

c. &nbs= p;     I think that we now safely consider this discussion issue as clo= sed

3.&= nbsp;      Metadata:

a. &nbs= p;     I fully agree that we should hear from other RTG-DIR members on = what exactly (if at all) should be specified to clarify the relationship be= tween the Single Nickname draft and RFC 6325

b. &nbs= p;    I can only add that, AFAIK, the Multi-Level TRILL draft, being p= ositioned as an Informational, can neither update nor obsolete RFC 6325 (wh= ich is Standards Track). So there is no issue with its metadata being empty.

 

There is one issue in = my original review that we have not discussed at all – namely, the be= havior implied by the Single Nickname draft when a new border RBridge is ad= ded to a certain area.

 

Regards,

Sasha

 

Office: +972-39266= 302

Cell:   = ;   +972-549266302

Email:   Ale= xander.Vainshtein@ecitele.com

 

From: Mingui Zhang [mailto:zhangmingui@huawei= .com]
Sent: Wednesday, May 25, 2016 6:07 AM
To: Alexander Vainshtein
Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf= -trill-multilevel-single-nickname@ietf.org; Susan Hares; jon.hudson@gmail.c= om; Jonathan Hardwick
Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multil= evel-single-nickname

 

Hi Sasha,

 

Thanks for the comments.

 

[[Sasha]] Do you (or the authors of the multi-level TRILL dra= ft) consider deployment scenarios with more than 64K RBridges in a single T= RILL campus? Is this a realistic scenario?

[Mingui] We can also doubt whether a domain with more= that 2^32 IP routers is a realistic scenario. The fact is that a single ca= mpus is usually not allowed to use up the entire 64K namespace. Please consider the scenario that lots of TRILL = campuses are to be interconnected.

 

[[Sasha]] In other words, your draft explicitly states that the a= rea border RBridges modify the nicknames in the TRILL header of a packet th= at crosses the Level 2 domain. How is this different from swapping (save from the name of the operation)?

[Mingui] As I said, there is no “swap nickna= me field” conception in the draft.  Yes, the border RBridge = needs to modify the nickname but it does not have to modify it through the “swapping” operation. Instead, the borde= r RBridge “replaces” the nickname in the TRILL data packets wit= h its own nickname (rather than a nickname in the “swap nickname fiel= d” provided by the originating RBridge). Why authors prefer the replacing operation than the swapping operation? Because the swapping oper= ation requires a new TRILL header (two additional 16-bit fields) which has = not been standardized yet.

 

As for the “Updates” metadata, let’= s see if people on the RTG-DIR list would give directions.

 

Best regards,

Mingui

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ec= itele.com]
Sent: Tuesday, May 24, 2016 6:45 PM
To: Mingui Zhang
Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares; jon.hudson@gmail.com; Jonathan Hardwick
Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multil= evel-single-nickname=

 

Mingui hi!

Lots of thanks for a prompt response.

 

A few short comments inlin= e below.

 

Regards,<= /span>

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ec= itele.com<= /span>

 

From:<= /span> Mingui Zhang [mailto:zhangmingui@huawei.com]
Sent: Tuesday, May 24, 2016 11:23 AM
To: Alexander Vainshtein
Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares; jon.hudson@gmail.com; Jonathan Hardwick
Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multil= evel-single-nickname

 

Hi Sasha,

 

Thanks for your comments. Please see responses inl= ine below.

 

Thanks,

Mingui

 

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ec= itele.com]
Sent: Monday, May 23, 2016 6:13 PM
To: Mingui Zhang
Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares (shares@ndzh.com); jon.hudson@gmail.com; Jonathan = Hardwick (Jonathan.Hard= wick@metaswitch.com)
Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multil= evel-single-nickname=

 

Mingui= hi!

Lots o= f thanks for a prompt response to some of the issues I've raised in the rev= iew.

 =

Please= see some comments to you responses inline below.=

 =

Regard= s,

Sasha<= o:p>

 =

Office= : +972-39266302

Cell:&= nbsp;     +972-549266302

Email:=    Alexander.Vainshtein@ecitele.com

 =

-----O= riginal Message-----
From: rtg-dir [mailto:rtg-dir-b= ounces@ietf.org] On Behalf Of Mingui Zhang
Sent: Monday, May 23, 2016 12:31 PM
To: Alexander Vainshtein; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)
Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; dra= ft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares (shares@ndzh.com); jon.hudson@gmail.com
Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-si= ngle-nickname

 =

Hi Ale= xander,

 =

Thanks= for the review!

 =

The mu= ltilevel conception itself is abstract and not easily understandable.<= /o:p>

[[Sasha]] Do you refer to the multi-level IS-IS in general or= multi-level TRILL specifically? I am asking because I believe am reasonabl= y well aware of the multi-level architecture of IS-IS as used for IP routing. It is somewhat different from that of OSP= F, but I would not call it “abstract and not easily understandable= 221;.  And there are quite a few excellent introductions to the subjec= t (again in the context of IP routing). However, I am definitely not a TRILL expert, and have stated that in the review. <= /p>

 

[Mingui] Yes, multi-level arch of IS-IS has alr= eady been well understood. However, the extending TRILL to multi-levels bri= ngs new challenges. As stated in the informational draft, one issue is on processing the TRILL switch nicknames= and the other issue is on handling multi-destination packet distribution t= rees. In order not to make the specifications “abstract”, the d= raft carefully designed two walking-through examples in Section 3. If the examples were understood, it would be non-ab= stract as well. ;-)

=  =

Howeve= r, it was really interesting in designing such a solution. Appreciate the r= eview and the time on relevant documents to figure out the whole scheme.

 =

> ?=   Nor provides any explanations about the reasons that make

> s= ingle-level IS-IS used by TRILL less scalable that single-level IS-IS

> w= hen it is used for distributing IP reachability

 =

The re= ason comes from the fact that the length of a nickname is different from an= IP address.

[[Sasha]] I must admit that I do not understand the connectio= n. By this logic, IS-IS for CLNS and IPv6 should be much more scalable than= IS-IS for IPv4, but I have never seen such claims before. Could you please elaborate? Could somebody on the RTG-= DIR list to comment on that?

 

[Mingui] For a single-level IS-IS instance, the= length of the address determines the name space. In the informational draf= t, Section 1.1 TRILL Scalability Issues, the following statement is relevant

“  = ; 5. the limit of the number of TRILL switches, due to the 16-bit nickname = space,”

[[Sasha]] Do you (or the authors of the multi-level TRILL dra= ft) consider deployment scenarios with more than 64K RBridges in a single T= RILL campus? Is this a realistic scenario?

 

 

I thin= k this could be addressed in the updated version of the draft: https://datatracker.i= etf.org/doc/draft-ietf-trill-rbridge-multilevel/?include_text=3D1.

 =

> *=          The draft positions itself= as an alternative to the Aggregate

> N= icknames approach while, from my POV, it is just provides additional

> d= etails on one of the possible flavors of this approach

 =

The WG= used to discuss several ways to address the "Aggregate Nickname"= approach.

[[Sasha]] I do not follow the TRILL WG mailing list, so I am = not aware of any discussions that have been hold there. I am only speaking = about what I could find in the two drafts mentioned in my review.

 

[Mingui] Actually, the informational draft had = included the information of those alternatives as well. Please see “S= ection 2.2.2.2 Swap Nickname Field Aggregated Nicknames” and read the words about “pseudonode” of Sect= ion 2.5. <= /span>

 

One wa= y was to use pseudonode nickname to denote an L1 area. Another way was to l= et border RBridges swap L1 and L2 nicknames.

[[Sasha]] I was under impression that the Aggregate Nicknames= approach always implies swapping of ingress and egress nicknames – a= t least this is what the Multi-Level Trill draft states, and the Single Nickname draft follows suit.

 

[Mingui] Oh, that’s not true. The “= Single Nickname” draft is definitely different from “Swapping N= ickname” approach. In the “Single Nickname” draft, there = is no “ingress swap nickname field” or “egress swap nicknam= e field”.<= /o:p>

[[Sasha]] Quoting from Section 3.1 of the Dingle Nickname dra= ft (and apologies for a long quotation; the relevant places are highlighted= ):

    -  S transmits an Et= hernet frame with source MAC =3D S and destination

      MAC =3D D.=

 

   -  RB27 [[Sasha – the ingress RBridge]] encapsulates with a TRILL header with ingress RBridge =3D 27,

      and egress RBridge = =3D 3 producing a TRILL Data packet.

 

   -  RB2 and RB20 have announced in = the Level 1 IS-IS instance in area

      {2,20}, that they are= attached to all those area nicknames,

      including {3,30}. The= refore, IS-IS routes the packet to RB2 (or

      RB20, if RB20 on the = least-cost route from RB27 to RB3).

 

   -  RB2, when transi= tioning the packet from Level 1 to Level 2,

   = ;   replaces the ingress TRILL switch nickname with its own nickn= ame,

  &nbs= p;   so replaces 27 with 2.

…

 

   -  The packet is forwarded through= Level 2, to RB3, which has

      advertised, in Level = 2, its L2 nickname as 3.

 

   -  RB3, when forwarding int= o area {3,30}, replaces the egress

   = ;   nickname in the TRILL header with RB44's nickname (44). (The

   = ;   ingress nickname MAY be replaced with an area nickname select= ed

   = ;   from {2,20}. See Section 4 for the detail of the selection method.

      Here, suppose nicknam= e 2 is selected.) So, within the destination

      area, the ingress nic= kname will be 2 and the egress nickname will

      be 44.

In other words, your draft explicitly states= that the area border RBridges modify the nicknames in the TRILL header of = a packet that crosses the Level 2 domain. How is this different from swapping (save from the name of the operation)?=

 

I also do not understand how using L1 area names (which is a = control plane functionality) could replace the swapping of nicknames (which= is a pure data plane function).

 

[Mingui] There is no “swapping” act= ion in the “Single Nickname” draft. To explain with an example,= if the TRILL data packet is transitioned from level 1 to level 2, the ingress nickname will be rewritten to the L1 area nickname. Please = also refer to bullet 4 of Section 3.1 in the “Single Nickname” = draft.

[[Sasha]] Please see above.

 

Howeve= r, these possible alternatives were never detailed as the one being reviewe= d, after the WG weighted their issues and complexity.

[[Sasha]] It is all fine, but, from my POV, it does not addre= ss the issue I’ve raised, namely that the Single Nickname draft incorrectly positions itself as an alternative approach to that of Ag= gregate Nicknames in the Multi-Level TRILL draft, and that such incorrect positioning negatively affects abilit= y of a non-expert=

 

[Mingui] I think the above explanation about th= e difference between “Single Nickname” and “Swapping Nick= name” will clear the confusion.

[[Sasha]] Sorry, but no, it doesn’t.

 =

> *=          The draft is intended for = the Standards Track, but it does not say that

> i= t updates the base TRILL spec (neither in the text nor in metadata)

 =

RFC 63= 25 is the base TRILL spec and it restricts itself to level 1 IS-IS while th= e draft being reviewed is talking about how to enable inter-communication b= etween level 1 IS-IS areas with level 2 border RBridges. That also means level 1 RBridges conforms to RFC 6325 r= emain unchanged. So RFC 6325 should not appear in the "Updates" m= etadata?

[[Sasha]] It seems that we understand the meaning of the RFC = metadata differently. From my POV if  you remove/relax a restriction i= mposed by an already published Standards Track RFC, this means that you update it, and the metadata should reflect = that. E.g., you can take a look at RFC 4379 that is marked as updating RFC = 1122 because it allows transmission of IP packets with the Destination IP a= ddress  in the 127/8 subnet – something that RFC 1122 explicitly prohibits.

Again, it would be interesting to hear what the people on the= RTG-DIR list (especially ones that serve now – or have served in the= past – as ADs and/or WG Chairs) think on that.

 =

[Mingui] OK. Thanks for the informational examp= le. I am afraid the relationship between the draft and  RFC 6325 is sl= ightly different. Since specifications of RFC 6325 would still hold after the draft is published.

[[Sasha]] Were it otherwise, I would ask why the Single Nickn= ame draft is not marked as obsoleting RFC 6325.

 

Best r= egards,

Mingui=

 =

> -= ----Original Message-----

> F= rom: Alexander Vainshtein [mailto:Alexander.= Vainshtein@ecitele.com]

> S= ent: Thursday, May 19, 2016 6:59 PM

> T= o: Jonathan Hardwick (<= span style=3D"color:windowtext;text-decoration:none">Jonathan.Hardwick@meta= switch.com)

> C= c: Susan Hares (shares@ndzh.com); jon.hudson@gmail.com; Zhangxian

> (= Xian); draft-ietf-trill-mult= ilevel-single-nickname@ietf.org;

> '= rtg-dir@ietf.org'; trill@ietf.org

> S= ubject: RTG-DIR QA review for

> d= raft-ietf-trill-multilevel-single-nickname

> <= o:p>

> H= i all,

> I= have been appointed as the QA reviewer for

> d= raft-ietf-trill-multilevel-single-nickname<https://datatracker.ietf.o

> r= g/doc/draft-i etf-trill-multilevel-single-nickname/?include_text=3D1>.

> B= efore going into the review proper, I would like to make a couple of

> i= ntroductory statements.

> <= o:p>

> <= o:p>

> 1= .       I am NOT a TRILL expert and actually = never before has been involved

> w= ith TRILL. I have been told that this is OK and the ADs are

> i= nterested into getting reviews from non-experts. Well, in my case this is w= hat they will get.

> <= o:p>

> 2= .       The time frame for providing the revi= ew was quite demanding (at least

> f= or me). This probably affected the review quality and it effectively

> p= revented me from discussing the review with the draft authors

> p= rivately - I owe them a sincere apology for that.

> <= o:p>

> 3= .       The RtgDirDocQa - Rtg Area=

> W= iki<https://trac.tools= .ietf.org/area/rtg/trac/wiki/RtgDirDocQa>

> s= tates that the QA review is usually performed when a draft is going

> t= o be adopted as a WG document. While it mentions, that a WG document

> m= ay be also subjected to such a review at the discretion of the WG

> C= hairs, the initial guidelines for the QA reviewer in the Wiki mention

> o= nly reviewing the draft for a QA adoption. As a consequence, I had to

> c= reate my own list of questions that will try to answer based on what I have= found in the Wiki. Here is this list:

> <= o:p>

> a= .       Is the draft easily readable and unde= rstandable?

> <= o:p>

> b= .      Does the draft represent an attempt to solv= e a real problem?

> <= o:p>

> c= .       Are there some serious technical gaps= that the authors should try to

> f= ill?

> <= o:p>

> d= .      Are there any potential IETF process issues= with the draft in its present

> f= orm?

> P= lease note that the question about "a good start for a WG draft"

> w= hich appears in the Wiki does not appear on my list (since the draft is alr= eady a WG document).

> A= t the same time I have included the question about solving a real

> p= roblem (which appeared in the previous version of the Wiki page). The

> c= urrent version only asks if the draft "makes sense" which, from m= y POV, is something else.

> <= o:p>

> <= o:p>

> M= y answers to these questions follow.

> <= o:p>

> I= s the draft easily readable and understandable?

> O= f course, "easily readable and understandable" is in the eye of t= he beholder.

> B= ut as a non-expert can say that it was quite difficult for me to

> u= nderstand what this draft is really about.

> E= ventually, I have succeeded to build the following scheme that helped

> m= e to understand what I am dealing with:

> <= o:p>

> *=          The TRILL base<= /span>

> s= pec<https://datatracke= r.ietf.org/doc/rfc6325/?include_text=3D1>:<= /p>

> <= o:p>

> o=    Explicitly restricts TRILL to a single Level 1 IS-IS

> <= o:p>

> o=    Explicitly states that the nicknames of RBridges in the Trill = packet header

> r= emain unchanged when the packet traverses the TRILL domain from

> i= ngress (where the TRILL header is pushed on the original Ethernet

> f= rame) to egress (where this header is popped)

> <= o:p>

> *=          An Informational Multi-Lev= el

> T= RILL<https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multil

> e= vel/?include _text=3D1> WG draft claims that this restriction

> n= egatively affects TRILL scalability:

> <= o:p>

> o=    It mentions several scalability issues

> <= o:p>

> o=    However, it

> <= o:p>

> ?=   Neither mentions any specific scale parameters where these issues

> b= ecome real

> <= o:p>

> ?=   Nor provides any explanations about the reasons that make

> s= ingle-level IS-IS used by TRILL less scalable that single-level IS-IS

> w= hen it is used for distributing IP reachability

> <= o:p>

> o=    It claims that some of these issues may be addressed by allowi= ng usage of

> m= ulti-level IS-IS for TRILL

> <= o:p>

> o=    It provides two specific proposals for making multi-level TRIL= L work:

> <= o:p>

> o=    One of these proposals is called "unique nicknames".= This proposal:

> <= o:p>

> ?=    Does not require any changes in the TRILL data plane

> <= o:p>

> ?=   Requires introducing some structure in the nicknames of RBridges in

> o= rder to guarantee that these names are unique within the TRILL-based

> c= ampus

> <= o:p>

> o=    The other proposal is called "aggregate nicknames". = This proposal:

> <= o:p>

> ?=   Allows RBridges in different L1 areas of the campus to share

> n= icknames

> <= o:p>

> ?=   Requires a change in the TRILL data plane: the nicknames in the

> T= RILL header of a packet will be modified by the L12 RBridges

> <= o:p>

> ?=   Allows two possible flavors (bot mentioned in the draft):=

> <= o:p>

> *=          The flavor that uses L1 ar= ea nicknames

> <= o:p>

> *=          The flavor that uses the n= icknames of all L12 RBridges connected to a

> g= iven L1 area as its name

> <= o:p>

> *=          The Standards Track Single= Nickname draft (one that I have been

> a= sked to review) provides details on the second of the above-mentioned

> f= lavors of the "Aggregate Nicknames" approach:

> <= o:p>

> o=    It also allows sharing the same nickname between RBridges in d= ifferent L1

> a= reas

> <= o:p>

> o=    It also requires the same change in the TRILL data plane<= /o:p>

> <= o:p>

> o=    It eliminates the need for allocating nicknames to L1 areas. I= nstead, each

> s= uch area is identified by the set of nicknames of all L12 RBridges

> t= hat connect to it.

> I= t took me quite some time to build this scheme, and the text in the

> d= raft was not very helpful in this.

> T= he following points contributed to "negative readability" from my= POV:

> <= o:p>

> *=          The draft positions itself= as an alternative to the Aggregate

> N= icknames approach while, from my POV, it is just provides additional

> d= etails on one of the possible flavors of this approach

> <= o:p>

> *=          The draft is intended for = the Standards Track, but it does not say that

> i= t updates the base TRILL spec (neither in the text nor in metadata)

 =

--_000_HE1PR0301MB2266387BBFD233A622BF5A319D400HE1PR0301MB2266_-- From nobody Wed May 25 07:44:55 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81DD12D176; Wed, 25 May 2016 07:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] 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 iaFYzKJGNP7h; Wed, 25 May 2016 07:44:52 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 4129C12D768; Wed, 25 May 2016 07:44:51 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.182.128; From: "Susan Hares" To: Date: Wed, 25 May 2016 10:44:45 -0400 Message-ID: <01b401d1b693$fb411810$f1c34830$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B5_01D1B672.74308980" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdG2keUYwqsP4AJKSjCZY/xFiMIDqg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: rtg-dir@ietf.org, zhang.xian@huawei.com, damascene.joachimpillai@verizon.com, hadi@mojatatu.com, forces@ietf.org, Jonathan.Hardwick@metaswitch.com, draft-ietf-forces-interfelfb@tools.ietf.org, 'Jon Hudson' Subject: [RTG-DIR] RTG-DIR review of ForCES Inter-FE LFB (draft-ietf-forces-interfelfb-04.txt) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 14:44:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01B5_01D1B672.74308980 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello:=20 I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or 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 = = =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. Document: draft-ietf-forces-interfelfb-04.txt Reviewer: Susan Hares Date: 5/25/2016 IETF End Date: unknown=20 Intended Status: Standards track =20 Summary: This document is basically ready for publication, but has nits = that should be considered before publication.=20 =20 Comments:=20 =C2=B7 Document contains good technical content for extending = the Forces work into an Inter-FE LFB. The document is easily read, but = a few nits would improve its readability. =C2=B7 My hand check of the inter-FE LFB XML model indicated all = XML is fine. If an automated check of the XML with the Forces LFBs, it = would be useful to run this check. =20 =C2=B7 The improvement in the congestion consideration section = (5.1.3) between -03 and -04 was necessary. =20 =20 Major issues: none=20 =20 Nits:=20 Page 9 figure 5. =E2=80=93 the between figure lines is not aligned.=20 This line begins with the =E2=80=9CEthernet Frame with:=E2=80=9D=20 =20 Page 12 =E2=80=93=20 Old /(XXX: note to editor/ New /(XXX: note to RFC editor/ =20 Page 15=20 Old /original payload i.e. skips the IFE header information./ New /original payload (i.e. skips the IFE header information)/ =20 Page 21=20 =20 Old /This memo includes one IANA requests within the registry = https://www.iana.org/assignments/forces/ =20 New /This memo includes one IANA request within the registry = https://www.iana.org/assignments/forces. / =20 p. 22=20 Old /As such, it has no impact on their security considerations./ New/ As such, it has no impact on these documents security = considerations./ =20 Sue Hares=20 =20 =20 ------=_NextPart_000_01B5_01D1B672.74308980 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hello: =

I have been selected as the = Routing Directorate reviewer for this draft. The Routing Directorate = seeks to review all routing or 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 =E2=80=8Bhttp://trac.tools.ietf.org/area/= rtg/trac/wiki/RtgDir

Although these comments are = primarily for the use of the Routing ADs, it would be helpful if you = could consider them along with any other IETF Last Call comments that = you receive, and strive to resolve them through discussion or by = updating the draft.

Document: = draft-ietf-forces-interfelfb-04.txt

Reviewer: Susan Hares

Date: 5/25/2016

IETF End Date: unknown

Intended Status: Standards track

 

Summary: = This document is basically ready for publication, but has nits that = should be considered before publication.

 

Comments: =

=C2=B7         = Document contains good technical content = for extending the Forces work into an Inter-FE LFB. =C2=A0=C2=A0The = document is easily read, but a few nits would improve its = readability.

=C2=B7         = My hand check of the inter-FE LFB XML = model indicated all XML is fine.=C2=A0 If an automated check of the XML = with the Forces LFBs, it would be useful to run this check.=C2=A0 =

=C2=B7         = The improvement in the congestion = consideration section (5.1.3) between -03 and -04 was necessary.=C2=A0 =

 

Major issues: none

 

Nits: =

Page 9=C2=A0 figure 5. =E2=80=93 the = between figure lines is not aligned.

This line begins with the =E2=80=9CEthernet Frame = with:=E2=80=9D

 

Page 12 = =E2=80=93

Old

/(XXX: note to editor/

New /(XXX: note to RFC editor/

 

Page 15 =

Old /original payload i.e. skips the = IFE header information./

New = /original payload (i.e. skips the IFE header = information)/

 

Page 21

 

Old

/This memo = includes one IANA requests within the registry https://www.iana.org/as= signments/forces/

 

New

/This memo = includes one IANA request within the registry = https://www.iana.org/assignments/forces. /

 

p. 22 =

Old /As such, it has no impact on = their security considerations./

New/ = As such, it has no impact on these documents security = considerations./

 

Sue Hares =

 

 

------=_NextPart_000_01B5_01D1B672.74308980-- From nobody Wed May 25 11:28:40 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88ABA12D8B5 for ; Wed, 25 May 2016 11:28:38 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=venaas-com.20150623.gappssmtp.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 DBKDXcnyEEvH for ; Wed, 25 May 2016 11:28:37 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::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 92C8712D8BC for ; Wed, 25 May 2016 11:28:36 -0700 (PDT) Received: by mail-lb0-x22f.google.com with SMTP id h1so17636523lbj.3 for ; Wed, 25 May 2016 11:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=BexRua6/hB1lqQ8n+B2/jDiMMld90fK0wII0QrZJORc=; b=IkJ35IcTnlMWFZjWqQJdQFDK1w19zsEuM7+PtjZJYbh0hseNjGYLwy4jXqEQcLJ6Zd lTuAIRNBQkxNxn5e6bG2DRhaZp6BLjeM7ErsVYEwtha3fSMzftd10TzftISp0QL87Muo UHR6wsyyxxHNcsdLcnVTkd1UN/AKJi2rMvQetRjWXktEtnw77zk3P+zT8gG79ZuPb4ig jB1Uc5lPPX5aB9XmSvi9rwL+JU2Le1+OIWwrkXl6QmXandZ6qvmcww+J04jDJcwn898u 3wiUcSiug77PXhVTJ7s6bdCYaoBGto27kskI1jDYTubVZSh0MEobamHwU7NNuAm0jRFU tyYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=BexRua6/hB1lqQ8n+B2/jDiMMld90fK0wII0QrZJORc=; b=d6yh2Y4Lt4tAIKNuYNQW1ehCc52maaya3F9qbcf30t1aYAG4tsdyYyTr/xY8/3wdEn TQ6bNwTAeJqrYuk7OaSN2lg5lUDIY86+av6QOLu93ZaDxr/whhvxwuxFwLQEZ2ywZg/u fo6TfpX24sWYVAgfj8OP/oX7jTZyVno07kA+ap3pnSl9I83d75rB1m9kEZcfTEOc1OK4 Iz5K0C8WlQBgqdZQd++bAk7cXh9/ObX2iWmr595jWSRW/oZxr8j9k903veYLzMKyD26E A1ol+z600yq5nlRRlm+sJ1QkEeFZEFhndOEnCkk2fsoTN+lQrGpkEs4Yyhitbea4LWhb UPHw== X-Gm-Message-State: ALyK8tIITShQsq+9f4H0c66q1dZqqUYVIMnwFI54k1C6qdom5k+My5FSNqo2xmOTMczsXrb1lGNq4CZI9DfVUw== MIME-Version: 1.0 X-Received: by 10.112.77.2 with SMTP id o2mr1621692lbw.83.1464200914766; Wed, 25 May 2016 11:28:34 -0700 (PDT) Received: by 10.25.27.70 with HTTP; Wed, 25 May 2016 11:28:34 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 May 2016 11:28:34 -0700 Message-ID: From: Stig Venaas To: Jonathan Hardwick , rtg-dir@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Zhangxian \(Xian\)" , Susan Hares , Jon Hudson Subject: Re: [RTG-DIR] Routing directorate QA review of draft-ietf-trill-rbridge-multilevel X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 18:28:38 -0000 Hi Sorry for being a bit late with this review. At least the document is well written and easy to understand. There are no significant issues. I am wondering about the security considerations though. Are there really no differences between the multi-level alternatives when it comes to security? I have two tiny editorial comments. Section 1.4 typo RBridge - Routing Bridge, an alterntive name for a TRILL switch ^^^^^^^^^ Also, several places it says "non-zero" which is correct, but there are some instances of "nonzero". Stig On Wed, May 4, 2016 at 11:52 PM, Jonathan Hardwick wrote: > Hi Stig > > > > Please would you do a routing directorate QA review of > draft-ietf-trill-rbridge-multilevel? > > https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/ > > > > Note that this is a =E2=80=9CQA review.=E2=80=9D The document is still be= ing worked on by > the TRILL working group. The goal of this review is to provide a differe= nt > perspective on the work and to improve its quality. Hence, your comments > will be provided primarily for the benefit of the TRILL chairs and the > document authors. > > > > Please could you provide your comments by May 20 and copy your comments t= o > the rtg-dir list? > > > > The following web page contains a briefing on the QA process, and guidanc= e > for the QA reviewer. > > https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa > > > > Please let me know whether you can do it, or not. > > > > Many thanks > > Jon > > > > > > > > From nobody Wed May 25 12:26:22 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D771112D0A9; Wed, 25 May 2016 12:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.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, USER_IN_WHITELIST=-100] 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 tHKkuWKCAf55; Wed, 25 May 2016 12:26:17 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::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 75D7F12D97D; Wed, 25 May 2016 12:26:15 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id x189so57563165ywe.3; Wed, 25 May 2016 12:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=peGDFoIMgxo+P2tyvvuay6QmYPD6VV34qJ7sCimdHPc=; b=cI1+xx5qEz+VLynFmv7VsIr5gXeMq9e7AxW7Kirx8iMfKQ1hYN0eipj0IbIbEdr3/f alZPY1J464ADr1MdN+aP2k1QAF8mFJD/YRdyI7AzmAVFdG1qaIgvIUAC5YzojEU1lO8q OcMX4F9eGBSPWkOuHmOdNj0KFiVF3nnLdHx08ZXKJ9WtkqU7m9XQVMSIziIKJgDf63fZ GJzRsK4Z1b/dlJ0bX6TpyDcZovj4uny9PANXpXXRTHu/rEqysWGkNWWcRYTd9x8KKZsY DSgusq2yWoO9mpYrdLOPAZb4VIZNJBPtDczuihGtUB0CVyBOcGTgn1t2TjRHkCPu3FXe U4dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=peGDFoIMgxo+P2tyvvuay6QmYPD6VV34qJ7sCimdHPc=; b=XAeCG0zr1ksocp2iGavQuTqo0BjobxwG742z+RzZpSWfbsLlC92PUQCI2RgN+TZ39I qn/kVSYays7RRtiSXdKXSQ3difrLwr8VxwTM03m1k2P6ESFj8pGHg+meWkDRSBPoHI/V YAD14/GCeb/OISXMlTJI/dVWcNka2WdMyOwCneUsx1JmDFSL5fFNS6WBbMw8Xb7+3g3+ UD4x8UiZTSOeeF3nqd5KwrqcHkoNySdEsqGKVoqrg7SA3l3bTmjpe60NnyndRwmmQT5E Q2oR7sQv/7reZ0akGiU6fmjy6ycXA5z1EiS4mGai/XmeleIOdPKXeSJYiMZCAPWEJQ8P C2+g== X-Gm-Message-State: ALyK8tLZRVrNjJJU2VX/Ml4nmqgAw6PbLkEZoZoqor44oqhGbezI68IUerJeg7Glhi/aN4zEesfH1aToPGaPKw== MIME-Version: 1.0 X-Received: by 10.13.195.132 with SMTP id f126mr3909912ywd.7.1464204374673; Wed, 25 May 2016 12:26:14 -0700 (PDT) Received: by 10.13.221.74 with HTTP; Wed, 25 May 2016 12:26:14 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 May 2016 15:26:14 -0400 Message-ID: From: Alia Atlas To: Stig Venaas , trill@ietf.org Content-Type: multipart/alternative; boundary=001a114e419ea1907a0533afa507 Archived-At: Cc: Jonathan Hardwick , "rtg-dir@ietf.org" , "Zhangxian \(Xian\)" , Susan Hares , Jon Hudson Subject: Re: [RTG-DIR] Routing directorate QA review of draft-ietf-trill-rbridge-multilevel X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 19:26:19 -0000 --001a114e419ea1907a0533afa507 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Stig, Thank you very much for your review. I'm also forwarding it to trill so that the WG can see it. Regards, Alia On Wed, May 25, 2016 at 2:28 PM, Stig Venaas wrote: > Hi > > Sorry for being a bit late with this review. At least the document is > well written and easy to understand. There are no significant issues. > > I am wondering about the security considerations though. Are there > really no differences between the multi-level alternatives when it > comes to security? > > I have two tiny editorial comments. > > Section 1.4 typo > RBridge - Routing Bridge, an alterntive name for a TRILL switch > ^^^^^^^^^ > > Also, several places it says "non-zero" which is correct, but there > are some instances of "nonzero". > > Stig > > > On Wed, May 4, 2016 at 11:52 PM, Jonathan Hardwick > wrote: > > Hi Stig > > > > > > > > Please would you do a routing directorate QA review of > > draft-ietf-trill-rbridge-multilevel? > > > > https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/ > > > > > > > > Note that this is a =E2=80=9CQA review.=E2=80=9D The document is still = being worked on by > > the TRILL working group. The goal of this review is to provide a > different > > perspective on the work and to improve its quality. Hence, your comment= s > > will be provided primarily for the benefit of the TRILL chairs and the > > document authors. > > > > > > > > Please could you provide your comments by May 20 and copy your comments > to > > the rtg-dir list? > > > > > > > > The following web page contains a briefing on the QA process, and > guidance > > for the QA reviewer. > > > > https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa > > > > > > > > Please let me know whether you can do it, or not. > > > > > > > > Many thanks > > > > Jon > > > > > > > > > > > > > > > > > > --001a114e419ea1907a0533afa507 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stig,

Thank you very much for your revi= ew.=C2=A0 I'm also forwarding it to trill so that the WG can see it.

Regards,
Alia

On Wed, May 25, 2016 at 2:28 PM, S= tig Venaas <stig@venaas.com> wrote:
Hi

Sorry for being a bit late with this review. At least the document is
well written and easy to understand. There are no significant issues.

I am wondering about the security considerations though. Are there
really no differences between the multi-level alternatives when it
comes to security?

I have two tiny editorial comments.

Section 1.4 typo
RBridge - Routing Bridge, an alterntive name for a TRILL switch
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0^^^^^^^^^

Also, several places it says "non-zero" which is correct, but the= re
are some instances of "nonzero".

Stig


On Wed, May 4, 2016 at 11:52 PM, Jonathan Hardwick
<Jonathan.Hardwick@m= etaswitch.com> wrote:
> Hi Stig
>
>
>
> Please would you do a routing directorate QA review of
> draft-ietf-trill-rbridge-multilevel?
>
> https://datatracker.ietf.o= rg/doc/draft-ietf-trill-rbridge-multilevel/
>
>
>
> Note that this is a =E2=80=9CQA review.=E2=80=9D The document is still= being worked on by
> the TRILL working group.=C2=A0 The goal of this review is to provide a= different
> perspective on the work and to improve its quality. Hence, your commen= ts
> will be provided primarily for the benefit of the TRILL chairs and the=
> document authors.
>
>
>
> Please could you provide your comments by May 20 and copy your comment= s to
> the rtg-dir list?
>
>
>
> The following web page contains a briefing on the QA process, and guid= ance
> for the QA reviewer.
>
> https://trac.tools.ietf.org/area/rtg/= trac/wiki/RtgDirDocQa
>
>
>
> Please let me know whether you can do it, or not.
>
>
>
> Many thanks
>
> Jon
>
>
>
>
>
>
>
>


--001a114e419ea1907a0533afa507-- From nobody Wed May 25 14:04:16 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FEC12D1ED; Wed, 25 May 2016 14:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 X3w_0YBw_9c2; Wed, 25 May 2016 14:04:11 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 68F0F12D1AC; Wed, 25 May 2016 14:04:11 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id p64so40919650ioi.2; Wed, 25 May 2016 14:04:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/1ociY1TECIlLZjCiuSEuic5/ple2Yd5yS7tn5dOYoI=; b=M9EVLdxSvm3O7Z2JsHFzDl38w2CHskjKJQ6a9boQ6P9uEs25X2dd/VC1JBrNpWZ5Lo wT8RB4C8tpcHJ85iy3V15/32KXpAoRLE2aoCo8TZvIy/3we+b96kugaCqhbImV6OLs2Q ZmFCq2Mmf3XuSvunNNbrOKcLbneqqwn7ri4y03L5pq/E5cJArMm9JuoQw6m92FwD1PxB oHoyMK1cF1OnY9KHLwKlbYhmkYpEI1hQ2dBHDkfTt4e9S1cCSTpnh8q4EQyrAblWUomT 5HGfc+WTFZ7S+ZeiuNiKYvZO1rcaIJNUSk/rpeVuyNLtxdkwA28Nm1hcd9YvWnFRWIny 82lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/1ociY1TECIlLZjCiuSEuic5/ple2Yd5yS7tn5dOYoI=; b=SKBukG3b724eGjMPXNg19U5wozNLJHjHM74mewcjoF//798TvHrQfSoHbH1BDDb9Km TK6BAemiek+SjdS9jSGsOXLrvVkFQXu3/1eYOnNa9bd3UMWttTwV1wq2oAUD/lgo8tOA vpfrzjg3TONgdSlu9x87riIijLNWDrpncYANx2ECoHEQVVhBTmrI1mOLY3G2lAl9U+gV suShX3+DpVcFxzkP8WlnNEG/3cHh8Il/qIL7d6xLPw3+Gltc7sCYcZYCvcfXeqPHqxa9 crIFee03td3CZElbcb67eCaMyYce+gNQ3P5VHHRZwzUJswxTDeoHQmEOrhdFUP1OrG83 Q7+A== X-Gm-Message-State: ALyK8tJySawuru3QkauSAx/MsAjg6K6NvSv04M9/vzMP209q3K77qVs80XarZpiDMHxFQMQqOpgIJJuBAaQw7Q== X-Received: by 10.157.47.248 with SMTP id b53mr4075852otd.102.1464210249337; Wed, 25 May 2016 14:04:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.249 with HTTP; Wed, 25 May 2016 14:03:54 -0700 (PDT) In-Reply-To: References: <4552F0907735844E9204A62BBDD325E787CB087E@NKGEML515-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E787CB7589@NKGEML515-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E787CB9054@NKGEML515-MBS.china.huawei.com> From: Donald Eastlake Date: Wed, 25 May 2016 17:03:54 -0400 Message-ID: To: Alexander Vainshtein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtg-dir@ietf.org" , "Zhangxian \(Xian\)" , Mingui Zhang , "trill@ietf.org" , Jonathan Hardwick , "draft-ietf-trill-multilevel-single-nickname@ietf.org" , Susan Hares , "jon.hudson@gmail.com" Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 21:04:13 -0000 Hi Alexander, Thanks from me also for your review. I'd like to chime in with a few thoughts: On Wed, May 25, 2016 at 8:23 AM, Alexander Vainshtein wrote: > > Hi Mingui, > I will try to summarize our agreements and disagreements. > > 1. The scale of TRILL deployments: > > a. I have not seen any specific numbers or references to any > specific topologies that could really make single-level TRILL not > scalable enough - neither in the TRILL drafts I've read nor in our > discussions so far I am puzzled as to why you think there would be some specific numeric hard boundary, other than number space or memory space exhaustion, beyond which you cannot scale. Can you point to a documentation of such a thing for IP use of IS-IS? Surely it depends on how much computer power the routers have, link stability, and numerous other factors. Just looking at convergence time and approximating it as the amount of computation required at a typical router in the TRILL campus, it is on the order of N*(log N) for computation of least cost routes where there are N routers in a single level campus while it is on the order of (sqrt N)*(log N) for multi-level, in both cases assuming optimized calculations. The largest TRILL campuses I am aware of are on the order of 3,000 routers. So one would expect that converting such a campus to multi-level TRILL would reduce convergence time by approximately a factor of 50. Furthermore, one would expect the rate of failures within each Level 1 area in the multi-level case to be approximately proportional to the number of links/routers and thus also fall by one and a half orders of magnitude. Do you claim these improvements would never be valuable? There are many other scaling factors such as the size of the link state database, etc. I believe the informational draft-ietf-trill-rbridge-multi-level gives a good summary. > b. Regarding your reference to multiple interconnected TRILL-based > campuses in your last email: I do not think that TRILL is an > alternative to or competes with Internet. I agree that TRILL does not compete with the Internet. :-) I believe this facet of the discussion was in connection with the possibility of TRILL nickname space exhaustion. Consider the following factors: 1) TRILL supports active-active connection of end stations at the TRILL edge. Using the techniques in RFC 7781 (Pseudo-Nickname for Active-Active Access) consumes TRILL nicknames for active-active edge groups. 2) Assuming, for the moment, you are using multi-level with unique nicknames, the nickname allocation mechanism will waste many nicknames due to hierarchical assignment, the same way power-of-two sized IP subnets waste IP addresses. 3) There is a desire to interconnect TRILL campuses that are under joint or cooperative management with limited control plane coupling so as to limit error propagation, etc. There are various possible ways to do this but most of them assume non-conflicting nicknames (or non-conflicting level 2 nicknames if the campuses are multi-level). I admit that even taking the largest existing TRILL campuses I know about and adding extensive active-active end station support at the edge and multi-level with unique nicknames that are hierarchically allocated, you would still probably not exhaust the TRILL nickname space. But you could be getting close to that hard limit. This seems like enough reason to me to be advancing a standard where Level 1 areas are aggregated (whether by a single nickname or set of border router nicknames) to, for all practical purposes, eliminate the nickname space restriction. > c. I have also noticed that, once upon a time (4 years ago) there > was an attempt to use BGP with TRILL. I wonder why this draft has > been left to expire because, from my POV, BGP is greatly preferable > to multi-level IS-IS when it comes to scalability issues. > > 2. Nickname Re-write vs Nickname Swapping: Looks like a clear case > of misunderstanding between us, probably due to the fact that I am > not a TRILL expert: > > a. I have used the term "swapping" in the same way it is used > in MPLS (e.g., see RFC 3031 discussing label swapping). In other > words, from my POV "nickname swapping" and "nickname re-write" were > synonyms. > > b. It seems that some yet to be standardized extension of TRILL > considers some dedicated nickname swapping mechanism that carries > new nicknames in some extension of the TRILL header. In this > parlance "nickname re-write" and "nickname swapping" are different. Right. The possibility was discussed some time ago of expanding the TRILL header so that, for TRILL Data packets going between different Level 1 Areas, there could be, in effect, two ingress nicknames (an ingress RBridge nickname and an ingress Area nickname) and two egress nicknames (an egress RBridge nickname and an egress Area nickname). Appropriate swapping would occur at border routers to avoid changes in fast path logic at all non-border routers. Within Level 2, the Area nicknames would be in the existing header slots that are routed on, etc. However, as far as I can recall, no specification was ever been produced for this "nickname swapping" although it is mentioned in the informational multi-level draft. > c. I think that we now safely consider this discussion issue > as closed. > > 3. Metadata: > > a. I fully agree that we should hear from other RTG-DIR > members on what exactly (if at all) should be specified to clarify > the relationship between the Single Nickname draft and RFC 6325 I would note that the IESG policy on "updates" has become very strict recently. It used to be a judgment call. Now, when a Standards Track RFC merely extends another such RFC so you could implement an instance of the earlier standard as specified without reference to or violating the subsequent specification, the IESG will generally prohibit you from claiming that the subsequent specification "updates" the first. (I do not particularly agree with this policy change myself.) > b. I can only add that, AFAIK, the Multi-Level TRILL draft, > being positioned as an Informational, can neither update nor > obsolete RFC 6325 (which is Standards Track). So there is no issue > with its metadata being empty. > > There is one issue in my original review that we have not discussed > at all - namely, the behavior implied by the Single Nickname draft > when a new border RBridge is added to a certain area. I agree that what needs to be done when border RBridges are added/deleted needs to be clear in the draft. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > Sent: Wednesday, May 25, 2016 6:07 AM > To: Alexander Vainshtein > Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-tril= l-multilevel-single-nickname@ietf.org; Susan Hares; jon.hudson@gmail.com; J= onathan Hardwick > Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-= single-nickname > > Hi Sasha, > > Thanks for the comments. > > > [[Sasha]] Do you (or the authors of the multi-level TRILL draft) consider= deployment scenarios with more than 64K RBridges in a single TRILL campus?= Is this a realistic scenario? > [Mingui] We can also doubt whether a domain with more that 2^32 IP router= s is a realistic scenario. The fact is that a single campus is usually not = allowed to use up the entire 64K namespace. Please consider the scenario th= at lots of TRILL campuses are to be interconnected. > > > [[Sasha]] In other words, your draft explicitly states that the area bord= er RBridges modify the nicknames in the TRILL header of a packet that cross= es the Level 2 domain. How is this different from swapping (save from the n= ame of the operation)? > [Mingui] As I said, there is no "swap nickname field" conception in the d= raft. Yes, the border RBridge needs to modify the nickname but it does not= have to modify it through the "swapping" operation. Instead, the border RB= ridge "replaces" the nickname in the TRILL data packets with its own nickna= me (rather than a nickname in the "swap nickname field" provided by the ori= ginating RBridge). Why authors prefer the replacing operation than the swap= ping operation? Because the swapping operation requires a new TRILL header = (two additional 16-bit fields) which has not been standardized yet. > > As for the "Updates" metadata, let's see if people on the RTG-DIR list wo= uld give directions. > > Best regards, > Mingui > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Tuesday, May 24, 2016 6:45 PM > To: Mingui Zhang > Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares; jon.hudson@gma= il.com; Jonathan Hardwick > Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-= single-nickname > > Mingui hi! > Lots of thanks for a prompt response. > > A few short comments inline below. > > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > Sent: Tuesday, May 24, 2016 11:23 AM > To: Alexander Vainshtein > Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares; jon.hudson@gma= il.com; Jonathan Hardwick > Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-= single-nickname > > Hi Sasha, > > Thanks for your comments. Please see responses inline below. > > Thanks, > Mingui > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Monday, May 23, 2016 6:13 PM > To: Mingui Zhang > Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares (shares@ndzh.co= m); jon.hudson@gmail.com; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com) > Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-= single-nickname > > > Mingui hi! > > Lots of thanks for a prompt response to some of the issues I've raised in= the review. > > > > Please see some comments to you responses inline below. > > > > Regards, > > Sasha > > > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > > -----Original Message----- > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Mingui Zhang > Sent: Monday, May 23, 2016 12:31 PM > To: Alexander Vainshtein; Jonathan Hardwick (Jonathan.Hardwick@metaswitch= .com) > Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares (shares@ndzh.co= m); jon.hudson@gmail.com > Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-= single-nickname > > > > Hi Alexander, > > > > Thanks for the review! > > > > The multilevel conception itself is abstract and not easily understandabl= e. > > [[Sasha]] Do you refer to the multi-level IS-IS in general or multi-level= TRILL specifically? I am asking because I believe am reasonably well aware= of the multi-level architecture of IS-IS as used for IP routing. It is som= ewhat different from that of OSPF, but I would not call it "abstract and no= t easily understandable". And there are quite a few excellent introduction= s to the subject (again in the context of IP routing). However, I am defini= tely not a TRILL expert, and have stated that in the review. > > > > [Mingui] Yes, multi-level arch of IS-IS has already been well understood.= However, the extending TRILL to multi-levels brings new challenges. As sta= ted in the informational draft, one issue is on processing the TRILL switch= nicknames and the other issue is on handling multi-destination packet dist= ribution trees. In order not to make the specifications "abstract", the dra= ft carefully designed two walking-through examples in Section 3. If the exa= mples were understood, it would be non-abstract as well. ;-) > > > > However, it was really interesting in designing such a solution. Apprecia= te the review and the time on relevant documents to figure out the whole sc= heme. > > > > > ? Nor provides any explanations about the reasons that make > > > single-level IS-IS used by TRILL less scalable that single-level IS-IS > > > when it is used for distributing IP reachability > > > > The reason comes from the fact that the length of a nickname is different= from an IP address. > > [[Sasha]] I must admit that I do not understand the connection. By this l= ogic, IS-IS for CLNS and IPv6 should be much more scalable than IS-IS for I= Pv4, but I have never seen such claims before. Could you please elaborate? = Could somebody on the RTG-DIR list to comment on that? > > > > [Mingui] For a single-level IS-IS instance, the length of the address det= ermines the name space. In the informational draft, Section 1.1 TRILL Scala= bility Issues, the following statement is relevant > > " 5. the limit of the number of TRILL switches, due to the 16-bit nickn= ame space," > > [[Sasha]] Do you (or the authors of the multi-level TRILL draft) consider= deployment scenarios with more than 64K RBridges in a single TRILL campus?= Is this a realistic scenario? > > > > > > I think this could be addressed in the updated version of the draft: http= s://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/?include_t= ext=3D1. > > > > > * The draft positions itself as an alternative to the Aggregate > > > Nicknames approach while, from my POV, it is just provides additional > > > details on one of the possible flavors of this approach > > > > The WG used to discuss several ways to address the "Aggregate Nickname" a= pproach. > > [[Sasha]] I do not follow the TRILL WG mailing list, so I am not aware of= any discussions that have been hold there. I am only speaking about what I= could find in the two drafts mentioned in my review. > > > > [Mingui] Actually, the informational draft had included the information o= f those alternatives as well. Please see "Section 2.2.2.2 Swap Nickname Fie= ld Aggregated Nicknames" and read the words about "pseudonode" of Section 2= .5 From nobody Wed May 25 21:23:44 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70D812D597; Wed, 25 May 2016 21:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 cMHU52ozyigk; Wed, 25 May 2016 21:23:38 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 BD31812D583; Wed, 25 May 2016 21:23:38 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id w184so99666908oiw.2; Wed, 25 May 2016 21:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=8vMX3CT74DO7+kK2o4bSSppsLnQb9KpBysYMQqMH/ns=; b=TtbdfYN1a2IB51EjBA1sDL3EWvHuMAYNRrOIUl3jNvNV5bbZZzTDPWQV5Gxtpm8IfD iW12ymDgk19GUhihD2h3NVRm9CTr6rWO/3+lBnYv//dize2QCP2S4HoMJcZijjOrHgOe yy8aSS2BNDq8FBPlDGXLmAX5UmO4CncqMAmvI3iYmsd7gQe42dME9uWTzu8BQkhKJIFm fNwiPScUFphkAPkK2wA9pig+1pEn/SGuWvTQLR/heQw9CuJ1ggpbaAUwcginObtY7/6L 2fhQneQQwVIJ31DDHPlERsyB41MMdRYZsRWWhocy8qct6FF4VFposGNlJ8/3uhUTvtI6 Ym+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=8vMX3CT74DO7+kK2o4bSSppsLnQb9KpBysYMQqMH/ns=; b=HD0eq3vwm31V0G25DxA3nZPJwGb9mKrC6k6SDKyL9x2xGZZVOGCX2kQfRvc1WQkFFq tNXRyb1x7mTCLlRu1ekUU70A2UzbVlAOBoEgCztMBbXdVoT9wgXF6/jrykoP4Q3B8oqH 0mx3E+nggJUh3YKJIdLpLpTRAkvU6iBN3XkZMTOcfjgbq8VkHC4QE/rMgJUTO+UN9Vb4 mDMsEyre9u43kMxLQTdNet643cx0qrvtqGNJcXOgFHn3H7p06Y2p+uX1kJ+SSggSd8qQ TukUxfH465pGZkkXUkRF8NHr3Plz4PRw3udNFbJf91HxluXvM86wlvEzYt/GxhyDjUlH m/Ag== X-Gm-Message-State: ALyK8tKtIttHHvN8bBAN1mYlcns1p3uLHp8lLbthbwu5QWXyKU+/r0XN4hpWqZSC9CaUCD7/vqfY/X7meqwARA== X-Received: by 10.202.65.133 with SMTP id o127mr4799138oia.43.1464236618065; Wed, 25 May 2016 21:23:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.249 with HTTP; Wed, 25 May 2016 21:23:23 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Thu, 26 May 2016 00:23:23 -0400 Message-ID: To: Stig Venaas Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtg-dir@ietf.org" , "Zhangxian \(Xian\)" , Alia Atlas , "trill@ietf.org" , Jonathan Hardwick , Susan Hares , Jon Hudson Subject: Re: [RTG-DIR] [trill] Routing directorate QA review of draft-ietf-trill-rbridge-multilevel X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 04:23:41 -0000 Hi Stig, On Wed, May 25, 2016 at 3:26 PM, Alia Atlas wrote: > Stig, > > Thank you very much for your review. I'm also forwarding it to trill so > that the WG can see it. > > Regards, > Alia > > On Wed, May 25, 2016 at 2:28 PM, Stig Venaas wrote: >> >> Hi >> >> Sorry for being a bit late with this review. At least the document is >> well written and easy to understand. There are no significant issues. >> >> I am wondering about the security considerations though. Are there >> really no differences between the multi-level alternatives when it >> comes to security? Well, I guess a couple sentences could be added that the choice of using aggregated nicknames, and the resulting possible duplication of nicknames between areas, increases the possibility of a TRILL Data packet being delivered to the wrong egress RBridge if areas are suddenly merged. However, is many cases the data would be discarded at that egress because it would not match a known end station data label / MAC address. >> I have two tiny editorial comments. >> >> Section 1.4 typo >> RBridge - Routing Bridge, an alterntive name for a TRILL switch >> ^^^^^^^^^ OK, >> Also, several places it says "non-zero" which is correct, but there >> are some instances of "nonzero". Apparently both of those are correct but I agree the draft should use one of them consistently. I'll replace the two instances of nonzero with the hyphenated form. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com >> Stig >> >> >> On Wed, May 4, 2016 at 11:52 PM, Jonathan Hardwick >> wrote: >> > Hi Stig >> > >> > >> > >> > Please would you do a routing directorate QA review of >> > draft-ietf-trill-rbridge-multilevel? >> > >> > https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/ >> > >> > >> > >> > Note that this is a =E2=80=9CQA review.=E2=80=9D The document is still= being worked on >> > by >> > the TRILL working group. The goal of this review is to provide a >> > different >> > perspective on the work and to improve its quality. Hence, your commen= ts >> > will be provided primarily for the benefit of the TRILL chairs and the >> > document authors. >> > >> > >> > >> > Please could you provide your comments by May 20 and copy your comment= s >> > to >> > the rtg-dir list? >> > >> > >> > >> > The following web page contains a briefing on the QA process, and >> > guidance >> > for the QA reviewer. >> > >> > https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa >> > >> > >> > >> > Please let me know whether you can do it, or not. >> > >> > >> > >> > Many thanks >> > >> > Jon >> > >> > >> > >> > >> > >> > >> > >> > >> > > > _______________________________________________ > trill mailing list > trill@ietf.org > https://www.ietf.org/mailman/listinfo/trill > From nobody Wed May 25 23:10:09 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2E012D12D; Wed, 25 May 2016 23:09:57 -0700 (PDT) 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=eci365.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 luoi5jp4pOtU; Wed, 25 May 2016 23:09:51 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0094.outbound.protection.outlook.com [104.47.2.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DD0A12D0A0; Wed, 25 May 2016 23:09:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+2wAuIrCb86EPUBLYmZiuskr4NLyHk8raHBPbNm5kbw=; b=Rp6huQNr3O52Fa3OCizYDIHZZ57Z/PWU9WIrm9cHF81wQ+Koon4oiFWK3znowJ65r+5LLDbXcdfx+0OX5ZtOZGAYtIiGEQE+rUs9vTXT2O8ZHsqjm7msWMTkM+dV91Qace3NPh7K/DxIQQTUWsWErHR/aJiZwSM8dZcuq88ocBg= Received: from AM4PR0301MB2258.eurprd03.prod.outlook.com (10.165.44.25) by AM4PR0301MB2258.eurprd03.prod.outlook.com (10.165.44.25) with Microsoft SMTP Server (TLS) id 15.1.497.12; Thu, 26 May 2016 06:08:10 +0000 Received: from AM4PR0301MB2258.eurprd03.prod.outlook.com ([10.165.44.25]) by AM4PR0301MB2258.eurprd03.prod.outlook.com ([10.165.44.25]) with mapi id 15.01.0497.022; Thu, 26 May 2016 06:08:10 +0000 From: Alexander Vainshtein To: Donald Eastlake Thread-Topic: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname Thread-Index: AQHRtZZOOYuy+h1UCUGjRJ1qjVLvXZ/H45PQgAEWN4CAAJSMMIAAmGEAgACLGjc= Date: Thu, 26 May 2016 06:08:10 +0000 Message-ID: References: <4552F0907735844E9204A62BBDD325E787CB087E@NKGEML515-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E787CB7589@NKGEML515-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E787CB9054@NKGEML515-MBS.china.huawei.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=ecitele.com; x-originating-ip: [132.245.50.69] x-ms-office365-filtering-correlation-id: f6c34ddf-7084-4c78-061a-08d3852c1d2c x-microsoft-exchange-diagnostics: 1; AM4PR0301MB2258; 5:WRkVZmda79qg7/faSWiMzQ+3XSDdJ8cJqOR/lQUOqo4rMnbYkzBkwOwiYGf1/xuCUHwG0W88zo6+/wY1Ieq5z+w83jQwaHxPSD7pt0ZRjBYDYA1im3T2vd3fZBKGmXxSrCy68qgU+aUTY8oAvOk1+g==; 24:N2rfor5cTOPSn8eXNdmdPCzTwMC3uW40TwBDBnfIvSvwiVdMK2k2DulgvACva7uZ72B1dGdvzMFDKjnJEHfqm00Q/Tm8yaLgAIisAlodqSM=; 7:qhqQPuJ43b1xbKVFvOyThlF8e3OzWNMU//CWFAxvYZuMNQ+erF76IV1nFGEwgMu1iTkPIMxzfM76/ZoE0HC2nUncf+DHf6s9IVL4a9d0IHMsPr7g5XgKvvquUfVCpF3RwEmAf62u5XOpxlpTgE4CwnzZyBuYx3YSB6hw4bRD6quyqEexptT5KAwKBRqpYfPF x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR0301MB2258; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(50582790962513)(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:AM4PR0301MB2258; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB2258; x-forefront-prvs: 0954EE4910 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(30594003)(51444003)(51914003)(24454002)(377454003)(252514010)(13464003)(3846002)(6116002)(8936002)(102836003)(122556002)(586003)(5002640100001)(15975445007)(110136002)(3660700001)(106116001)(77096005)(1411001)(19580395003)(8676002)(3280700002)(3900700001)(81166006)(92566002)(1220700001)(2906002)(4326007)(5003600100002)(189998001)(230783001)(86362001)(76576001)(9686002)(19580405001)(5008740100001)(19627405001)(93886004)(74316001)(19625215002)(2900100001)(5004730100002)(87936001)(33656002)(50986999)(76176999)(10400500002)(66066001)(54356999)(16236675004)(2950100001)(11100500001)(17750500001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR0301MB2258; H:AM4PR0301MB2258.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR0301MB2258DBADC97212E6783D1E5A9D410AM4PR0301MB2258_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2016 06:08:10.3226 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB2258 Archived-At: Cc: "rtg-dir@ietf.org" , "Zhangxian \(Xian\)" , Mingui Zhang , "trill@ietf.org" , Jonathan Hardwick , "draft-ietf-trill-multilevel-single-nickname@ietf.org" , Susan Hares , "jon.hudson@gmail.com" Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 06:09:57 -0000 --_000_AM4PR0301MB2258DBADC97212E6783D1E5A9D410AM4PR0301MB2258_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Donald, Lots of thanks for a very detailed response! Lots of thanks for very important information about the actual and expected= scale of TRILL deployments as well as for presenting some of the factors (= line active-active TRILL operation) that affect the consumption of the nick= name space. It addresses my question about the reason to go for multi-level= IS-IS at all. Flat IGP configuration (both IS-IS and OSPF) are very popula= r in IP/MPLS deployments due to LDP (and, now, IP/LDP FRR techniques), so = this information was important to me in order to understand that the multi-= level TRILL drafts solve a real problem. I would suggest adding this inform= ation to the multi-level TRILL draft. However, I am still not sure if the Single Nickname draft (one I have been = reviewing) represents an attempt to solve a real problem. My understanding= so far has been that it follows the Aggregate Nicknames approach in the mu= lti-level TRILL draft, but eliminates the need to assign nicknames to L1 ar= eas. I do not see if, even with the scale you have mentioned) this could be= a serious issue (e.g., contribute significantly to depletion of the nickna= me space). Do I miss something here? The swapping vs. re-write issue I have discussed with Mingui is a pure case= of terminology. AsI have said, I consider it as closed. As for the metadata issue - I am perfectly ready to follow the guidance of= ADs and WG chairs. especially since this policy has recently undergone ser= ious changes. Two additional questions - for the sake of my curiosity: 1. Can possibly you explain what has happened to draft that proposed usi= ng BGP with TRILL? 2. Did anybody consider combining IPFRR techniques with TRILL? Regards, and lots of thanks in advance, Sasha ________________________________________ From: Donald Eastlake Sent: Thursday, May 26, 2016 12:03 AM To: Alexander Vainshtein Cc: Mingui Zhang; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multil= evel-single-nickname@ietf.org; Susan Hares; jon.hudson@gmail.com; Jonathan = Hardwick; rtg-dir@ietf.org Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-si= ngle-nickname Hi Alexander, Thanks from me also for your review. I'd like to chime in with a few thoughts: On Wed, May 25, 2016 at 8:23 AM, Alexander Vainshtein wrote: > > Hi Mingui, > I will try to summarize our agreements and disagreements. > > 1. The scale of TRILL deployments: > > a. I have not seen any specific numbers or references to any > specific topologies that could really make single-level TRILL not > scalable enough - neither in the TRILL drafts I've read nor in our > discussions so far I am puzzled as to why you think there would be some specific numeric hard boundary, other than number space or memory space exhaustion, beyond which you cannot scale. Can you point to a documentation of such a thing for IP use of IS-IS? Surely it depends on how much computer power the routers have, link stability, and numerous other factors. Just looking at convergence time and approximating it as the amount of computation required at a typical router in the TRILL campus, it is on the order of N*(log N) for computation of least cost routes where there are N routers in a single level campus while it is on the order of (sqrt N)*(log N) for multi-level, in both cases assuming optimized calculations. The largest TRILL campuses I am aware of are on the order of 3,000 routers. So one would expect that converting such a campus to multi-level TRILL would reduce convergence time by approximately a factor of 50. Furthermore, one would expect the rate of failures within each Level 1 area in the multi-level case to be approximately proportional to the number of links/routers and thus also fall by one and a half orders of magnitude. Do you claim these improvements would never be valuable? There are many other scaling factors such as the size of the link state database, etc. I believe the informational draft-ietf-trill-rbridge-multi-level gives a good summary. > b. Regarding your reference to multiple interconnected TRILL-based > campuses in your last email: I do not think that TRILL is an > alternative to or competes with Internet. I agree that TRILL does not compete with the Internet. :-) I believe this facet of the discussion was in connection with the possibility of TRILL nickname space exhaustion. Consider the following factors: 1) TRILL supports active-active connection of end stations at the TRILL edge. Using the techniques in RFC 7781 (Pseudo-Nickname for Active-Active Access) consumes TRILL nicknames for active-active edge groups. 2) Assuming, for the moment, you are using multi-level with unique nicknames, the nickname allocation mechanism will waste many nicknames due to hierarchical assignment, the same way power-of-two sized IP subnets waste IP addresses. 3) There is a desire to interconnect TRILL campuses that are under joint or cooperative management with limited control plane coupling so as to limit error propagation, etc. There are various possible ways to do this but most of them assume non-conflicting nicknames (or non-conflicting level 2 nicknames if the campuses are multi-level). I admit that even taking the largest existing TRILL campuses I know about and adding extensive active-active end station support at the edge and multi-level with unique nicknames that are hierarchically allocated, you would still probably not exhaust the TRILL nickname space. But you could be getting close to that hard limit. This seems like enough reason to me to be advancing a standard where Level 1 areas are aggregated (whether by a single nickname or set of border router nicknames) to, for all practical purposes, eliminate the nickname space restriction. > c. I have also noticed that, once upon a time (4 years ago) there > was an attempt to use BGP with TRILL. I wonder why this draft has > been left to expire because, from my POV, BGP is greatly preferable > to multi-level IS-IS when it comes to scalability issues. > > 2. Nickname Re-write vs Nickname Swapping: Looks like a clear case > of misunderstanding between us, probably due to the fact that I am > not a TRILL expert: > > a. I have used the term "swapping" in the same way it is used > in MPLS (e.g., see RFC 3031 discussing label swapping). In other > words, from my POV "nickname swapping" and "nickname re-write" were > synonyms. > > b. It seems that some yet to be standardized extension of TRILL > considers some dedicated nickname swapping mechanism that carries > new nicknames in some extension of the TRILL header. In this > parlance "nickname re-write" and "nickname swapping" are different. Right. The possibility was discussed some time ago of expanding the TRILL header so that, for TRILL Data packets going between different Level 1 Areas, there could be, in effect, two ingress nicknames (an ingress RBridge nickname and an ingress Area nickname) and two egress nicknames (an egress RBridge nickname and an egress Area nickname). Appropriate swapping would occur at border routers to avoid changes in fast path logic at all non-border routers. Within Level 2, the Area nicknames would be in the existing header slots that are routed on, etc. However, as far as I can recall, no specification was ever been produced for this "nickname swapping" although it is mentioned in the informational multi-level draft. > c. I think that we now safely consider this discussion issue > as closed. > > 3. Metadata: > > a. I fully agree that we should hear from other RTG-DIR > members on what exactly (if at all) should be specified to clarify > the relationship between the Single Nickname draft and RFC 6325 I would note that the IESG policy on "updates" has become very strict recently. It used to be a judgment call. Now, when a Standards Track RFC merely extends another such RFC so you could implement an instance of the earlier standard as specified without reference to or violating the subsequent specification, the IESG will generally prohibit you from claiming that the subsequent specification "updates" the first. (I do not particularly agree with this policy change myself.) > b. I can only add that, AFAIK, the Multi-Level TRILL draft, > being positioned as an Informational, can neither update nor > obsolete RFC 6325 (which is Standards Track). So there is no issue > with its metadata being empty. > > There is one issue in my original review that we have not discussed > at all - namely, the behavior implied by the Single Nickname draft > when a new border RBridge is added to a certain area. I agree that what needs to be done when border RBridges are added/deleted needs to be clear in the draft. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > Sent: Wednesday, May 25, 2016 6:07 AM > To: Alexander Vainshtein > Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-tril= l-multilevel-single-nickname@ietf.org; Susan Hares; jon.hudson@gmail.com; J= onathan Hardwick > Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-= single-nickname > > Hi Sasha, > > Thanks for the comments. > > > [[Sasha]] Do you (or the authors of the multi-level TRILL draft) consider= deployment scenarios with more than 64K RBridges in a single TRILL campus?= Is this a realistic scenario? > [Mingui] We can also doubt whether a domain with more that 2^32 IP router= s is a realistic scenario. The fact is that a single campus is usually not = allowed to use up the entire 64K namespace. Please consider the scenario th= at lots of TRILL campuses are to be interconnected. > > > [[Sasha]] In other words, your draft explicitly states that the area bord= er RBridges modify the nicknames in the TRILL header of a packet that cross= es the Level 2 domain. How is this different from swapping (save from the n= ame of the operation)? > [Mingui] As I said, there is no "swap nickname field" conception in the d= raft. Yes, the border RBridge needs to modify the nickname but it does not= have to modify it through the "swapping" operation. Instead, the border RB= ridge "replaces" the nickname in the TRILL data packets with its own nickna= me (rather than a nickname in the "swap nickname field" provided by the ori= ginating RBridge). Why authors prefer the replacing operation than the swap= ping operation? Because the swapping operation requires a new TRILL header = (two additional 16-bit fields) which has not been standardized yet. > > As for the "Updates" metadata, let's see if people on the RTG-DIR list wo= uld give directions. > > Best regards, > Mingui > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Tuesday, May 24, 2016 6:45 PM > To: Mingui Zhang > Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares; jon.hudson@gma= il.com; Jonathan Hardwick > Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-= single-nickname > > Mingui hi! > Lots of thanks for a prompt response. > > A few short comments inline below. > > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > Sent: Tuesday, May 24, 2016 11:23 AM > To: Alexander Vainshtein > Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares; jon.hudson@gma= il.com; Jonathan Hardwick > Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-= single-nickname > > Hi Sasha, > > Thanks for your comments. Please see responses inline below. > > Thanks, > Mingui > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Monday, May 23, 2016 6:13 PM > To: Mingui Zhang > Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares (shares@ndzh.co= m); jon.hudson@gmail.com; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com) > Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-= single-nickname > > > Mingui hi! > > Lots of thanks for a prompt response to some of the issues I've raised in= the review. > > > > Please see some comments to you responses inline below. > > > > Regards, > > Sasha > > > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > > -----Original Message----- > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Mingui Zhang > Sent: Monday, May 23, 2016 12:31 PM > To: Alexander Vainshtein; Jonathan Hardwick (Jonathan.Hardwick@metaswitch= .com) > Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares (shares@ndzh.co= m); jon.hudson@gmail.com > Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-= single-nickname > > > > Hi Alexander, > > > > Thanks for the review! > > > > The multilevel conception itself is abstract and not easily understandabl= e. > > [[Sasha]] Do you refer to the multi-level IS-IS in general or multi-level= TRILL specifically? I am asking because I believe am reasonably well aware= of the multi-level architecture of IS-IS as used for IP routing. It is som= ewhat different from that of OSPF, but I would not call it "abstract and no= t easily understandable". And there are quite a few excellent introduction= s to the subject (again in the context of IP routing). However, I am defini= tely not a TRILL expert, and have stated that in the review. > > > > [Mingui] Yes, multi-level arch of IS-IS has already been well understood.= However, the extending TRILL to multi-levels brings new challenges. As sta= ted in the informational draft, one issue is on processing the TRILL switch= nicknames and the other issue is on handling multi-destination packet dist= ribution trees. In order not to make the specifications "abstract", the dra= ft carefully designed two walking-through examples in Section 3. If the exa= mples were understood, it would be non-abstract as well. ;-) > > > > However, it was really interesting in designing such a solution. Apprecia= te the review and the time on relevant documents to figure out the whole sc= heme. > > > > > ? Nor provides any explanations about the reasons that make > > > single-level IS-IS used by TRILL less scalable that single-level IS-IS > > > when it is used for distributing IP reachability > > > > The reason comes from the fact that the length of a nickname is different= from an IP address. > > [[Sasha]] I must admit that I do not understand the connection. By this l= ogic, IS-IS for CLNS and IPv6 should be much more scalable than IS-IS for I= Pv4, but I have never seen such claims before. Could you please elaborate? = Could somebody on the RTG-DIR list to comment on that? > > > > [Mingui] For a single-level IS-IS instance, the length of the address det= ermines the name space. In the informational draft, Section 1.1 TRILL Scala= bility Issues, the following statement is relevant > > " 5. the limit of the number of TRILL switches, due to the 16-bit nickn= ame space," > > [[Sasha]] Do you (or the authors of the multi-level TRILL draft) consider= deployment scenarios with more than 64K RBridges in a single TRILL campus?= Is this a realistic scenario? > > > > > > I think this could be addressed in the updated version of the draft: http= s://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/?include_t= ext=3D1. > > > > > * The draft positions itself as an alternative to the Aggregate > > > Nicknames approach while, from my POV, it is just provides additional > > > details on one of the possible flavors of this approach > > > > The WG used to discuss several ways to address the "Aggregate Nickname" a= pproach. > > [[Sasha]] I do not follow the TRILL WG mailing list, so I am not aware of= any discussions that have been hold there. I am only speaking about what I= could find in the two drafts mentioned in my review. > > > > [Mingui] Actually, the informational draft had included the information o= f those alternatives as well. Please see "Section 2.2.2.2 Swap Nickname Fie= ld Aggregated Nicknames" and read the words about "pseudonode" of Section 2= .5 --_000_AM4PR0301MB2258DBADC97212E6783D1E5A9D410AM4PR0301MB2258_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Donald,
Lots of thanks for a very detailed response!

Lots of thanks for very important information about the actual and exp= ected scale of TRILL deployments as well as for presenting some of the= factors (line active-active TRILL operation) that affect the consumption o= f the nickname space. It addresses my question about the reason to go for multi-level IS-IS at all. Flat IGP con= figuration (both IS-IS and OSPF) are very popular in IP/MPLS depl= oyments due to LDP  (and, now, IP/LDP FRR techniques), so this informa= tion was important to me in order to understand that the multi-level TRILL drafts solve a real problem. I woul= d suggest adding this information to the multi-level TRILL draft. 

However, I am still not sure if the Single Nickname draft = (one I have been reviewing)  represents an attempt to sol= ve a real problem. My understanding so far has been that it follows the= Aggregate Nicknames approach in the multi-level TRILL draft, but eliminates the need to assign nicknames to L1 areas. I d= o not see if, even with the scale you have mentioned) this could be a serio= us issue (e.g., contribute significantly to depletion of the nickname space= ). Do I  miss something here?

The swapping vs. re-write issue I have discussed with Mingui is a pure= case of terminology. AsI have said, I consider it as closed.

As for the metadata issue  - I am perfectly ready to follow the g= uidance of ADs and WG chairs. especially since this policy has recently&nbs= p;undergone serious changes.

Two additional questions - for the sake of my curiosity:
  1. Can possibly you explain what has happened to draft that proposed = using BGP with TRILL?
  2. Did anybody consider combining IPFRR tec= hniques with TRILL?

Regards, and lots of thanks in advance,
Sasha










________________________________________
From: Donald Eastlake <d3e3e3@gmail.com>
Sent: Thursday, May 26, 2016 12:03 AM
To: Alexander Vainshtein
Cc: Mingui Zhang; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multil= evel-single-nickname@ietf.org; Susan Hares; jon.hudson@gmail.com; Jonathan = Hardwick; rtg-dir@ietf.org
Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-si= ngle-nickname

Hi Alexander,

Thanks from me also for your review.  I'd like to chime in with a few<= br> thoughts:

On Wed, May 25, 2016 at 8:23 AM, Alexander Vainshtein
<Alexander.Vainshtein@ecitele.com> wrote:
>
> Hi Mingui,
> I will try to summarize our agreements and disagreements.
>
> 1.       The scale of TRILL deployments:=
>
> a. I have not seen any specific numbers or references to any
> specific topologies that could really make single-level TRILL not
> scalable enough - neither in the TRILL drafts I've read nor in our
> discussions so far

I am puzzled as to why you think there would be some specific numeric
hard boundary, other than number space or memory space exhaustion,
beyond which you cannot scale. Can you point to a documentation of
such a thing for IP use of IS-IS? Surely it depends on how much
computer power the routers have, link stability, and numerous other
factors.

Just looking at convergence time and approximating it as the amount of
computation required at a typical router in the TRILL campus, it is on
the order of N*(log N) for computation of least cost routes where
there are N routers in a single level campus while it is on the order
of (sqrt N)*(log N) for multi-level, in both cases assuming optimized
calculations. The largest TRILL campuses I am aware of are on the
order of 3,000 routers. So one would expect that converting such a
campus to multi-level TRILL would reduce convergence time by
approximately a factor of 50. Furthermore, one would expect the rate
of failures within each Level 1 area in the multi-level case to be
approximately proportional to the number of links/routers and thus
also fall by one and a half orders of magnitude. Do you claim these
improvements would never be valuable?

There are many other scaling factors such as the size of the link
state database, etc. I believe the informational
draft-ietf-trill-rbridge-multi-level gives a good summary.

> b. Regarding your reference to multiple interconnected TRILL-based
> campuses in your last email: I do not think that TRILL is an
> alternative to or competes with Internet.

I agree that TRILL does not compete with the Internet.  :-)

I believe this facet of the discussion was in connection with the
possibility of TRILL nickname space exhaustion. Consider the following
factors:

1) TRILL supports active-active connection of end stations at the
TRILL edge. Using the techniques in RFC 7781 (Pseudo-Nickname for
Active-Active Access) consumes TRILL nicknames for active-active edge
groups.

2) Assuming, for the moment, you are using multi-level with unique
nicknames, the nickname allocation mechanism will waste many nicknames
due to hierarchical assignment, the same way power-of-two sized IP
subnets waste IP addresses.

3) There is a desire to interconnect TRILL campuses that are under
joint or cooperative management with limited control plane coupling so
as to limit error propagation, etc. There are various possible ways to
do this but most of them assume non-conflicting nicknames (or
non-conflicting level 2 nicknames if the campuses are multi-level).

I admit that even taking the largest existing TRILL campuses I know
about and adding extensive active-active end station support at the
edge and multi-level with unique nicknames that are hierarchically
allocated, you would still probably not exhaust the TRILL nickname
space. But you could be getting close to that hard limit. This seems
like enough reason to me to be advancing a standard where Level 1
areas are aggregated (whether by a single nickname or set of border
router nicknames) to, for all practical purposes, eliminate the
nickname space restriction.

> c. I have also noticed that, once upon a time (4 years ago) there
> was an attempt to use BGP with TRILL. I wonder why this draft has
> been left to expire because, from my POV, BGP is greatly preferable > to multi-level IS-IS when it comes to scalability issues.
>
> 2. Nickname Re-write vs Nickname Swapping: Looks like a clear case
> of misunderstanding between us, probably due to the fact that I am
> not a TRILL expert:
>
> a.       I have used the term "swap= ping" in the same way it is used
> in MPLS (e.g., see RFC 3031 discussing label swapping). In other
> words, from my POV "nickname swapping" and "nickname re= -write" were
> synonyms.
>
> b.      It seems that some yet to be standard= ized extension of TRILL
> considers some dedicated nickname swapping mechanism that carries
> new nicknames in some extension of the TRILL header.  In this
> parlance "nickname re-write" and "nickname swapping&quo= t; are different.

Right. The possibility was discussed some time ago of expanding the
TRILL header so that, for TRILL Data packets going between different
Level 1 Areas, there could be, in effect, two ingress nicknames (an
ingress RBridge nickname and an ingress Area nickname) and two egress
nicknames (an egress RBridge nickname and an egress Area nickname).
Appropriate swapping would occur at border routers to avoid changes in
fast path logic at all non-border routers. Within Level 2, the Area
nicknames would be in the existing header slots that are routed on,
etc. However, as far as I can recall, no specification was ever been
produced for this "nickname swapping" although it is mentioned in= the
informational multi-level draft.

> c.       I think that we now safely cons= ider this discussion issue
> as closed.
>
> 3.       Metadata:
>
> a.       I fully agree that we should he= ar from other RTG-DIR
> members on what exactly (if at all) should be specified to clarify
> the relationship between the Single Nickname draft and RFC 6325

I would note that the IESG policy on "updates" has become very st= rict
recently. It used to be a judgment call. Now, when a Standards Track
RFC merely extends another such RFC so you could implement an instance
of the earlier standard as specified without reference to or violating
the subsequent specification, the IESG will generally prohibit you
from claiming that the subsequent specification "updates" the fir= st.
(I do not particularly agree with this policy change myself.)

> b.      I can only add that, AFAIK, the Multi= -Level TRILL draft,
> being positioned as an Informational, can neither update nor
> obsolete RFC 6325 (which is Standards Track). So there is no issue
> with its metadata being empty.
>
> There is one issue in my original review that we have not discussed > at all - namely, the behavior implied by the Single Nickname draft
> when a new border RBridge is added to a certain area.

I agree that what needs to be done when border RBridges are
added/deleted needs to be clear in the draft.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e3e3@gmail.com

> Regards,
> Sasha
>
> Office: +972-39266302
> Cell:      +972-549266302
> Email:   Alexander.Vainshtein@ecitele.com
>
> From: Mingui Zhang [mailto:zhangmingui@huawei.com]
> Sent: Wednesday, May 25, 2016 6:07 AM
> To: Alexander Vainshtein
> Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-t= rill-multilevel-single-nickname@ietf.org; Susan Hares; jon.hudson@gmail.com= ; Jonathan Hardwick
> Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilev= el-single-nickname
>
> Hi Sasha,
>
> Thanks for the comments.
>
>
> [[Sasha]] Do you (or the authors of the multi-level TRILL draft) consi= der deployment scenarios with more than 64K RBridges in a single TRILL camp= us? Is this a realistic scenario?
> [Mingui] We can also doubt whether a domain with more that 2^32 IP rou= ters is a realistic scenario. The fact is that a single campus is usually n= ot allowed to use up the entire 64K namespace. Please consider the scenario= that lots of TRILL campuses are to be interconnected.
>
>
> [[Sasha]] In other words, your draft explicitly states that the area b= order RBridges modify the nicknames in the TRILL header of a packet that cr= osses the Level 2 domain. How is this different from swapping (save from th= e name of the operation)?
> [Mingui] As I said, there is no "swap nickname field" concep= tion in the draft.  Yes, the border RBridge needs to modify the nickna= me but it does not have to modify it through the "swapping" opera= tion. Instead, the border RBridge "replaces" the nickname in the TRILL data packets with its own nickname (rather than a nickname in th= e "swap nickname field" provided by the originating RBridge). Why= authors prefer the replacing operation than the swapping operation? Becaus= e the swapping operation requires a new TRILL header (two additional 16-bit fields) which has not been standardized yet.=
>
> As for the "Updates" metadata, let's see if people on the RT= G-DIR list would give directions.
>
> Best regards,
> Mingui
> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Tuesday, May 24, 2016 6:45 PM
> To: Mingui Zhang
> Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org<mailto:tri= ll@ietf.org>; draft-ietf-trill-multilevel-single-nickname@ietf.org<ma= ilto:draft-ietf-trill-multilevel-single-nickname@ietf.org>; Susan Hares;= jon.hudson@gmail.com<mailto:jon.hudson@gmail.com>; Jonathan Hardwick
> Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilev= el-single-nickname
>
> Mingui hi!
> Lots of thanks for a prompt response.
>
> A few short comments inline below.
>
> Regards,
> Sasha
>
> Office: +972-39266302
> Cell:      +972-549266302
> Email:   Alexander.Vainshtein@ecitele.com<mailto:Alexande= r.Vainshtein@ecitele.com>
>
> From: Mingui Zhang [mailto:zhangmingui@huawei.com]
> Sent: Tuesday, May 24, 2016 11:23 AM
> To: Alexander Vainshtein
> Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org<mailto:tri= ll@ietf.org>; draft-ietf-trill-multilevel-single-nickname@ietf.org<ma= ilto:draft-ietf-trill-multilevel-single-nickname@ietf.org>; Susan Hares;= jon.hudson@gmail.com<mailto:jon.hudson@gmail.com>; Jonathan Hardwick
> Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilev= el-single-nickname
>
> Hi Sasha,
>
> Thanks for your comments. Please see responses inline below.
>
> Thanks,
> Mingui
>
> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Monday, May 23, 2016 6:13 PM
> To: Mingui Zhang
> Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org<mailto:tri= ll@ietf.org>; draft-ietf-trill-multilevel-single-nickname@ietf.org<ma= ilto:draft-ietf-trill-multilevel-single-nickname@ietf.org>; Susan Hares = (shares@ndzh.com<mailto:shares@ndzh.com>); jon.hudson@gmail.com<ma= ilto:jon.hudson@gmail.com>; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com<mailto:Jonathan.Har= dwick@metaswitch.com>)
> Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilev= el-single-nickname
>
>
> Mingui hi!
>
> Lots of thanks for a prompt response to some of the issues I've raised= in the review.
>
>
>
> Please see some comments to you responses inline below.
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell:      +972-549266302
>
> Email:   Alexander.Vainshtein@ecitele.com<mailto:Alexande= r.Vainshtein@ecitele.com>
>
>
>
> -----Original Message-----
> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Mingui Zh= ang
> Sent: Monday, May 23, 2016 12:31 PM
> To: Alexander Vainshtein; Jonathan Hardwick (Jonathan.Hardwick@metaswi= tch.com<mailto:Jonathan.Hardwick@metaswitch.com>)
> Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org<mailto:tri= ll@ietf.org>; draft-ietf-trill-multilevel-single-nickname@ietf.org<ma= ilto:draft-ietf-trill-multilevel-single-nickname@ietf.org>; Susan Hares = (shares@ndzh.com<mailto:shares@ndzh.com>); jon.hudson@gmail.com<ma= ilto:jon.hudson@gmail.com>
> Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilev= el-single-nickname
>
>
>
> Hi Alexander,
>
>
>
> Thanks for the review!
>
>
>
> The multilevel conception itself is abstract and not easily understand= able.
>
> [[Sasha]] Do you refer to the multi-level IS-IS in general or multi-le= vel TRILL specifically? I am asking because I believe am reasonably well aw= are of the multi-level architecture of IS-IS as used for IP routing. It is = somewhat different from that of OSPF, but I would not call it "abstract and not easily understandable"= .  And there are quite a few excellent introductions to the subject (a= gain in the context of IP routing). However, I am definitely not a TRILL ex= pert, and have stated that in the review.
>
>
>
> [Mingui] Yes, multi-level arch of IS-IS has already been well understo= od. However, the extending TRILL to multi-levels brings new challenges. As = stated in the informational draft, one issue is on processing the TRILL swi= tch nicknames and the other issue is on handling multi-destination packet distribution trees. In order not to m= ake the specifications "abstract", the draft carefully designed t= wo walking-through examples in Section 3. If the examples were understood, = it would be non-abstract as well. ;-)
>
>
>
> However, it was really interesting in designing such a solution. Appre= ciate the review and the time on relevant documents to figure out the whole= scheme.
>
>
>
> > ?  Nor provides any explanations about the reasons that make=
>
> > single-level IS-IS used by TRILL less scalable that single-level = IS-IS
>
> > when it is used for distributing IP reachability
>
>
>
> The reason comes from the fact that the length of a nickname is differ= ent from an IP address.
>
> [[Sasha]] I must admit that I do not understand the connection. By thi= s logic, IS-IS for CLNS and IPv6 should be much more scalable than IS-IS fo= r IPv4, but I have never seen such claims before. Could you please elaborat= e? Could somebody on the RTG-DIR list to comment on that?
>
>
>
> [Mingui] For a single-level IS-IS instance, the length of the address = determines the name space. In the informational draft, Section 1.1 TRILL Sc= alability Issues, the following statement is relevant
>
> "   5. the limit of the number of TRILL switches, due t= o the 16-bit nickname space,"
>
> [[Sasha]] Do you (or the authors of the multi-level TRILL draft) consi= der deployment scenarios with more than 64K RBridges in a single TRILL camp= us? Is this a realistic scenario?
>
>
>
>
>
> I think this could be addressed in the updated version of the draft: h= ttps://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/?includ= e_text=3D1.
>
>
>
> > *         The draft posit= ions itself as an alternative to the Aggregate
>
> > Nicknames approach while, from my POV, it is just provides additi= onal
>
> > details on one of the possible flavors of this approach
>
>
>
> The WG used to discuss several ways to address the "Aggregate Nic= kname" approach.
>
> [[Sasha]] I do not follow the TRILL WG mailing list, so I am not aware= of any discussions that have been hold there. I am only speaking about wha= t I could find in the two drafts mentioned in my review.
>
>
>
> [Mingui] Actually, the informational draft had included the informatio= n of those alternatives as well. Please see "Section 2.2.2.2 Swap Nick= name Field Aggregated Nicknames" and read the words about "pseudo= node" of Section 2.5
--_000_AM4PR0301MB2258DBADC97212E6783D1E5A9D410AM4PR0301MB2258_-- From nobody Wed May 25 23:21:37 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FB512B071; Wed, 25 May 2016 23:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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=-1.426, 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 Nh4J15EI5Ey8; Wed, 25 May 2016 23:21:15 -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 91AC612D0A0; Wed, 25 May 2016 23:21:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKU44338; Thu, 26 May 2016 06:21:11 +0000 (GMT) Received: from SZXEMA416-HUB.china.huawei.com (10.82.72.35) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 26 May 2016 07:21:08 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.42]) by SZXEMA416-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0235.001; Thu, 26 May 2016 14:21:04 +0800 From: Mach Chen To: Daniele Ceccarelli , " (rtg-ads@ietf.org)" Thread-Topic: RtgDir review: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06 Thread-Index: AdGe+Z/lFOzQc8O7SFSbqLe7ce8oewAG1OFwA2v05+AAAARS8AJlk/FwAAHw8kAAAKspgAABGawwAACm3lAAKmREgA== Date: Thu, 26 May 2016 06:21:03 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE48162EBD1D@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE48162EBF6F@ESESSMB301.ericsson.se> <4A1562797D64E44993C5CBF38CF1BE48162EC0EA@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48162EC0EA@ESESSMB301.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.135] 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.574695D7.0142, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.42, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c1bd2077fdb78ac4453c9ffedee5bcb7 Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-pals-mpls-tp-pw-over-bidir-lsp.all@tools.ietf.org" , "pals@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 06:21:24 -0000 VGhhbmtzIERhbmllbGUhDQoNCldlIGhhdmUgdXBsb2FkZWQgdGhlIHZlcnNpb24tMDcgdG8gYWRk cmVzcyB0aGUgUnRnRGlyIHJldmlldyBjb21tZW50cy4gDQoNCkh0bWxpemVkOiAgICAgICBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtcHctb3Zlci1i aWRpci1sc3AtMDcNCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtcHctb3Zlci1iaWRpci1sc3AtMDcNCg0KQmVz dCByZWdhcmRzLA0KTWFjaA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IERhbmllbGUgQ2VjY2FyZWxsaSBbbWFpbHRvOmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5j b21dDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDI1LCAyMDE2IDY6MDMgUE0NCj4gVG86IE1hY2gg Q2hlbjsgPHJ0Zy1hZHNAaWV0Zi5vcmc+IChydGctYWRzQGlldGYub3JnKQ0KPiBDYzogcnRnLWRp ckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtcHctb3Zlci1iaWRpci1sc3AuYWxs QHRvb2xzLmlldGYub3JnOw0KPiBwYWxzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBSdGdEaXIg cmV2aWV3OiBkcmFmdC1pZXRmLXBhbHMtbXBscy10cC1wdy1vdmVyLWJpZGlyLWxzcC0wNg0KPiAN Cj4gVGhhdCdzIHBlcmZlY3QhDQo+IA0KPiBCUg0KPiBEYW5pZWxlDQo+IA0KPiA+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogTWFjaCBDaGVuIFttYWlsdG86bWFjaC5jaGVu QGh1YXdlaS5jb21dDQo+ID4gU2VudDogbWVyY29sZWTDrCAyNSBtYWdnaW8gMjAxNiAxMTo0Nw0K PiA+IFRvOiBEYW5pZWxlIENlY2NhcmVsbGkgPGRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5j b20+Ow0KPiA+IDxydGctYWRzQGlldGYub3JnPg0KPiA+IChydGctYWRzQGlldGYub3JnKSA8cnRn LWFkc0BpZXRmLm9yZz4NCj4gPiBDYzogcnRnLWRpckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1wYWxz LW1wbHMtdHAtcHctb3Zlci1iaWRpci0NCj4gPiBsc3AuYWxsQHRvb2xzLmlldGYub3JnOyBwYWxz QGlldGYub3JnDQo+ID4gU3ViamVjdDogUkU6IFJ0Z0RpciByZXZpZXc6DQo+ID4gZHJhZnQtaWV0 Zi1wYWxzLW1wbHMtdHAtcHctb3Zlci1iaWRpci1sc3AtMDYNCj4gPg0KPiA+IEhpIERhbmllbGUs DQo+ID4NCj4gPiBZZXMsIHlvdXIgdW5kZXJzdGFuZGluZyBpcyByaWdodC4gSG93IGFib3V0IGFk ZCB0aGUgZm9sbG93aW5nIHRleHQ6DQo+ID4NCj4gPiBUaGUgVS1iaXQgYW5kIEYtYml0IGFyZSBk ZWZpbmVkIFNlY3Rpb24gMy4zIFJGQzUwMzYuIFNpbmNlIHRoZSBQU04NCj4gPiBUdW5uZWwgQmlu ZGluZyBUTFYgaXMgYW4gb3B0aW9uYWwgVExWLCB0aGUgVS1iaXQgTVVTVCBiZSBzZXQgdG8gMSBz bw0KPiA+IHRoYXQgYSByZWNlaXZlciBNVVNUIHNpbGVudGx5IGlnbm9yZSB0aGlzIFRMViBpZiB1 bmtub3duIHRvIGl0LCBhbmQNCj4gPiBjb250aW51ZSBwcm9jZXNzaW5nIHRoZSByZXN0IG9mIHRo ZSBtZXNzYWdlLg0KPiA+IEEgcmVjZWl2ZXIgb2YgdGhpcyBUTFYgaXMgbm90IGFsbG93ZWQgdG8g Zm9yd2FyZCB0aGUgVExWIGZ1cnRoZXIgd2hlbg0KPiA+IGl0IGRvZXMgbm90IGtub3cgdGhlIFRM Vi4gU28sIHRoZSBGLWJpdCBNVVNUIGJlIHNldCB0byAwLg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+ IE1hY2gNCj4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206 IERhbmllbGUgQ2VjY2FyZWxsaSBbbWFpbHRvOmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5j b21dDQo+ID4gPiBTZW50OiBXZWRuZXNkYXksIE1heSAyNSwgMjAxNiA1OjIxIFBNDQo+ID4gPiBU bzogTWFjaCBDaGVuOyA8cnRnLWFkc0BpZXRmLm9yZz4gKHJ0Zy1hZHNAaWV0Zi5vcmcpDQo+ID4g PiBDYzogcnRnLWRpckBpZXRmLm9yZzsNCj4gPiA+IGRyYWZ0LWlldGYtcGFscy1tcGxzLXRwLXB3 LW92ZXItYmlkaXItbHNwLmFsbEB0b29scy5pZXRmLm9yZzsNCj4gPiA+IHBhbHNAaWV0Zi5vcmcN Cj4gPiA+IFN1YmplY3Q6IFJFOiBSdGdEaXIgcmV2aWV3Og0KPiA+ID4gZHJhZnQtaWV0Zi1wYWxz LW1wbHMtdHAtcHctb3Zlci1iaWRpci1sc3AtMDYNCj4gPiA+DQo+ID4gPiBIaSBNYWNoLA0KPiA+ ID4NCj4gPiA+IE9rLCBsZXQgbWUgdHJ5IHRvIHN1bW1hcml6ZS4NCj4gPiA+DQo+ID4gPiBUaGUg ZHJhZnQgZGVmaW5lcyBhIG5ldyBUTFYgZm9yIHRoZSBMRFAgTWFwcGluZyBNZXNzYWdlIChSRkMg NTAzNg0KPiA+ID4gc2VjdGlvbg0KPiA+ID4gMy41LjcpIHdoaWNoIEkgZ3Vlc3Mgd291bGQgZW5k IHVwIGluIHRoZSAib3B0aW9uYWwgcGFyYW1ldGVycyIgZmllbGQNCj4gPiA+ICh0aGUgdGV4dA0K PiA+ID4gc2F5czogImNvbnRhaW5zIDAgb3IgbW9yZSBwYXJhbWV0ZXJzLCBlYWNoIGVuY29kZWQg YXMgYSBUTFYiKS4NCj4gPiA+IFRoZW4gc2VjdGlvbiAzLjMgbWFuZGF0ZXMgaG93IHRvIGJ1aWxk IHRob3NlIFRMVnMgKFUsIEYgYW5kIHNvIG9uKS4NCj4gPiA+DQo+ID4gPiBJZiBteSB1bmRlcnN0 YW5kaW5nIGNvcnJlY3Q/IElmIHllcyBJIHN1Z2dlc3QgdG8gc3RhdGUgaXQgaW4gdGhlDQo+ID4g PiB0ZXh0IGFuZCBwb3NzaWJseSBhZGQgd2h5IHRoZSBVIGJpdCBpcyBhbHdheXMgMSBpbiB5b3Vy IGNhc2UgYW5kIHRoZQ0KPiA+ID4gRiBiaXQgaXMNCj4gPiBhbHdheXMgMC4NCj4gPiA+DQo+ID4g PiBUaGFua3MgZm9yIHRoZSBleHBsYW5hdGlvbg0KPiA+ID4gRGFuaWVsZQ0KPiA+ID4NCj4gPiA+ ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gRnJvbTogTWFjaCBDaGVuIFtt YWlsdG86bWFjaC5jaGVuQGh1YXdlaS5jb21dDQo+ID4gPiA+IFNlbnQ6IG1lcmNvbGVkw6wgMjUg bWFnZ2lvIDIwMTYgMTE6MDINCj4gPiA+ID4gVG86IERhbmllbGUgQ2VjY2FyZWxsaSA8ZGFuaWVs ZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbT47DQo+ID4gPiA+IDxydGctYWRzQGlldGYub3JnPg0K PiA+ID4gPiAocnRnLWFkc0BpZXRmLm9yZykgPHJ0Zy1hZHNAaWV0Zi5vcmc+DQo+ID4gPiA+IENj OiBydGctZGlyQGlldGYub3JnOyBkcmFmdC1pZXRmLXBhbHMtbXBscy10cC1wdy1vdmVyLWJpZGly LQ0KPiA+ID4gPiBsc3AuYWxsQHRvb2xzLmlldGYub3JnOyBwYWxzQGlldGYub3JnDQo+ID4gPiA+ IFN1YmplY3Q6IFJFOiBSdGdEaXIgcmV2aWV3Og0KPiA+ID4gPiBkcmFmdC1pZXRmLXBhbHMtbXBs cy10cC1wdy1vdmVyLWJpZGlyLWxzcC0wNg0KPiA+ID4gPg0KPiA+ID4gPiBIaSBEYW5pZWxlLA0K PiA+ID4gPg0KPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4g RnJvbTogRGFuaWVsZSBDZWNjYXJlbGxpDQo+ID4gPiA+ID4gW21haWx0bzpkYW5pZWxlLmNlY2Nh cmVsbGlAZXJpY3Nzb24uY29tXQ0KPiA+ID4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDI1LCAy MDE2IDQ6MDggUE0NCj4gPiA+ID4gPiBUbzogTWFjaCBDaGVuOyA8cnRnLWFkc0BpZXRmLm9yZz4g KHJ0Zy1hZHNAaWV0Zi5vcmcpDQo+ID4gPiA+ID4gQ2M6IHJ0Zy1kaXJAaWV0Zi5vcmc7DQo+ID4g PiA+ID4gZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtcHctb3Zlci1iaWRpci1sc3AuYWxsQHRvb2xz LmlldGYub3JnOw0KPiA+ID4gPiA+IHBhbHNAaWV0Zi5vcmcNCj4gPiA+ID4gPiBTdWJqZWN0OiBS RTogUnRnRGlyIHJldmlldzoNCj4gPiA+ID4gPiBkcmFmdC1pZXRmLXBhbHMtbXBscy10cC1wdy1v dmVyLWJpZGlyLWxzcC0wNg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSGkgTWFjaCwNCj4gPiA+ID4g Pg0KPiA+ID4gPiA+IFRoYW5rcyBmb3IgdGhlIHVwZGF0ZS4NCj4gPiA+ID4gPiBUaGVyZSBpcyBq dXN0IG9uZSBvdXRzdGFuZGluZyBwb2ludDoNCj4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g4oCiIFNl Y3Rpb24gMi4xOiDigJxMRFAgTGFiZWwgTWFwcGluZyBtZXNzYWdl4oCdIG1pc3NpbmcgcmVmZXJl bmNlLg0KPiA+ID4gPiA+ID4gQW5kIHdoeSB0aGUgVHlwZSBmaWVsZCBzdGFydHMgd2l0aCAxIGFu ZCAwPw0KPiA+ID4gPiA+IFRoYW5rcyBmb3IgYWRkaW5nIHRoZSByZWZlcmVuY2UgYnV0IEkgc3Rp bGwgZG9uJ3QgZ2V0IHdoeSB0aGUNCj4gPiA+ID4gPiBUeXBlIGZpZWxkIHN0YXJ0cyB3aXRoIDEg YW5kIDAuDQo+ID4gPiA+DQo+ID4gPiA+IFRoZSBmaXJzdCB0d28gYml0cyBhcmUgVS1iaXQgYW5k IEYtYml0LCB3aGljaCBhcmUgZGVmaW5lZCBpbg0KPiA+ID4gPiBTZWN0aW9uDQo+ID4gPiA+IDMu MyBvZiBSRkM1MDM2LiBIb3cgYWJvdXQgYWRkaW5nIHRoZSBmb2xsb3cgdGV4dDoNCj4gPiA+ID4N Cj4gPiA+ID4gRm9yIHRoaXMgVExWLCB0aGUgVW5rbm93biBUTFYgYml0IChVLWJpdCkgKFNlY3Rp b24gMy4zIG9mIFJGQzUwMzYpDQo+ID4gPiA+IGlzIHNldCB0byAxLCBhbmQgdGhlIEZvcndhcmRp bmcgdW5rbm93biBiaXQgKEYtYml0KSAoU2VjdGlvbiAzLjMNCj4gPiA+ID4gb2YNCj4gPiA+ID4g UkZDNTAzNikgaXMNCj4gPiA+IHNldCB0byAwLg0KPiA+ID4gPg0KPiA+ID4gPiA+IE9uZSBtb3Jl IGNvbW1lbnQgdGhhdCBJIGxvc3QgZHVyaW5nIHRoZSBmaXJzdCBpdGVyYXRpb246IHdoeSBkbw0K PiA+ID4gPiA+IHlvdSBkZWZpbmUgdGhlICJmbGFnIiBmaWVsZCBpbiBmaWd1cmUgMyBhbmQgdGhl biBiZWxvdyBoYXZlIGENCj4gPiA+ID4gPiBmdXJ0aGVyIGZpZ3VyZSBzaG93aW5nIEMsIFMsIFQg YW5kIHRoZSBtdXN0IGJlIHplcm8gZmllbGQ/IEknZA0KPiA+ID4gPiA+IGRpcmVjdGx5IHB1dCB0 aGUgQyxTLFQgYW5kIG11c3QgYmUgemVybyBmaWVsZHMgaW4gcGxhY2Ugb2YgdGhlDQo+ID4gPiA+ ID4gRmxhZyBmaWVsZCBpbiBmaWd1cmUgMy4gSXQNCj4gPiA+ID4gaGVscHMgd2l0aCByZWFkYWJp bGl0eSBJTUhPLg0KPiA+ID4gPg0KPiA+ID4gPiBPSywgd2lsbCBwdXQgdGhlbSBiYWNrIHRvIHRo ZSBUTFYgYW5kIHJlbW92ZSB0aGUgZmxhZ3MgZmlndXJlLg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ ID4gPiBIb3BlIGFib3ZlIGFkZHJlc3MgeW91ciBjb21tZW50cyENCj4gPiA+ID4NCj4gPiA+ID4g VGhhbmtzLA0KPiA+ID4gPiBNYWNoDQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEJS DQo+ID4gPiA+ID4gRGFuaWVsZQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+ID4gRnJvbTogTWFjaCBDaGVuIFttYWlsdG86bWFjaC5j aGVuQGh1YXdlaS5jb21dDQo+ID4gPiA+ID4gPiBTZW50OiB2ZW5lcmTDrCAxMyBtYWdnaW8gMjAx NiAwOToyNQ0KPiA+ID4gPiA+ID4gVG86IERhbmllbGUgQ2VjY2FyZWxsaSA8ZGFuaWVsZS5jZWNj YXJlbGxpQGVyaWNzc29uLmNvbT47DQo+ID4gPiA+ID4gPiA8cnRnLWFkc0BpZXRmLm9yZz4NCj4g PiA+ID4gPiA+IChydGctYWRzQGlldGYub3JnKSA8cnRnLWFkc0BpZXRmLm9yZz4NCj4gPiA+ID4g PiA+IENjOiBydGctZGlyQGlldGYub3JnOyBkcmFmdC1pZXRmLXBhbHMtbXBscy10cC1wdy1vdmVy LWJpZGlyLQ0KPiA+ID4gPiA+ID4gbHNwLmFsbEB0b29scy5pZXRmLm9yZzsgcGFsc0BpZXRmLm9y Zw0KPiA+ID4gPiA+ID4gU3ViamVjdDogUkU6IFJ0Z0RpciByZXZpZXc6DQo+ID4gPiA+ID4gPiBk cmFmdC1pZXRmLXBhbHMtbXBscy10cC1wdy1vdmVyLWJpZGlyLWxzcC0wNg0KPiA+ID4gPiA+ID4N Cj4gPiA+ID4gPiA+IEhpIERhbmllbGUsDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gVGhhbmtz IGZvciB0aGUgZGV0YWlsZWQgcmV2aWV3IGFuZCB2YWx1YWJsZSBjb21tZW50cyENCj4gPiA+ID4g PiA+DQo+ID4gPiA+ID4gPiBQbGVhc2Ugc2VlIG15IHJlc3BvbnNlcyBpbmxpbmUuLi4NCj4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPiBJIGFsc28gYXR0YWNoZWQgYSBkaWZmIHRoYXQgc2hvd3MgdGhl IHVwZGF0ZXMgdGhhdCB0cnkgdG8NCj4gPiA+ID4gPiA+IGFkZHJlc3MgeW91ciBjb21tZW50cy4g SWYgeW91IGFyZSBPSyB3aXRoIHRoZSB1cGRhdGVzLCBJIHdpbGwNCj4gPiA+ID4gPiA+IHN1Ym1p dA0KPiA+IGl0IHRoZW4uDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gVGhhbmtzLA0KPiA+ID4g PiA+ID4gTWFjaA0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gRnJvbTogRGFuaWVsZSBDZWNj YXJlbGxpDQo+ID4gPiA+ID4gPiA+IFNlbnQ6IGx1bmVkw6wgMjUgYXByaWxlIDIwMTYgMTk6MDQN Cj4gPiA+ID4gPiA+ID4gVG86IDxydGctYWRzQGlldGYub3JnPiAocnRnLWFkc0BpZXRmLm9yZykN Cj4gPiA+ID4gPiA+ID4gQ2M6ICdydGctZGlyQGlldGYub3JnJzsNCj4gPiA+ID4gPiA+ID4gJ2Ry YWZ0LWlldGYtcGFscy1tcGxzLXRwLXB3LW92ZXItYmlkaXItDQo+ID4gPiA+IGxzcC5hbGxAaWV0 Zi5vcmcnDQo+ID4gPiA+ID4gPiA+IFN1YmplY3Q6IFJ0Z0RpciByZXZpZXc6DQo+ID4gPiA+ID4g PiA+IGRyYWZ0LWlldGYtcGFscy1tcGxzLXRwLXB3LW92ZXItYmlkaXItbHNwLTA2DQo+ID4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPiA+IEhlbGxvLA0KPiA+ID4gPiA+ID4gPiBJIGhhdmUgYmVlbiBz ZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3INCj4gPiA+ID4g PiA+ID4gdGhpcyBkcmFmdC4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3 IGFsbA0KPiA+ID4gPiA+ID4gPiByb3V0aW5nIG9yIHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMg dGhleSBwYXNzIHRocm91Z2ggSUVURg0KPiA+ID4gPiA+ID4gPiBsYXN0IGNhbGwgYW5kIElFU0cg cmV2aWV3LA0KPiA+ID4gPiA+ID4gYW5kIHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVlc3QuDQo+ ID4gPiA+ID4gPiA+IFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Np c3RhbmNlIHRvIHRoZQ0KPiA+ID4gPiA+ID4gPiBSb3V0aW5nDQo+ID4gQURzLg0KPiA+ID4gPiA+ ID4gPiBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwg cGxlYXNlDQo+ID4gPiA+ID4gPiA+IHNlZSBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVh L3J0Zy90cmFjL3dpa2kvUnRnRGlyDQo+ID4gPiA+ID4gPiA+IEFsdGhvdWdoIHRoZXNlIGNvbW1l bnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlDQo+ID4gPiA+ID4gPiA+IFJvdXRp bmcgQURzLCBpdCB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtDQo+ ID4gPiA+ID4gPiA+IGFsb25nIHdpdGggYW55IG90aGVyIElFVEYgTGFzdCBDYWxsIGNvbW1lbnRz IHRoYXQgeW91DQo+ID4gPiA+ID4gPiA+IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0 aGVtIHRocm91Z2ggZGlzY3Vzc2lvbiBvciBieQ0KPiA+ID4gPiA+ID4gPiB1cGRhdGluZyB0aGUN Cj4gPiBkcmFmdC4NCj4gPiA+ID4gPiA+ID4gRG9jdW1lbnQ6wqBkcmFmdC1pZXRmLXBhbHMtbXBs cy10cC1wdy1vdmVyLWJpZGlyLWxzcC0wNg0KPiA+ID4gPiA+ID4gPiBSZXZpZXdlcjogRGFuaWVs ZSBDZWNjYXJlbGxpIFJldmlldyBEYXRlOiBBcHJpbCAyNSAyMDE2IElFVEYNCj4gPiA+ID4gPiA+ ID4gTEMgRW5kIERhdGU6IC0gSW50ZW5kZWQgU3RhdHVzOiBTdGFuZGFyZCBUcmFjaw0KPiA+ID4g PiA+ID4gPiBTdW1tYXJ5Og0KPiA+ID4gPiA+ID4gPiDigKIgSSBoYXZlIHNvbWUgbWlub3IgY29u Y2VybnMgYWJvdXQgdGhpcyBkb2N1bWVudCB0aGF0IEkNCj4gPiA+ID4gPiA+ID4gdGhpbmsgc2hv dWxkIGJlIHJlc29sdmVkIGJlZm9yZSBwdWJsaWNhdGlvbi4NCj4gPiA+ID4gPiA+ID4gQ29tbWVu dHM6DQo+ID4gPiA+ID4gPiA+IOKAoiBXaGF0IHRoZSBkcmFmdHMgaXMgcHJvcG9zaW5nIGFzIHBy b3RvY29sIG1vZGlmaWNhdGlvbiBpcw0KPiA+ID4gPiA+ID4gPiBjbGVhciBhbmQgYWxzbyB0aGUg b3BlcmF0aW9uIHNlY3Rpb24gYXJlIHByZXR0eQ0KPiA+ID4gPiA+ID4gPiBzdHJhaWdoZm9yd2Fy ZC4gV2hhdCBuZWVkcyB0byBiZSBpbXByb3ZlZCBpcyB0aGUNCj4gPiA+ID4gPiA+ID4gaW50cm9k dWN0aW9uIHBhcnQsIHdoaWNoIHNob3VsZCBiZSByZXZpZXdlZCBieSBhIG5hdGl2ZSBFbmdsaXNo DQo+IHNwZWFrZXIuDQo+ID4gPiA+ID4gPiA+IEFsc28gdGhlIElBTkEgc2VjdGlvbiBzaG91bGQg YmUNCj4gPiA+ID4gbWFkZSBjbGVhcmVyLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFRoYW5r cyBmb3IgeW91ciBzdWdnZXN0aW9uLCBJIGFzc3VtZSB0aGUgUkZDIGVkaXRvciB3aWxsIGRvDQo+ ID4gPiA+ID4gPiBhbm90aGVyIHJldmlldyBvbmNlIHRoZSBkb2N1bWVudCBwcm9ncmVzc2VkIHRv IHRoYXQgc3RhZ2UuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBNYWpvciBJc3N1ZXM6DQo+ ID4gPiA+ID4gPiA+IOKAoiBObyBtYWpvciBpc3N1ZXMgZm91bmQNCj4gPiA+ID4gPiA+ID4gTWlu b3IgSXNzdWVzOg0KPiA+ID4gPiA+ID4gPiDigKIgQWJzdHJhY3Q6IOKAnEluIGFkZGl0aW9uLCB0 aGUgdXNlciB0cmFmZmljIG1heSB0cmF2ZXJzZQ0KPiA+ID4gPiA+ID4gPiB0aHJvdWdoIG11bHRp cGxlIHRyYW5zcG9ydCBuZXR3b3Jrcy7igJ0gTWF5YmUgaXMgd29ydGgNCj4gPiA+ID4gPiA+ID4g ZWxhYm9yYXRpbmcgYSBiaXQgdGhpcyBzZW50ZW5jZSBzYXlpbmcgdGhhdCB0aGUgZXh0ZW5zaW9u cw0KPiA+ID4gPiA+ID4gPiBkZWZpbmVkIGluIHRoaXMgZHJhZnQgYXBwbHkgYm90aCB0byBTUy0N Cj4gPiA+ID4gPiA+IFBXIGFuZCBNUy1QVy4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBIb3cg YWJvdXQgdGhpczoNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiAiTWFueSB0cmFuc3BvcnQgc2Vy dmljZXMgcmVxdWlyZSB0aGF0IHVzZXIgdHJhZmZpYywgaW4gdGhlDQo+ID4gPiA+ID4gPiBmb3Jt IG9mIFBzZXVkb3dpcmVzIChQVyksIGJlIGRlbGl2ZXJlZCBvbiBhIHNpbmdsZSBjby1yb3V0ZWQN Cj4gPiA+ID4gPiA+IGJpZGlyZWN0aW9uYWwgdHVubmVsIG9yIHR3byB0dW5uZWxzIHRoYXQgc2hh cmUgdGhlIHNhbWUgcm91dGVzLg0KPiA+ID4gPiA+ID4gVGhpcyBkb2N1bWVudCBkZWZpbmVzIGFu IG9wdGlvbmFsIGV4dGVuc2lvbiB0byBMRFAgdGhhdA0KPiA+ID4gPiA+ID4gZW5hYmxlcyB0aGUg YmluZGluZyBiZXR3ZWVuIFBXcyBhbmQgdGhlIHVuZGVybHlpbmcgVEUgdHVubmVscy4NCj4gPiA+ ID4gPiA+IFRoZSBleHRlbnNpb24gYXBwbGllcyB0byBib3RoIFNTLVBXIGFuZA0KPiA+ID4gPiA+ IE1TLVBXLiINCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IOKAoiBJbiB0aGUgYWJzdHJhY3Qg aXQgaXMgc2FpZCB0aGF0IGEgUFcgaXMgbGlua2VkIHRvIGFuIExTUA0KPiA+ID4gPiA+ID4gPiBi dXQgdGhlbiBpbiB0aGUgaW50cm8gaXQgaXMgc2FpZCB0aGF0IHRoZSBQVyBiaW5kaW5nIGlzIHRv IGEgdHVubmVsLg0KPiA+ID4gPiA+ID4gPiBDYW4geW91IGNsYXJpZnkgdGhpcz8gSeKAmWQgc2F5 IHRoYXQgaXQgc2hvdWxkIGJlIGxpbmtlZCB0byBhIHR1bm5lbCwNCj4gcmlnaHQ/DQo+ID4gPiA+ ID4gPg0KPiA+ID4gPiA+ID4gWWVzLCBpdCdzIGJldHRlciB0byB1c2UgdHVubmVsLCBJIGhhdmUg dXBkYXRlZCB0aGUgYWJzdHJhY3QgdG8NCj4gPiA+ID4gPiA+IG1ha2UgQWJzdHJhY3QgYW5kIElu dHJvZHVjdGlvbiBoYXZlIHRoZSBjb25zaXN0ZW50IHVzYWdlLg0KPiA+ID4gPiA+ID4gUGxlYXNl IHNlZSBhYm92ZSB0aGUgbmV3IHRleHQgZm9yIEFic3RyYWN0Lg0KPiA+ID4gPiA+ID4NCj4gPiA+ ID4gPiA+ID4g4oCiIEludHJvOsKgwqAg4oCcUFctdG8tUFNOIFR1bm5lbCBiaW5kaW5nIGhhcyBi ZWNvbWUgaW5jcmVhc2luZ2x5DQo+ID4gPiA+ID4gPiA+IGNvbW1vbiBhbmQgaW1wb3J0YW50IGlu IG1hbnkgZGVwbG95bWVudCBzY2VuYXJpb3PigJ0uIEkgZ3Vlc3MNCj4gPiA+ID4gPiA+ID4geW91 IG1lYW4gYW4gYXV0b21hdGljIGJpbmRpbmcgZG9uZSB2aWEgYSBzaWduYWxpbmcgcHJvdG9jb2w/ DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gTm8sIHRoaXMgc2VudGVuY2UganVzdCBicmluZ3Mg dGhlIHJlcXVpcmVtZW50cyBvZiBleHBsaWNpdCBQVw0KPiA+ID4gPiA+ID4gdG8gUFNOIHR1bm5l bCBiaW5kaW5nLCB3aGF0ZXZlciBpdCBpcyBhdXRvbWF0aWMgc2lnbmFsaW5nIG9yDQo+ID4gPiA+ ID4gPiBtYW51YWwNCj4gPiA+IGNvbmZpZ3VyYXRpb24uDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ ID4gPiDigKIgV2hhdCBkbyB5b3UgbWVhbiB3aXRoIOKAnG1heSB0cmF2ZXJzZSB0aHJvdWdoIGRp ZmZlcmVudCByb3V0ZXPigJ0/DQo+ID4gPiA+ID4gPiA+IEkgc3VnZ2VzdCBsZWF2aW5nIOKAnG1h eSB0cmF2ZXJzZSBtdWx0aXBsZSBuZXR3b3JrcyBvciBkb21haW5zLg0KPiA+ID4gPiA+ID4NCj4g PiA+ID4gPiA+IEhlcmUgdGhlICJyb3V0ZXMiIG1lYW5zICJwYXRocyIuDQo+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gSG93IGFib3V0OiAiLi4ubWF5IHRyYXZlcnNlIHRocm91Z2ggZGlmZmVyZW50 IHBhdGhzIG9yIG5ldHdvcmtzIj8NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IOKAoiBJbnRy byBhbmQgRmlndXJlIDE6IGNvdWxkIGJlIGV4YW1wbGUgYmUgbWFkZSBhIGJpdCBtb3JlDQo+ID4g PiA+ID4gPiA+IGdlbmVyaWMgd2l0aCBhIG5ldHdvcmsgYmV0d2VlbiB0aGUgUEVzPyBXaXRoIGRp cmVjdGx5DQo+ID4gPiA+ID4gPiA+IGNvbm5lY3RlZCBQRXMgaXQgZG9lc27igJl0IHNlZW0gYSBy ZWFsaXN0aWMgYW5kIGdlbmVyaWMgZW5vdWdoDQo+ID4gZXhhbXBsZS4NCj4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiDigKIgSW50cm86IHN1Z2dlc3QgcmVtb3Zpbmcg4oCc QXMgbWVudGlvbmVkIGFib3Zl4oCdLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IE9LLg0KPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4g4oCiIMKgVGhlIG5hbWUgb2YgdGhlIGRyYWZ0IGV4cGxp Y2l0bHkgbWVudGlvbnMgTVBMUy1UUCBidXQgaW4NCj4gPiA+ID4gPiA+ID4gdGhlIHJlc3Qgb2Yg dGhlIGRyYWZ0IHRoZXJlIGlzIG5vIG1lbnRpb24gb2YgaXQsIGp1c3QgdGhlDQo+ID4gPiA+ID4g PiA+IG11Y2ggbW9yZSBnZW5lcmFsIFBhY2tldCBTd2l0Y2hpbmcgTmV0d29yayB0ZXJtIGlzIHVz ZWQuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gSW5kZWVkLCB0aGF0J3MgdGhlIGludGVudGlv bi4gVGhpcyB3b3JrIHdhcyB0cmlnZ2VyZWQgYnkgdGhlDQo+ID4gPiA+ID4gPiBkaXNjdXNzaW9u IG9mIE1QTFMtVFAuIEJ1dCB3aXRoIHRoZSBwcm9ncmVzcyBvZiB0aGlzIGRyYWZ0IGFuZA0KPiA+ ID4gPiA+ID4gZGlzY3Vzc2lvbiB3aXRoaW4gdGhlIFdHLCB0aGVyZSBpcyBhIGNvbnNlbnN1cyB0 aGF0IHRoaXMNCj4gPiA+ID4gPiA+IHRlY2huaXF1ZSBpcyBhIGdlbmVyYWwgc29sdXRpb24gdGhh dCBjYW4gYWN0dWFsbHkgYXBwbHkgdG8NCj4gPiA+ID4gPiA+IGJvdGggVFAgYW5kDQo+ID4gbm9u LVRQIGNhc2VzLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4g4oCiIFNlY3Rpb24gMjrCoMKg IOKAnFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5ldyBvcHRpb25hbCBUTFYsDQo+ID4gPiA+ID4g PiA+IFBTTiBUdW5uZWwgQmluZGluZyBUTFYsIHRvIGNvbW11bmljYXRlIHR1bm5lbC9MU1BzIHNl bGVjdGlvbg0KPiA+ID4gPiA+ID4gPiBhbmQgYmluZGluZyByZXF1ZXN0cw0KPiA+ID4gPiA+ID4g YmV0d2VlbiBQRXMuDQo+ID4gPiA+ID4gPiA+IOKAnCBUaGUgYmluZGluZyByZXF1ZXN0IGlzIGJl dHdlZW4gUEVzPyBPciBiZXR3ZWVuIGFuIFBXIGFuZCBhDQo+ID4gPiA+ID4gPiA+IFR1bm5lbCAo b3IgTFNQPykgYmV0d2VlbiB0d28gUEVzPw0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEJldHdl ZW4gUEVzIG9mIGFuIFBXLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4g4oCiIFNlY3Rpb24g MjogU3RyaWN0IGJpbmRpbmcgdnMgQ28tcm91dGVkIGJpbmRpbmc6IGZyb20gdGhlDQo+ID4gPiA+ ID4gPiA+IGRlc2NyaXB0aW9uIGl0IHNlZW1zIHRoYXQgdGhlIGZpcnN0IG9uZSBpcyBzdHJpY3Qg YW5kIHRoZQ0KPiA+ID4gPiA+ID4gPiBzZWNvbmQgb25lIGlzDQo+ID4gPiA+ID4g4oCcbG9vc2Xi gJ0NCj4gPiA+ID4gPiA+ID4gKGluIHRoZSBzZW5zZSB0aGF0IHRoZSBQRSBjYW4gYWNjZXB0IHRo ZSByZXF1ZXN0IG9yIG5vdCkuDQo+ID4gPiA+ID4gPiA+IERvbuKAmXQgYm90aCBhcHBseQ0KPiA+ ID4gPiA+ID4gdG8gY28tcm91dGVkIExTUHM/DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gWWVz LCBib3RoIGNhbiBhcHBseSB0byBjby1yb3V0ZWQgTFNQcy4gQnV0IGZvciAic3RyaWN0IiBtb2Rl LA0KPiA+ID4gPiA+ID4gaWYgdGhlIGVncmVzcyBQRSBtdXN0IGJpbmQgdG8gdGhlIHNwZWNpZmll ZCB0dW5uZWwgYnkgdGhlDQo+ID4gPiA+ID4gPiBpbmdyZXNzIFBFLCBvdGhlcndpc2UsIHRoZSBi aW5kaW5nIHdpbGwgbm90IHN1Y2Nlc3MuIFRoZSAiY28tcm91dGVkIg0KPiA+ID4gPiA+ID4gbW9k ZSBnaXZlcyB0aGUgZWdyZXNzIFBFIHRoZSB1c2UgYWx0ZXJuYXRpdmUgdHVubmVsLg0KPiA+ID4g PiA+ID4NCj4gPiA+ID4gPiA+ID4g4oCiIFNlY3Rpb24gMjog4oCdVGhlIHRlcm1pbm9sb2d5ICJM U1AiIGlzwqAgaWRlbnRpY2FsIHRvIHRoZSAiTFNQIHR1bm5lbCINCj4gPiA+ID4gPiA+ID4gZGVm aW5lZCBpbiBTZWN0aW9uIDIuMSBvZiBbUkZDMzIwOV0swqAgd2hpY2ggaXMgdW5pcXVlbHkNCj4g PiA+ID4gPiA+ID4gaWRlbnRpZmllZCBieSB0aGUgU0VTU0lPTiBvYmplY3QgdG9nZXRoZXIgd2l0 aA0KPiA+ID4gPiA+ID4gPiBTRU5ERVJfVEVNUExBVEUgKG9yDQo+ID4gPiA+ID4gPiA+IEZJTFRF Ul9TUEVDKSBvYmplY3QgdGhhdCBjb25zaXN0cyBvZiBMU1AgSUQgYW5kIFR1bm5lbA0KPiA+ID4g PiA+ID4gPiBlbmRwb2ludCBhZGRyZXNzLuKAnSBXaHkgaXMgdGhlIGRyYWZ0IGNvbnNpZGVyaW5n IG9ubHkgc2lnbmFsZWQgTFNQcz8NCj4gPiA+ID4gPiA+ID4gRG9lc27igJl0IGl0IGFwcGx5IGFs c28gdG8gY2VudHJhbGx5DQo+ID4gPiA+ID4gPiBwcm92aXNpb25lZCBvbmVzPyAoZS5nLiBOTVMg b3IgU0ROKS4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBUaGUgbWFpbiBwdXJwb3NlIGhlcmUg aXMgdG8gZ2l2ZSBhIHJlZmVyZW5jZSB0byB0aGUgdGVybSBvZiAiTFNQIg0KPiA+ID4gPiA+ID4g YW5kICJ0dW5uZWwiLCBoZW5jZSB0byBlbGltaW5hdGUgdGhlIGNvbmZ1c2lvbiBvZiB3aGVuIHVz ZQ0KPiA+ID4gPiA+ID4gdGhlc2UgaW4gdGhlIGZvbGxvd2luZyBzZWN0aW9ucy4gQXMgZm9yIHRo ZSBOTVMgYW5kIFNETiBiYXNlZA0KPiA+ID4gPiA+ID4gVEUgTFNQL1R1bm5lbCwgdGVjaG5pY2Fs bHksIGl0IGNhbiBhcHBseSB0byBhcyB3ZWxsIG9ubHkgaWYNCj4gPiA+ID4gPiA+IHRoZSBURSBM U1AvVHVubmVsIGhhcyB0aGUgTFNQIG51bWJlciwgbm9kZSBJRCBldGMuIGluZm9ybWF0aW9uLg0K PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4g4oCiIFNlY3Rpb24gMi4xOiDigJxMRFAgTGFiZWwg TWFwcGluZyBtZXNzYWdl4oCdIG1pc3NpbmcgcmVmZXJlbmNlLg0KPiA+ID4gPiA+ID4gPiBBbmQg d2h5IHRoZSBUeXBlIGZpZWxkIHN0YXJ0cyB3aXRoIDEgYW5kIDA/DQo+ID4gPiA+ID4gPg0KPiA+ ID4gPiA+ID4gR29vZCBjYXRjaCwgd2lsbCBhZGQgYSByZWZlcmVuY2UgaGVyZS4NCj4gPiA+ID4g PiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBOaXRzOg0KPiA+ID4gPiA+ID4gPiDigKIg QWJzdHJhY3Qgcy8gdHJhdmVyc2UgdGhyb3VnaCBtdWx0aXBsZS8gdHJhdmVyc2UgbXVsdGlwbGUg 4oCiDQo+ID4gPiA+IEludHJvZHVjdGlvbjoNCj4gPiA+ID4gPiA+ID4g4oCcUHNldWRvd2lyZSAo UFcpIEVtdWxhdGlvbiBFZGdlLXRvLUVkZ2UgKFBXRTMp4oCdLiBJIHN1Z2dlc3QNCj4gPiA+ID4g PiA+ID4gcmVtb3ZpbmcgKFBXKSwgaXTigJlzIGFscmVhZHkgaW5jbHVkZWQgaW50byBQV0UzLg0K PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IE9LLg0KPiA+ID4gPiA+ID4gPiDigKIgSW50cm86IHMv IGEgYmlkaXJlY3Rpb25hbCBjaXJjdWl0cy8gYSBiaWRpcmVjdGlvbmFsDQo+ID4gPiA+ID4gPiA+ IGNpcmN1aXQNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBPSy4NCj4gPiA+ID4gPiA+DQo+ID4g PiA+ID4gPiDigKIgSW50cm86IHN1Z2dlc3QNCj4gPiA+ID4gPiA+ID4gcmVwaHJhc2luZzog4oCc QmlkaXJlY3Rpb25hbCBMU1BzIHNoYXJlIGZhdGUgYW5kIHNpbXBsaWZ5IHRoZQ0KPiA+ID4gPiA+ ID4gPiByb3V0aW5nIG9mIGEgcHJvdGVjdGlvbiBwYXRoIGFsc28gY29uc2lzdGluZyBvZg0KPiA+ ID4gPiA+ID4gPiBiaWRpcmVjdGlvbmFsIExTUHMgYmVjYXVzZSB3b3JraW5nIGFuZCBwcm90ZWN0 aW9uIHBhdGhzIGhhdmUgdG8gYmUNCj4gZGlzam9pbnQu4oCdDQo+ID4gPiA+ID4gPg0KPiA+ID4g PiA+ID4gT0suDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiDigKIgSW50cm86IHMvIHRoZXJl IGFyZSBhIGxhcmdlIG51bWJlci8gdGhlcmUgaXMgYSBsYXJnZQ0KPiA+ID4gPiA+ID4gPiBudW1i ZXINCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBPSy4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4g PiDigKIgSW50cm86cy90byBiZQ0KPiA+ID4gPiA+ID4gPiBjYXJyaWVkL2FyZSBjYXJyaWVkDQo+ ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gT0suDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g4oCi IEludHJvOnMvdGhlcmUgYXJlIGEgbnVtYmVyL3RoZXJlIGlzIGEgbnVtYmVyDQo+ID4gPiA+ID4g Pg0KPiA+ID4gPiA+ID4gT0suDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4g4oCiIEludHJvOiBz Lw0KPiA+ID4gPiA+ID4gPiB0cmFmZmljIGJlbG9uZ3MvdHJhZmZpYyBiZWxvbmdpbmcNCj4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPiBPSy4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiDigKIgSW50 cm86IChzdWdnZXN0aW9uKSBzLyhQRTEtUDMtUEUyKS8NCj4gPiA+ID4gPiA+ID4gKFBFMi1QMy1Q RTEpIHNpbmNlIHdlIGFyZSBzcGVha2luZyBhYm91dCBkaXJlY3Rpb25hbGl0eSBpdA0KPiA+ID4g PiA+ID4gPiBtYWtlcyBtb3JlIHNlbnNlIHRvIGxpc3QgdGhlIG5vZGVzIG9mIHRoZSBwYXRoIGlu IHRoZQ0KPiA+ID4gPiA+ID4gPiByZXZlcnNlDQo+ID4gZGlyZWN0aW9uLg0KPiA+ID4gPiA+ID4N Cj4gPiA+ID4gPiA+IE9LLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4g4oCiIEludHJvOiBz LyBUaGUgc2ltaWxhciBwcm9ibGVtcy9BIHNpbWlsYXIgcHJvYmxlbQ0KPiA+ID4gPiA+ID4NCj4g PiA+ID4gPiA+IE9LLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID7igKIgSW50cm86IHMvIHdv bid0L2RvZXMgbm90DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gT0suDQo+ID4gPiA+ID4gPiA+ 4oCiSW50cm86IHMvIEluIHRoaXMgZG9jdW1lbnQsIGl0IGludHJvZHVjZXMvVGhpcyBkb2N1bWVu dA0KPiA+ID4gPiA+ID4gPmludHJvZHVjZXMgQlIgRGFuaWVsZQ0KPiA+ID4gPiA+ID4NCj4gPiA+ ID4gPiA+IE9LLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4NCg0K From nobody Thu May 26 04:29:45 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2E712DA6B for ; Thu, 26 May 2016 04:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mojatatu-com.20150623.gappssmtp.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 bAqzasKglP5Q for ; Thu, 26 May 2016 04:29:40 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (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 B226A12DDE1 for ; Thu, 26 May 2016 04:29:33 -0700 (PDT) Received: by mail-qg0-x231.google.com with SMTP id f92so35803702qgf.0 for ; Thu, 26 May 2016 04:29:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mojatatu-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sOxpiXzLdbM0EALfWR5zJ1ttB00y6mmH1CoTQ1Zc0lY=; b=yjb8dmPTitX6VYcHpuYzHogQIuxAFCeF03fQLUr/JN7HcI4JfAubAGxjovdVCdY2xP nBdKijtyBp9eNTHH+PNnI2b6TdE0NZffROEIIfV7CH0YyJFWNt+X04q3VyvRDFp1+LBH nc5IAqco7iyAuS+CJ6agk8kLjzohN2MLzxyOPwIzzTfcGlrz+fH8YpY/Z/sZCO7KxjXU zN3EBUDcpKdcq3xMzFkIq7xCXyE5ijBLVKmuMK55nALXzfk8AcaCk8u59+TYLQ79RTWK 4KCESYl5Ia1iHA2i4bQpoUFsXgnnesY+OWieq4eNnPjPzIIjnPDcyNnJWWaHxbLKYPTy O2RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sOxpiXzLdbM0EALfWR5zJ1ttB00y6mmH1CoTQ1Zc0lY=; b=D2nipLsce7Mr9Y2wViYDGTOMbSPClYm/fyvvcMcPHVqiTDcOitmluTiHXqkGmuA/ih SsZ2w0wA4iZifnI6DMBNnh0EdqbCeMgWc2lvCrrFfO3W2/BjFHr1zQZtiLMJ0IW0IPvH ZgIuPGaru7yg5QDII4OY1u+Y2Ls09FK85FQw5T1FdT1myBFrhQryUXRq2Zd+OVMxddxz GehfEn6kAGtbx5vU/HnfPFBtYZFkPwWSXK+RMRBiaqhBNm81nmrGKnk40aV18N48pw3l hjsuKlr8MwdaXb37zCWeMbQ6zEA1k5W51DQ9qN4TKSOVVLAQu4PzFeszuSWObTjBVXpT fyrg== X-Gm-Message-State: ALyK8tJUyubYqV9DVPoqG89tdXt5xTWk49/KMNd+aCtPwxqk5A64rQ9N8fPPH3llr+n6CQ1+ctvZ6hqXNfVs0g== X-Received: by 10.140.166.3 with SMTP id m3mr8417600qhm.100.1464262172615; Thu, 26 May 2016 04:29:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.46.195 with HTTP; Thu, 26 May 2016 04:29:12 -0700 (PDT) In-Reply-To: <01b401d1b693$fb411810$f1c34830$@ndzh.com> References: <01b401d1b693$fb411810$f1c34830$@ndzh.com> From: Jamal Hadi Salim Date: Thu, 26 May 2016 07:29:12 -0400 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=001a11393f74a85bb20533bd1a18 Archived-At: Cc: "rtg-dir@ietf.org" , zhang.xian@huawei.com, "Joachimpillai, Damascene M" , "" , draft-ietf-forces-interfelfb@tools.ietf.org, Jonathan Hardwick , "forces@ietf.org" , Jon Hudson Subject: Re: [RTG-DIR] RTG-DIR review of ForCES Inter-FE LFB (draft-ietf-forces-interfelfb-04.txt) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 11:29:42 -0000 --001a11393f74a85bb20533bd1a18 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Sue, Appreciate the review. All your suggested changes will be reflected in version 5 (which i hope we will get out by worst case the weekend). cheers, jamal On Wed, May 25, 2016 at 10:44 AM, Susan Hares wrote: > Hello: > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or 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, plea= se > see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF Las= t > Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-forces-interfelfb-04.txt > > Reviewer: Susan Hares > > Date: 5/25/2016 > > IETF End Date: unknown > > Intended Status: Standards track > > > > Summary: This document is basically ready for publication, but has nits > that should be considered before publication. > > > > Comments: > > =C2=B7 Document contains good technical content for extending the > Forces work into an Inter-FE LFB. The document is easily read, but a fe= w > nits would improve its readability. > > =C2=B7 My hand check of the inter-FE LFB XML model indicated all = XML > is fine. If an automated check of the XML with the Forces LFBs, it would > be useful to run this check. > > =C2=B7 The improvement in the congestion consideration section (5= .1.3) > between -03 and -04 was necessary. > > > > Major issues: none > > > > Nits: > > Page 9 figure 5. =E2=80=93 the between figure lines is not aligned. > > This line begins with the =E2=80=9CEthernet Frame with:=E2=80=9D > > > > Page 12 =E2=80=93 > > Old > > /(XXX: note to editor/ > > New /(XXX: note to RFC editor/ > > > > Page 15 > > Old /original payload i.e. skips the IFE header information./ > > New /original payload (i.e. skips the IFE header information)/ > > > > Page 21 > > > > Old > > /This memo includes one IANA requests within the registry > https://www.iana.org/assignments/forces/ > > > > New > > /This memo includes one IANA request within the registry > https://www.iana.org/assignments/forces. / > > > > p. 22 > > Old /As such, it has no impact on their security considerations./ > > New/ As such, it has no impact on these documents security considerations= ./ > > > > Sue Hares > > > > > --001a11393f74a85bb20533bd1a18 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Sue,

Appreciate the review. All your suggested changes will be refl= ected in
version 5 (which i hope we will ge= t out by worst case the weekend).

cheers,
jamal

On Wed, May 25, 2016 at 10:44 AM, Susan Hares <shares@nd= zh.com> wrote:

Hello: <= u>

I have been selected as the Routing Directorate reviewer f= or this draft. The Routing Directorate seeks to review all routing or routi= ng-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 assis= tance to the Routing ADs. For more information about the Routing Directorat= e, please see=C2=A0=E2=80=8Bhttp= ://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing A= Ds, it would be helpful if you could consider them along with any other IET= F Last Call comments that you receive, and strive to resolve them through d= iscussion or by updating the draft.

Document: draft-ietf-forces-interfelfb-04.txt

Reviewer: Susan Hares

Date: 5/25/2016

IETF End Date= : unknown

Intended Status: Standar= ds track

=C2=A0

Summary: This document is basically ready for publicat= ion, but has nits that should be considered before publication. <= /u>

=C2=A0

Comments:

= =C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Docu= ment contains good technical content for extending the Forces work into an = Inter-FE LFB. =C2=A0=C2=A0The document is easily read, but a few nits would= improve its readability.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = My hand check of the inter-FE LFB XML model indicated all XML is fin= e.=C2=A0 If an automated check of the XML with the Forces LFBs, it would be= useful to run this check.=C2=A0

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The improvement in the congestion consideration section (5.1= .3) between -03 and -04 was necessary.=C2=A0

= =C2=A0

Major issues: none

=C2=A0

Nit= s:

Page 9=C2=A0 figure 5. =E2=80= =93 the between figure lines is not aligned.

This line begins with the =E2=80=9CEthernet Frame with:=E2=80=9D=

=C2=A0

Page 12 =E2=80=93

O= ld

/(XXX: note to editor/=

New /(XXX: note to RFC editor/=

=C2=A0

P= age 15

Old /original payload i.e. = skips the IFE header information./

= New /original payload (i.e. skips the IFE header information)/

=C2=A0

= Page 21

=C2=A0

Old

/This memo= includes one IANA requests within the registry https://www.iana.org/assignment= s/forces/

=C2=A0<= /p>

New

/This= memo includes one IANA request within the registry https://www.iana.org/assignm= ents/forces. /

=C2=A0=

p. 22

Old /As such, it has no impact on their security considerations./=

New/ As such, it has no impact on these d= ocuments security considerations./

= =C2=A0

Sue Hares

=

=C2=A0

=C2=A0


--001a11393f74a85bb20533bd1a18-- From nobody Thu May 26 16:42:06 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5FF12D587; Thu, 26 May 2016 16:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 m3P-0F3fg4l1; Thu, 26 May 2016 16:42:02 -0700 (PDT) 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 8334A12D1D9; Thu, 26 May 2016 16:42:02 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id b65so149259946oia.1; Thu, 26 May 2016 16:42:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2I9VEITJVOHBhindcDYq2KJxGuJUoJX+PkMaG+aX8mY=; b=GdhrLVwSkg0TxfCPjU8mofs24RXUr7dS8NV+ns0QwD8yrXeAltAZCoy2VNdWV1pkyR svaGfRf23EfD3GaTds5PJnHf7e7de0/ZnYZyNAP0BUeQQt/61jcYWrkqylHDfMRvducr OA0ipBYfSVT52ifdbOSL4TQU0W2QtLmEL0Oz44kgj6UYqViGo98uBqr7YtoweksjjO87 LrQm9oZQkOwUWtbAJDGPbYee40veD2ihnf0qJxftaQuVZItoHxC1B8J/s2f/H1tjIf7Z etP3vGV5VYJTRsdUWXszax7bwpooNA4v6C5UDjrE6618+zF7sJ+Am/HBsHiEXZz5mIx/ g1jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2I9VEITJVOHBhindcDYq2KJxGuJUoJX+PkMaG+aX8mY=; b=LAAFoAdM10MgMfgbUvl0CHRD860UDfI9CMwhe/tEZGSrIl1duAi3haNuiNvQfe3mJp FnADveeuDP3lTfOsnXZAwhhc2yWD25MuX/RZqAAbkEvmA6hvuQLZ2zyB/nkLvTswj3ky 9DCXc2F59Q7r/idjroM9ur0w9K2O/IL56TBsH8a8k1KVYbawMoSqdUuJyWYQjV8vQyeo O9s7/+w5Sn6rcwbMvw/N/cM1kK9c5rGCT2tsSVkPIG7XMZMMV7pTM1YVFQzZuCpm4xV7 9JMe1T61ztHmcGlJhx9Ratbjp8YXViRnJ0Vkmj8jonRjAiHBPfHZCCnacBYatn0hBs7E BtOQ== X-Gm-Message-State: ALyK8tKXrWFF3i0VdqwZxMx5L6LrjNB3t+BWtZGxoD+p0a7cOQ1DYNqAOmHlqMQP162f0oBt8FQ4jPE9CICEcw== X-Received: by 10.202.192.196 with SMTP id q187mr8010018oif.126.1464306121684; Thu, 26 May 2016 16:42:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.249 with HTTP; Thu, 26 May 2016 16:41:46 -0700 (PDT) In-Reply-To: References: <4552F0907735844E9204A62BBDD325E787CB087E@NKGEML515-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E787CB7589@NKGEML515-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E787CB9054@NKGEML515-MBS.china.huawei.com> From: Donald Eastlake Date: Thu, 26 May 2016 19:41:46 -0400 Message-ID: To: Alexander Vainshtein Content-Type: multipart/alternative; boundary=001a113dcfd839bce40533c756ca Archived-At: Cc: "rtg-dir@ietf.org" , "Zhangxian \(Xian\)" , Mingui Zhang , "trill@ietf.org" , Jonathan Hardwick , "draft-ietf-trill-multilevel-single-nickname@ietf.org" , Susan Hares , "jon.hudson@gmail.com" Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 23:42:06 -0000 --001a113dcfd839bce40533c756ca Content-Type: text/plain; charset=UTF-8 Hi Sasha, On Thu, May 26, 2016 at 2:08 AM, Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> wrote: > Donald, > Lots of thanks for a very detailed response! > > Lots of thanks for very important information about the actual and > expected scale of TRILL deployments as well as for presenting some of the > factors (line active-active TRILL operation) that affect the consumption of > the nickname space. It addresses my question about the reason to go for > multi-level IS-IS at all. Flat IGP configuration (both IS-IS and OSPF) are > very popular in IP/MPLS deployments due to LDP (and, now, IP/LDP FRR > techniques), so this information was important to me in order to understand > that *the multi-level TRILL drafts solve a real problem*. I would suggest > adding this information to the multi-level TRILL draft. > Sounds reasonable. Something like that can be added to draft-ietf-trill-rbridge-multilevel. > However, I am still not sure if* the Single Nickname draft* (one I have > been reviewing) represents an attempt *to solve a real problem*. My > understanding so far has been that it follows the Aggregate Nicknames > approach in the multi-level TRILL draft, but *eliminates the need to > assign nicknames to L1 areas*. I do not see if, even with the scale you > have mentioned) this could be a serious issue (e.g., contribute > significantly to depletion of the nickname space). Do I miss something > here? > I'm not sure it matters. If you believe that there is a good reason for aggregated nicknames, this draft is the only aggregated nickname draft that is current active and the only such draft that has been adopted by the TRILL WG. So unless there is some problem with its approach, it seems to me that it should be progressed. > The swapping vs. re-write issue I have discussed with Mingui is a pure > case of terminology. AsI have said, I consider it as closed. > > As for the metadata issue - I am perfectly ready to follow the guidance > of ADs and WG chairs. especially since this policy has recently undergone > serious changes. > > Two additional questions - for the sake of my curiosity: > > 1. Can possibly you explain what has happened to draft that proposed > using BGP with TRILL? > > If you give me a pointer to the specific expired draft, I might remember something about its history. By the way, there is currently a draft in IDR: draft-idr-ietf-ls-trill. > > 1. Did anybody consider combining IPFRR techniques with TRILL > > While I don't recall any specific mention of it, I don't see that any change would be required to existing TRILL standards. Fast ReRoute would run off the existing link state databases. Actually, the above applies only to unicast data. TRILL uses distribution trees for multi-destination data and there is draft-ietf-trill-resilient-trees which provides back-up distribution trees sort of like FRR provides back-up paths. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Regards, and lots of thanks in advance, > Sasha > > > > ________________________________________ > From: Donald Eastlake > Sent: Thursday, May 26, 2016 12:03 AM > To: Alexander Vainshtein > Cc: Mingui Zhang; Zhangxian (Xian); trill@ietf.org; > draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares; > jon.hudson@gmail.com; Jonathan Hardwick; rtg-dir@ietf.org > > Subject: Re: [RTG-DIR] RTG-DIR QA review for > draft-ietf-trill-multilevel-single-nickname > > Hi Alexander, > > Thanks from me also for your review. I'd like to chime in with a few > thoughts: > > On Wed, May 25, 2016 at 8:23 AM, Alexander Vainshtein > wrote: > > > > Hi Mingui, > > I will try to summarize our agreements and disagreements. > > > > 1. The scale of TRILL deployments: > > > > a. I have not seen any specific numbers or references to any > > specific topologies that could really make single-level TRILL not > > scalable enough - neither in the TRILL drafts I've read nor in our > > discussions so far > > I am puzzled as to why you think there would be some specific numeric > hard boundary, other than number space or memory space exhaustion, > beyond which you cannot scale. Can you point to a documentation of > such a thing for IP use of IS-IS? Surely it depends on how much > computer power the routers have, link stability, and numerous other > factors. > > Just looking at convergence time and approximating it as the amount of > computation required at a typical router in the TRILL campus, it is on > the order of N*(log N) for computation of least cost routes where > there are N routers in a single level campus while it is on the order > of (sqrt N)*(log N) for multi-level, in both cases assuming optimized > calculations. The largest TRILL campuses I am aware of are on the > order of 3,000 routers. So one would expect that converting such a > campus to multi-level TRILL would reduce convergence time by > approximately a factor of 50. Furthermore, one would expect the rate > of failures within each Level 1 area in the multi-level case to be > approximately proportional to the number of links/routers and thus > also fall by one and a half orders of magnitude. Do you claim these > improvements would never be valuable? > > There are many other scaling factors such as the size of the link > state database, etc. I believe the informational > draft-ietf-trill-rbridge-multi-level gives a good summary. > > > b. Regarding your reference to multiple interconnected TRILL-based > > campuses in your last email: I do not think that TRILL is an > > alternative to or competes with Internet. > > I agree that TRILL does not compete with the Internet. :-) > > I believe this facet of the discussion was in connection with the > possibility of TRILL nickname space exhaustion. Consider the following > factors: > > 1) TRILL supports active-active connection of end stations at the > TRILL edge. Using the techniques in RFC 7781 (Pseudo-Nickname for > Active-Active Access) consumes TRILL nicknames for active-active edge > groups. > > 2) Assuming, for the moment, you are using multi-level with unique > nicknames, the nickname allocation mechanism will waste many nicknames > due to hierarchical assignment, the same way power-of-two sized IP > subnets waste IP addresses. > > 3) There is a desire to interconnect TRILL campuses that are under > joint or cooperative management with limited control plane coupling so > as to limit error propagation, etc. There are various possible ways to > do this but most of them assume non-conflicting nicknames (or > non-conflicting level 2 nicknames if the campuses are multi-level). > > I admit that even taking the largest existing TRILL campuses I know > about and adding extensive active-active end station support at the > edge and multi-level with unique nicknames that are hierarchically > allocated, you would still probably not exhaust the TRILL nickname > space. But you could be getting close to that hard limit. This seems > like enough reason to me to be advancing a standard where Level 1 > areas are aggregated (whether by a single nickname or set of border > router nicknames) to, for all practical purposes, eliminate the > nickname space restriction. > > > c. I have also noticed that, once upon a time (4 years ago) there > > was an attempt to use BGP with TRILL. I wonder why this draft has > > been left to expire because, from my POV, BGP is greatly preferable > > to multi-level IS-IS when it comes to scalability issues. > > > > 2. Nickname Re-write vs Nickname Swapping: Looks like a clear case > > of misunderstanding between us, probably due to the fact that I am > > not a TRILL expert: > > > > a. I have used the term "swapping" in the same way it is used > > in MPLS (e.g., see RFC 3031 discussing label swapping). In other > > words, from my POV "nickname swapping" and "nickname re-write" were > > synonyms. > > > > b. It seems that some yet to be standardized extension of TRILL > > considers some dedicated nickname swapping mechanism that carries > > new nicknames in some extension of the TRILL header. In this > > parlance "nickname re-write" and "nickname swapping" are different. > > Right. The possibility was discussed some time ago of expanding the > TRILL header so that, for TRILL Data packets going between different > Level 1 Areas, there could be, in effect, two ingress nicknames (an > ingress RBridge nickname and an ingress Area nickname) and two egress > nicknames (an egress RBridge nickname and an egress Area nickname). > Appropriate swapping would occur at border routers to avoid changes in > fast path logic at all non-border routers. Within Level 2, the Area > nicknames would be in the existing header slots that are routed on, > etc. However, as far as I can recall, no specification was ever been > produced for this "nickname swapping" although it is mentioned in the > informational multi-level draft. > > > c. I think that we now safely consider this discussion issue > > as closed. > > > > 3. Metadata: > > > > a. I fully agree that we should hear from other RTG-DIR > > members on what exactly (if at all) should be specified to clarify > > the relationship between the Single Nickname draft and RFC 6325 > > I would note that the IESG policy on "updates" has become very strict > recently. It used to be a judgment call. Now, when a Standards Track > RFC merely extends another such RFC so you could implement an instance > of the earlier standard as specified without reference to or violating > the subsequent specification, the IESG will generally prohibit you > from claiming that the subsequent specification "updates" the first. > (I do not particularly agree with this policy change myself.) > > > b. I can only add that, AFAIK, the Multi-Level TRILL draft, > > being positioned as an Informational, can neither update nor > > obsolete RFC 6325 (which is Standards Track). So there is no issue > > with its metadata being empty. > > > > There is one issue in my original review that we have not discussed > > at all - namely, the behavior implied by the Single Nickname draft > > when a new border RBridge is added to a certain area. > > I agree that what needs to be done when border RBridges are > added/deleted needs to be clear in the draft. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > > Regards, > > Sasha > > > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > > Sent: Wednesday, May 25, 2016 6:07 AM > > To: Alexander Vainshtein > > Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org; > draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares; > jon.hudson@gmail.com; Jonathan Hardwick > > Subject: RE: [RTG-DIR] RTG-DIR QA review for > draft-ietf-trill-multilevel-single-nickname > > > > Hi Sasha, > > > > Thanks for the comments. > > > > > > [[Sasha]] Do you (or the authors of the multi-level TRILL draft) > consider deployment scenarios with more than 64K RBridges in a single TRILL > campus? Is this a realistic scenario? > > [Mingui] We can also doubt whether a domain with more that 2^32 IP > routers is a realistic scenario. The fact is that a single campus is > usually not allowed to use up the entire 64K namespace. Please consider the > scenario that lots of TRILL campuses are to be interconnected. > > > > > > [[Sasha]] In other words, your draft explicitly states that the area > border RBridges modify the nicknames in the TRILL header of a packet that > crosses the Level 2 domain. How is this different from swapping (save from > the name of the operation)? > > [Mingui] As I said, there is no "swap nickname field" conception in the > draft. Yes, the border RBridge needs to modify the nickname but it does > not have to modify it through the "swapping" operation. Instead, the border > RBridge "replaces" the nickname in the TRILL data packets with its own > nickname (rather than a nickname in the "swap nickname field" provided by > the originating RBridge). Why authors prefer the replacing operation than > the swapping operation? Because the swapping operation requires a new TRILL > header (two additional 16-bit fields) which has not been standardized yet. > > > > As for the "Updates" metadata, let's see if people on the RTG-DIR list > would give directions. > > > > Best regards, > > Mingui > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > > Sent: Tuesday, May 24, 2016 6:45 PM > > To: Mingui Zhang > > Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org trill@ietf.org>; draft-ietf-trill-multilevel-single-nickname@ietf.org > ; Susan > Hares; jon.hudson@gmail.com; Jonathan > Hardwick > > Subject: RE: [RTG-DIR] RTG-DIR QA review for > draft-ietf-trill-multilevel-single-nickname > > > > Mingui hi! > > Lots of thanks for a prompt response. > > > > A few short comments inline below. > > > > Regards, > > Sasha > > > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com Alexander.Vainshtein@ecitele.com> > > > > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > > Sent: Tuesday, May 24, 2016 11:23 AM > > To: Alexander Vainshtein > > Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org trill@ietf.org>; draft-ietf-trill-multilevel-single-nickname@ietf.org > ; Susan > Hares; jon.hudson@gmail.com; Jonathan > Hardwick > > Subject: RE: [RTG-DIR] RTG-DIR QA review for > draft-ietf-trill-multilevel-single-nickname > > > > Hi Sasha, > > > > Thanks for your comments. Please see responses inline below. > > > > Thanks, > > Mingui > > > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > > Sent: Monday, May 23, 2016 6:13 PM > > To: Mingui Zhang > > Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org trill@ietf.org>; draft-ietf-trill-multilevel-single-nickname@ietf.org > ; Susan > Hares (shares@ndzh.com); jon.hudson@gmail.com > ; Jonathan Hardwick ( > Jonathan.Hardwick@metaswitch.com) > > Subject: RE: [RTG-DIR] RTG-DIR QA review for > draft-ietf-trill-multilevel-single-nickname > > > > > > Mingui hi! > > > > Lots of thanks for a prompt response to some of the issues I've raised > in the review. > > > > > > > > Please see some comments to you responses inline below. > > > > > > > > Regards, > > > > Sasha > > > > > > > > Office: +972-39266302 > > > > Cell: +972-549266302 > > > > Email: Alexander.Vainshtein@ecitele.com Alexander.Vainshtein@ecitele.com> > > > > > > > > -----Original Message----- > > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Mingui > Zhang > > Sent: Monday, May 23, 2016 12:31 PM > > To: Alexander Vainshtein; Jonathan Hardwick ( > Jonathan.Hardwick@metaswitch.com) > > Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@ietf.org trill@ietf.org>; draft-ietf-trill-multilevel-single-nickname@ietf.org > ; Susan > Hares (shares@ndzh.com); jon.hudson@gmail.com > > > Subject: Re: [RTG-DIR] RTG-DIR QA review for > draft-ietf-trill-multilevel-single-nickname > > > > > > > > Hi Alexander, > > > > > > > > Thanks for the review! > > > > > > > > The multilevel conception itself is abstract and not easily > understandable. > > > > [[Sasha]] Do you refer to the multi-level IS-IS in general or > multi-level TRILL specifically? I am asking because I believe am reasonably > well aware of the multi-level architecture of IS-IS as used for IP routing. > It is somewhat different from that of OSPF, but I would not call it > "abstract and not easily understandable". And there are quite a few > excellent introductions to the subject (again in the context of IP > routing). However, I am definitely not a TRILL expert, and have stated that > in the review. > > > > > > > > [Mingui] Yes, multi-level arch of IS-IS has already been well > understood. However, the extending TRILL to multi-levels brings new > challenges. As stated in the informational draft, one issue is on > processing the TRILL switch nicknames and the other issue is on handling > multi-destination packet distribution trees. In order not to make the > specifications "abstract", the draft carefully designed two walking-through > examples in Section 3. If the examples were understood, it would be > non-abstract as well. ;-) > > > > > > > > However, it was really interesting in designing such a solution. > Appreciate the review and the time on relevant documents to figure out the > whole scheme. > > > > > > > > > ? Nor provides any explanations about the reasons that make > > > > > single-level IS-IS used by TRILL less scalable that single-level IS-IS > > > > > when it is used for distributing IP reachability > > > > > > > > The reason comes from the fact that the length of a nickname is > different from an IP address. > > > > [[Sasha]] I must admit that I do not understand the connection. By this > logic, IS-IS for CLNS and IPv6 should be much more scalable than IS-IS for > IPv4, but I have never seen such claims before. Could you please elaborate? > Could somebody on the RTG-DIR list to comment on that? > > > > > > > > [Mingui] For a single-level IS-IS instance, the length of the address > determines the name space. In the informational draft, Section 1.1 TRILL > Scalability Issues, the following statement is relevant > > > > " 5. the limit of the number of TRILL switches, due to the 16-bit > nickname space," > > > > [[Sasha]] Do you (or the authors of the multi-level TRILL draft) > consider deployment scenarios with more than 64K RBridges in a single TRILL > campus? Is this a realistic scenario? > > > > > > > > > > > > I think this could be addressed in the updated version of the draft: > https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/?include_text=1 > . > > > > > > > > > * The draft positions itself as an alternative to the Aggregate > > > > > Nicknames approach while, from my POV, it is just provides additional > > > > > details on one of the possible flavors of this approach > > > > > > > > The WG used to discuss several ways to address the "Aggregate Nickname" > approach. > > > > [[Sasha]] I do not follow the TRILL WG mailing list, so I am not aware > of any discussions that have been hold there. I am only speaking about what > I could find in the two drafts mentioned in my review. > > > > > > > > [Mingui] Actually, the informational draft had included the information > of those alternatives as well. Please see "Section 2.2.2.2 Swap Nickname > Field Aggregated Nicknames" and read the words about "pseudonode" of > Section 2.5 > --001a113dcfd839bce40533c756ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Sasha,

On Thu, May 26, 2016 at 2:08 AM, Alexander Vainshtein <= span dir=3D"ltr"><Alexander.Vainshtein@ecitele.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa= dding-left:1ex">
Donald,
Lots of thanks for a very detailed response!

Lots of thanks for very important information about the actual and exp= ected=C2=A0scale of TRILL deployments as well as for presenting some of the= factors (line active-active TRILL operation) that affect the consumption o= f the nickname space.=C2=A0It addresses my question about the reason to go for multi-level IS-IS at all. Flat IGP con= figuration=C2=A0(both IS-IS and OSPF)=C2=A0are very popular in IP/MPLS depl= oyments due to LDP =C2=A0(and, now, IP/LDP FRR techniques), so this informa= tion was important to me in order to understand that=C2=A0the multi-level TRILL drafts solve a real problem. I woul= d suggest adding this information to the multi-level TRILL draft.=C2=A0

Sounds reasonable. Something= like that can be added to draft-ietf-trill-rbridge-multilevel.
= =C2=A0
However,=C2=A0I am still not sure if the Single Nickname draft = (one=C2=A0I have been reviewing)=C2=A0 represents an attempt=C2=A0to sol= ve a real problem. My understanding so far has been that it follows the= Aggregate Nicknames approach in the multi-level TRILL draft, but eliminates the need to assign nicknames to L1 areas. I d= o not see if, even with the scale you have mentioned) this could be a serio= us issue (e.g., contribute significantly to depletion of the nickname space= ). Do I =C2=A0miss something here?

<= /div>
I'm not sure it matters. If you believe that there is a good = reason for aggregated nicknames, this draft is the only aggregated nickname= draft that is current active and the only such draft that has been adopted= by the TRILL WG. So unless there is some problem with its approach, it see= ms to me that it should be progressed.
=C2=A0
The swapping vs. re-write issue I have discussed with Mingui is a pure= case of terminology. AsI have said, I consider it as closed.

As for the metadata issue =C2=A0- I am perfectly ready to follow the g= uidance of ADs and WG chairs. especially since this policy has recently=C2= =A0undergone serious=C2=A0changes.

Two additional questions - for the sake of my curiosity:
  1. Can possibly=C2=A0you explain what has happened to draft that proposed = using BGP with TRILL?
If you g= ive me a pointer to the specific expired draft, I might remember something = about its history. By the way, there is currently a draft in IDR: draft-idr= -ietf-ls-trill.=C2=A0
  1. Did anybody consider= combining=C2=A0IPFRR techniques with TRILL
While I don't recall any s= pecific mention of it, I don't see that any change would be required to= existing TRILL standards. Fast ReRoute would run off the existing link sta= te databases.

Actually, the above applies only to unicast data. TRILL use= s distribution trees for multi-destination data and there is draft-ietf-tri= ll-resilient-trees which provides back-up distribution trees sort of like F= RR provides back-up paths.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd = =C2=A0 +1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Milford, MA 01757= USA
=C2=A0d3e3e3@= gmail.com
=C2=A0
Regards, and=C2=A0lots of thanks in advance,
Sasha



________________________________________
From: Donald Eastlake <d3e3e3@gmail.com>
Sent: Thursday, May 26, 2016 12:03 AM
To: Alexander Vainshtein
Cc: Mingui Zhang; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multilevel= -single-nickname@ietf.org; Susan Hares; jon.hudson@gmail.com; Jonathan Hardwick; rtg-dir@ietf.org

Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-si= ngle-nickname

Hi Alexander,

Thanks from me also for your review.=C2=A0 I'd like to chime in with a = few
thoughts:

On Wed, May 25, 2016 at 8:23 AM, Alexander Vainshtein
<A= lexander.Vainshtein@ecitele.com> wrote:
>
> Hi Mingui,
> I will try to summarize our agreements and disagreements.
>
> 1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The scale of TRILL deployments:=
>
> a. I have not seen any specific numbers or references to any
> specific topologies that could really make single-level TRILL not
> scalable enough - neither in the TRILL drafts I've read nor in our=
> discussions so far

I am puzzled as to why you think there would be some specific numeric
hard boundary, other than number space or memory space exhaustion,
beyond which you cannot scale. Can you point to a documentation of
such a thing for IP use of IS-IS? Surely it depends on how much
computer power the routers have, link stability, and numerous other
factors.

Just looking at convergence time and approximating it as the amount of
computation required at a typical router in the TRILL campus, it is on
the order of N*(log N) for computation of least cost routes where
there are N routers in a single level campus while it is on the order
of (sqrt N)*(log N) for multi-level, in both cases assuming optimized
calculations. The largest TRILL campuses I am aware of are on the
order of 3,000 routers. So one would expect that converting such a
campus to multi-level TRILL would reduce convergence time by
approximately a factor of 50. Furthermore, one would expect the rate
of failures within each Level 1 area in the multi-level case to be
approximately proportional to the number of links/routers and thus
also fall by one and a half orders of magnitude. Do you claim these
improvements would never be valuable?

There are many other scaling factors such as the size of the link
state database, etc. I believe the informational
draft-ietf-trill-rbridge-multi-level gives a good summary.

> b. Regarding your reference to multiple interconnected TRILL-based
> campuses in your last email: I do not think that TRILL is an
> alternative to or competes with Internet.

I agree that TRILL does not compete with the Internet.=C2=A0 :-)

I believe this facet of the discussion was in connection with the
possibility of TRILL nickname space exhaustion. Consider the following
factors:

1) TRILL supports active-active connection of end stations at the
TRILL edge. Using the techniques in RFC 7781 (Pseudo-Nickname for
Active-Active Access) consumes TRILL nicknames for active-active edge
groups.

2) Assuming, for the moment, you are using multi-level with unique
nicknames, the nickname allocation mechanism will waste many nicknames
due to hierarchical assignment, the same way power-of-two sized IP
subnets waste IP addresses.

3) There is a desire to interconnect TRILL campuses that are under
joint or cooperative management with limited control plane coupling so
as to limit error propagation, etc. There are various possible ways to
do this but most of them assume non-conflicting nicknames (or
non-conflicting level 2 nicknames if the campuses are multi-level).

I admit that even taking the largest existing TRILL campuses I know
about and adding extensive active-active end station support at the
edge and multi-level with unique nicknames that are hierarchically
allocated, you would still probably not exhaust the TRILL nickname
space. But you could be getting close to that hard limit. This seems
like enough reason to me to be advancing a standard where Level 1
areas are aggregated (whether by a single nickname or set of border
router nicknames) to, for all practical purposes, eliminate the
nickname space restriction.

> c. I have also noticed that, once upon a time (4 years ago) there
> was an attempt to use BGP with TRILL. I wonder why this draft has
> been left to expire because, from my POV, BGP is greatly preferable > to multi-level IS-IS when it comes to scalability issues.
>
> 2. Nickname Re-write vs Nickname Swapping: Looks like a clear case
> of misunderstanding between us, probably due to the fact that I am
> not a TRILL expert:
>
> a.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I have used the term "swap= ping" in the same way it is used
> in MPLS (e.g., see RFC 3031 discussing label swapping). In other
> words, from my POV "nickname swapping" and "nickname re= -write" were
> synonyms.
>
> b.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 It seems that some yet to be standard= ized extension of TRILL
> considers some dedicated nickname swapping mechanism that carries
> new nicknames in some extension of the TRILL header.=C2=A0 In this
> parlance "nickname re-write" and "nickname swapping&quo= t; are different.

Right. The possibility was discussed some time ago of expanding the
TRILL header so that, for TRILL Data packets going between different
Level 1 Areas, there could be, in effect, two ingress nicknames (an
ingress RBridge nickname and an ingress Area nickname) and two egress
nicknames (an egress RBridge nickname and an egress Area nickname).
Appropriate swapping would occur at border routers to avoid changes in
fast path logic at all non-border routers. Within Level 2, the Area
nicknames would be in the existing header slots that are routed on,
etc. However, as far as I can recall, no specification was ever been
produced for this "nickname swapping" although it is mentioned in= the
informational multi-level draft.

> c.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I think that we now safely cons= ider this discussion issue
> as closed.
>
> 3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Metadata:
>
> a.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I fully agree that we should he= ar from other RTG-DIR
> members on what exactly (if at all) should be specified to clarify
> the relationship between the Single Nickname draft and RFC 6325

I would note that the IESG policy on "updates" has become very st= rict
recently. It used to be a judgment call. Now, when a Standards Track
RFC merely extends another such RFC so you could implement an instance
of the earlier standard as specified without reference to or violating
the subsequent specification, the IESG will generally prohibit you
from claiming that the subsequent specification "updates" the fir= st.
(I do not particularly agree with this policy change myself.)

> b.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I can only add that, AFAIK, the Multi= -Level TRILL draft,
> being positioned as an Informational, can neither update nor
> obsolete RFC 6325 (which is Standards Track). So there is no issue
> with its metadata being empty.
>
> There is one issue in my original review that we have not discussed > at all - namely, the behavior implied by the Single Nickname draft
> when a new border RBridge is added to a certain area.

I agree that what needs to be done when border RBridges are
added/deleted needs to be clear in the draft.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
Donald E. Eastlake 3rd=C2=A0=C2=A0 +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e3e3@gmail.com<= br>
> Regards,
> Sasha
>
> Office: +972-39266302
> Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302
> Email:=C2=A0=C2=A0 Alexander.Vainshtein@ecitele.com
>
> From: Mingui Zhang [mailto:zhangmingui@huawei.com]
> Sent: Wednesday, May 25, 2016 6:07 AM
> To: Alexander Vainshtein
> Cc: 'rtg-dir= @ietf.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multilev= el-single-nickname@ietf.org; Susan Hares; jon.hudson@gmail.com; Jonathan Hardwick > Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilev= el-single-nickname
>
> Hi Sasha,
>
> Thanks for the comments.
>
>
> [[Sasha]] Do you (or the authors of the multi-level TRILL draft) consi= der deployment scenarios with more than 64K RBridges in a single TRILL camp= us? Is this a realistic scenario?
> [Mingui] We can also doubt whether a domain with more that 2^32 IP rou= ters is a realistic scenario. The fact is that a single campus is usually n= ot allowed to use up the entire 64K namespace. Please consider the scenario= that lots of TRILL campuses are to be interconnected.
>
>
> [[Sasha]] In other words, your draft explicitly states that the area b= order RBridges modify the nicknames in the TRILL header of a packet that cr= osses the Level 2 domain. How is this different from swapping (save from th= e name of the operation)?
> [Mingui] As I said, there is no "swap nickname field" concep= tion in the draft.=C2=A0 Yes, the border RBridge needs to modify the nickna= me but it does not have to modify it through the "swapping" opera= tion. Instead, the border RBridge "replaces" the nickname in the TRILL data packets with its own nickname (rather than a nickname in th= e "swap nickname field" provided by the originating RBridge). Why= authors prefer the replacing operation than the swapping operation? Becaus= e the swapping operation requires a new TRILL header (two additional 16-bit fields) which has not been standardized yet.=
>
> As for the "Updates" metadata, let's see if people on th= e RTG-DIR list would give directions.
>
> Best regards,
> Mingui
> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Tuesday, May 24, 2016 6:45 PM
> To: Mingui Zhang
> Cc: 'rtg-dir= @ietf.org'; Zhangxian (Xian); trill@ietf.org<mailto:trill@ietf.org>; draft-ietf-tril= l-multilevel-single-nickname@ietf.org<mailto:draft-ie= tf-trill-multilevel-single-nickname@ietf.org>; Susan Hares; jon.hudson@gmail.com= <mailto:jon.hu= dson@gmail.com>; Jonathan Hardwick
> Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilev= el-single-nickname
>
> Mingui hi!
> Lots of thanks for a prompt response.
>
> A few short comments inline below.
>
> Regards,
> Sasha
>
> Office: +972-39266302
> Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302
> Email:=C2=A0=C2=A0 Alexander.Vainshtein@ecitele.com<mailto:Alexander.Va= inshtein@ecitele.com>
>
> From: Mingui Zhang [mailto:zhangmingui@huawei.com]
> Sent: Tuesday, May 24, 2016 11:23 AM
> To: Alexander Vainshtein
> Cc: 'rtg-dir= @ietf.org'; Zhangxian (Xian); trill@ietf.org<mailto:trill@ietf.org>; draft-ietf-tril= l-multilevel-single-nickname@ietf.org<mailto:draft-ie= tf-trill-multilevel-single-nickname@ietf.org>; Susan Hares; jon.hudson@gmail.com= <mailto:jon.hu= dson@gmail.com>; Jonathan Hardwick
> Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilev= el-single-nickname
>
> Hi Sasha,
>
> Thanks for your comments. Please see responses inline below.
>
> Thanks,
> Mingui
>
> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Monday, May 23, 2016 6:13 PM
> To: Mingui Zhang
> Cc: 'rtg-dir= @ietf.org'; Zhangxian (Xian); trill@ietf.org<mailto:trill@ietf.org>; draft-ietf-tril= l-multilevel-single-nickname@ietf.org<mailto:draft-ie= tf-trill-multilevel-single-nickname@ietf.org>; Susan Hares (shares@ndzh.com<mailto= :shares@ndzh.com&g= t;); jon.hudson@g= mail.com<mailto:jon.hudson@gmail.com>; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com<mailto:Jonathan.Hardwick@= metaswitch.com>)
> Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilev= el-single-nickname
>
>
> Mingui hi!
>
> Lots of thanks for a prompt response to some of the issues I've ra= ised in the review.
>
>
>
> Please see some comments to you responses inline below.
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +972-549266302
>
> Email:=C2=A0=C2=A0 Alexander.Vainshtein@ecitele.com<mailto:Alexander.Va= inshtein@ecitele.com>
>
>
>
> -----Original Message-----
> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Mingui Zhang
> Sent: Monday, May 23, 2016 12:31 PM
> To: Alexander Vainshtein; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.c= om<mailto:Jonathan.Hardwick@metaswitch.com>)
> Cc: 'rtg-dir= @ietf.org'; Zhangxian (Xian); trill@ietf.org<mailto:trill@ietf.org>; draft-ietf-tril= l-multilevel-single-nickname@ietf.org<mailto:draft-ie= tf-trill-multilevel-single-nickname@ietf.org>; Susan Hares (shares@ndzh.com<mailto= :shares@ndzh.com&g= t;); jon.hudson@g= mail.com<mailto:jon.hudson@gmail.com>
> Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilev= el-single-nickname
>
>
>
> Hi Alexander,
>
>
>
> Thanks for the review!
>
>
>
> The multilevel conception itself is abstract and not easily understand= able.
>
> [[Sasha]] Do you refer to the multi-level IS-IS in general or multi-le= vel TRILL specifically? I am asking because I believe am reasonably well aw= are of the multi-level architecture of IS-IS as used for IP routing. It is = somewhat different from that of OSPF, but I would not call it "abstract and not easily understandable"= .=C2=A0 And there are quite a few excellent introductions to the subject (a= gain in the context of IP routing). However, I am definitely not a TRILL ex= pert, and have stated that in the review.
>
>
>
> [Mingui] Yes, multi-level arch of IS-IS has already been well understo= od. However, the extending TRILL to multi-levels brings new challenges. As = stated in the informational draft, one issue is on processing the TRILL swi= tch nicknames and the other issue is on handling multi-destination packet distribution trees. In order not to m= ake the specifications "abstract", the draft carefully designed t= wo walking-through examples in Section 3. If the examples were understood, = it would be non-abstract as well. ;-)
>
>
>
> However, it was really interesting in designing such a solution. Appre= ciate the review and the time on relevant documents to figure out the whole= scheme.
>
>
>
> > ?=C2=A0 Nor provides any explanations about the reasons that make=
>
> > single-level IS-IS used by TRILL less scalable that single-level = IS-IS
>
> > when it is used for distributing IP reachability
>
>
>
> The reason comes from the fact that the length of a nickname is differ= ent from an IP address.
>
> [[Sasha]] I must admit that I do not understand the connection. By thi= s logic, IS-IS for CLNS and IPv6 should be much more scalable than IS-IS fo= r IPv4, but I have never seen such claims before. Could you please elaborat= e? Could somebody on the RTG-DIR list to comment on that?
>
>
>
> [Mingui] For a single-level IS-IS instance, the length of the address = determines the name space. In the informational draft, Section 1.1 TRILL Sc= alability Issues, the following statement is relevant
>
> "=C2=A0=C2=A0 5. the limit of the number of TRILL switches, due t= o the 16-bit nickname space,"
>
> [[Sasha]] Do you (or the authors of the multi-level TRILL draft) consi= der deployment scenarios with more than 64K RBridges in a single TRILL camp= us? Is this a realistic scenario?
>
>
>
>
>
> I think this could be addressed in the updated version of the draft: <= a href=3D"https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multile= vel/?include_text=3D1" target=3D"_blank">https://datatracker.ietf.org/doc/d= raft-ietf-trill-rbridge-multilevel/?include_text=3D1.
>
>
>
> > *=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The draft posit= ions itself as an alternative to the Aggregate
>
> > Nicknames approach while, from my POV, it is just provides additi= onal
>
> > details on one of the possible flavors of this approach
>
>
>
> The WG used to discuss several ways to address the "Aggregate Nic= kname" approach.
>
> [[Sasha]] I do not follow the TRILL WG mailing list, so I am not aware= of any discussions that have been hold there. I am only speaking about wha= t I could find in the two drafts mentioned in my review.
>
>
>
> [Mingui] Actually, the informational draft had included the informatio= n of those alternatives as well. Please see "Section 2.2.2.2 Swap Nick= name Field Aggregated Nicknames" and read the words about "pseudo= node" of Section 2.5

--001a113dcfd839bce40533c756ca-- From nobody Thu May 26 22:03:44 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 219AD12D161; Thu, 26 May 2016 22:03:39 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=eci365.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 ZNbb3qgxsHSD; Thu, 26 May 2016 22:03:34 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0729.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2554F12D584; Thu, 26 May 2016 22:03:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lDTssSF9R9h8f2T6QW4ZkykVErDnznix6i0Cn0HoddY=; b=azRhueHDz/uvf5GwTeMRHC+J+Lxb54ZpC86LI6jVh2h1HqSdNqwTFTkr+DPlidFTG1INNCy7+zHz32h1sKQyEalpJL73U0Jc4npl9YcDsGhG6S08+MLpSss7DsA87bScxKI3f7U2WTvdHx6l1lZEZYbZj9J1G0AaTB0t6O2CJ3I= Received: from HE1PR0301MB2266.eurprd03.prod.outlook.com (10.168.31.153) by HE1PR0301MB2268.eurprd03.prod.outlook.com (10.168.31.155) with Microsoft SMTP Server (TLS) id 15.1.506.9; Fri, 27 May 2016 05:01:32 +0000 Received: from HE1PR0301MB2266.eurprd03.prod.outlook.com ([10.168.31.153]) by HE1PR0301MB2266.eurprd03.prod.outlook.com ([10.168.31.153]) with mapi id 15.01.0506.009; Fri, 27 May 2016 05:01:32 +0000 From: Alexander Vainshtein To: Donald Eastlake Thread-Topic: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname Thread-Index: AQHRtZZOOYuy+h1UCUGjRJ1qjVLvXZ/H45PQgAEWN4CAAJSMMIAAmGEAgACLGjeAATNWAIAAVKZq Date: Fri, 27 May 2016 05:01:31 +0000 Message-ID: References: <4552F0907735844E9204A62BBDD325E787CB087E@NKGEML515-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E787CB7589@NKGEML515-MBS.china.huawei.com> <4552F0907735844E9204A62BBDD325E787CB9054@NKGEML515-MBS.china.huawei.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=ecitele.com; x-originating-ip: [132.245.69.69] x-ms-office365-filtering-correlation-id: 39909ea9-d3c1-4934-1934-08d385ebf867 x-microsoft-exchange-diagnostics: 1; HE1PR0301MB2268; 5:ApXzXohLar5R+lVoTineS0hoC9R64g5QIdSskT8QfrkU/LlMMqNLxH4Yniso3iHhHFYed9IrmKExhlW6qwvyXvHW0tYia5jPpUmflsEy+66PdOpUFwFS21WkB5uPfNY+ZySVK9cOejlOtI+WHbSp/A==; 24:1M96OejO+rQJhmtkWML72moLqaG/xqKQKbdhC2fUtOysPox4X02LXhJseABH9jAeBEksTKnpbc8ViQflSaaFBfh4BbKAU1xrJPIGYI8Z4aE=; 7:cz+yUseWD0zRjW8RuGoRTKfwR+NLwQMFRlm8+70mOyhh/74QtEuPAt++5pK0/xpHc8oT4wkQFiutRP++rcYRtoaYfUsOAUv33oBsuQoVoxIQNOkmF+Un2QDbe2Nfmpryn59ha/1OSlepmWpksmPeLDApcl4e7O7QNeuyVgN37d+AZPSkpJsd/0OjDS91MZT7 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0301MB2268; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705)(50582790962513)(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:HE1PR0301MB2268; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0301MB2268; x-forefront-prvs: 09555FB1AD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(377454003)(13464003)(51444003)(24454002)(252514010)(30594003)(51914003)(51874003)(19580395003)(19625215002)(1220700001)(2950100001)(19580405001)(74316001)(66066001)(586003)(8936002)(230783001)(102836003)(6116002)(4326007)(76576001)(5004730100002)(8676002)(2900100001)(81166006)(3846002)(5002640100001)(5003600100002)(86362001)(87936001)(77096005)(15975445007)(1411001)(189998001)(19617315012)(5008740100001)(14971765001)(110136002)(3660700001)(3280700002)(92566002)(16236675004)(3900700001)(50986999)(76176999)(106116001)(93886004)(11100500001)(33656002)(122556002)(9686002)(2906002)(54356999)(10400500002)(19627405001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0301MB2268; H:HE1PR0301MB2266.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0301MB22661AECB1D962ACAE3E20629D420HE1PR0301MB2266_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2016 05:01:31.6468 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0301MB2268 Archived-At: Cc: "rtg-dir@ietf.org" , "Zhangxian \(Xian\)" , Mingui Zhang , "trill@ietf.org" , Jonathan Hardwick , "draft-ietf-trill-multilevel-single-nickname@ietf.org" , Susan Hares , "jon.hudson@gmail.com" Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-single-nickname X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 05:03:39 -0000 --_000_HE1PR0301MB22661AECB1D962ACAE3E20629D420HE1PR0301MB2266_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Donald, Again, lots of thanks for a prompt response regarding the NGP dratf: here is the link: https://tools.ietf.org/html/draft-balaji-trill-over-ip-multi-level-05 This draft has expired 4 years ago, and to me it looks as addressing the sa= me problem you and your colleagues try to address with multi-level IS-IS. Regarding your statement that the Single Nickname draft "is the only aggreg= ated nickname draft that is current active": I think that the specific problematic point of this draft is volatility of = the area names (that are just the collections of the nicknames of all borde= r RBridges of a given area in this draft). - This may be - or may be not - a serious technical issue with the proposed a= pproach. In any case I'd say it requires careful analysis. And, after re-reading your previous email, I think there is a common potent= ial issue with the Aggregate Nicknames approach as such. Please consider the following scenario (actually mentioned as a security is= sue in your email) 1. There is a L1 one area with multiple border RBridges. 2. Due to some failure this area is partitioned 3. Later still, a new RBridge comes up in one of the new areas and acqui= res a nickname that is unique in this area 4. Now the failure that has caused partitioning f the area has been repa= ired. The areas are merged, and some RBridges now have duplicate nicknames. Again, this requires some analysis IMHO. Regards, Sasha ________________________________ From: Donald Eastlake Sent: Friday, May 27, 2016 2:41 AM To: Alexander Vainshtein Cc: Mingui Zhang; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multil= evel-single-nickname@ietf.org; Susan Hares; jon.hudson@gmail.com; Jonathan = Hardwick; rtg-dir@ietf.org Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-si= ngle-nickname Hi Sasha, On Thu, May 26, 2016 at 2:08 AM, Alexander Vainshtein > wrote: Donald, Lots of thanks for a very detailed response! Lots of thanks for very important information about the actual and expected= scale of TRILL deployments as well as for presenting some of the factors (= line active-active TRILL operation) that affect the consumption of the nick= name space. It addresses my question about the reason to go for multi-level= IS-IS at all. Flat IGP configuration (both IS-IS and OSPF) are very popula= r in IP/MPLS deployments due to LDP (and, now, IP/LDP FRR techniques), so = this information was important to me in order to understand that the multi-= level TRILL drafts solve a real problem. I would suggest adding this inform= ation to the multi-level TRILL draft. Sounds reasonable. Something like that can be added to draft-ietf-trill-rbr= idge-multilevel. However, I am still not sure if the Single Nickname draft (one I have been = reviewing) represents an attempt to solve a real problem. My understanding= so far has been that it follows the Aggregate Nicknames approach in the mu= lti-level TRILL draft, but eliminates the need to assign nicknames to L1 ar= eas. I do not see if, even with the scale you have mentioned) this could be= a serious issue (e.g., contribute significantly to depletion of the nickna= me space). Do I miss something here? I'm not sure it matters. If you believe that there is a good reason for agg= regated nicknames, this draft is the only aggregated nickname draft that is= current active and the only such draft that has been adopted by the TRILL = WG. So unless there is some problem with its approach, it seems to me that = it should be progressed. The swapping vs. re-write issue I have discussed with Mingui is a pure case= of terminology. AsI have said, I consider it as closed. As for the metadata issue - I am perfectly ready to follow the guidance of= ADs and WG chairs. especially since this policy has recently undergone ser= ious changes. Two additional questions - for the sake of my curiosity: 1. Can possibly you explain what has happened to draft that proposed usi= ng BGP with TRILL? If you give me a pointer to the specific expired draft, I might remember so= mething about its history. By the way, there is currently a draft in IDR: d= raft-idr-ietf-ls-trill. 1. Did anybody consider combining IPFRR techniques with TRILL While I don't recall any specific mention of it, I don't see that any chang= e would be required to existing TRILL standards. Fast ReRoute would run off= the existing link state databases. Actually, the above applies only to unicast data. TRILL uses distribution t= rees for multi-destination data and there is draft-ietf-trill-resilient-tre= es which provides back-up distribution trees sort of like FRR provides back= -up paths. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com Regards, and lots of thanks in advance, Sasha ________________________________________ From: Donald Eastlake > Sent: Thursday, May 26, 2016 12:03 AM To: Alexander Vainshtein Cc: Mingui Zhang; Zhangxian (Xian); trill@ietf.org; = draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares; jon.hudson@gmail.com; Jonathan Hardwick; rtg-dir@ietf.org Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-si= ngle-nickname Hi Alexander, Thanks from me also for your review. I'd like to chime in with a few thoughts: On Wed, May 25, 2016 at 8:23 AM, Alexander Vainshtein >= wrote: > > Hi Mingui, > I will try to summarize our agreements and disagreements. > > 1. The scale of TRILL deployments: > > a. I have not seen any specific numbers or references to any > specific topologies that could really make single-level TRILL not > scalable enough - neither in the TRILL drafts I've read nor in our > discussions so far I am puzzled as to why you think there would be some specific numeric hard boundary, other than number space or memory space exhaustion, beyond which you cannot scale. Can you point to a documentation of such a thing for IP use of IS-IS? Surely it depends on how much computer power the routers have, link stability, and numerous other factors. Just looking at convergence time and approximating it as the amount of computation required at a typical router in the TRILL campus, it is on the order of N*(log N) for computation of least cost routes where there are N routers in a single level campus while it is on the order of (sqrt N)*(log N) for multi-level, in both cases assuming optimized calculations. The largest TRILL campuses I am aware of are on the order of 3,000 routers. So one would expect that converting such a campus to multi-level TRILL would reduce convergence time by approximately a factor of 50. Furthermore, one would expect the rate of failures within each Level 1 area in the multi-level case to be approximately proportional to the number of links/routers and thus also fall by one and a half orders of magnitude. Do you claim these improvements would never be valuable? There are many other scaling factors such as the size of the link state database, etc. I believe the informational draft-ietf-trill-rbridge-multi-level gives a good summary. > b. Regarding your reference to multiple interconnected TRILL-based > campuses in your last email: I do not think that TRILL is an > alternative to or competes with Internet. I agree that TRILL does not compete with the Internet. :-) I believe this facet of the discussion was in connection with the possibility of TRILL nickname space exhaustion. Consider the following factors: 1) TRILL supports active-active connection of end stations at the TRILL edge. Using the techniques in RFC 7781 (Pseudo-Nickname for Active-Active Access) consumes TRILL nicknames for active-active edge groups. 2) Assuming, for the moment, you are using multi-level with unique nicknames, the nickname allocation mechanism will waste many nicknames due to hierarchical assignment, the same way power-of-two sized IP subnets waste IP addresses. 3) There is a desire to interconnect TRILL campuses that are under joint or cooperative management with limited control plane coupling so as to limit error propagation, etc. There are various possible ways to do this but most of them assume non-conflicting nicknames (or non-conflicting level 2 nicknames if the campuses are multi-level). I admit that even taking the largest existing TRILL campuses I know about and adding extensive active-active end station support at the edge and multi-level with unique nicknames that are hierarchically allocated, you would still probably not exhaust the TRILL nickname space. But you could be getting close to that hard limit. This seems like enough reason to me to be advancing a standard where Level 1 areas are aggregated (whether by a single nickname or set of border router nicknames) to, for all practical purposes, eliminate the nickname space restriction. > c. I have also noticed that, once upon a time (4 years ago) there > was an attempt to use BGP with TRILL. I wonder why this draft has > been left to expire because, from my POV, BGP is greatly preferable > to multi-level IS-IS when it comes to scalability issues. > > 2. Nickname Re-write vs Nickname Swapping: Looks like a clear case > of misunderstanding between us, probably due to the fact that I am > not a TRILL expert: > > a. I have used the term "swapping" in the same way it is used > in MPLS (e.g., see RFC 3031 discussing label swapping). In other > words, from my POV "nickname swapping" and "nickname re-write" were > synonyms. > > b. It seems that some yet to be standardized extension of TRILL > considers some dedicated nickname swapping mechanism that carries > new nicknames in some extension of the TRILL header. In this > parlance "nickname re-write" and "nickname swapping" are different. Right. The possibility was discussed some time ago of expanding the TRILL header so that, for TRILL Data packets going between different Level 1 Areas, there could be, in effect, two ingress nicknames (an ingress RBridge nickname and an ingress Area nickname) and two egress nicknames (an egress RBridge nickname and an egress Area nickname). Appropriate swapping would occur at border routers to avoid changes in fast path logic at all non-border routers. Within Level 2, the Area nicknames would be in the existing header slots that are routed on, etc. However, as far as I can recall, no specification was ever been produced for this "nickname swapping" although it is mentioned in the informational multi-level draft. > c. I think that we now safely consider this discussion issue > as closed. > > 3. Metadata: > > a. I fully agree that we should hear from other RTG-DIR > members on what exactly (if at all) should be specified to clarify > the relationship between the Single Nickname draft and RFC 6325 I would note that the IESG policy on "updates" has become very strict recently. It used to be a judgment call. Now, when a Standards Track RFC merely extends another such RFC so you could implement an instance of the earlier standard as specified without reference to or violating the subsequent specification, the IESG will generally prohibit you from claiming that the subsequent specification "updates" the first. (I do not particularly agree with this policy change myself.) > b. I can only add that, AFAIK, the Multi-Level TRILL draft, > being positioned as an Informational, can neither update nor > obsolete RFC 6325 (which is Standards Track). So there is no issue > with its metadata being empty. > > There is one issue in my original review that we have not discussed > at all - namely, the behavior implied by the Single Nickname draft > when a new border RBridge is added to a certain area. I agree that what needs to be done when border RBridges are added/deleted needs to be clear in the draft. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > Sent: Wednesday, May 25, 2016 6:07 AM > To: Alexander Vainshtein > Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@= ietf.org; draft-ietf-trill-multilevel-single-nicknam= e@ietf.org; Su= san Hares; jon.hudson@gmail.com; Jonathan Hard= wick > Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-= single-nickname > > Hi Sasha, > > Thanks for the comments. > > > [[Sasha]] Do you (or the authors of the multi-level TRILL draft) consider= deployment scenarios with more than 64K RBridges in a single TRILL campus?= Is this a realistic scenario? > [Mingui] We can also doubt whether a domain with more that 2^32 IP router= s is a realistic scenario. The fact is that a single campus is usually not = allowed to use up the entire 64K namespace. Please consider the scenario th= at lots of TRILL campuses are to be interconnected. > > > [[Sasha]] In other words, your draft explicitly states that the area bord= er RBridges modify the nicknames in the TRILL header of a packet that cross= es the Level 2 domain. How is this different from swapping (save from the n= ame of the operation)? > [Mingui] As I said, there is no "swap nickname field" conception in the d= raft. Yes, the border RBridge needs to modify the nickname but it does not= have to modify it through the "swapping" operation. Instead, the border RB= ridge "replaces" the nickname in the TRILL data packets with its own nickna= me (rather than a nickname in the "swap nickname field" provided by the ori= ginating RBridge). Why authors prefer the replacing operation than the swap= ping operation? Because the swapping operation requires a new TRILL header = (two additional 16-bit fields) which has not been standardized yet. > > As for the "Updates" metadata, let's see if people on the RTG-DIR list wo= uld give directions. > > Best regards, > Mingui > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Tuesday, May 24, 2016 6:45 PM > To: Mingui Zhang > Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@= ietf.org>; draft-ietf-trill-multilevel-single-nickname@ietf.org>; Susan Hares; jon.hudson@gmail.com>; Jonathan Har= dwick > Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-= single-nickname > > Mingui hi! > Lots of thanks for a prompt response. > > A few short comments inline below. > > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com> > > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > Sent: Tuesday, May 24, 2016 11:23 AM > To: Alexander Vainshtein > Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@= ietf.org>; draft-ietf-trill-multilevel-single-nickname@ietf.org>; Susan Hares; jon.hudson@gmail.com>; Jonathan Har= dwick > Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-= single-nickname > > Hi Sasha, > > Thanks for your comments. Please see responses inline below. > > Thanks, > Mingui > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Monday, May 23, 2016 6:13 PM > To: Mingui Zhang > Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@= ietf.org>; draft-ietf-trill-multilevel-single-nickname@ietf.org>; Susan Hares (shares@ndzh.com>); jon.hudson@gmail.com= >; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com>) > Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-= single-nickname > > > Mingui hi! > > Lots of thanks for a prompt response to some of the issues I've raised in= the review. > > > > Please see some comments to you responses inline below. > > > > Regards, > > Sasha > > > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com> > > > > -----Original Message----- > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Mingui Zhang > Sent: Monday, May 23, 2016 12:31 PM > To: Alexander Vainshtein; Jonathan Hardwick (Jonathan.Hardwick@metaswitch= .com>) > Cc: 'rtg-dir@ietf.org'; Zhangxian (Xian); trill@= ietf.org>; draft-ietf-trill-multilevel-single-nickname@ietf.org>; Susan Hares (shares@ndzh.com>); jon.hudson@gmail.com= > > Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-= single-nickname > > > > Hi Alexander, > > > > Thanks for the review! > > > > The multilevel conception itself is abstract and not easily understandabl= e. > > [[Sasha]] Do you refer to the multi-level IS-IS in general or multi-level= TRILL specifically? I am asking because I believe am reasonably well aware= of the multi-level architecture of IS-IS as used for IP routing. It is som= ewhat different from that of OSPF, but I would not call it "abstract and no= t easily understandable". And there are quite a few excellent introduction= s to the subject (again in the context of IP routing). However, I am defini= tely not a TRILL expert, and have stated that in the review. > > > > [Mingui] Yes, multi-level arch of IS-IS has already been well understood.= However, the extending TRILL to multi-levels brings new challenges. As sta= ted in the informational draft, one issue is on processing the TRILL switch= nicknames and the other issue is on handling multi-destination packet dist= ribution trees. In order not to make the specifications "abstract", the dra= ft carefully designed two walking-through examples in Section 3. If the exa= mples were understood, it would be non-abstract as well. ;-) > > > > However, it was really interesting in designing such a solution. Apprecia= te the review and the time on relevant documents to figure out the whole sc= heme. > > > > > ? Nor provides any explanations about the reasons that make > > > single-level IS-IS used by TRILL less scalable that single-level IS-IS > > > when it is used for distributing IP reachability > > > > The reason comes from the fact that the length of a nickname is different= from an IP address. > > [[Sasha]] I must admit that I do not understand the connection. By this l= ogic, IS-IS for CLNS and IPv6 should be much more scalable than IS-IS for I= Pv4, but I have never seen such claims before. Could you please elaborate? = Could somebody on the RTG-DIR list to comment on that? > > > > [Mingui] For a single-level IS-IS instance, the length of the address det= ermines the name space. In the informational draft, Section 1.1 TRILL Scala= bility Issues, the following statement is relevant > > " 5. the limit of the number of TRILL switches, due to the 16-bit nickn= ame space," > > [[Sasha]] Do you (or the authors of the multi-level TRILL draft) consider= deployment scenarios with more than 64K RBridges in a single TRILL campus?= Is this a realistic scenario? > > > > > > I think this could be addressed in the updated version of the draft: http= s://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/?include_t= ext=3D1. > > > > > * The draft positions itself as an alternative to the Aggregate > > > Nicknames approach while, from my POV, it is just provides additional > > > details on one of the possible flavors of this approach > > > > The WG used to discuss several ways to address the "Aggregate Nickname" a= pproach. > > [[Sasha]] I do not follow the TRILL WG mailing list, so I am not aware of= any discussions that have been hold there. I am only speaking about what I= could find in the two drafts mentioned in my review. > > > > [Mingui] Actually, the informational draft had included the information o= f those alternatives as well. Please see "Section 2.2.2.2 Swap Nickname Fie= ld Aggregated Nicknames" and read the words about "pseudonode" of Section 2= .5 --_000_HE1PR0301MB22661AECB1D962ACAE3E20629D420HE1PR0301MB2266_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Donald,

Again, lots of thanks for a prompt response


regarding the NGP dratf: here is the link:

https://tools.ietf.org/html/draft= -balaji-trill-over-ip-multi-level-05


This draft has expired 4 years ago, and to me it looks as addressing the= same problem you and your colleagues try to address with multi-level IS-IS= .


Regarding your statement that the Single Nickname draft "is the only aggregated nickname draft that is current active": 

I think that the specific problematic point of this draft is volati= lity of the area names (that are just the collections of the nicknames= of all border RBridges of a given area in this draft). -


This may be - or may be not - a serious technical issue with the pr= oposed approach. In any case I'd say it requires careful analysis.


And, after re-reading your previous email, I think there is a commo= n potential issue with the Aggregate Nicknames approach as such.

Please consider the following scenario (actually mentioned as a security= issue in your email)

  1. There is a L1 one area with multiple b= order RBridges.
  2. Due to some= failure this area is partitioned
  3. Later still, a new RBridge comes up in one of the new areas&nbs= p;and acquires a nickname that is unique in this area
  4. Now the failure that has caused p= artitioning f the area has been repaired. The areas are merged, and so= me RBridges now have duplicate nicknames.
Again, this requires some analysis IMHO.

Regards,
Sasha



From: Donald Eastlake <d= 3e3e3@gmail.com>
Sent: Friday, May 27, 2016 2:41 AM
To: Alexander Vainshtein
Cc: Mingui Zhang; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill= -multilevel-single-nickname@ietf.org; Susan Hares; jon.hudson@gmail.com; Jo= nathan Hardwick; rtg-dir@ietf.org
Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multil= evel-single-nickname
 
Hi Sasha,

On Thu, May 26, 2016 at 2:08 AM, Alexander Vains= htein <A= lexander.Vainshtein@ecitele.com> wrote:
Donald,
Lots of thanks for a very detailed response!

Lots of thanks for very important information about the actual and exp= ected scale of TRILL deployments as well as for presenting some of the= factors (line active-active TRILL operation) that affect the consumption o= f the nickname space. It addresses my question about the reason to go for multi-level IS-IS at all. Flat IGP con= figuration (both IS-IS and OSPF) are very popular in IP/MPLS depl= oyments due to LDP  (and, now, IP/LDP FRR techniques), so this informa= tion was important to me in order to understand that the multi-level TRILL drafts solve a real problem. I woul= d suggest adding this information to the multi-level TRILL draft. 

Sounds reasonable. Something like that can be added to draft-ietf-tril= l-rbridge-multilevel.
 
However, I am still not sure if the Single Nickname draft = (one I have been reviewing)  represents an attempt to sol= ve a real problem. My understanding so far has been that it follows the= Aggregate Nicknames approach in the multi-level TRILL draft, but eliminates the need to assign nicknames to L1 areas. I d= o not see if, even with the scale you have mentioned) this could be a serio= us issue (e.g., contribute significantly to depletion of the nickname space= ). Do I  miss something here?

I'm not sure it matters. If you believe that there is a good reason fo= r aggregated nicknames, this draft is the only aggregated nickname draft th= at is current active and the only such draft that has been adopted by the T= RILL WG. So unless there is some problem with its approach, it seems to me that it should be progressed.
 
The swapping vs. re-write issue I have discussed with Mingui is a pure= case of terminology. AsI have said, I consider it as closed.

As for the metadata issue  - I am perfectly ready to follow the g= uidance of ADs and WG chairs. especially since this policy has recently&nbs= p;undergone serious changes.

Two additional questions - for the sake of my curiosity:
  1. Can possibly you explain what has happened to draft that proposed = using BGP with TRILL?
If you give me a pointer to the specific expired draft, I might rememb= er something about its history. By the way, there is currently a draft in I= DR: draft-idr-ietf-ls-trill. 
  1. Did anybody consider combining IPFRR techniques with TRILL
While I don't recall any specific mention of= it, I don't see that any change would be required to existing TRILL standa= rds. Fast ReRoute would run off the existing link state databases.

Actually, the above applies only to unicast = data. TRILL uses distribution trees for multi-destination data and there is= draft-ietf-trill-resilient-trees which provides back-up distribution trees= sort of like FRR provides back-up paths.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.co= m
 
Regards, and lots of thanks in advance,
Sasha



________________________________________
From: Donald Eastlake <d3e3e3@gmail.com>
Sent: Thursday, May 26, 2016 12:03 AM
To: Alexander Vainshtein
Cc: Mingui Zhang; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares; jon.hudson@gmail.com; Jonathan Hardwick; rtg-dir@ietf.org

Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilevel-si= ngle-nickname

Hi Alexander,

Thanks from me also for your review.  I'd like to chime in with a few<= br> thoughts:

On Wed, May 25, 2016 at 8:23 AM, Alexander Vainshtein
<A= lexander.Vainshtein@ecitele.com> wrote:
>
> Hi Mingui,
> I will try to summarize our agreements and disagreements.
>
> 1.       The scale of TRILL deployments:=
>
> a. I have not seen any specific numbers or references to any
> specific topologies that could really make single-level TRILL not
> scalable enough - neither in the TRILL drafts I've read nor in our
> discussions so far

I am puzzled as to why you think there would be some specific numeric
hard boundary, other than number space or memory space exhaustion,
beyond which you cannot scale. Can you point to a documentation of
such a thing for IP use of IS-IS? Surely it depends on how much
computer power the routers have, link stability, and numerous other
factors.

Just looking at convergence time and approximating it as the amount of
computation required at a typical router in the TRILL campus, it is on
the order of N*(log N) for computation of least cost routes where
there are N routers in a single level campus while it is on the order
of (sqrt N)*(log N) for multi-level, in both cases assuming optimized
calculations. The largest TRILL campuses I am aware of are on the
order of 3,000 routers. So one would expect that converting such a
campus to multi-level TRILL would reduce convergence time by
approximately a factor of 50. Furthermore, one would expect the rate
of failures within each Level 1 area in the multi-level case to be
approximately proportional to the number of links/routers and thus
also fall by one and a half orders of magnitude. Do you claim these
improvements would never be valuable?

There are many other scaling factors such as the size of the link
state database, etc. I believe the informational
draft-ietf-trill-rbridge-multi-level gives a good summary.

> b. Regarding your reference to multiple interconnected TRILL-based
> campuses in your last email: I do not think that TRILL is an
> alternative to or competes with Internet.

I agree that TRILL does not compete with the Internet.  :-)

I believe this facet of the discussion was in connection with the
possibility of TRILL nickname space exhaustion. Consider the following
factors:

1) TRILL supports active-active connection of end stations at the
TRILL edge. Using the techniques in RFC 7781 (Pseudo-Nickname for
Active-Active Access) consumes TRILL nicknames for active-active edge
groups.

2) Assuming, for the moment, you are using multi-level with unique
nicknames, the nickname allocation mechanism will waste many nicknames
due to hierarchical assignment, the same way power-of-two sized IP
subnets waste IP addresses.

3) There is a desire to interconnect TRILL campuses that are under
joint or cooperative management with limited control plane coupling so
as to limit error propagation, etc. There are various possible ways to
do this but most of them assume non-conflicting nicknames (or
non-conflicting level 2 nicknames if the campuses are multi-level).

I admit that even taking the largest existing TRILL campuses I know
about and adding extensive active-active end station support at the
edge and multi-level with unique nicknames that are hierarchically
allocated, you would still probably not exhaust the TRILL nickname
space. But you could be getting close to that hard limit. This seems
like enough reason to me to be advancing a standard where Level 1
areas are aggregated (whether by a single nickname or set of border
router nicknames) to, for all practical purposes, eliminate the
nickname space restriction.

> c. I have also noticed that, once upon a time (4 years ago) there
> was an attempt to use BGP with TRILL. I wonder why this draft has
> been left to expire because, from my POV, BGP is greatly preferable > to multi-level IS-IS when it comes to scalability issues.
>
> 2. Nickname Re-write vs Nickname Swapping: Looks like a clear case
> of misunderstanding between us, probably due to the fact that I am
> not a TRILL expert:
>
> a.       I have used the term "swap= ping" in the same way it is used
> in MPLS (e.g., see RFC 3031 discussing label swapping). In other
> words, from my POV "nickname swapping" and "nickname re= -write" were
> synonyms.
>
> b.      It seems that some yet to be standard= ized extension of TRILL
> considers some dedicated nickname swapping mechanism that carries
> new nicknames in some extension of the TRILL header.  In this
> parlance "nickname re-write" and "nickname swapping&quo= t; are different.

Right. The possibility was discussed some time ago of expanding the
TRILL header so that, for TRILL Data packets going between different
Level 1 Areas, there could be, in effect, two ingress nicknames (an
ingress RBridge nickname and an ingress Area nickname) and two egress
nicknames (an egress RBridge nickname and an egress Area nickname).
Appropriate swapping would occur at border routers to avoid changes in
fast path logic at all non-border routers. Within Level 2, the Area
nicknames would be in the existing header slots that are routed on,
etc. However, as far as I can recall, no specification was ever been
produced for this "nickname swapping" although it is mentioned in= the
informational multi-level draft.

> c.       I think that we now safely cons= ider this discussion issue
> as closed.
>
> 3.       Metadata:
>
> a.       I fully agree that we should he= ar from other RTG-DIR
> members on what exactly (if at all) should be specified to clarify
> the relationship between the Single Nickname draft and RFC 6325

I would note that the IESG policy on "updates" has become very st= rict
recently. It used to be a judgment call. Now, when a Standards Track
RFC merely extends another such RFC so you could implement an instance
of the earlier standard as specified without reference to or violating
the subsequent specification, the IESG will generally prohibit you
from claiming that the subsequent specification "updates" the fir= st.
(I do not particularly agree with this policy change myself.)

> b.      I can only add that, AFAIK, the Multi= -Level TRILL draft,
> being positioned as an Informational, can neither update nor
> obsolete RFC 6325 (which is Standards Track). So there is no issue
> with its metadata being empty.
>
> There is one issue in my original review that we have not discussed > at all - namely, the behavior implied by the Single Nickname draft
> when a new border RBridge is added to a certain area.

I agree that what needs to be done when border RBridges are
added/deleted needs to be clear in the draft.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e3e3@gmail.com<= br>
> Regards,
> Sasha
>
> Office: +972-392= 66302
> Cell:      +972-549266302
> Email:   Alexander.Vainshtein@ecitele.com
>
> From: Mingui Zhang [mailto:zhangmingui@huawei.com]
> Sent: Wednesday, May 25, 2016 6:07 AM
> To: Alexander Vainshtein
> Cc: 'rtg-dir@iet= f.org'; Zhangxian (Xian); trill@ietf.org; draft-ietf-trill-multilevel-single-nickname@ietf.org; Susan Hares; jon.hudson@gmail.com; Jonathan Hardwick
> Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilev= el-single-nickname
>
> Hi Sasha,
>
> Thanks for the comments.
>
>
> [[Sasha]] Do you (or the authors of the multi-level TRILL draft) consi= der deployment scenarios with more than 64K RBridges in a single TRILL camp= us? Is this a realistic scenario?
> [Mingui] We can also doubt whether a domain with more that 2^32 IP rou= ters is a realistic scenario. The fact is that a single campus is usually n= ot allowed to use up the entire 64K namespace. Please consider the scenario= that lots of TRILL campuses are to be interconnected.
>
>
> [[Sasha]] In other words, your draft explicitly states that the area b= order RBridges modify the nicknames in the TRILL header of a packet that cr= osses the Level 2 domain. How is this different from swapping (save from th= e name of the operation)?
> [Mingui] As I said, there is no "swap nickname field" concep= tion in the draft.  Yes, the border RBridge needs to modify the nickna= me but it does not have to modify it through the "swapping" opera= tion. Instead, the border RBridge "replaces" the nickname in the TRILL data packets with its own nickname (rather than a nickname in th= e "swap nickname field" provided by the originating RBridge). Why= authors prefer the replacing operation than the swapping operation? Becaus= e the swapping operation requires a new TRILL header (two additional 16-bit fields) which has not been standardized yet.=
>
> As for the "Updates" metadata, let's see if people on the RT= G-DIR list would give directions.
>
> Best regards,
> Mingui
> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Tuesday, May 24, 2016 6:45 PM
> To: Mingui Zhang
> Cc: 'rtg-dir@iet= f.org'; Zhangxian (Xian); trill@ietf.org<m= ailto:trill@ietf.org>; draft-ietf-trill-multilevel-single-nickname@ietf.org<mailto:draft-ietf-trill-multilevel-single-nickname@ietf.org>; Susan= Hares; jon.hudson@gmail.= com<mailto:jon.hudson@gmail.com>; Jonathan Hardwick
> Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilev= el-single-nickname
>
> Mingui hi!
> Lots of thanks for a prompt response.
>
> A few short comments inline below.
>
> Regards,
> Sasha
>
> Office: +972-392= 66302
> Cell:      +972-549266302
> Email:   Alexander.Vainshtein@ecitele.com<mailto:Alexander.Va= inshtein@ecitele.com>
>
> From: Mingui Zhang [mailto:zhangmingui@huawei.com]
> Sent: Tuesday, May 24, 2016 11:23 AM
> To: Alexander Vainshtein
> Cc: 'rtg-dir@iet= f.org'; Zhangxian (Xian); trill@ietf.org<m= ailto:trill@ietf.org>; draft-ietf-trill-multilevel-single-nickname@ietf.org<mailto:draft-ietf-trill-multilevel-single-nickname@ietf.org>; Susan= Hares; jon.hudson@gmail.= com<mailto:jon.hudson@gmail.com>; Jonathan Hardwick
> Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilev= el-single-nickname
>
> Hi Sasha,
>
> Thanks for your comments. Please see responses inline below.
>
> Thanks,
> Mingui
>
> From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Monday, May 23, 2016 6:13 PM
> To: Mingui Zhang
> Cc: 'rtg-dir@iet= f.org'; Zhangxian (Xian); trill@ietf.org<m= ailto:trill@ietf.org>; draft-ietf-trill-multilevel-single-nickname@ietf.org<mailto:draft-ietf-trill-multilevel-single-nickname@ietf.org>; Susan= Hares (shares@ndzh.co= m<mailto:shares= @ndzh.com>); jon.hudson@gmail.= com<mailto:jon.hudson@gmail.com>; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.c= om<mailto:Jonathan.Hardwick@metaswitch.com>)
> Subject: RE: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilev= el-single-nickname
>
>
> Mingui hi!
>
> Lots of thanks for a prompt response to some of the issues I've raised= in the review.
>
>
>
> Please see some comments to you responses inline below.
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-392= 66302
>
> Cell:      +972-549266302
>
> Email:   Alexander.Vainshtein@ecitele.com<mailto:Alexander.Va= inshtein@ecitele.com>
>
>
>
> -----Original Message-----
> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Mingui Zhang
> Sent: Monday, May 23, 2016 12:31 PM
> To: Alexander Vainshtein; Jonathan Hardwick (Jonathan.Hardwick@metaswitch.c= om<mailto:Jonathan.Hardwick@metaswitch.com>)
> Cc: 'rtg-dir@iet= f.org'; Zhangxian (Xian); trill@ietf.org<m= ailto:trill@ietf.org>; draft-ietf-trill-multilevel-single-nickname@ietf.org<mailto:draft-ietf-trill-multilevel-single-nickname@ietf.org>; Susan= Hares (shares@ndzh.co= m<mailto:shares= @ndzh.com>); jon.hudson@gmail.= com<mailto:jon.hudson@gmail.com>
> Subject: Re: [RTG-DIR] RTG-DIR QA review for draft-ietf-trill-multilev= el-single-nickname
>
>
>
> Hi Alexander,
>
>
>
> Thanks for the review!
>
>
>
> The multilevel conception itself is abstract and not easily understand= able.
>
> [[Sasha]] Do you refer to the multi-level IS-IS in general or multi-le= vel TRILL specifically? I am asking because I believe am reasonably well aw= are of the multi-level architecture of IS-IS as used for IP routing. It is = somewhat different from that of OSPF, but I would not call it "abstract and not easily understandable"= .  And there are quite a few excellent introductions to the subject (a= gain in the context of IP routing). However, I am definitely not a TRILL ex= pert, and have stated that in the review.
>
>
>
> [Mingui] Yes, multi-level arch of IS-IS has already been well understo= od. However, the extending TRILL to multi-levels brings new challenges. As = stated in the informational draft, one issue is on processing the TRILL swi= tch nicknames and the other issue is on handling multi-destination packet distribution trees. In order not to m= ake the specifications "abstract", the draft carefully designed t= wo walking-through examples in Section 3. If the examples were understood, = it would be non-abstract as well. ;-)
>
>
>
> However, it was really interesting in designing such a solution. Appre= ciate the review and the time on relevant documents to figure out the whole= scheme.
>
>
>
> > ?  Nor provides any explanations about the reasons that make=
>
> > single-level IS-IS used by TRILL less scalable that single-level = IS-IS
>
> > when it is used for distributing IP reachability
>
>
>
> The reason comes from the fact that the length of a nickname is differ= ent from an IP address.
>
> [[Sasha]] I must admit that I do not understand the connection. By thi= s logic, IS-IS for CLNS and IPv6 should be much more scalable than IS-IS fo= r IPv4, but I have never seen such claims before. Could you please elaborat= e? Could somebody on the RTG-DIR list to comment on that?
>
>
>
> [Mingui] For a single-level IS-IS instance, the length of the address = determines the name space. In the informational draft, Section 1.1 TRILL Sc= alability Issues, the following statement is relevant
>
> "   5. the limit of the number of TRILL switches, due t= o the 16-bit nickname space,"
>
> [[Sasha]] Do you (or the authors of the multi-level TRILL draft) consi= der deployment scenarios with more than 64K RBridges in a single TRILL camp= us? Is this a realistic scenario?
>
>
>
>
>
> I think this could be addressed in the updated version of the draft: <= a href=3D"https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multile= vel/?include_text=3D1" target=3D"_blank"> https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-multilevel/?inclu= de_text=3D1.
>
>
>
> > *         The draft posit= ions itself as an alternative to the Aggregate
>
> > Nicknames approach while, from my POV, it is just provides additi= onal
>
> > details on one of the possible flavors of this approach
>
>
>
> The WG used to discuss several ways to address the "Aggregate Nic= kname" approach.
>
> [[Sasha]] I do not follow the TRILL WG mailing list, so I am not aware= of any discussions that have been hold there. I am only speaking about wha= t I could find in the two drafts mentioned in my review.
>
>
>
> [Mingui] Actually, the informational draft had included the informatio= n of those alternatives as well. Please see "Section 2.2.2.2 Swap Nick= name Field Aggregated Nicknames" and read the words about "pseudo= node" of Section 2.5

--_000_HE1PR0301MB22661AECB1D962ACAE3E20629D420HE1PR0301MB2266_-- From nobody Fri May 27 07:45:55 2016 Return-Path: <7riw77@gmail.com> X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B88A12D53E; Fri, 27 May 2016 07:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 F40Tcswif64I; Fri, 27 May 2016 07:45:52 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 D6A2D12D551; Fri, 27 May 2016 07:45:51 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id c127so107842647ywb.1; Fri, 27 May 2016 07:45:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=TqR7XI3TXY0zHrCLp264L15fq7o+PVJJyzU0hFoVdGE=; b=buM8sK/qn8SDAfik0BdYaGxYbNC9Ro0ZizrftJjpSnW4MmSnLhzzulrZswXrAJA3/B p0JcuQLcPQ5Q62owKxpzEqFK96hnMnRtaFxjmiJv82Edh8qn/2hR2Xja1JtTtsmFZylD pYstmXXNodluwu5nDlgPN2IdABKtB6jFXccFrtAr1AQ1c9z5ibyT+8tkB7OMJ/f2fmjL NfWLmeb7Psaa/Vf0Ym2SqEHMSxUWMXAeoDmU8aW6xJUqsypqcQC/z/ipTAqq8/Xyq4bY ST6OcWwyk/4Rtp0zJg+ra6146eywq+/uo7qR/J4yqRiCzYRmHLKFb65odOLIYaeL3hsR 46UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=TqR7XI3TXY0zHrCLp264L15fq7o+PVJJyzU0hFoVdGE=; b=H9FCr7gOu9S0zbcchXi7I124B43uAJESfcyY4Lva02R48RNAtniGqmQaOHhttXtlXl cKKwikTIeYAbewN4ssfTtJbgjAVVMwEqiojdMwQdPIWlucIoBsDSJA/vLqIARubuOPrT zw/V+TnUUXKmmuUYp0bqF7SZBbb772Lt7pbFJQH+kgYycSos+cb89vnL1dkb+QLHgVbu fDESjPYdp5OXisP4wpsIq8Jh7ma/yIkf0vs5uoxCFD+Guh7K5jXHt2AAlWPEKb3J/3sN JgTNbZOa56G8xoQBou+oXpGM96JQ9jjUOLoBwT4bEqzqKAR91F4BcsyNXKKSoTn6XzBa acwg== X-Gm-Message-State: ALyK8tKFU31qoLQvQc/qvHGY/VcxJ80q5Nx1YNm5EwL5s/2Ee418h0lcMDSIKND8As7Ftg== X-Received: by 10.13.216.147 with SMTP id a141mr8487810ywe.313.1464360351001; Fri, 27 May 2016 07:45:51 -0700 (PDT) Received: from Russ (162-229-180-77.lightspeed.rlghnc.sbcglobal.net. [162.229.180.77]) by smtp.gmail.com with ESMTPSA id i125sm5524989ywc.26.2016.05.27.07.45.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 May 2016 07:45:50 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: Date: Fri, 27 May 2016 10:45:49 -0400 Message-ID: <03f101d1b826$7624b440$626e1cc0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdG4JXeaPgztMzHRRfyJyq7nsiiK3g== Content-Language: en-us Archived-At: Cc: rtg-dir@ietf.org, draft-ietf-dhc-topo-conf.all@ietf.org Subject: [RTG-DIR] Routing Directorate Review of draft-ietf-dhc-topo-conf-08 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 14:45:53 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or 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 = =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. Document: draft-ietf-dhc-topo-conf-08 Reviewer: Russ White=20 Review Date: 27 May 2016 IETF LC End Date: 23 May 2016 Intended Status: Informational Summary:=20 No issues found. This document is ready for publication. Comments: This is a very useful draft for informational state. Overall, the draft = is well written, the diagrams are helpful, and the references look = correct. Major Issues: None found Minor Issues: None found Nits: It is important to understand the background of how DHCP works when = considering those diagrams. Those/these The relay agent that receives client=E2=80=99s message sets giaddr field = to the address... Either remove "field" after giaddr or add "the" before giaddr I found one or two more really minor nits, but didn't write them down, = and now can't find them again. Generally, though, the quality of this = document is very high, and all nits are very minor. :-) Russ From nobody Fri May 27 11:27:06 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B8F12D7FA; Fri, 27 May 2016 11:27:04 -0700 (PDT) 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 D7UhuMLUJa2h; Fri, 27 May 2016 11:27:03 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 4B1E012D80A; Fri, 27 May 2016 11:27:02 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id w16so37169216lfd.2; Fri, 27 May 2016 11:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=BovtRjWSnFvMky408JyQh87Zn1KBIY7cCpXrHv+0iYg=; b=P10ViIlT4fON/GZTNrjxUFZi8oN4dKcY0UfchMLYTDZvKlJcNuYEY0tJmZFw9WOFe/ 7wE4NaL5q/QRuPEih9rjmw8RZFxLp4UtqDEc9easTecNQ61uciF94mS7pvdwmha0sO1i 7nmiF0hO9NKVpmXeRdRkc0Ik04/sQKlxxNEXKVCSJhjc/nRLsFltQkL2uqVQTTDqH8zi dO2kBmESQk7pZBk374whNNKiXCprXf0BDlwjeix2XXy+yNtP3l+HALeg8LciIMI4aO6B slJcXVKYGfuQvdurKhuxBoHirhwzUTY5lCOzpwLBfvS5if020YHcDco+rAwXpS0OWp8r tWLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=BovtRjWSnFvMky408JyQh87Zn1KBIY7cCpXrHv+0iYg=; b=baaCZPv/CwWJWCZMOTDi4Ripo7mEmTIwNEuq5/+AgkITzi7XbxPAKQr7uQggnlC9bZ nS/1CQCPCYMWz6QZKDg0FLmgV8Agf1fu0uvn03sjkK3C8duuL8dKv+PCg7eljIdtaJSd IzL+jhFAo5lIJW4DSk4IlOU2yjRd6Y7YzfKEoLDAyKrbHnwcdMbpsYUkTVoIuHvaDEza RAB0GtNW1tdtxnUzPx27YUTkROyxus5o5Wzez4/HUIfjqm57U6njmN1RnFs4QL9ngv0m cFZOi3VzOmx5IpfjDNKteCB5MV9vis73m3Ia1OCfkYvTtPxbuHKE7IqeAXpJhlBYIS/O 9Kdw== X-Gm-Message-State: ALyK8tJzmuJNGn5gdrJwM/izRZk7e4y2pa5ldKy4z/ufdzTBUKfhsgTFVRYbI1pDQRgAgQ== X-Received: by 10.25.81.13 with SMTP id f13mr4816302lfb.78.1464373620372; Fri, 27 May 2016 11:27:00 -0700 (PDT) Received: from [10.0.0.100] (088156132194.dynamic-ww-04.vectranet.pl. [88.156.132.194]) by smtp.googlemail.com with ESMTPSA id 83sm742121ljj.1.2016.05.27.11.26.58 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 May 2016 11:26:59 -0700 (PDT) To: Russ White <7riw77@gmail.com>, rtg-ads@ietf.org References: <03f101d1b826$7624b440$626e1cc0$@gmail.com> From: Tomek Mrugalski Message-ID: <57489172.5050002@gmail.com> Date: Fri, 27 May 2016 20:26:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <03f101d1b826$7624b440$626e1cc0$@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: rtg-dir@ietf.org, draft-ietf-dhc-topo-conf.all@ietf.org Subject: Re: [RTG-DIR] Routing Directorate Review of draft-ietf-dhc-topo-conf-08 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 18:27:04 -0000 On 27.05.2016 16:45, Russ White wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or Hi Russ, Thank you for your review and for your kind words. I will fix the nits you reported, but will hold off with uploading corrected version for other comments. If there are other comments, I'll bundle the corrections together. If not (has that ever happened?), I'll make sure these are corrected in RFC Ed phase. Thanks again, Tomek From nobody Mon May 30 04:06:14 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F4012D5B7; Mon, 30 May 2016 04:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 wsHg3blctRHS; Mon, 30 May 2016 04:06:03 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 D17C512D5B9; Mon, 30 May 2016 04:06:02 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 42C1CE88C9B47; Mon, 30 May 2016 10:55:02 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4UAt326029979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 May 2016 10:55:04 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u4UAssTO027975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 May 2016 12:55:03 +0200 Received: from [135.224.193.115] (135.239.27.39) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 30 May 2016 12:55:00 +0200 Message-ID: <574C1C04.4020300@alcatel-lucent.com> Date: Mon, 30 May 2016 12:55:00 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.39] Archived-At: Cc: draft-ietf-trill-multi-topology@ietf.org Subject: [RTG-DIR] QA review of draft-ietf-trill-multi-topology-01 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 11:06:12 -0000 Hi, I have been selected as the Routing Directorate QA reviewer for this draft. Document: draft-ietf-trill-multi-topology-01 Reviewer: Martin Vigoureux Review Date: May 20, 2016 Intended Status: Proposed Standard The draft is both quite well written and well structured such that I did not have to go back and forth in the doc. As a result also, I have only very few editorial comments and questions. Section 1 If routers in the network do not agree on the topology classification of packets or links, persistent routing loops can occur. It is not clear if that could happen in mt-trill or if mt-trill solves that. Section 1.1 goes beyond defining acronyms but specifies some pieces of technology: By implication, an "FGL TRILL switch" does not support MT. An MT TRILL switch MUST support FGL in the sense that it MUST be FGL safe [RFC7172]. Is this the right place to do this? By the way, this requirement is stated further down in the doc. Section 2.2 s/and received/and receive/ Section 2.4 Commonly, the topology of a TRILL Data packet is commonly One superfluous occurrence of "commonly" Section 2.4.1 It would be better to write "2/3" as "2 and 3" A TRILL switch advertising in a Hello on Port P support for topology T but not advertising in those Hellos that it requires explicit topology labeling is assumed to have the ability and configuration to correctly classify TRILL Data packets into topology T by examination of those TRILL Data packets and/or by using the fact that they are arriving at port P. Does this mean that Value 1 is default behaviour? Section 3.4.1 s/are determine/are determined/ Section 7 s/some links was more/some links were more/ From nobody Tue May 31 11:11:44 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E631A12D1CA; Tue, 31 May 2016 11:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 8fWghjE_hzL4; Tue, 31 May 2016 11:11:39 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 A919012D566; Tue, 31 May 2016 11:11:36 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id n63so150598217qkf.0; Tue, 31 May 2016 11:11:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eozcIgMSpbIyrIu3mxSujd1MZxNTQQGLqAfloKdl8qE=; b=IkFgNLSGSazL8xzJL80M6x6hvS/JkIPsUUkLsvVUzZbtTmBznAUrT22gmdGZEcXn1Z vrR5KtgI3CBfDEtQQe/guOMvQ78BJLbqtBY9gjEorjLoJda2GHcNzPnA6LGLH87RqOTm 4N/TZJqLdm3EHjS1iMeQwqc9a1LNPtBDvNxDDqiWVT2hQcCi7Jt8ojlX37xLJU51WOeO B+euRf2khrygBUUj1b5iuFdGV29N4ErVfy9tF+4lmLSVc2/Q81Z1EjKM8woJCEJut2Gm odZjBEWeCw+3w4yX2MQ9rMR5NYgsd/ypbHYrNZd2J0ym9/uhLgOcTIY9vunbwNkPQj1E bxgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eozcIgMSpbIyrIu3mxSujd1MZxNTQQGLqAfloKdl8qE=; b=OycBkoffTuEX1noa0J24hWXRviY5h4F5FQ8rGTI6rMXnsWIjvCndbjfeJHc6cfi644 IlGz9CBn9/yClZUQLE5iWDBhpDPzsH4k4OXlDe+c9gFCx7qLiDAy2Si298trfzVG0nwx 61Sm9evVndkdC1fOZU42bMVYvPvvsJVdQvMRWIMY0IyX7/cBpY6ZGOeqsOFQf0CGqaeE yOnDFnC23Ue/s4hvLEjAM0bQbD83To8b0jVSuhisCqcnjOr/8NtkfYjy7S1Ff9jsEWDF 01bwkw7lLvLWfQ+lKAAJ67x+p3vxO6ny6vbBPUJs2C+mPT9qryglkDRHp3hBeJMPMPZ7 gxuA== X-Gm-Message-State: ALyK8tK8hn11RB6C5mpG0OsIEjA3HYtuTsRC/BvU3r5G6obXc2OkNsm82OPJZ/x1rElS7yR2i4bURJ+qb+AS9A== X-Received: by 10.55.120.196 with SMTP id t187mr32079894qkc.6.1464718295737; Tue, 31 May 2016 11:11:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.40.5 with HTTP; Tue, 31 May 2016 11:11:21 -0700 (PDT) In-Reply-To: <574C1C04.4020300@alcatel-lucent.com> References: <574C1C04.4020300@alcatel-lucent.com> From: Donald Eastlake Date: Tue, 31 May 2016 14:11:21 -0400 Message-ID: To: Martin Vigoureux Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtg-dir@ietf.org" , draft-ietf-trill-multi-topology.all@ietf.org, "trill@ietf.org" Subject: Re: [RTG-DIR] QA review of draft-ietf-trill-multi-topology-01 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 18:11:42 -0000 Hi Martin, Thanks for your review. See response below. On Mon, May 30, 2016 at 6:55 AM, Martin Vigoureux wrote: > Hi, > > I have been selected as the Routing Directorate QA reviewer for this draft. > > Document: draft-ietf-trill-multi-topology-01 > Reviewer: Martin Vigoureux > Review Date: May 20, 2016 > Intended Status: Proposed Standard > > The draft is both quite well written and well structured such that I did not > have to go back and forth in the doc. > As a result also, I have only very few editorial comments and questions. Thanks. > Section 1 > If routers in the network do not agree on the topology > classification of packets or links, persistent routing loops can > occur. > It is not clear if that could happen in mt-trill or if mt-trill solves that. Multi-topology TRILL doesn't specify what kind of traffic should be classified as being in what topology. Indeed, the traffic classified as being in topology T can be arbitrarily different in different parts of the TRILL campus if there are disjoint instances of a topology T. This classification needs to be decided and configuration by network management. This is consistent with how IS-IS multi-topology is used in other applications. So, yes, routing loops can be caused by misconfiguring IS-IS mutli-topology is TRILL or IP. > Section 1.1 goes beyond defining acronyms but specifies some pieces of > technology: > By implication, an "FGL TRILL switch" does not support MT. > An MT TRILL switch MUST support FGL in the sense that it MUST be FGL > safe [RFC7172]. > Is this the right place to do this? By the way, this requirement is stated > further down in the doc. There is a similar sentence at the end of the entry for "VL". The idea is that the capabilities of an "MT TRILL switch" are a superset of the capabilities of an "FGL TRILL switch" which are in turn a superset of the capabilities of a "VL TRILL switch". This is intended to simplify things by having, at least to some extent, a linear sequence of added capabilities rather than the cross product of the presence/absence of each added capability. Sort of MT > FLG > VL. I don't see anything wrong with having these statements here as well as further down in the document. > Section 2.2 > s/and received/and receive/ OK. > Section 2.4 > Commonly, the topology of a TRILL Data packet is commonly > One superfluous occurrence of "commonly" OK. I think deleting the initial "Commonly, " would be a good solution. So the sentence would start "The topology of a TRILL Data packet is commonly ..." > Section 2.4.1 > It would be better to write "2/3" as "2 and 3" OK. > A TRILL switch advertising in a Hello on Port P support for topology > T but not advertising in those Hellos that it requires explicit > topology labeling is assumed to have the ability and configuration to > correctly classify TRILL Data packets into topology T by examination > of those TRILL Data packets and/or by using the fact that they are > arriving at port P. > Does this mean that Value 1 is default behaviour? The first paragraph of Section 2.4.1 makes it clear that the default value of the two bit field in the Port Capabilities sub-TLV is zero and this is also the value assumed if that sub-TLV is not present. I can clarify the statement you quote above but it means exactly what it says. "not advertising in those Hellos that it requires explicit topology labeling" means it is not advertising a value of 2 or 3 in the Explicit Topology capability field. The sentence you quote is already effectively included in the entry text for Explicit Topology capability field value 1. Probably the sentence you quote should be deleted and the applicable portion of should also merged into the text for Explicit Topology capability field value 0. That seems like the best way to reduce confusion. > Section 3.4.1 > s/are determine/are determined/ OK. > Section 7 > s/some links was more/some links were more/ OK. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com