From nobody Thu Apr 6 14:28:54 2017 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 BB7D112966D; Thu, 6 Apr 2017 14:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIjQSE-oWHY5; Thu, 6 Apr 2017 14:28:48 -0700 (PDT) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::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 49A8A12966F; Thu, 6 Apr 2017 14:28:29 -0700 (PDT) Received: by mail-yb0-x22c.google.com with SMTP id l201so13343386ybf.0; Thu, 06 Apr 2017 14:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=+iRgpmmWTBmcK48eKNo26oc5fPnwpXHT/de+fUENhWs=; b=jlKU4LBtdO/aRd8dMS75gGf5XHnVh/ajscdCVAWtwGE8ns53qrjwJDxwbX4AoD2mVB s9MNEnlCgQ336USI7Aj3htTBBleC/i9+a569rWKeUPPUtr34lVw3IxvuD9Ha3LzdhpZ5 Msy8b2GnS/FQVj/T16muue64FdavB6vFSSHLFWigJLvwiFHhL/8F7YP0LhxG/0d9eEW6 LLgZz+HFP5lsOX7ITDomwfBEk3Y+UZ8Fc+KKbarBjhCMOLu9lmUslXPDVNOrVPLx2vDY xddlRNOkBihAlmfqd0Bp8PY+hkOdOJg4W0mcFNK0kWsbBgALEvGR5jpURMS1DuJLZIY6 87Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=+iRgpmmWTBmcK48eKNo26oc5fPnwpXHT/de+fUENhWs=; b=nYnYA7ZHX/gPIGNbJCNoT8wbBo9aOBHQP1iWX69eeHQO6Ohdocn5Xh0payeffgQGVj 0RVPfORBSJEapuRcRp9vGq23XkipUKaO28291YbgLCXVOQ8exjGKBERQT9kwAhr/nsw+ wYN2AqkP77AgRyrI97aNR03jmvtYK+cBOoLRrhS5WCyCXD6PpOAGxj87pXm39Dom5Ebq /FLmEfgiiEt8dBOeekeHjKjOhMD0xN5wtMGlqiowZDo7L0ZmFhDcvUgzMmO6j3te3Y8l TtYvJm/98rvOlnEW4iePOxuNdAAgYTDLFtWPmxWUdEeQzKqTEgFiO52NAM+BbSq8SJqu jiQQ== X-Gm-Message-State: AFeK/H0KdUEpTWy7qXtUwyA0PialxhE9WHUux287CYG6xgH3qOVCMvqXLxWVI8FrPbJEkr2JV7hjQdvk1FtuOw== X-Received: by 10.37.178.167 with SMTP id k39mr24000903ybj.64.1491514107977; Thu, 06 Apr 2017 14:28:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.174.98 with HTTP; Thu, 6 Apr 2017 14:28:27 -0700 (PDT) From: Victoria Pritchard Date: Thu, 6 Apr 2017 22:28:27 +0100 Message-ID: To: rtg-ads@ietf.org Cc: rtg-dir@ietf.org, draft-ietf-pce-pce-initiated-lsp.all@ietf.org, pce@ietf.org Content-Type: multipart/alternative; boundary=f403045f364c9566fe054c86301d Archived-At: Subject: [RTG-DIR] RtgDir review: draft-ietf-pce-pce-initiated-lsp-09 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 21:28:52 -0000 --f403045f364c9566fe054c86301d 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. 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-pce-pce-initiated-lsp-09.txt Reviewer: Victoria Pritchard Review Date: 06 April 2017 IETF LC End Date: Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: Although I was not very familiar with PCEP, I found the draft for the most part easy to understand, but did need to look up some things in the referenced documents and was unclear on a couple of small points. I have some suggestions that may help improve the draft for other readers, and I have some queries which may require clarification in the document. However, as most readers will be more familiar with the subject, perhaps not all comments will require any action. Major Issues: No major issues found. Minor Issues and Nits: Section 1, 1st paragraph Path Control Element / Path Computation Element ? Section 1, 2nd paragraph Stateful pce / Stateful PCE Reference link [I-D.ietf-pce-stateful-pce] points to section 3.1, not the references section. The 2nd sentence was hard to read, could be split into two sentences. Section 2 Last paragraph: Routing Backus-Naur Format / Routing Backus-Naur Form, to match the RFC title. Section 3.1 At the end of the 1st paragraph, "possible agile software-driven network operation" is then repeated in the next paragraph as "A possible use case is a software-driven network" Section 3.2 The acronyms SRP, PLSP and ERO are used a few times in this section. It may well be OK to assume most readers will be familiar with these, but would be good to have the expansion here too. Section 3.2, 3rd paragraph SRP-id-number / SRP-ID-number, for consistency The sentence beginning "The PCE MAY update" could be moved to a new paragraph, to separate it from the text regarding instantiation. Section 3.2, last paragraph Suggest to replace the "and" with a comma in this sentence: "During State Synchronization, a PCC reports the state of its LSPs to the PCE using PCRpt messages and setting the SYNC flag in the LSP Object. " "include the Create Flag" / "set the Create Flag" - also the create flag has not yet been mentioned. Actually I think this overview could be much briefer and simpler. There is a lot of detail about objects, flags and options, which is explained in later sections but complicates this overview. I think it might be good to also summarise here what the extension adds in terms of messages and flags, to clearly indicate what's new compared to the referenced documents. Section 4 After the first sentence, I would rephrase: "First, the Open message must include the Stateful PCE Capability TLV, defined in []." Then continue to the sentence beginning "A new flag is introduced in this TLV, ...". Section 4.1 In the flag bit description, "that the PCE may attempt to instantiate LSPs" could be changed to "that the PCE supports instantiating LSPs". Also rather than "in order to support", use "in order to enable". Not sure this section is necessary in this form with Figure 1. For example, I think the sync-optimizations draft specifies flags in a nice way (Section 7 of that draft), suggesting the bit to use without a diagram. The description here in section 4.1 could be rolled into the main body of Section 4. Also, is there any need to mention the U flag or the S flag in this draft? I noticed a mix and match between terminology of "STATEFUL-PCE-CAPABILITY TLV" vs "Stateful PCE Capability" TLV - could be made consistent, I'd suggest "Stateful PCE Capability TLV" throughout for readability. Also the same applies to "Path Computation LSP Initiate Message", "Path Computation LSP Initiate Request", "LSP Initiate Message", "LSP Initiate Request", "LSP initiation request". Would be nice to see this consistent throughout. Section 5.1 The 1st paragraph could be simplified by removing text about other objects and missing objects, and moving the final two sentences into sections 5.3 and 5.4. The 2nd paragraph states "The format ... for LSP instantiation", but this looks like it applies to deletion too. Suggest to remove "for LSP instantiation". On first read (although most readers will be familiar already) I would have liked to see some mention of what the Common Header is, maybe even just a reference to its definition in RFC5440. Section 5, final paragraph I would suggest you dont need the 3rd sentence at all, as correlation is already mentioned in the 1st sentence in this paragraph. Also, is SRP-ID-number incremented when an operation is requested *from* the PCE? Or *by* the PCE, or in either direction? Is it clearer to say "The PCE increments the current PCEP session's SRP-ID-number before including it in the PCInitiate message" (assuming any other usage is unchanged from the Stateful PCE draft)? Section 5.2 This section could be condensed in a similar way as I mentioned before regarding the I flag in the Capability TLV in Section 4.1. The text could be included at the bottom of section 5.1, and there is no need to draw the SRP object. Also no need for the reference as it's already in section 5.1. Perhaps also state the alternative case, that if the flag is set to 0, it indicates an instantiation request. Section 5.3, 1st paragraph "LSP instantiation is done by" / "The LSP is instantiated by". "an PCInitiate" / "a PCInitiate" Suggest removing the sentence beginning "The LSP is set up" Section 5.3 in general I suggest reorganising this section: -First discuss message contents that should be included for instantiation, i.e., objects mentioned in the format section above, and their contents. -Then once you have defined what the PCInitiate should look like, in new paragraph(s) talk through checking validity of the PCInitiate (non-zero PLSP-ID and missing ERO or SYMBOLIC-PATH-NAME) and discuss the error messages. -Then use the text describing LSP setup based on the info included. -Then discuss the PCRpt. You currently mention PCRpt in a couple of places in this section and it would be easier to read if it was in one place. For clarity, also state that in the PCRpt, both the Delegate and Create flags are in the LSP object. Section 5.3, 8th paragraph. "The PCEP-ERROR object SHOULD include the RSVP Error Spec TLV (if an ERROR SPEC was returned to the PCC by a downstream node)." Is that already covered by the 1st sentence in this paragraph, "relay to the PCE errors it encounters"? Could re-phrase to "If an RSVP Error Spec TLV was returned to the PCC by a downstream node, it should be included in the PCEP-ERROR object in the PCErr message". Also would prefer not to use 2 terms "RSVP Error Spec TLV" and "ERROR SPEC". suggeseted / suggested Is the sentence "After the LSP is set up, errors in RSVP..." necessary? By that I mean does that behaviour differ from normal, is it particular to this extension? Section 5.3, paragraphs 8 and 9 Would you want to inform the PCE of any limits during the capability exchange rather than sending an error later and ignoring further PCE requests? Section 5.3.1 The create flag could be described earlier. As mentioned above, Section 4 would be a good place to detail all the bits newly defined in this draft, the new message, the new flags. Again, I dont think you need to draw a diagram, just describe the flag added and its position within the LSP Object. Section 5.3.2 could be rolled into the description of the create flag since the two would be used together. Also, back in Section 3 it said you SHOULD include the SPEAKER-IDENTITY-ID TLV, whereas 5.3.2 instead uses MAY. SPEAKER-IDENTITY-ID is not actually defined in the sync-optimizations draft - assume you mean SPEAKER-ENTITY-ID? Also just to make it clear, you are re-using that TLV but this time within the LSP Object, and to give the PCE's identity, rather than in the OPEN object to give the speaker's identity? Also in the final sentence: "the TLV MUST be ignored the and the PCE MUST send a PCErr" - there's an extra "the" in the middle, and being very fussy, the TLV is not really ignored if you send an error message. Also if you do send the error message, is the rest of the PCRpt message ignored? Section 5.4 may benefit from splitting into multiple paragraphs, one for each error type, plus another for the final part beginning at "Following the removal". Section 6, 1st paragraph "are automatically delegated": suggest this reads "MUST be delegated". Automatically might imply you dont need to do anything to make this happen. If the PCE returns a delegation to the PCC, would the PCC then end up sending that PCE a PCRpt with the delegation bit set to zero? The first paragraph states that this is an error, but in that case, would it be? As "Redelegation Timeout Interval" and "State Timeout Interval" are both terms defined in the Stateful PCE draft, I would try to use the exact same terminology and same capitalisation found there throughout. Section 6, 3rd paragraph. Where it says "In case of PCEP session failure", does that mean failure at any point in time, or just a failure after the PCE has returned delegation in order to transfer the LSP to a different PCE? Also, is the LSP considered an orphan as soon as the initiating PCE returns delegation to the PCC? Or only if a PCEP session fails? Having these two bits of information in two different paragraphs makes it seem like they are separate but I would think they go together? If I have interpreted this correctly, I would suggest the following text: A PCE MAY return a delegation to the PCC to allow for LSP transfer between PCEs. The PCC will also regain control over a PCE-initiated LSP if the PCEP session fails and the Redelegation Timeout Interval timer expires. In both cases, the LSP is considered an "orphan" and the PCC MUST trigger the State Timeout Interval timer for that LSP ([I-D.ietf-pce-stateful-pce]). But, what is not clear to me, is what is happening at this point to try to delegate to another PCE? From looking at the Stateful PCE draft, I believe the PCC would send a report to 1/any(?) PCE it was connected to, setting the delegate flag to 1 to try to get that PCE to accept delegation. If I interpreted that correctly, i.e. the PCC actively tries to switch delegation to another PCE, it might be worth stating that here. Assuming a reply comes in from that PCE, with the delegate flag set, within the state timeout interval, all is good. However, I was slightly concerned by the statement from the Stateful PCE draft that says: "If the PCE accepts the LSP Delegation, it MUST set the Delegate flag to 1 when it sends an LSP Update Request for the delegated LSP (note that this may occur at a later time)." I dont know how far in the future "a later time" could be, but if the State Timeout Interval expires at the PCC first, wont the LSP get flushed? The text also says that to obtain control, a PCE can send a PCInitiate. So as an alternative to my initial interpretation, does that mean the PCC could advertise the LSP with delegate flag set to zero, and wait for a PCE to take control by sending a PCInitiate as described? This also makes me wonder how/when the initial PCE would decide to give up control? Is that in scope for this draft? Section 6, final paragraph The explanation about the timeout sounds like it applies to Stateful PCE in general, and therefore may not be necessary to explain in this draft? Also, on PCE crash (bearing in mind paragraph 3 above), does the Redelegation Timeout Interval occur first, and then the State Timeout Interval? Section 8.1 Meaning: Initiate. Being really picky, I would like this to match the full term used in this draft "Path Computation LSP Initiate Request" (or whatever term you settle on - see comment above between Section 4.1 and 5.1). This would then match RFC5440's way of doing it for PCReq. Kind regards, Victoria --f403045f364c9566fe054c86301d 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 purp= ose of the review is to provide assistance to the Routing ADs. For more inf= ormation about the Routing Directorate, please see =E2=80=8Bhttp://trac.tools.ietf.or= g/area/rtg/trac/wiki/RtgDir

Although these com= ments 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 y= ou receive, and strive to resolve them through discussion or by updating th= e draft.


Document: draft-ietf-pce-p= ce-initiated-lsp-09.txt=C2=A0
Reviewer: Victoria Pritchard
<= div>Review Date: 06 April 2017
IETF LC End Date: =C2=A0
Intended Status: Standards Track


S= ummary:=C2=A0
I have some minor concerns about this document that= I think should be resolved before publication.

Comments:
Although I was not very familiar with PCEP= , I found the draft for the most part easy to understand, but did need to l= ook up some things in the referenced documents and was unclear on a couple = of small points. I have some suggestions that may help improve the draft fo= r other readers, and I have some queries which may require clarification in= the document. However, as most readers will be more familiar with the subj= ect, perhaps not all comments will require any action.

=

Major Issues:
No major issues found.


Minor Issues and Nits:

=
Section 1, 1st paragraph
Path Control Element / Path Computa= tion Element ?

Section 1, 2nd paragraph
= Stateful pce / Stateful PCE
Reference link [I-D.ietf-pce-stateful= -pce] points to section 3.1, not the references section.=C2=A0
Th= e 2nd sentence was hard to read, could be split into two sentences.

Section 2
Last paragraph: Routing Backus-Naur F= ormat / Routing Backus-Naur Form, to match the RFC title.

Section 3.1
At the end of the 1st paragraph, "possib= le agile software-driven network operation" is then repeated in the ne= xt paragraph as "A possible use case is a software-driven network"= ;

Section 3.2
The acronyms SRP, PLSP and= ERO are used a few times in this section. It may well be OK to assume most= readers will be familiar with these, but would be good to have the expansi= on here too.

Section 3.2, 3rd paragraph
= SRP-id-number / SRP-ID-number, for consistency
The sentence begin= ning "The PCE MAY update" could be moved to a new paragraph, to s= eparate it from the text regarding instantiation.

= Section 3.2, last paragraph
Suggest to replace the "and"= ; with a comma in this sentence:=C2=A0
"During State Synchro= nization, a PCC
=C2=A0 =C2=A0reports the state of its LSPs to the= PCE using PCRpt messages and
=C2=A0 =C2=A0setting the SYNC flag = in the LSP Object. "
"include the Create Flag" / &= quot;set the Create Flag" - also the create flag has not yet been ment= ioned.
Actually I think this overview could be much briefer and s= impler. There is a lot of detail about objects, flags and options, which is= explained in later sections but complicates this overview. I think it migh= t be good to also summarise here what the extension adds in terms of messag= es and flags, to clearly indicate what's new compared to the referenced= documents.

Section 4
After the first se= ntence, I would rephrase: "First, the Open message must include the St= ateful PCE Capability TLV, defined in []." Then continue to the senten= ce beginning "A new flag is introduced in this TLV, ...".

Section 4.1=C2=A0
In the flag bit description, = "that the PCE may attempt to instantiate LSPs" could be changed t= o "that the PCE supports instantiating LSPs".=C2=A0
Als= o rather than "in order to support", use "in order to enable= ".
Not sure this section is necessary in this form with Figu= re 1. For example, I think the sync-optimizations draft specifies flags in = a nice way (Section 7 of that draft), suggesting the bit to use without a d= iagram. The description here in section 4.1 could be rolled into the main b= ody of Section 4. Also, is there any need to mention the U flag or the S fl= ag in this draft?

I noticed a mix and match betwee= n terminology of "STATEFUL-PCE-CAPABILITY TLV" vs "Stateful = PCE Capability" TLV - could be made consistent, I'd suggest "= Stateful PCE Capability TLV" throughout for readability.
Als= o the same applies to "Path Computation LSP Initiate Message", &q= uot;Path Computation LSP Initiate Request", "LSP Initiate Message= ", "LSP Initiate Request", "LSP initiation request"= ;. Would be nice to see this consistent throughout.

Section 5.1
The 1st paragraph could be simplified by removing t= ext about other objects and missing objects, and moving the final two sente= nces into sections 5.3 and 5.4.
The 2nd paragraph states "Th= e format ... for LSP instantiation", but this looks like it applies to= deletion too. Suggest to remove "for LSP instantiation".
On first read (although most readers will be familiar already) I would h= ave liked to see some mention of what the Common Header is, maybe even just= a reference to its definition in RFC5440.=C2=A0

S= ection 5, final paragraph=C2=A0
I would suggest you dont need the= 3rd sentence at all, as correlation is already mentioned in the 1st senten= ce in this paragraph.
Also, is SRP-ID-number incremented when an = operation is requested *from* the PCE? Or *by* the PCE, or in either direct= ion? Is it clearer to say "The PCE increments the current PCEP session= 's SRP-ID-number before including it in the PCInitiate message" (a= ssuming any other usage is unchanged from the Stateful PCE draft)?=C2=A0

Section 5.2=C2=A0
This section could be co= ndensed in a similar way as I mentioned before regarding the I flag in the = Capability TLV in Section 4.1. The text could be included at the bottom of = section 5.1, and there is no need to draw the SRP object. Also no need for = the reference as it's already in section 5.1.=C2=A0
Perhaps a= lso state the alternative case, that if the flag is set to 0, it indicates = an instantiation request.

Section 5.3, 1st paragra= ph=C2=A0
"LSP instantiation is done by" / "The LSP= is instantiated by".=C2=A0
"an PCInitiate" / &quo= t;a PCInitiate"
Suggest removing the sentence beginning &quo= t;The LSP is set up"

Section 5.3 in general
I suggest reorganising this section:
-First discuss mess= age contents that should be included for instantiation, i.e., objects menti= oned in the format section above, and their contents.
-Then once = you have defined what the PCInitiate should look like, in new paragraph(s) = talk through checking validity of the PCInitiate (non-zero PLSP-ID and miss= ing ERO or SYMBOLIC-PATH-NAME) and discuss the error messages.
-T= hen use the text describing LSP setup based on the info included.
-Then discuss the PCRpt. You currently mention PCRpt in a couple of places= in this section and it would be easier to read if it was in one place. For= clarity, also state that in the PCRpt, both the Delegate and Create flags = are in the LSP object.

Section 5.3, 8th paragraph.= "The PCEP-ERROR object SHOULD include the RSVP
=C2=A0 =C2= =A0Error Spec TLV (if an ERROR SPEC was returned to the PCC by a
= =C2=A0 =C2=A0downstream node)."
Is that already covered by t= he 1st sentence in this paragraph, "relay to the PCE errors it encount= ers"? Could re-phrase to "If an RSVP Error Spec TLV was returned = to the PCC by a downstream node, it should be included in the PCEP-ERROR ob= ject in the PCErr message". Also would prefer not to use 2 terms "= ;RSVP Error Spec TLV" and "ERROR SPEC".
suggeseted= / suggested
Is the sentence "After the LSP is set up, error= s in RSVP..." necessary? By that I mean does that behaviour differ fro= m normal, is it particular to this extension?

Sect= ion 5.3, paragraphs 8 and 9
Would you want to inform the PCE of a= ny limits during the capability exchange rather than sending an error later= and ignoring further PCE requests?

Section 5.3.1<= /div>
The create flag could be described earlier. As mentioned above, S= ection 4 would be a good place to detail all the bits newly defined in this= draft, the new message, the new flags. Again, I dont think you need to dra= w a diagram, just describe the flag added and its position within the LSP O= bject.

Section 5.3.2 could be rolled into the desc= ription of the create flag since the two would be used together. Also, back= in Section 3 it said you SHOULD include the SPEAKER-IDENTITY-ID TLV, where= as 5.3.2 instead uses MAY. SPEAKER-IDENTITY-ID is not actually defined in t= he sync-optimizations draft - assume you mean SPEAKER-ENTITY-ID? Also just = to make it clear, you are re-using that TLV but this time within the LSP Ob= ject, and to give the PCE's identity, rather than in the OPEN object to= give the speaker's identity?
Also in the final sentence: &qu= ot;the TLV MUST be ignored the and the PCE MUST send a PCErr" - there&= #39;s an extra "the" in the middle, and being very fussy, the TLV= is not really ignored if you send an error message. Also if you do send th= e error message, is the rest of the PCRpt message ignored?

Section 5.4 may benefit from splitting into multiple paragraphs, o= ne for each error type, plus another for the final part beginning at "= Following the removal".

Section 6, 1st paragr= aph
"are automatically delegated": suggest this reads &= quot;MUST be delegated". Automatically might imply you dont need to do= anything to make this happen.
If the PCE returns a delegation to= the PCC, would the PCC then end up sending that PCE a PCRpt with the deleg= ation bit set to zero? The first paragraph states that this is an error, bu= t in that case, would it be?

As "Redelegation= Timeout Interval" and "State Timeout Interval" are both ter= ms defined in the Stateful PCE draft, I would try to use the exact same ter= minology and same capitalisation found there throughout.=C2=A0
Section 6, 3rd paragraph.
Where it says "In cas= e of PCEP session failure", does that mean failure at any point in tim= e, or just a failure after the PCE has returned delegation in order to tran= sfer the LSP to a different PCE? Also, is the LSP considered an orphan as s= oon as the initiating PCE returns delegation to the PCC? Or only if a PCEP = session fails? Having these two bits of information in two different paragr= aphs makes it seem like they are separate but I would think they go togethe= r? If I have interpreted this correctly, I would suggest the following text= :
=C2=A0 =C2=A0A PCE MAY return a delegation to the PCC to allow = for LSP transfer between
=C2=A0 =C2=A0PCEs. The PCC will also reg= ain control over a PCE-initiated LSP if the PCEP session
=C2=A0 = =C2=A0fails and the Redelegation Timeout Interval timer expires.=C2=A0 In b= oth cases, the
=C2=A0 =C2=A0LSP is considered an "orphan&quo= t; and the PCC MUST trigger the State Timeout Interval=C2=A0
=C2= =A0 =C2=A0timer for that LSP ([I-D.ietf-pce-stateful-pce]).=C2=A0
But, what is not clear to me, is what is happening at this point to try to= delegate to another PCE? From looking at the Stateful PCE draft, I believe= the PCC would send a report to 1/any(?) PCE it was connected to, setting t= he delegate flag to 1 to try to get that PCE to accept delegation. If I int= erpreted that correctly, i.e. the PCC actively tries to switch delegation t= o another PCE, it might be worth stating that here.
Assuming a re= ply comes in from that PCE, with the delegate flag set, within the state ti= meout interval, all is good. However, I was slightly concerned by the state= ment from the Stateful PCE draft that says:
"If the PCE acce= pts the LSP Delegation,
=C2=A0 =C2=A0it MUST set the Delegate fla= g to 1 when it sends an LSP Update
=C2=A0 =C2=A0Request for the d= elegated LSP (note that this may occur at a later
=C2=A0 =C2=A0ti= me)."=C2=A0
I dont know how far in the future "a later = time" could be, but if the State Timeout Interval expires at the PCC f= irst, wont the LSP get flushed?
The text also says that to obtain= control, a PCE can send a PCInitiate. So as an alternative to my initial i= nterpretation, does that mean the PCC could advertise the LSP with delegate= flag set to zero, and wait for a PCE to take control by sending a PCInitia= te as described?
This also makes me wonder how/when the initial P= CE would decide to give up control? Is that in scope for this draft?
<= div>
Section 6, final paragraph
The explanation abo= ut the timeout sounds like it applies to Stateful PCE in general, and there= fore may not be necessary to explain in this draft? Also, on PCE crash (bea= ring in mind paragraph 3 above), does the Redelegation Timeout Interval occ= ur first, and then the State Timeout Interval?

Sec= tion 8.1
Meaning: Initiate. Being really picky, I would like this= to match the full term used in this draft "Path Computation LSP Initi= ate Request" (or whatever term you settle on - see comment above betwe= en Section 4.1 and 5.1). This would then match RFC5440's way of doing i= t for PCReq.


Kind regards,
Victoria
--f403045f364c9566fe054c86301d-- From nobody Fri Apr 7 03:15:30 2017 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 1F3FF129649; Fri, 7 Apr 2017 03:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmrpEQXaKSCK; Fri, 7 Apr 2017 03:15:12 -0700 (PDT) Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 02FD91243FE; Fri, 7 Apr 2017 03:15:12 -0700 (PDT) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 842C35D886B; Fri, 7 Apr 2017 12:15:09 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail2.rd.orange.com (Postfix) with ESMTP id 08FC95D8881; Fri, 7 Apr 2017 12:15:08 +0200 (CEST) Received: from [10.193.71.173] (10.193.71.173) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.319.2; Fri, 7 Apr 2017 12:15:07 +0200 To: Victoria Pritchard References: CC: , , , From: Julien Meuric Organization: Orange Message-ID: <49499463-bf65-c7a5-2452-d2169dc1ce4b@orange.com> Date: Fri, 7 Apr 2017 12:15:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pce-pce-initiated-lsp-09 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 10:15:16 -0000 Hi Vicky, Thank you for your review and this helpful feedback. We'll make sure they're addressed in the next revision. Cheers, Julien Apr. 06, 2017 - pritchardv0@gmail.com: > 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-pce-pce-initiated-lsp-09.txt > Reviewer: Victoria Pritchard > Review Date: 06 April 2017 > IETF LC End Date: > Intended Status: Standards Track > > > Summary: > I have some minor concerns about this document that I think should be > resolved before publication. > > > Comments: > Although I was not very familiar with PCEP, I found the draft for the > most part easy to understand, but did need to look up some things in > the referenced documents and was unclear on a couple of small points. > I have some suggestions that may help improve the draft for other > readers, and I have some queries which may require clarification in > the document. However, as most readers will be more familiar with the > subject, perhaps not all comments will require any action. > > > Major Issues: > No major issues found. > > > Minor Issues and Nits: > > Section 1, 1st paragraph > Path Control Element / Path Computation Element ? > > Section 1, 2nd paragraph > Stateful pce / Stateful PCE > Reference link [I-D.ietf-pce-stateful-pce] points to section 3.1, not > the references section. > The 2nd sentence was hard to read, could be split into two sentences. > > Section 2 > Last paragraph: Routing Backus-Naur Format / Routing Backus-Naur Form, > to match the RFC title. > > Section 3.1 > At the end of the 1st paragraph, "possible agile software-driven > network operation" is then repeated in the next paragraph as "A > possible use case is a software-driven network" > > Section 3.2 > The acronyms SRP, PLSP and ERO are used a few times in this section. > It may well be OK to assume most readers will be familiar with these, > but would be good to have the expansion here too. > > Section 3.2, 3rd paragraph > SRP-id-number / SRP-ID-number, for consistency > The sentence beginning "The PCE MAY update" could be moved to a new > paragraph, to separate it from the text regarding instantiation. > > Section 3.2, last paragraph > Suggest to replace the "and" with a comma in this sentence: > "During State Synchronization, a PCC > reports the state of its LSPs to the PCE using PCRpt messages and > setting the SYNC flag in the LSP Object. " > "include the Create Flag" / "set the Create Flag" - also the create > flag has not yet been mentioned. > Actually I think this overview could be much briefer and simpler. > There is a lot of detail about objects, flags and options, which is > explained in later sections but complicates this overview. I think it > might be good to also summarise here what the extension adds in terms > of messages and flags, to clearly indicate what's new compared to the > referenced documents. > > Section 4 > After the first sentence, I would rephrase: "First, the Open message > must include the Stateful PCE Capability TLV, defined in []." Then > continue to the sentence beginning "A new flag is introduced in this > TLV, ...". > > Section 4.1 > In the flag bit description, "that the PCE may attempt to instantiate > LSPs" could be changed to "that the PCE supports instantiating LSPs". > Also rather than "in order to support", use "in order to enable". > Not sure this section is necessary in this form with Figure 1. For > example, I think the sync-optimizations draft specifies flags in a > nice way (Section 7 of that draft), suggesting the bit to use without > a diagram. The description here in section 4.1 could be rolled into > the main body of Section 4. Also, is there any need to mention the U > flag or the S flag in this draft? > > I noticed a mix and match between terminology of > "STATEFUL-PCE-CAPABILITY TLV" vs "Stateful PCE Capability" TLV - could > be made consistent, I'd suggest "Stateful PCE Capability TLV" > throughout for readability. > Also the same applies to "Path Computation LSP Initiate Message", > "Path Computation LSP Initiate Request", "LSP Initiate Message", "LSP > Initiate Request", "LSP initiation request". Would be nice to see this > consistent throughout. > > Section 5.1 > The 1st paragraph could be simplified by removing text about other > objects and missing objects, and moving the final two sentences into > sections 5.3 and 5.4. > The 2nd paragraph states "The format ... for LSP instantiation", but > this looks like it applies to deletion too. Suggest to remove "for LSP > instantiation". > On first read (although most readers will be familiar already) I would > have liked to see some mention of what the Common Header is, maybe > even just a reference to its definition in RFC5440. > > Section 5, final paragraph > I would suggest you dont need the 3rd sentence at all, as correlation > is already mentioned in the 1st sentence in this paragraph. > Also, is SRP-ID-number incremented when an operation is requested > *from* the PCE? Or *by* the PCE, or in either direction? Is it clearer > to say "The PCE increments the current PCEP session's SRP-ID-number > before including it in the PCInitiate message" (assuming any other > usage is unchanged from the Stateful PCE draft)? > > Section 5.2 > This section could be condensed in a similar way as I mentioned before > regarding the I flag in the Capability TLV in Section 4.1. The text > could be included at the bottom of section 5.1, and there is no need > to draw the SRP object. Also no need for the reference as it's already > in section 5.1. > Perhaps also state the alternative case, that if the flag is set to 0, > it indicates an instantiation request. > > Section 5.3, 1st paragraph > "LSP instantiation is done by" / "The LSP is instantiated by". > "an PCInitiate" / "a PCInitiate" > Suggest removing the sentence beginning "The LSP is set up" > > Section 5.3 in general > I suggest reorganising this section: > -First discuss message contents that should be included for > instantiation, i.e., objects mentioned in the format section above, > and their contents. > -Then once you have defined what the PCInitiate should look like, in > new paragraph(s) talk through checking validity of the PCInitiate > (non-zero PLSP-ID and missing ERO or SYMBOLIC-PATH-NAME) and discuss > the error messages. > -Then use the text describing LSP setup based on the info included. > -Then discuss the PCRpt. You currently mention PCRpt in a couple of > places in this section and it would be easier to read if it was in one > place. For clarity, also state that in the PCRpt, both the Delegate > and Create flags are in the LSP object. > > Section 5.3, 8th paragraph. "The PCEP-ERROR object SHOULD include the RSVP > Error Spec TLV (if an ERROR SPEC was returned to the PCC by a > downstream node)." > Is that already covered by the 1st sentence in this paragraph, "relay > to the PCE errors it encounters"? Could re-phrase to "If an RSVP Error > Spec TLV was returned to the PCC by a downstream node, it should be > included in the PCEP-ERROR object in the PCErr message". Also would > prefer not to use 2 terms "RSVP Error Spec TLV" and "ERROR SPEC". > suggeseted / suggested > Is the sentence "After the LSP is set up, errors in RSVP..." > necessary? By that I mean does that behaviour differ from normal, is > it particular to this extension? > > Section 5.3, paragraphs 8 and 9 > Would you want to inform the PCE of any limits during the capability > exchange rather than sending an error later and ignoring further PCE > requests? > > Section 5.3.1 > The create flag could be described earlier. As mentioned above, > Section 4 would be a good place to detail all the bits newly defined > in this draft, the new message, the new flags. Again, I dont think you > need to draw a diagram, just describe the flag added and its position > within the LSP Object. > > Section 5.3.2 could be rolled into the description of the create flag > since the two would be used together. Also, back in Section 3 it said > you SHOULD include the SPEAKER-IDENTITY-ID TLV, whereas 5.3.2 instead > uses MAY. SPEAKER-IDENTITY-ID is not actually defined in the > sync-optimizations draft - assume you mean SPEAKER-ENTITY-ID? Also > just to make it clear, you are re-using that TLV but this time within > the LSP Object, and to give the PCE's identity, rather than in the > OPEN object to give the speaker's identity? > Also in the final sentence: "the TLV MUST be ignored the and the PCE > MUST send a PCErr" - there's an extra "the" in the middle, and being > very fussy, the TLV is not really ignored if you send an error > message. Also if you do send the error message, is the rest of the > PCRpt message ignored? > > Section 5.4 may benefit from splitting into multiple paragraphs, one > for each error type, plus another for the final part beginning at > "Following the removal". > > Section 6, 1st paragraph > "are automatically delegated": suggest this reads "MUST be delegated". > Automatically might imply you dont need to do anything to make this > happen. > If the PCE returns a delegation to the PCC, would the PCC then end up > sending that PCE a PCRpt with the delegation bit set to zero? The > first paragraph states that this is an error, but in that case, would > it be? > > As "Redelegation Timeout Interval" and "State Timeout Interval" are > both terms defined in the Stateful PCE draft, I would try to use the > exact same terminology and same capitalisation found there throughout. > > Section 6, 3rd paragraph. > Where it says "In case of PCEP session failure", does that mean > failure at any point in time, or just a failure after the PCE has > returned delegation in order to transfer the LSP to a different PCE? > Also, is the LSP considered an orphan as soon as the initiating PCE > returns delegation to the PCC? Or only if a PCEP session fails? Having > these two bits of information in two different paragraphs makes it > seem like they are separate but I would think they go together? If I > have interpreted this correctly, I would suggest the following text: > A PCE MAY return a delegation to the PCC to allow for LSP transfer > between > PCEs. The PCC will also regain control over a PCE-initiated LSP if > the PCEP session > fails and the Redelegation Timeout Interval timer expires. In both > cases, the > LSP is considered an "orphan" and the PCC MUST trigger the State > Timeout Interval > timer for that LSP ([I-D.ietf-pce-stateful-pce]). > But, what is not clear to me, is what is happening at this point to > try to delegate to another PCE? From looking at the Stateful PCE > draft, I believe the PCC would send a report to 1/any(?) PCE it was > connected to, setting the delegate flag to 1 to try to get that PCE to > accept delegation. If I interpreted that correctly, i.e. the PCC > actively tries to switch delegation to another PCE, it might be worth > stating that here. > Assuming a reply comes in from that PCE, with the delegate flag set, > within the state timeout interval, all is good. However, I was > slightly concerned by the statement from the Stateful PCE draft that says: > "If the PCE accepts the LSP Delegation, > it MUST set the Delegate flag to 1 when it sends an LSP Update > Request for the delegated LSP (note that this may occur at a later > time)." > I dont know how far in the future "a later time" could be, but if the > State Timeout Interval expires at the PCC first, wont the LSP get flushed? > The text also says that to obtain control, a PCE can send a > PCInitiate. So as an alternative to my initial interpretation, does > that mean the PCC could advertise the LSP with delegate flag set to > zero, and wait for a PCE to take control by sending a PCInitiate as > described? > This also makes me wonder how/when the initial PCE would decide to > give up control? Is that in scope for this draft? > > Section 6, final paragraph > The explanation about the timeout sounds like it applies to Stateful > PCE in general, and therefore may not be necessary to explain in this > draft? Also, on PCE crash (bearing in mind paragraph 3 above), does > the Redelegation Timeout Interval occur first, and then the State > Timeout Interval? > > Section 8.1 > Meaning: Initiate. Being really picky, I would like this to match the > full term used in this draft "Path Computation LSP Initiate Request" > (or whatever term you settle on - see comment above between Section > 4.1 and 5.1). This would then match RFC5440's way of doing it for PCReq. > > > Kind regards, > Victoria From nobody Mon Apr 10 09:30:54 2017 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 116A4129562; Mon, 10 Apr 2017 09:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.08 X-Spam-Level: X-Spam-Status: No, score=0.08 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 oqWtYUpkl7Bp; Mon, 10 Apr 2017 09:30:51 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DBD2129566; Mon, 10 Apr 2017 09:30:48 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E465D20A39; Mon, 10 Apr 2017 12:30:47 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Mon, 10 Apr 2017 12:30:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=pPIOmGvi3h3CNmSqo8 6+Cir9qjMN8vBpY9fZcV1Emrw=; b=HI3I8AaniqFK3tEs+fUhgerqW/7y0n+e/6 l9a7Kx5tL5n142gJ9Hu9GFZ3y90QPAqGY04pBEZUgkbDKh34upYaquzGflmhYV4G VIGvevvBdUvWMs1RYR8WApi2JKdi5+TVn229eP+nTDYehF535rJDLcAl8B+uIVQI d9MR8CypNFishjIWO3mYf/WnqJlf8vyDNyfH+dmjX3wtIY4mZpMTyglCZd//t/OB 8g+HklnuJbtIU5u7Qy+V625UQeF/6aD++sikFT/qtE/OJdYL60A306pQGAUNFxvx u8hk+WcT1uBXDHvHDrgpRINnmxo2tG6itjaUMlUBdm89NUK2nc0w== X-ME-Sender: X-Sasl-enc: FAP5sK5ZKrc+2iZ+BpdGnvqI23qW2yvzVas+YO361MVS 1491841847 Received: from Russ (108-78-210-25.lightspeed.chrlnc.sbcglobal.net [108.78.210.25]) by mail.messagingengine.com (Postfix) with ESMTPA id 7249F7E334; Mon, 10 Apr 2017 12:30:47 -0400 (EDT) From: "Russ White" To: Cc: , , Date: Mon, 10 Apr 2017 12:30:44 -0400 Message-ID: <006601d2b217$cddc3b40$6994b1c0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdKyF7al9Ze3c3FfS0qlnu1Vd/Vu5g== Content-Language: en-us Archived-At: Subject: [RTG-DIR] RtgDir review: draft-ietf-grow-bgp-reject-04 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 16:30: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-grow-bgp-reject-04 Reviewer: Russ White Review Date: 10 April 2017 Intended Status: Standards Track Summary:=20 No issues found. This document is ready for publication. Comments: The draft is mercifully short and very readable, clearly noting the = requirements on implementations and their consequences. Major Issues: No major issues found. Minor Issues: No minor issues found. :-) /r From nobody Tue Apr 11 17:08:39 2017 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 90842128B51 for ; Tue, 11 Apr 2017 17:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEheDWFG8efy for ; Tue, 11 Apr 2017 17:08:37 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 B5108127419 for ; Tue, 11 Apr 2017 17:08:36 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id z109so7425740wrb.1 for ; Tue, 11 Apr 2017 17:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=rgP7Sv3t3mn4CcAiMUENY+c1kI0hOlvTCvwLP6fI+0s=; b=VU1NqAypR5cyY1AB44EhlSEZBal/t/ZMAv4pvZQD50mQHQMWJdTHl5Vg6Gtx1RjH/Q qgG4/me6+jchOK6Wyla2aTYBPjRAoxJTgiBUiEhcabKLxgjHMTBVKwWI5y3UtajNeJsI fY9m0yLs3BHKhdn26mWwXEvdwRu4NZFIGKOm086Y2oqACIKs3INxHAWE/7U1I8NhZ+Zy I+k3sqmpD8pdUJ4POkxssoQ4Xvl7GLKwcgCvjH1TTcqhwp78NrD6C1uohfcX4yr0+S8a kpWZ7n+jz7tsEr9DwxY+Kehp3gNCozkzEqaKHZDnBFlVjN3w/06sP8pC/aO/Qs/RU69O HPHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rgP7Sv3t3mn4CcAiMUENY+c1kI0hOlvTCvwLP6fI+0s=; b=OVb3WK4YNjqt51LpoeOYt4DioyeGkWI5c3ZYAKR/oGgySHYHZLXNrelEAf75qw9gfm 6bMlNpFZUNQlCPxyhwpfjXHbu779BpjeWLd+xTyRbDzqbSvNPFfJW3lzOJ0FMo3V9gA4 mgCxIWQTF4pPFZwBaekioXpgxu4M2bzTrQlPm/Ef2eIFkj/BD2JeSRppFa3M13lWD1ax qFXNKKeDi3kmYAYjvsUsBWxKrmE9fOmre7D8sbe/qrumoefuNClsR45AKa9YbxWtI2Y1 4tEkd3fILEYbRgDZGScqsvX/CDYP4LZ4Cq59hkRYgJNaIuayZGLguHTz04tr04RKabKd laxw== X-Gm-Message-State: AN3rC/71tFU8+IddQLU3amuLRK3qqooVTBkwR5YwgEmHUWuxup8ZognjzpzTZF7PS+rI++ytb6mNJPWNB/SMYg== X-Received: by 10.223.150.120 with SMTP id c53mr236891wra.85.1491955714823; Tue, 11 Apr 2017 17:08:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.135.125 with HTTP; Tue, 11 Apr 2017 17:08:34 -0700 (PDT) From: Alia Atlas Date: Tue, 11 Apr 2017 20:08:34 -0400 Message-ID: To: "rtg-dir@ietf.org" Content-Type: multipart/alternative; boundary=001a113e1156671c7d054ced02c3 Archived-At: Subject: [RTG-DIR] extremely rapid reviews/comments on "Effects of Encryption" (draft-mm-wg-effect-encrypt) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 00:08:38 -0000 --001a113e1156671c7d054ced02c3 Content-Type: text/plain; charset=UTF-8 draft-mm-wg-effect-encrypt reads very differently to folks depending on their background, as you can see from the thread starting at https://www.ietf.org/mail-archive/web/ietf/current/msg102367.html It is back on the IESG telechat for this Thursday. It's unclear whether that will resolve the discussion about the document or if it will continue. If any of you were motivated to read the draft and provide a calm and rational review that is respectful of different viewpoints, that would be appreciated. Thanks, Alia --001a113e1156671c7d054ced02c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
draft-mm-wg-effect-encrypt reads very differently to fo= lks depending on their background, as you

It is back on the IESG telechat for this= Thursday.=C2=A0 It's unclear whether that will resolve the discussion = about the document or if it will continue.

If any = of you were motivated to read the draft and provide a calm and rational rev= iew that is respectful of different viewpoints, that would be appreciated.<= /div>

Thanks,
Alia
--001a113e1156671c7d054ced02c3-- From nobody Wed Apr 12 01:35:59 2017 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 53FA612EBF7 for ; Wed, 12 Apr 2017 01:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.874 X-Spam-Level: X-Spam-Status: No, score=-0.874 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, HTTP_ESCAPED_HOST=1.125, RCVD_IN_DNSWL_NONE=-0.0001, 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 ivlyW5iLzZVZ for ; Wed, 12 Apr 2017 01:35:49 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 9ABFA12EA97 for ; Wed, 12 Apr 2017 01:35:48 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id o21so12578554wrb.2 for ; Wed, 12 Apr 2017 01:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=E6F9ZfI0unM21t6DUNF7ZFHTb3wHkBeBsYw+r0qaaXw=; b=s86DCrCohRg3ReHrscKMHWRr+MHUzRgdyA13TZ+n63KXZF0LRQKiapkUDn8e6AV5i1 TmqnKJrrZvfYU/yMIj8W9inGw64p17nRSwAVouTLxem5KmE1I4hFSewXaLoejfJa1UBA JPvmy5If24uYrEWsGUIredPrHwsbAHLJC5n7TP9ItjlN+uMOSoapJB9xu57z5FLutypS 3ddK3FrQ3/uByFGCSuGNvw4R6HoCMMsJCCu+md5+wEFz0z/TsZlQ//+mI06oSNQ6CR+M appJZtIbz/yQuleIB4QluxJBW9SkGcR9KhW8iNPGeyevc0eyNZJK4M+qtH4iI3Wj9PeK ZIlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=E6F9ZfI0unM21t6DUNF7ZFHTb3wHkBeBsYw+r0qaaXw=; b=chD8302IRRJ0SYPM5CE6HurQwuXKdJE5pWysArluW6JKbZbqPg0SB4jth6jxUsjCaK iHZT/qMMuYLF/SmRUeT7kX/hXLYU9pUewmutopfS5DEZ/yn1Kts4M2nv+uRsrPc5KNre /GH2UalzoPhKPmIqedhdVHn6toV3pOehm9ztbfA49e7FhtslfShQN2zMrfQSSn2KW2ep rnrvVVniq4VbJ/+is0mK/tLYfaBUxDBvC+31NtaiQyrA0HNTplUJsgf5X+mMJIuo7Fli +28fJLw+IJrPuWLXFSZDoDkMDmB6ilSBziIMiF3/5TySj/K0BmBA5h2x9QnkCMd/2kpy FqcQ== X-Gm-Message-State: AN3rC/4/WU+Uz8NNVC5XkR5yR8v7YyD8HbGXWHgxdeDU/FNBaSnjWj7/pSRLygWW/rcj9A== X-Received: by 10.223.135.234 with SMTP id c39mr1849709wrc.16.1491986147132; Wed, 12 Apr 2017 01:35:47 -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 q31sm24152792wrb.3.2017.04.12.01.35.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 01:35:46 -0700 (PDT) To: Alia Atlas , "rtg-dir@ietf.org" References: From: Stewart Bryant Message-ID: <2b643b0e-9e73-f8dd-51d1-b6c8fec53a54@gmail.com> Date: Wed, 12 Apr 2017 09:35:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BF9E2E8FC004CA7F6ACD5BF4" Archived-At: Subject: Re: [RTG-DIR] extremely rapid reviews/comments on "Effects of Encryption" (draft-mm-wg-effect-encrypt) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 08:35:57 -0000 This is a multi-part message in MIME format. --------------BF9E2E8FC004CA7F6ACD5BF4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 12/04/2017 01:08, Alia Atlas wrote: > draft-mm-wg-effect-encrypt > <%20https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/>reads > very differently to folks depending on their background, as you > can see from the thread starting at > https://www.ietf.org/mail-archive/web/ietf/current/msg102367.html > > It is back on the IESG telechat for this Thursday. It's unclear > whether that will resolve the discussion about the document or if it > will continue. > > If any of you were motivated to read the draft and provide a calm and > rational review that is respectful of different viewpoints, that would > be appreciated. > > Thanks, > Alia I only have time to scan read this before tomorrow, but I think Alexey Melnikov's comment summarises what I gleaned from the document so far: "This document is not perfect, but I found it to be generally useful". This is a subject that we need a more open discussion about in the IETF. You would think from the vocal IETF position that the situation was a clear cut: monitoring is bad therefore encryption is good. What this document is trying to demonstrate is that there are pluses and minuses to encryption, just as there are are pluses and minuses to traffic monitoring. This document therefore attempts to moves us to a more balanced discussion of the problem, and as such it makes a valuable contribution to the design of the Internet. If at the end of there is no IESG consensus to publish this in the IETF stream, I think it should be taken to the Independent stream the purpose of which is to provide a platform to articulate well thought out technical views that are contra to the mainstream position. - Stewart --------------BF9E2E8FC004CA7F6ACD5BF4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 12/04/2017 01:08, Alia Atlas wrote:
draft-mm-wg-effect-encrypt reads very differently to folks depending on their background, as you

It is back on the IESG telechat for this Thursday.  It's unclear whether that will resolve the discussion about the document or if it will continue.

If any of you were motivated to read the draft and provide a calm and rational review that is respectful of different viewpoints, that would be appreciated.

Thanks,
Alia

I only have time to scan read this before tomorrow, but I think Alexey Melnikov's comment summarises what I gleaned from the document so far: "This document is not perfect, but I found it to be generally useful".

This is a subject that we need a more open discussion about in the IETF. You would think from the vocal IETF position that the situation was a clear cut: monitoring is bad therefore encryption is good. What this document is trying to demonstrate is that there are pluses and minuses to encryption, just as there are are pluses and minuses to traffic monitoring. This document therefore  attempts to moves us to a more balanced discussion of the problem, and as such it makes a valuable contribution to the design of the Internet.

If at the end of there is no IESG consensus to publish this in the IETF stream, I think it should be taken to the Independent stream the purpose of which is to provide a platform to articulate well thought out technical views that are contra to the mainstream position.

- Stewart


--------------BF9E2E8FC004CA7F6ACD5BF4-- From nobody Wed Apr 12 04:35:50 2017 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 7DFD2131674 for ; Wed, 12 Apr 2017 04:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, HTTP_ESCAPED_HOST=1.125, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 UwneGI40sZ5i for ; Wed, 12 Apr 2017 04:35:46 -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 81589131672 for ; Wed, 12 Apr 2017 04:35:45 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v3CBZJhC010442; Wed, 12 Apr 2017 07:35:42 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049295.ppops.net-00191d01. with ESMTP id 29s8dnkdpg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Apr 2017 07:35:42 -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 v3CBZflO008228; Wed, 12 Apr 2017 07:35:41 -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 v3CBZZsk008148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Apr 2017 07:35:36 -0400 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 12 Apr 2017 11:35:26 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.58]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0319.002; Wed, 12 Apr 2017 07:35:26 -0400 From: "BRUNGARD, DEBORAH A" To: Stewart Bryant CC: Alia Atlas , "rtg-dir@ietf.org" Thread-Topic: [RTG-DIR] extremely rapid reviews/comments on "Effects of Encryption" (draft-mm-wg-effect-encrypt) Thread-Index: AQHSsyDx07zuiuo7YUyhSUB/oCUCeaHBrFkA///vJmU= Date: Wed, 12 Apr 2017 11:35:25 +0000 Message-ID: References: , <2b643b0e-9e73-f8dd-51d1-b6c8fec53a54@gmail.com> In-Reply-To: <2b643b0e-9e73-f8dd-51d1-b6c8fec53a54@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_FFED38AEB7994D7892C5A23C32917120attcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-12_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704120098 Archived-At: Subject: Re: [RTG-DIR] extremely rapid reviews/comments on "Effects of Encryption" (draft-mm-wg-effect-encrypt) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 11:35:49 -0000 --_000_FFED38AEB7994D7892C5A23C32917120attcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Much thanks Stewart, you have hit the problem which has been troubling me t= o voice. It's very hard to say which sentences are concerning but it comes across as= a "view" (tone) of the document - operators vs. ietf and privacy advocates= . Operators are extremely concerned on privacy - both as individuals and our = companies. It's only that our current tools which we have are based on a pr= e-encrypted era. It would be really bad for all of us if this document went IS with this int= erpretation as the "view" of the operator sector. Sent from my iPhone On Apr 12, 2017, at 4:36 AM, Stewart Bryant > wrote: On 12/04/2017 01:08, Alia Atlas wrote: draft-mm-wg-effect-encrypt <%20https://datatracker.ietf.org/doc/draft-mm-wg= -effect-encrypt/> reads very differently to folks depending on their backgr= ound, as you can see from the thread starting at https://www.ietf.org/mail-archive/web/i= etf/current/msg102367.html It is back on the IESG telechat for this Thursday. It's unclear whether th= at will resolve the discussion about the document or if it will continue. If any of you were motivated to read the draft and provide a calm and ratio= nal review that is respectful of different viewpoints, that would be apprec= iated. Thanks, Alia I only have time to scan read this before tomorrow, but I think Alexey Meln= ikov's comment summarises what I gleaned from the document so far: "This do= cument is not perfect, but I found it to be generally useful". This is a subject that we need a more open discussion about in the IETF. Yo= u would think from the vocal IETF position that the situation was a clear c= ut: monitoring is bad therefore encryption is good. What this document is t= rying to demonstrate is that there are pluses and minuses to encryption, ju= st as there are are pluses and minuses to traffic monitoring. This document= therefore attempts to moves us to a more balanced discussion of the probl= em, and as such it makes a valuable contribution to the design of the Inter= net. If at the end of there is no IESG consensus to publish this in the IETF str= eam, I think it should be taken to the Independent stream the purpose of wh= ich is to provide a platform to articulate well thought out technical views= that are contra to the mainstream position. - Stewart --_000_FFED38AEB7994D7892C5A23C32917120attcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Much thanks Stewart, you have hit the problem which has been troubling= me to voice.

It's very hard to say which sentences are co= ncerning but it comes across as a "view" (tone) of the document -= operators vs. ietf and privacy advocates.

Operators are extremely concerned on privacy= - both as individuals and our companies. It's only that our current tools = which we have are based on a pre-encrypted era.

It would be really bad for all of us if this= document went IS with this interpretation as the "view" of the o= perator sector.

Sent from my iPhone

On Apr 12, 2017, at 4:36 AM, Stewart Bryant <stewart.bryant@gmail.com> wrote:



On 12/04/2017 01:08, Alia Atlas wrote:
draft-mm-wg-effect-encrypt reads very differently to folks depending on their background, as you

It is back on the IESG telechat for this Thursday.  It's unclear = whether that will resolve the discussion about the document or if it will c= ontinue.

If any of you were motivated to read the draft and provide a calm and = rational review that is respectful of different viewpoints, that would be a= ppreciated.

Thanks,
Alia

I only have time to scan read this before tomorrow, but I think Alexey Meln= ikov's comment summarises what I gleaned from the document so far: "Th= is document is not perfect, but I found it to be generally useful".
This is a subject that we need a more open discussion about in the IETF. Yo= u would think from the vocal IETF position that the situation was a clear c= ut: monitoring is bad therefore encryption is good. What this document is t= rying to demonstrate is that there are pluses and minuses to encryption, just as there are are pluses and min= uses to traffic monitoring. This document therefore  attempts to moves= us to a more balanced discussion of the problem, and as such it makes a va= luable contribution to the design of the Internet.

If at the end of there is no IESG consensus to publish this in the IETF str= eam, I think it should be taken to the Independent stream the purpose of wh= ich is to provide a platform to articulate well thought out technical views= that are contra to the mainstream position.

- Stewart


--_000_FFED38AEB7994D7892C5A23C32917120attcom_-- From nobody Thu Apr 13 20:11:03 2017 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 11C1A129489; Thu, 13 Apr 2017 20:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.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 JjQ6-BQdKvnb; Thu, 13 Apr 2017 20:11:00 -0700 (PDT) Received: from dispatch1-us1.ppe-hosted.com (connect-us.pphosted.com [67.231.154.164]) (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 500CB12947D; Thu, 13 Apr 2017 20:11:00 -0700 (PDT) Received: from pure.maildistiller.com (unknown [10.110.50.29]) by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id 85CF680067; Fri, 14 Apr 2017 03:10:59 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx3-us4.ppe-hosted.com (unknown [10.110.49.251]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id E9BA080049; Fri, 14 Apr 2017 03:10:58 +0000 (UTC) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0111.outbound.protection.outlook.com [207.46.163.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx3-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id A8E476005B; Fri, 14 Apr 2017 03:10:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WdCjh2IXYuHC7Ib0KKCqyY2SIG+IzyOZanqTBLVEth0=; b=TPodemULmJ2Y4AQc4ATVo4v259aORJvKNbdJANQ7vymzbv0kzHPdQpLcdbinzCJpEMcsrseeYPRIEcs/UJd1Hr9K0W6fTtaeA+WTApvjLOH8GQCSBhbVCRgHpyK3vISfGW/iANKQMnSbQrBwvWEjFx0WIr/LmnaMLrPCmzKunic= Received: from BY2PR18MB0262.namprd18.prod.outlook.com (10.163.72.152) by BY2PR18MB0263.namprd18.prod.outlook.com (10.163.72.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.17; Fri, 14 Apr 2017 03:10:55 +0000 Received: from BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) by BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) with mapi id 15.01.1034.013; Fri, 14 Apr 2017 03:10:55 +0000 From: Keyur Patel To: "rtg-dir@ietf.org" CC: "amy.yemin@huawei.com" , "rtg-ads@ietf.org" Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-pals-p2mp-pw-lsp-ping Thread-Index: AQHStMy7HHMYUH0StEa7qHi2peugqw== Date: Fri, 14 Apr 2017 03:10:55 +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=arrcus.com; x-originating-ip: [2601:646:8981:c940:185b:635f:1208:66d8] x-microsoft-exchange-diagnostics: 1; BY2PR18MB0263; 7:sX7EeK/xy4u1ne4UNbefjxymQzUxJAp9S+9vDBH+4h0ioenXUDtcHc3kmCSlOcHQMtFknL71mNHGOorzHxUF7IKLVTsaL3woAdFCpR2CZslp+glcdMmjheJ9RHLwSfoNZnQJjZdTxWedEVDKlEzPEhQYZfzx3hxiBSy6wrWX4mvKih3pFvSkJpIU8rVyodH4PVtkuEFblKuhJfDC/XQn1aAouqzwB9qAxVFkOskK2R3uCuJSc9a6QmPTGSq1sWxGiq0wK6pjhnzs2TB3arkHwU8EKqVTQxT8aM9t9h8xe4vEY6GA0rmaikQtQzOhw0V6LgE08HxxWeRM3WAsXHC/sw== x-ms-office365-filtering-correlation-id: 5f79c315-e8f4-4ef7-7a23-08d482e3ddb5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201702281549075); SRVR:BY2PR18MB0263; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(2016111802025)(6043046)(6072148); SRVR:BY2PR18MB0263; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0263; x-forefront-prvs: 02778BF158 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39410400002)(39830400002)(39400400002)(39450400003)(6916009)(50986999)(54356999)(81166006)(8676002)(2351001)(8936002)(36756003)(7736002)(7906003)(102836003)(6116002)(189998001)(2900100001)(33656002)(230783001)(5660300001)(122556002)(6506006)(99286003)(3660700001)(2906002)(25786009)(77096006)(53936002)(6486002)(4326008)(6512007)(6306002)(54896002)(236005)(2501003)(6436002)(110136004)(5640700003)(38730400002)(86362001)(606005)(82746002)(83716003)(3280700002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR18MB0263; H:BY2PR18MB0262.namprd18.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DF8B9098B3B74DE3B286172E62D2F8C9arrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2017 03:10:55.3365 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR18MB0263 X-MDID: 1492139459-hwBZf6Ugt-mF Archived-At: Subject: [RTG-DIR] RtgDir review: draft-ietf-pals-p2mp-pw-lsp-ping X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 03:11:02 -0000 --_000_DF8B9098B3B74DE3B286172E62D2F8C9arrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W1Jlc2VuZGluZyB0byBSVEctRElSXQ0KDQpIZWxsbywNCg0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQg YXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBS b3V0aW5nIERpcmVjdG9yYXRlIHNlZWtzIHRvIHJldmlldyBhbGwgcm91dGluZyBvciByb3V0aW5n LXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkgcGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJ RVNHIHJldmlldywgYW5kIHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVlc3QuIFRoZSBwdXJwb3Nl IG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFE cy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBs ZWFzZSBzZWUg4oCLaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtp L1J0Z0Rpcg0KDQpBbHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUg dXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQg Y29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50 cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoIGRp c2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0Lg0KDQpEb2N1bWVudDogZHJhZnQtaWV0 Zi1wYWxzLXAybXAtcHctbHNwLXBpbmcNClJldmlld2VyOiBLZXl1ciBQYXRlbA0KUmV2aWV3IERh dGU6IDEzIEFwcmlsIDIwMTcNCkludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIFRyYWNrDQoNClN1 bW1hcnk6DQoNCk5vIGlzc3VlcyBmb3VuZC4gVGhpcyBkb2N1bWVudCBpcyByZWFkeSBmb3IgcHVi bGljYXRpb24uDQoNCkNvbW1lbnRzOg0KDQpUaGUgZHJhZnQgaXMgc2hvcnQgYW5kIHZlcnkgcmVh ZGFibGUuDQoNCk1ham9yIElzc3VlczoNCg0KTm8gbWFqb3IgaXNzdWVzIGZvdW5kLg0KDQpNaW5v ciBJc3N1ZXM6DQoNCk5vIG1pbm9yIGlzc3VlcyBmb3VuZC4NCg0KUmVnYXJkcywNCktleXVyDQoN Cg== --_000_DF8B9098B3B74DE3B286172E62D2F8C9arrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: <01E74C5BD461D4408A0B291975FDA0F2@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i IzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5bUmVzZW5k aW5nIHRvIFJURy1ESVJdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5IZWxsbyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkgaGF2 ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0 aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJv dXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRG IGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZA0KIHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJl cXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNl IHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRp bmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUg4oCLPGEgaHJlZj0iaHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpciI+aHR0cDovL3RyYWMudG9vbHMuaWV0 Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpcjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFsdGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJp bHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURzLCBpdCB3b3VsZCBiZSBoZWxwZnVsIGlm IHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90aGVyIElFVEYgTGFzdCBD YWxsIGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVt DQogdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBkcmFmdC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkRvY3VtZW50OiBkcmFmdC1pZXRmLXBh bHMtcDJtcC1wdy1sc3AtcGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5SZXZpZXdlcjogS2V5dXIgUGF0 ZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+UmV2aWV3IERhdGU6IDEzIEFwcmlsIDIwMTc8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+SW50ZW5kZWQgU3RhdHVzOiBTdGFuZGFyZHMgVHJhY2s8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlN1bW1hcnk6Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5ObyBpc3N1ZXMgZm91bmQuIFRoaXMgZG9jdW1l bnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Q29tbWVudHM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5UaGUgZHJhZnQgaXMgc2hvcnQgYW5kIHZlcnkgcmVhZGFibGUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NYWpvciBJc3N1ZXM6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5ObyBtYWpvciBpc3N1ZXMgZm91bmQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NaW5vciBJc3N1ZXM6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5ObyBtaW5vciBpc3N1 ZXMgZm91bmQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5SZWdh cmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5LZXl1cjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DF8B9098B3B74DE3B286172E62D2F8C9arrcuscom_-- From nobody Thu Apr 13 23:02:52 2017 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 26F15129407; Thu, 13 Apr 2017 23:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 C0dOF6-C6fvH; Thu, 13 Apr 2017 23:02:48 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0105.outbound.protection.outlook.com [104.47.33.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A7A1128B90; Thu, 13 Apr 2017 23:02:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Jf7cg3xCs8WMOSKb6vWyZTacrKWEwy7rWsOCNAoO400=; b=Jppgy70AlAskIFh9kE+NW1Lv3yWj9E42tf5MUxPi1mu2x1UtHtKLlccnIG1oDnJMP90EUGaKsDR9yO5XlnPN7jZ7YFDqXTO5gnWuCceDO70AdsKoXQtlGUr12QDa2gN3edbV/DvNhC8kYB3kzwPz20L4vs/SMf56CxX88yiN/b8= Received: from CY1PR05MB2521.namprd05.prod.outlook.com (10.167.10.136) by CY1PR05MB2524.namprd05.prod.outlook.com (10.167.10.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.5; Fri, 14 Apr 2017 06:02:45 +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.1047.006; Fri, 14 Apr 2017 06:02:45 +0000 From: Ravi Singh To: "rtg-dir@ietf.org" CC: "draft-ietf-idr-bgpls-segment-routing-epe@ietf.org" , "idr@ietf.org" Thread-Topic: Review of draft-ietf-idr-bgpls-segment-routing-epe Thread-Index: AdK044TTNOR7tL3ASl6OLN2+c3aCsQ== Date: Fri, 14 Apr 2017 06:02:45 +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.10] x-microsoft-exchange-diagnostics: 1; CY1PR05MB2524; 7:nU/a7Nc5BpIiZUbJ+4/LJTNTfbZhYLbmmSUSztHxv7Gt8d9A0h3SxV78SbRtoI7Xus9GcGKM+Ov5Gns/9F4riFLgeqK/IR+z+uimXBBJtK4B+REe65eoXkYtxBZmwynIPROk4y4IlXdhJOWILaZe0wjfKcMQLfzjaz/fSjDqzmkPpsXj0S2OComqNJqg/tNu+8kh0QeU71H3Vga4SndjrGR2tIBIhbul+of6LV5sYVNK6oGY87Yy9cK3HnJj7esXgxM9tqPE82xxqgIx/uL0PVQ8y+dnOUshDB+Ay+otqUvx7BSSPr01izinYdWKcA9+shVFRI5nJIbRot+lJnGeTQ== x-ms-office365-filtering-correlation-id: fe060ba1-19bc-41bd-b95e-08d482fbdf1e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:CY1PR05MB2524; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:CY1PR05MB2524; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2524; x-forefront-prvs: 02778BF158 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39450400003)(39860400002)(39410400002)(39400400002)(39850400002)(790700001)(3846002)(102836003)(86362001)(6116002)(5660300001)(189998001)(25786009)(450100002)(68736007)(54356999)(50986999)(7736002)(110136004)(38730400002)(74316002)(4326008)(5630700001)(33656002)(230783001)(2501003)(2900100001)(77096006)(6916009)(9326002)(2351001)(9686003)(55016002)(54906002)(81166006)(8936002)(54896002)(8676002)(6306002)(3280700002)(2906002)(99286003)(6506006)(53936002)(3660700001)(122556002)(66066001)(5640700003)(7696004)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2524; H:CY1PR05MB2521.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR05MB25215A10F4E4372407A31F13AB050CY1PR05MB2521namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2017 06:02:45.7266 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2524 Archived-At: Subject: [RTG-DIR] Review of draft-ietf-idr-bgpls-segment-routing-epe X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 06:02:50 -0000 --_000_CY1PR05MB25215A10F4E4372407A31F13AB050CY1PR05MB2521namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I had been designated as the RTG-DIR reviewer for this draft. Overall the draft is clear. However, it could be use some editorial revision for improved readability. Specific comments listed below: 1. Document title could be less heavy on consecutive adjectives: some= suggestions: a. BGP-LS extensions for Segment Routing BGP Egress Peer Engineering b. BGP-LS extensions for "BGP-EPE using SR" c. Segment Routing BGP Egress Peer Engineering extensions for BGP-LS ... 2. Section 1: " This document defines new types of segments: a Peer Node segment describing the BGP session between two nodes; a Peer Adjacency Segment describing the link (one or more) that is used by the BGP session; the Peer Set Segment describing an arbitrary set of sessions or links between the local BGP node and its peers." Above has an unintended meaning. This should instead have stated that this = doc defines BGP-LS extensions to communicate the above listed SIDs that are= defined in "draft-ietf-spring-segment-routing" 3. Section 3: " This document defines the BGP-EPE Peering Segments: o Peer Node Segment (Peer-Node-SID) o Peer Adjacency Segment (Peer-Adj-SID) o Peer Set Segment (Peer-Set-SID)" Same issue as listed above for section 1 above. Section 5 has the same issue. 4. Section 4.2: I'd suggest that this be broken into 2 separate sub-s= ections: each listing the mandatory/optional sub-TLVs for the local and rem= ote node descriptors respectively. That will make for improved readability. 5. Section 4.2: please clarify in text as to Why no "BGP-LS ID" in li= nk NLRI in the remote node descriptor. 6. Section 4.3: a. values of the flags are specified only for the Per-Adj-SID. Explic= it text should be listed for per-node-SID and per-set-SID. b. " The Peer-Node-SID MUST be present when BGP-LS is used for the use case described in [I-D.ietf-spring-segment-routing-central-epe] and MAY be omitted for other use cases." Is there really a need to state what other use-cases might do, considering = that this doc is specific to BGP-LS for SR-EPE? Perhaps can be reworded. Si= milarly for "Peer-Adj-SID and Peer-Set-SID SubTLVs MAY" in next paragraph. 7. There is some repetition of info between sections 4 & 5. eg. What = local and remote node descriptors contain. Please reword these sections to = avoid the repetition while still presenting the info. 8. Sections 5.1 & 5.2: have lots of repetitive text. Tabular presenta= tion of the text in these sections would allow describing per-node-sid and = per-adj-sid without the repetition. 9. Section 9: typo in language in first sentence. 10. Section 10: please explicitly call out any additional (beyond rfc7752= ) security considerations or include text stating that none exist. 11. Typos a. Section 3: i. "an BGP-EPE" -> "a BGP= -EPE" b. Section 4: i. "Link-type" NLRI -> "l= ink-state" NLRI? Regards Ravi --_000_CY1PR05MB25215A10F4E4372407A31F13AB050CY1PR05MB2521namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

I had been designated as= the RTG-DIR reviewer for this draft.

 =

Overall the draft is cle= ar.

However, it could be use= some editorial revision for improved readability.

 =

Specific comments listed= below:

 =

1.  =      Document title c= ould be less heavy on consecutive adjectives: some suggestions:<= /span>

a.  =      BGP-LS extension= s for Segment Routing BGP Egress Peer Engineering

b.  =     BGP-LS extension= s for "BGP-EPE using SR"

c.  =      Segment Routing = BGP Egress Peer Engineering extensions for BGP-LS

…

2.  =      Section 1:<= /o:p>

"   This document defines new types of segments: a Peer= Node segment

   describing the BGP session between two nodes; a Peer Adja= cency

   Segment describing the link (one or more) that is used by= the BGP

   session; the Peer Set Segment describing an arbitrary set= of sessions

   or links between the local BGP node and its peers."<= o:p>

Above has an unintended meaning. This should instead have stated that = this doc defines BGP-LS extensions to communicate the above listed SIDs tha= t are defined in "draft-ietf-spring-segment-routing"

 

3.  =      Section 3: =

"

   This document defines the BGP-EPE Peering Segments:<= /o:p>

 

   o  Peer Node Segment (Peer-Node-SID)

 

   o  Peer Adjacency Segment (Peer-Adj-SID)<= /span>

 

  o  Peer Set Segment (Peer-Set-SID)"

 

Same issue as listed above for section 1 above.

Section 5 has the same issue.

 

4.  =      Section 4.2: I'd= suggest that this be broken into 2 separate sub-sections: each listing the= mandatory/optional sub-TLVs for the local and remote node descriptors resp= ectively. That will make for improved readability.

 

5.  =      Section 4.2: ple= ase clarify in text as to Why no "BGP-LS ID" in link NLRI in the = remote node descriptor.

 

6.  =      Section 4.3:

a.  =      values of the fl= ags are specified only for the Per-Adj-SID. Explicit text should be listed = for per-node-SID and per-set-SID.

b.  =     "

   The Peer-Node-SID MUST be present when BGP-LS is used for = the use

   case described in [I-D.ietf-spring-segment-routing-central= -epe] and

   MAY be omitted for other use cases."

Is there really a need to state what other use-cases might do, consider= ing that this doc is specific to BGP-LS for SR-EPE? Perhaps can be reworded= . Similarly for "Peer-Adj-SID and Peer-Set-SID SubTLVs MAY" in next paragraph.

 

7.  =      There is some re= petition of info between sections 4 & 5. eg. What local and remote node= descriptors contain. Please reword these sections to avoid the repetition = while still presenting the info.

 

8.  =      Sections 5.1 &am= p; 5.2: have lots of repetitive text. Tabular presentation of the text in t= hese sections would allow describing per-node-sid and per-adj-sid without t= he repetition.

 

9.  =      Section 9: typo = in language in first sentence.

 

10.  = ; Section 10: plea= se explicitly call out any additional (beyond rfc7752) security considerati= ons or include text stating that none exist.

 

11.  = ; Typos=

a.  =       Section 3:=

  &n= bsp;            = ;            &n= bsp;           i.  = ;          "an BGP-EPE" -> "= a BGP-EPE"

b.  =     Section 4:<= /o:p>

  &n= bsp;            = ;            &n= bsp;           i.  = ;          "Link-type" NLRI -> &q= uot;link-state" NLRI?

 

Regards

Ravi

 

--_000_CY1PR05MB25215A10F4E4372407A31F13AB050CY1PR05MB2521namp_-- From nobody Fri Apr 14 10:55:27 2017 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 111831294F0; Fri, 14 Apr 2017 10:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lw3TL9LZiFkx; Fri, 14 Apr 2017 10:55:17 -0700 (PDT) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id 528B61294CF; Fri, 14 Apr 2017 10:55:14 -0700 (PDT) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8FE2AE3009E; Fri, 14 Apr 2017 19:55:13 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 7A260E3009A; Fri, 14 Apr 2017 19:55:13 +0200 (CEST) Received: from [10.192.150.180] (10.192.150.180) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.319.2; Fri, 14 Apr 2017 19:55:13 +0200 From: Julien Meuric To: , CC: "rtg-dir@ietf.org" Organization: Orange Message-ID: Date: Fri, 14 Apr 2017 19:55:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Archived-At: Subject: [RTG-DIR] Routing Directorate QA Review of draft-ietf-trill-multilevel-unique-nickname X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 17:55:19 -0000 Hello, I have been selected as the Routing Directorate QA reviewer for this draft. For more information about the Routing Directorate, please see €‹http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir At this stage, the intend of the following is not to discuss the WG's decision about the I-D, but rather to help improving its content. Please note that, even though I have reviewed a few TRILL I-Ds in the past, I do not consider myself as being fluent in TRILL (yet?). _Summary_ The document defines a protocol extension which looks both correctly motivated and correctly scoped. However, the current wording of the behavior requires some improvement to become clear enough to someone who has not followed the associated discussions. _Comments_ There are mainly 2 sections which deserve improvement. First, the 3rd paragraph in section 3.2 is requires that "global Data Labels are disabled". Without more background, the phrase could refer to: - no global label is used/advertised, - received global labels are ignored/dropped, - received global labels are explicitly refused, - global labels are not distinguished from local labels (as suggested by the parenthesis). >From the following sentence, I understand that a legacy RBridge may benefit from global trees, however does it makes sense if that legacy RBridge is in a level 1 area and "MUST guarantee that global Data Labels are disabled"? Then, in section 4.3, I faced several (minor) issues. 1- The calculation of the length field seems incorrect. The formula looks aligned on the 1st figure on pages 9/10, depicting Nickname Blocks as 16-bit fields, however the bottom of page 10 defines them as 32 bits. As a result, the figure should extend the Nickname Block fields up to 2 "lines" and the length calculation would thus change to "2 + 4*K". 2- The definition of the set OK flag has puzzled me. Assuming it is meant to enable a border RBridge to advertise the Nickname Blocks associated to its attached Level 1 area, its definition is currently specified in a Level 1 context, and then scoped to both Levels 1 and 2. However, the definition wording for Level 1 is not applicable to Level 2. This could certainly be addressed either by a more generic definition (e.g. "Blocks associated to its attached Level 1 area") or by a 2-step definition: - "advertisement in Level 1 means...", - "advertisement in Level 2 means...". _Nits_ Page 3: - s/referred as the "unique nickname"/referred to as the "unique nickname"/ - s/that are transitions between/that transition between/ - s/RBrides/RBridges/ On figure 3.1, area boudaries looked odd, how about... Area X level 2 Area Y +-----------------+ +---------------------+ +------------+ | | | | | | S---RB27---Rx--Rz---RB2---Rb---Rc--Rd---Re--RB3---Rk--RB44---D | 27 | | | | 44 | | | | | | | +-----------------+ +---------------------+ +------------+ On page 4: - s/Let's say/Let us say/ - s/let's say/let us say/ On page 5: - s/only different is/only difference is/ On Figure 3.2, I assume that the order of the names on the first line does not change anything, but I have been puzzled not to find RB2 as the list head. Have you considered putting it as the 1st one of the list? On page 9, the word "artificial" seems both odd and useless. In section 5, RFC 7176 is used as a fallback mechanism for incompatible RBridges. What about its uses in other cases? Is it still allowed (though less efficient) or precluded? A clarification would be useful (maybe in section 4.3). On page 13, "TreeSel" is now RFC 7968. Regards, Julien From nobody Sun Apr 16 23:49:30 2017 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 8040B124C27; Sun, 16 Apr 2017 23:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMaEG52ToVnv; Sun, 16 Apr 2017 23:49:19 -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 4C35A1243F6; Sun, 16 Apr 2017 23:49:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLD85939; Mon, 17 Apr 2017 06:49:15 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 17 Apr 2017 07:49:13 +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; Mon, 17 Apr 2017 14:49:10 +0800 From: "Zhangmingui (Martin)" To: Julien Meuric , "trill@ietf.org" , "draft-ietf-trill-multilevel-unique-nickname.all@ietf.org" CC: "rtg-dir@ietf.org" Thread-Topic: Routing Directorate QA Review of draft-ietf-trill-multilevel-unique-nickname Thread-Index: AQHStUhQS888Gx2xcU+LdY8dWLXMfKHJIXyQ Date: Mon, 17 Apr 2017 06:49:09 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7A6461C31@NKGEML515-MBX.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="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.0A020201.58F4656C.0064, 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: a8c1740015df98219e76f9ba107918a6 Archived-At: Subject: Re: [RTG-DIR] Routing Directorate QA Review of draft-ietf-trill-multilevel-unique-nickname X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 06:49:22 -0000 SGkgSnVsaWVuLA0KDQpUaGFua3MgYSBsb3QgZm9yIHRoZSBjYXJlZnVsIHJldmlldy4gV2Ugd2ls bCBpbXByb3ZlIHRoZSBkcmFmdCBhcyB5b3Ugc3VnZ2VzdGVkIGFuZCBnZXQgYmFjayB0byB5b3Ug c29vbi4NCg0KQmVzdCByZWdhcmRzLA0KTWluZ3VpDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogSnVsaWVuIE1ldXJpYyBbbWFpbHRvOmp1bGllbi5tZXVyaWNAb3Jhbmdl LmNvbV0NCj4gU2VudDogU2F0dXJkYXksIEFwcmlsIDE1LCAyMDE3IDE6NTUgQU0NCj4gVG86IHRy aWxsQGlldGYub3JnOyBkcmFmdC1pZXRmLXRyaWxsLW11bHRpbGV2ZWwtdW5pcXVlLW5pY2tuYW1l LmFsbEBpZXRmLm9yZw0KPiBDYzogcnRnLWRpckBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSb3V0aW5n IERpcmVjdG9yYXRlIFFBIFJldmlldyBvZg0KPiBkcmFmdC1pZXRmLXRyaWxsLW11bHRpbGV2ZWwt dW5pcXVlLW5pY2tuYW1lDQo+IA0KPiBIZWxsbywNCj4gDQo+IEkgaGF2ZSBiZWVuIHNlbGVjdGVk IGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIFFBIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBG b3INCj4gbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxl YXNlIHNlZQ0KPiDCgMKLaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93 aWtpL1J0Z0Rpcg0KPiANCj4gQXQgdGhpcyBzdGFnZSwgdGhlIGludGVuZCBvZiB0aGUgZm9sbG93 aW5nIGlzIG5vdCB0byBkaXNjdXNzIHRoZSBXRydzIGRlY2lzaW9uDQo+IGFib3V0IHRoZSBJLUQs IGJ1dCByYXRoZXIgdG8gaGVscCBpbXByb3ZpbmcgaXRzIGNvbnRlbnQuDQo+IA0KPiBQbGVhc2Ug bm90ZSB0aGF0LCBldmVuIHRob3VnaCBJIGhhdmUgcmV2aWV3ZWQgYSBmZXcgVFJJTEwgSS1EcyBp biB0aGUgcGFzdCwgSSBkbw0KPiBub3QgY29uc2lkZXIgbXlzZWxmIGFzIGJlaW5nIGZsdWVudCBp biBUUklMTCAoeWV0PykuDQo+IA0KPiBfU3VtbWFyeV8NCj4gVGhlIGRvY3VtZW50IGRlZmluZXMg YSBwcm90b2NvbCBleHRlbnNpb24gd2hpY2ggbG9va3MgYm90aCBjb3JyZWN0bHkNCj4gbW90aXZh dGVkIGFuZCBjb3JyZWN0bHkgc2NvcGVkLiBIb3dldmVyLCB0aGUgY3VycmVudCB3b3JkaW5nIG9m IHRoZSBiZWhhdmlvcg0KPiByZXF1aXJlcyBzb21lIGltcHJvdmVtZW50IHRvIGJlY29tZSBjbGVh ciBlbm91Z2ggdG8gc29tZW9uZSB3aG8gaGFzIG5vdA0KPiBmb2xsb3dlZCB0aGUgYXNzb2NpYXRl ZCBkaXNjdXNzaW9ucy4NCj4gDQo+IF9Db21tZW50c18NCj4gVGhlcmUgYXJlIG1haW5seSAyIHNl Y3Rpb25zIHdoaWNoIGRlc2VydmUgaW1wcm92ZW1lbnQuDQo+IA0KPiBGaXJzdCwgdGhlIDNyZCBw YXJhZ3JhcGggaW4gc2VjdGlvbiAzLjIgaXMgcmVxdWlyZXMgdGhhdCAiZ2xvYmFsIERhdGEgTGFi ZWxzIGFyZQ0KPiBkaXNhYmxlZCIuIFdpdGhvdXQgbW9yZSBiYWNrZ3JvdW5kLCB0aGUgcGhyYXNl IGNvdWxkIHJlZmVyIHRvOg0KPiAtIG5vIGdsb2JhbCBsYWJlbCBpcyB1c2VkL2FkdmVydGlzZWQs DQo+IC0gcmVjZWl2ZWQgZ2xvYmFsIGxhYmVscyBhcmUgaWdub3JlZC9kcm9wcGVkLA0KPiAtIHJl Y2VpdmVkIGdsb2JhbCBsYWJlbHMgYXJlIGV4cGxpY2l0bHkgcmVmdXNlZCwNCj4gLSBnbG9iYWwg bGFiZWxzIGFyZSBub3QgZGlzdGluZ3Vpc2hlZCBmcm9tIGxvY2FsIGxhYmVscyAoYXMgc3VnZ2Vz dGVkIGJ5IHRoZQ0KPiBwYXJlbnRoZXNpcykuDQo+ID5Gcm9tIHRoZSBmb2xsb3dpbmcgc2VudGVu Y2UsIEkgdW5kZXJzdGFuZCB0aGF0IGEgbGVnYWN5IFJCcmlkZ2UgbWF5DQo+IGJlbmVmaXQgZnJv bSBnbG9iYWwgdHJlZXMsIGhvd2V2ZXIgZG9lcyBpdCBtYWtlcyBzZW5zZSBpZiB0aGF0IGxlZ2Fj eSBSQnJpZGdlIGlzDQo+IGluIGEgbGV2ZWwgMSBhcmVhIGFuZCAiTVVTVCBndWFyYW50ZWUgdGhh dCBnbG9iYWwgRGF0YSBMYWJlbHMgYXJlIGRpc2FibGVkIj8NCj4gDQo+IFRoZW4sIGluIHNlY3Rp b24gNC4zLCBJIGZhY2VkIHNldmVyYWwgKG1pbm9yKSBpc3N1ZXMuDQo+IA0KPiAxLSBUaGUgY2Fs Y3VsYXRpb24gb2YgdGhlIGxlbmd0aCBmaWVsZCBzZWVtcyBpbmNvcnJlY3QuIFRoZSBmb3JtdWxh IGxvb2tzIGFsaWduZWQNCj4gb24gdGhlIDFzdCBmaWd1cmUgb24gcGFnZXMgOS8xMCwgZGVwaWN0 aW5nIE5pY2tuYW1lIEJsb2NrcyBhcyAxNi1iaXQgZmllbGRzLA0KPiBob3dldmVyIHRoZSBib3R0 b20gb2YgcGFnZSAxMCBkZWZpbmVzIHRoZW0gYXMgMzIgYml0cy4NCj4gQXMgYSByZXN1bHQsIHRo ZSBmaWd1cmUgc2hvdWxkIGV4dGVuZCB0aGUgTmlja25hbWUgQmxvY2sgZmllbGRzIHVwIHRvIDIg ImxpbmVzIg0KPiBhbmQgdGhlIGxlbmd0aCBjYWxjdWxhdGlvbiB3b3VsZCB0aHVzIGNoYW5nZSB0 byAiMiArIDQqSyIuDQo+IA0KPiAyLSBUaGUgZGVmaW5pdGlvbiBvZiB0aGUgc2V0IE9LIGZsYWcg aGFzIHB1enpsZWQgbWUuIEFzc3VtaW5nIGl0IGlzIG1lYW50IHRvDQo+IGVuYWJsZSBhIGJvcmRl ciBSQnJpZGdlIHRvIGFkdmVydGlzZSB0aGUgTmlja25hbWUgQmxvY2tzIGFzc29jaWF0ZWQgdG8g aXRzDQo+IGF0dGFjaGVkIExldmVsIDEgYXJlYSwgaXRzIGRlZmluaXRpb24gaXMgY3VycmVudGx5 IHNwZWNpZmllZCBpbiBhIExldmVsIDEgY29udGV4dCwNCj4gYW5kIHRoZW4gc2NvcGVkIHRvIGJv dGggTGV2ZWxzIDEgYW5kIDIuDQo+IEhvd2V2ZXIsIHRoZSBkZWZpbml0aW9uIHdvcmRpbmcgZm9y IExldmVsIDEgaXMgbm90IGFwcGxpY2FibGUgdG8gTGV2ZWwgMi4gVGhpcw0KPiBjb3VsZCBjZXJ0 YWlubHkgYmUgYWRkcmVzc2VkIGVpdGhlciBieSBhIG1vcmUgZ2VuZXJpYyBkZWZpbml0aW9uIChl LmcuICJCbG9ja3MNCj4gYXNzb2NpYXRlZCB0byBpdHMgYXR0YWNoZWQgTGV2ZWwgMSBhcmVhIikg b3IgYnkgYSAyLXN0ZXANCj4gZGVmaW5pdGlvbjoNCj4gLSAiYWR2ZXJ0aXNlbWVudCBpbiBMZXZl bCAxIG1lYW5zLi4uIiwNCj4gLSAiYWR2ZXJ0aXNlbWVudCBpbiBMZXZlbCAyIG1lYW5zLi4uIi4N Cj4gDQo+IF9OaXRzXw0KPiBQYWdlIDM6DQo+IC0gcy9yZWZlcnJlZCBhcyB0aGUgInVuaXF1ZSBu aWNrbmFtZSIvcmVmZXJyZWQgdG8gYXMgdGhlICJ1bmlxdWUgbmlja25hbWUiLw0KPiAtIHMvdGhh dCBhcmUgdHJhbnNpdGlvbnMgYmV0d2Vlbi90aGF0IHRyYW5zaXRpb24gYmV0d2Vlbi8NCj4gLSBz L1JCcmlkZXMvUkJyaWRnZXMvDQo+IA0KPiBPbiBmaWd1cmUgMy4xLCBhcmVhIGJvdWRhcmllcyBs b29rZWQgb2RkLCBob3cgYWJvdXQuLi4NCj4gDQo+ICAgICAgICAgICBBcmVhIFggICAgICAgICAg ICAgICAgbGV2ZWwgMiAgICAgICAgICAgICBBcmVhIFkNCj4gICAgICstLS0tLS0tLS0tLS0tLS0t LSsgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgKy0tLS0tLS0tLS0tLSsNCj4gICAgIHwgICAgICAg ICAgICAgICAgIHwgfCAgICAgICAgICAgICAgICAgICAgIHwgfCAgICAgICAgICAgIHwNCj4gICBT LS0tUkIyNy0tLVJ4LS1Sei0tLVJCMi0tLVJiLS0tUmMtLVJkLS0tUmUtLVJCMy0tLVJrLS1SQjQ0 LS0tRA0KPiAgICAgfCAgICAgMjcgICAgICAgICAgfCB8ICAgICAgICAgICAgICAgICAgICAgfCB8 ICAgICA0NCAgICAgfA0KPiAgICAgfCAgICAgICAgICAgICAgICAgfCB8ICAgICAgICAgICAgICAg ICAgICAgfCB8ICAgICAgICAgICAgfA0KPiAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKyArLS0tLS0t LS0tLS0tLS0tLS0tLS0tKyArLS0tLS0tLS0tLS0tKw0KPiANCj4gT24gcGFnZSA0Og0KPiAtIHMv TGV0J3Mgc2F5L0xldCB1cyBzYXkvDQo+IC0gcy9sZXQncyBzYXkvbGV0IHVzIHNheS8NCj4gDQo+ IE9uIHBhZ2UgNToNCj4gLSBzL29ubHkgZGlmZmVyZW50IGlzL29ubHkgZGlmZmVyZW5jZSBpcy8N Cj4gDQo+IE9uIEZpZ3VyZSAzLjIsIEkgYXNzdW1lIHRoYXQgdGhlIG9yZGVyIG9mIHRoZSBuYW1l cyBvbiB0aGUgZmlyc3QgbGluZSBkb2VzIG5vdA0KPiBjaGFuZ2UgYW55dGhpbmcsIGJ1dCBJIGhh dmUgYmVlbiBwdXp6bGVkIG5vdCB0byBmaW5kIFJCMiBhcyB0aGUgbGlzdCBoZWFkLiBIYXZlDQo+ IHlvdSBjb25zaWRlcmVkIHB1dHRpbmcgaXQgYXMgdGhlIDFzdCBvbmUgb2YgdGhlIGxpc3Q/DQo+ IA0KPiBPbiBwYWdlIDksIHRoZSB3b3JkICJhcnRpZmljaWFsIiBzZWVtcyBib3RoIG9kZCBhbmQg dXNlbGVzcy4NCj4gDQo+IEluIHNlY3Rpb24gNSwgUkZDIDcxNzYgaXMgdXNlZCBhcyBhIGZhbGxi YWNrIG1lY2hhbmlzbSBmb3IgaW5jb21wYXRpYmxlDQo+IFJCcmlkZ2VzLiBXaGF0IGFib3V0IGl0 cyB1c2VzIGluIG90aGVyIGNhc2VzPyBJcyBpdCBzdGlsbCBhbGxvd2VkICh0aG91Z2ggbGVzcw0K PiBlZmZpY2llbnQpIG9yIHByZWNsdWRlZD8gQSBjbGFyaWZpY2F0aW9uIHdvdWxkIGJlIHVzZWZ1 bCAobWF5YmUgaW4gc2VjdGlvbiA0LjMpLg0KPiANCj4gT24gcGFnZSAxMywgIlRyZWVTZWwiIGlz IG5vdyBSRkMgNzk2OC4NCj4gDQo+IA0KPiBSZWdhcmRzLA0KPiANCj4gSnVsaWVuDQoNCg== From nobody Wed Apr 19 14:38:55 2017 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 A8882128A32; Wed, 19 Apr 2017 14:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 G-m9oL5kqR0J; Wed, 19 Apr 2017 14:38:51 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30111.outbound.protection.outlook.com [40.107.3.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AB6E128796; Wed, 19 Apr 2017 14:38:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Pv8Zk++klWvaDdyrhxW4tpWrk2Tsz36IDNTHpuhTwB8=; b=AlfkBGwJn5J9Fy+uFjhDD8gLWOaQYE9GZbsZNgbO+FFJIyplM3L0i3z1A66Aa6mNR7wqEYdyils9EkhEIW61ekkCUwtbqQebQHMeY0MPom/UwrLYaBzG/JahNXL8hXtMPm+C2+ml/4/f5MgvDuMx27NyE//BLUOYmUhf/DF9078= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; Received: from [192.168.1.5] (90.92.95.79) by HE1PR0701MB2475.eurprd07.prod.outlook.com (10.168.128.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Wed, 19 Apr 2017 21:38:48 +0000 From: Martin Vigoureux To: "" CC: "rtg-dir@ietf.org" , , Message-ID: Date: Wed, 19 Apr 2017 23:38:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [90.92.95.79] X-ClientProxiedBy: HE1PR0101CA0003.eurprd01.prod.exchangelabs.com (10.168.141.141) To HE1PR0701MB2475.eurprd07.prod.outlook.com (10.168.128.145) X-MS-Office365-Filtering-Correlation-Id: db684ab7-fb2c-4516-a83a-08d4876c7717 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:HE1PR0701MB2475; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2475; 3:ePxXhem7qCYrhtdhriqo+3U3BesE+DDJZ89pJ8QZihVd0nWC9jqFBUpbsPsnLN5sUN/Uc+eki7fr+w6b+GcW295UzWKqjOceLSMNMv/F7YskujQ1gajjaadTLMVtArCfq8HVqrMbXkuSeg+2ikM+iav37VkNsZRwLTEoOfyotbHcqYQGLMjnE+G5pyacbHUjl3oWterclvuo/gJB+V0wICuyMV8RJ2ht8IOnS6i2PhaDAFOLPsxlUhIu26Jw98bveP/BSQO4Y30XUCLCt4BqOSFYbnZv5lN78ycnkdjqtDoWZixCtq8Kob1RNPrFj/idJLowa1irkBgZ4QpWU3pe2jsuWjyHrm1nnErZrFghEJQ=; 25:XH6ViDpW7ntUrPxybUSkR//zgwxBaQXsbDMSCZ2vi29mg4+0KGIo27/4W4DxfrmZC/t2hChCklkX7y6zHZ8w+JwRUIMoYWd65i8QGZXuywuTp7hkY3IGVYQbQevGdidMCP6j/NYFdYXPZp/0Ohay69zx5IDyf68IllaPjHBOY12ufr6c/bcNQ12PKTYLj3ZSnc2bRQihoeQwFen2Gg8HRqqzPYcWRructDGK9gMEa962ERY0xiQ9W+yb2raJT/7e8hYi8poNq3gUAW5xGWqbm1f4PQdJPqagftDzltWQFqM8dmrygj1HeaOMZcypz6TpvLy6wJYZ1V0kj3M0nZjeB53hL3DzfbqhgS75aDUTmBg5cfIn4iZNSc7FGb/RbsiUMgUYN4ms3ktZK192p5Y4pi3IHEmJR7YoGgABm6XHnjmvqK6qZ2pFHbaX4r/RV5NfhzR7kavRzX7oALExE15KdiXx0vOsMe9A9YrVguy56gI= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2475; 31:Jh/wbudwc2wraFFVG8PWOmn05o4/3uhE+4waZ8jyksCo0zBXQMIn23GDty9ovbTrujW3Yt8SzjT1oZyenHiLBXFI23YZj2YoauQTR2B0SwvSteFTejyc+5obbO7dm/n+j4XQMHQyJ2NRc/OZ9fmA4NoP/h+LFV9ryHvWKRxQEBNfjbxw01BumKvWRdovHNsE4MI9FnTEJas0cdlbIhJVsChVfjN9jO7EMUCWO92UyUGp+YTR62ETJqNRVM4TWhW3K0d4IjaXY9g9Gnr2pgR4vg==; 20:kupT7zdsyfHFCScthKXvocoaxAYTyDXBcXd5dOAldDBHBJa7B73TEZj5SYHppiv8lomw0Zv1T2AyYNgLwI0tkV8b8DG5LqFWSXUs0JylYpwfARItREY8PGtW4VidFT/E2s1nI99KNHVFHa9zJq8cIjGIdAfF3kVy1Xwbz3Fflv1uLMObIPhmY2h7+Ku330est6QQJDtHC5fRnYwd6BfVfF6Pv5HO/2cE93SJNTDe0o9n5watX41ipLhQCJ1IekBj9cl4zf+VEk83E+ZnNPosGsAac4Cbc+IvJyaNCACDM+BkMjolbvpDVypovg9HxQd5QznG8f+yrGm/2WnbdKnW7ugYUnTMQ9wU2NKOmoO+BKD1InPq680MdaHBsDBgs6TN1dyp+GS1FvOgk1+wEQtCrALdzPL0n0+dP4hQzioE9WnK/K55H2az9/Py5AWnVZXOQLWLO5p5ArOP9qBVUthTNfY21srLpmtFHWQ/WYuGqAsP3+Q9N+TrhtmLDLvrNk8e X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:HE1PR0701MB2475; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2475; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2475; 4:VBadjdAvwH/8/zb8EcC4MVA3suIkHWNRi5/1LHxjprr9EGkAR8kCRzndpkbrGvJLw6OI1kEsuKk4zaqPODNjQry9BnmrQK+HM7PqwtymEXLaHGblnvwWDEqDhBwKoh9mv0hOvQ3/o6snvWswxLDWk6bGlDyk+9EWLUCYXcOVjPDdXzhflu1aXk6MEcyBiSSWDPN0LqxKhrr8W7hSDvRpCyC45lhNnFLazkXzC9Ie5+UUSb4jrdZwapsqOgjyQLO6OLOjkdKpLsXPBhup9lwO+Ha9HEP8y3AmmhlX48EKtxwXm4EPVDhLcKvzYzwyRZFblUr8Y6cJ5vrB6wuMZFi/JEv9kiV3CZKaqA0CAQNEEkHQrOrq9YFVWoZ+oGNBohe9O0Qtc31iwfQoU4o13o6S+6KtNBHtU4gXzo8Z4sfB2eubFDK+2BfnLJLQvfi7D1kMeTZ4IM1KkzzT0ZAXashPei8RRCL1r9kK2WkmT4hCf21y7Ju5tQwcD3Rc2lmFWXoUlbYyRR+O4gQqQbTcssX8t0TaxfgVDR1m2kZWzwQ329rkcpSKI8hex4u9o9SMLaNREQ1Q0j8eYBTydbefo3kbl365PWAO1YRzDttpIDXwzCrxtDQj4/FK5w4LPQ9difItGlY0A7c/b2F1hwqKl14qenYevTZchSdDzD1RUZFC0+1on1ww0GeuE4OUcxqtdQ7mSWkxSs489q1X+s1t7brqgWPZg8I9fMCkxx2QIj1QxS0= X-Forefront-PRVS: 028256169F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(39860400002)(39400400002)(39850400002)(39450400003)(39840400002)(39410400002)(377424004)(2906002)(23676002)(83506001)(4001350100001)(47776003)(65956001)(8676002)(81166006)(66066001)(36756003)(53936002)(31696002)(189998001)(2870700001)(31686004)(77096006)(6486002)(42186005)(86362001)(7736002)(117156002)(50986999)(1720100001)(90366009)(54906002)(5660300001)(38730400002)(305945005)(25786009)(54356999)(6666003)(50466002)(33646002)(6116002)(450100002)(110136004)(4326008)(3846002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2475; H:[192.168.1.5]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3MDFNQjI0NzU7MjM6RWlkMWowRm9ES0ozWmZ0VDVTQUJ2UnA2?= =?utf-8?B?ek1TZjZ2R2pyb2RYS2I5dmFaRm5lZXBiak41emdMNlZKc1ZlcURGSXU1RHRO?= =?utf-8?B?N21GcG9lWjJoTkR5QjVvKzVuUEpGQkptSlpmSktpK2tpWHB2ZDUzMjhwVVdO?= =?utf-8?B?V0tISGh3cUlKekhOSXY0VjY3Z0Vkc0habHI1U1J6MmFLOEZ1U2NRS1IwRlZ1?= =?utf-8?B?TUtvTUNTaFlSYTh6bFUxMndCQjBySGh4dHd5L3lLbGNJRVprWm5na1RXUDhR?= =?utf-8?B?MC9md1lZNkZ3d2N5ZUxLQVhYajdLSTlOU3IrdklsbmhTTFd3SHJxT2dUNUJh?= =?utf-8?B?SWRIVExFVDdZQmpRRTRmaEtKSWh0YmdXSFVoWHpyVlBrMmdiaks0TlZXN0Vl?= =?utf-8?B?MmhWM1l2RUFSY3BFSWZrdy8yNDc3VTlwYktpcFYxaFQ1WUlqcno4NW9HSWhv?= =?utf-8?B?MmVRMk50V21ocFdBazVldjljaTlXRk1uZWxMb1M2NHo0NklDRDRPUzlMaFFH?= =?utf-8?B?NmxwWlJqSTJhSURxYVZlMUtuckRCMytXRzNFUnYzZTd0Skl1QXdhdnhHMVJz?= =?utf-8?B?TTJIamNMSGxpdFR6RXNDdnUxcExIV2RFelNEeWpOZ0djeVVlZlJrNzFuYjRY?= =?utf-8?B?UWxQRWZMb0E5cmlpaUUzUjg5cE41V0s1RGNRYi9tZWJKUHgwSDJoWko5bU1W?= =?utf-8?B?SVJCVnZ1aUQ1TURUMlMrZVlUSVBoUlZVWkNKTzdaRmxkVGY5RjU3ZFRpUHl4?= =?utf-8?B?YVNZYWhKYzhXQ20xdmtPRWI0ME11WmZOaFdLVmI0NFZFSkNzWWZwR1VKeDdv?= =?utf-8?B?Mi9kTms1Rkt5QmdiUjJ0RXVOSHdEdmdlTXhzQmRhNWQzd3RXOHRtbUdyRC9k?= =?utf-8?B?QmVDc3lTTTR5bWp1TXNudU1kc1pkVUlaZlZDYlRBeTBCdWhxYXlzMTB5UGgz?= =?utf-8?B?NDAyZUJXYkRoK1oxV0d0MlhkOHZ6ellPWEFTYWZmSnBQcWVnMEVZWnBaV0p0?= =?utf-8?B?bkhJNzM1bWRSSUx6eWJ0K0U5bDk2eUcySStJTVJ2UGV3QmZScG5oZXR3YnB5?= =?utf-8?B?RmJDNHMrTSsrYmVqNDAxelZsMnhieGJ3ZmtRTGRoZTRzTStsT1ZPMEZJaEJs?= =?utf-8?B?ZEJwTkpQZEJVbW01Wm11VGR2bll4bHZrTkZITkp5cEN1Ymw4MnBNTmtKSDB4?= =?utf-8?B?cWFrMU53NnNrdm52ZUhNUFE1UXJMMkYyenZiOUZGQWZKdXUxRW5HVE94Uy8y?= =?utf-8?B?OGxlczlvTVNRbzhZbUpYdW4xQzdlUkx5U0w1ZG9YWWx2WDdGeC9TUGRSRERG?= =?utf-8?B?L3FxZGhyWVpQeDRXbzg1N1hLaWJPeEptdTM2K29pZHFDSVFtL0t3UGx1V3lH?= =?utf-8?B?VjRLMFhLakNRNHpRa0poTmdIdmRQL2tRUkduZ09JeDJQKzJBaFl3a3JwYklY?= =?utf-8?B?R2RQdmRDK2xDNGV0K25CQXJjL3lRUGVCNzY3bWMzaWN3ZkZpT0UzSmJhbnlU?= =?utf-8?B?VXE2N0cvazA0TVVFSGVEM0lITDZjMWp0ZFdjSHg2RjJRSWNjMFZLeGRPcHBS?= =?utf-8?B?UDBmQ2NNV1EyTnViNEsyQlJ4QzdzNW1kS2g2NWtlN1Q1ZlJnNjhhaHZ2cVh4?= =?utf-8?B?VENQTmJ6Rjk3UUV3cGR2SGJzSXRtaDBscTVtd2xGYjlvZHpRdmtjdFUwV0E9?= =?utf-8?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2475; 6:gxlXV0KGaNLWOTCDoTKaIVWV5+oeAfLzeUWA77hq3EcPz6FmePwT0aJd7EvR2WVyaHuQt7n5f62+5ALvIXEwHfPo77VGE7y8Sf3XRjG7XHmz4TvQVbfDpFVjcqvHFReyCd0RQDPgZqmDx0xYEdFjFBdBe/Dey4LPo1kH7419BAaQ64GwDx4wbIL6Y+Cd7B2u4FXS4g9baerHvzVJgxxggILyS1OHZekAQ4p4+Wdd+uQ4Dhr5NdfBNb2r7lgMe4nOY/Qr6XO5Q2lHGviHWpAbD8+YwzFgB03ozmUwd3h4JEDqLGBUy/q9QsUTKXN/dlUaXfdd9l05MDGQUM1xKLCUXyUa19VMmKlDZ8EYAC5y/NzCPTalaBO0OwbXOHtyUShQWGAFmDKAoXD1IGmgSTVTXRVctV8sXcJlSkSPAw+P48M0XwejZYovJJpvZwCDGEPM81/HspwgyiCVmfby/xMeKq+UXkQ8GEKbKlY4FZDTr8bu97+vI6GUhv7v++MPe6i0r2WEHluo/lKyO48svn/aPqjnFYrvjEg1AqHlnw2fsgQ=; 5:bf6R16DROhZunKXwhkDOGVcZUmrGrNizJAC1Y5kMjzqcllYD/ol5ykPkTq2FoZMacwj+LmEbm/QDY94UbD6S0VCUWwBwtnSabigHNdI+My7lsgd+/U/W74KqW3/mdpOJhtz/vZSiJJdwC3r49uA3nw==; 24:qSR5Uj8hzsUOqhVqN0Xgj/5eILk6i3saa7ef5Sgt7ymRgVG3Bp9QO6yIsEQvuKzfZNTz1gAQAgIlCTLYLLqRUUtME0iJXt/u7ftJmoZ3pCE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB2475; 7:rpu7W3OEUC5hwO2aJHuh0P/mr0raSud/icsBNcDwpRVB5CYVw1ZdvNSgWQGe1wct1yBcow0xWjiLPLIMoFNQx8HmMmrETFBKJzRY7UipTn4SkWh4FAoQ2EwAArTP/a5LsPdXDz5z2gyGUueeaTxg8cNPcS8vVfZfGOtfd8UuC21MCpdoPKstsesGwn2YckIgg87KM5jpq8HMkPEcr3JvxgpMNwuqMreRXrgPhBK+KJ/+yuLFFUfQgy3EkYUyRGzFiQLoSgWEVFim6pbx2qv/Dtld8WVxbcTwOYhlqsYcDiGJKB5f0JzpQHS/gma1k0Uwa+t9TgpPYHQiz/HCeHu7Eg== X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Apr 2017 21:38:48.7617 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2475 Archived-At: Subject: [RTG-DIR] RtgDir review: draft-ietf-grow-large-communities-usage-06 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 21:38:54 -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-grow-large-communities-usage-06 Reviewer: Martin Vigoureux Review Date: 2917-04-19 IETF LC End Date: 2917-04-21 Intended Status: Informational Summary: No issues found. This document is ready for publication. The only reservation I have is that the Document doesn't say much on how operators should coordinate such that values they use have a consistent meaning. Maybe at least say that it is needed but out of the scope of the Document. regards, martin From nobody Thu Apr 20 04:48:18 2017 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 4092B1294C3; Thu, 20 Apr 2017 04:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdieI02K3aVn; Thu, 20 Apr 2017 04:48:14 -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 4A0C1129B06; Thu, 20 Apr 2017 04:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6324; q=dns/txt; s=iport; t=1492688894; x=1493898494; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2ffTjLxO5PavAJohKUR/dC7o983PZzcRbAvl9raOKxo=; b=ZxAQg+PY2lw/JFpkKOXH/i3Kgr6L7qKRyM3jjoYnhuO5QiWJztDzlT/+ DDnlhrS1i5BtcGnVzD2OuYt20xWEJf7g5ApmEmut1tN6dUHUTLM+EgHrj 3W8HbULwjQw+rffNCRDe8Ntl5z63yuGzRpe6lWCDhcOkk6L3Ce0nzTLwC s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AkAQAFn/hY/4sNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1SBbAeDYIoVkWOVY4IPhiQCGoNfPxgBAgEBAQEBAQFrKIUVAQE?= =?us-ascii?q?BAQIBIwQNRQULAgEIGAICJgICAjAVEAIEDgWKFAiqU4FsOosgAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHYELhUiBXSuCboRXgwaCXwEEnTQBkwKCAIUziiKUEwEfOIE?= =?us-ascii?q?FYxUaOwGEVByBYgF1iCGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,225,1488844800"; d="scan'208";a="415068414" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Apr 2017 11:48:13 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v3KBmDr7006924 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Apr 2017 11:48:13 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 20 Apr 2017 07:48:12 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Thu, 20 Apr 2017 07:48:12 -0400 From: "Stefano Previdi (sprevidi)" To: Ravi Singh CC: "rtg-dir@ietf.org" , "draft-ietf-idr-bgpls-segment-routing-epe@ietf.org" , "idr@ietf.org" Thread-Topic: Review of draft-ietf-idr-bgpls-segment-routing-epe Thread-Index: AQHSucv9/27qJl6LRUK3n1+Z9ElHYA== Date: Thu, 20 Apr 2017 11:48:12 +0000 Message-ID: <4AE5E64E-4D7F-4AE7-9CEF-814623828956@cisco.com> References: 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.61.217.160] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [RTG-DIR] Review of draft-ietf-idr-bgpls-segment-routing-epe X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 11:48:16 -0000 SGkgUmF2aSwNCg0KdGhhbmtzIGZvciB0aGUgcmV2aWV3LiBJIGhhdmUgaW50ZWdyYXRlZCBtb3N0 IG9mIHlvdXIgY29tbWVudHMgYW5kIHdpbGwgc3VibWl0IGEgbmV3IHZlcnNpb24gYXNhcC4gU29t ZSBtb3JlIGNvbW1lbnRzIGlubGluZS4NCg0KDQo+IE9uIEFwciAxNCwgMjAxNywgYXQgODowMiBB TSwgUmF2aSBTaW5naCA8cmF2aXNAanVuaXBlci5uZXQ+IHdyb3RlOg0KPiANCj4gSGkNCj4gSSBo YWQgYmVlbiBkZXNpZ25hdGVkIGFzIHRoZSBSVEctRElSIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0 Lg0KPiAgDQo+IE92ZXJhbGwgdGhlIGRyYWZ0IGlzIGNsZWFyLiANCj4gSG93ZXZlciwgaXQgY291 bGQgYmUgdXNlIHNvbWUgZWRpdG9yaWFsIHJldmlzaW9uIGZvciBpbXByb3ZlZCByZWFkYWJpbGl0 eS4NCj4gIA0KPiBTcGVjaWZpYyBjb21tZW50cyBsaXN0ZWQgYmVsb3c6DQo+ICANCj4gMS4gICAg ICAgRG9jdW1lbnQgdGl0bGUgY291bGQgYmUgbGVzcyBoZWF2eSBvbiBjb25zZWN1dGl2ZSBhZGpl Y3RpdmVzOiBzb21lIHN1Z2dlc3Rpb25zOg0KPiBhLiAgICAgICBCR1AtTFMgZXh0ZW5zaW9ucyBm b3IgU2VnbWVudCBSb3V0aW5nIEJHUCBFZ3Jlc3MgUGVlciBFbmdpbmVlcmluZw0KPiBiLiAgICAg IEJHUC1MUyBleHRlbnNpb25zIGZvciAiQkdQLUVQRSB1c2luZyBTUiINCj4gYy4gICAgICAgU2Vn bWVudCBSb3V0aW5nIEJHUCBFZ3Jlc3MgUGVlciBFbmdpbmVlcmluZyBleHRlbnNpb25zIGZvciBC R1AtTFMNCj4g4oCmDQo+IDIuICAgICAgIFNlY3Rpb24gMToNCj4gIiAgIFRoaXMgZG9jdW1lbnQg ZGVmaW5lcyBuZXcgdHlwZXMgb2Ygc2VnbWVudHM6IGEgUGVlciBOb2RlIHNlZ21lbnQNCj4gICAg ZGVzY3JpYmluZyB0aGUgQkdQIHNlc3Npb24gYmV0d2VlbiB0d28gbm9kZXM7IGEgUGVlciBBZGph Y2VuY3kNCj4gICAgU2VnbWVudCBkZXNjcmliaW5nIHRoZSBsaW5rIChvbmUgb3IgbW9yZSkgdGhh dCBpcyB1c2VkIGJ5IHRoZSBCR1ANCj4gICAgc2Vzc2lvbjsgdGhlIFBlZXIgU2V0IFNlZ21lbnQg ZGVzY3JpYmluZyBhbiBhcmJpdHJhcnkgc2V0IG9mIHNlc3Npb25zDQo+ICAgIG9yIGxpbmtzIGJl dHdlZW4gdGhlIGxvY2FsIEJHUCBub2RlIGFuZCBpdHMgcGVlcnMuIg0KPiBBYm92ZSBoYXMgYW4g dW5pbnRlbmRlZCBtZWFuaW5nLiBUaGlzIHNob3VsZCBpbnN0ZWFkIGhhdmUgc3RhdGVkIHRoYXQg dGhpcyBkb2MgZGVmaW5lcyBCR1AtTFMgZXh0ZW5zaW9ucyB0byBjb21tdW5pY2F0ZSB0aGUgYWJv dmUgbGlzdGVkIFNJRHMgdGhhdCBhcmUgZGVmaW5lZCBpbiAiZHJhZnQtaWV0Zi1zcHJpbmctc2Vn bWVudC1yb3V0aW5nIg0KPiAgDQo+IDMuICAgICAgIFNlY3Rpb24gMzogDQo+ICINCj4gICAgVGhp cyBkb2N1bWVudCBkZWZpbmVzIHRoZSBCR1AtRVBFIFBlZXJpbmcgU2VnbWVudHM6DQo+ICANCj4g ICAgbyAgUGVlciBOb2RlIFNlZ21lbnQgKFBlZXItTm9kZS1TSUQpDQo+ICANCj4gICAgbyAgUGVl ciBBZGphY2VuY3kgU2VnbWVudCAoUGVlci1BZGotU0lEKQ0KPiAgDQo+ICAgbyAgUGVlciBTZXQg U2VnbWVudCAoUGVlci1TZXQtU0lEKSINCj4gIA0KPiBTYW1lIGlzc3VlIGFzIGxpc3RlZCBhYm92 ZSBmb3Igc2VjdGlvbiAxIGFib3ZlLg0KPiBTZWN0aW9uIDUgaGFzIHRoZSBzYW1lIGlzc3VlLg0K DQoNCmluZGVlZCB0aGVyZeKAmXMgYSBiaXQgb2YgY29uZnVzaW9uIGJldHdlZW4g4oCcc2VnbWVu dOKAnSBhbmQg4oCcU0lE4oCdIHRlcm1pbm9sb2d5LiBXaGlsZSB0aGUgc2VnbWVudCBoYXMgYmVl biBkZWZpbmVkIGluIGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1jZW50cmFsLWVw ZSwgdGhpcyBkcmFmdCBkZWZpbmVzIHRoZSBTSUQgYW5kIGhvdyB0aGV5IGFyZSBhZHZlcnRpc2Vk IGluIEJHUC1MUy4gSSB1cGRhdGVkIHRoZSB0ZXh0Lg0KDQoNCj4gNC4gICAgICAgU2VjdGlvbiA0 LjI6IEknZCBzdWdnZXN0IHRoYXQgdGhpcyBiZSBicm9rZW4gaW50byAyIHNlcGFyYXRlIHN1Yi1z ZWN0aW9uczogZWFjaCBsaXN0aW5nIHRoZSBtYW5kYXRvcnkvb3B0aW9uYWwgc3ViLVRMVnMgZm9y IHRoZSBsb2NhbCBhbmQgcmVtb3RlIG5vZGUgZGVzY3JpcHRvcnMgcmVzcGVjdGl2ZWx5LiBUaGF0 IHdpbGwgbWFrZSBmb3IgaW1wcm92ZWQgcmVhZGFiaWxpdHkuDQo+ICANCj4gNS4gICAgICAgU2Vj dGlvbiA0LjI6IHBsZWFzZSBjbGFyaWZ5IGluIHRleHQgYXMgdG8gV2h5IG5vICJCR1AtTFMgSUQi IGluIGxpbmsgTkxSSSBpbiB0aGUgcmVtb3RlIG5vZGUgZGVzY3JpcHRvci4NCg0KDQpXZWxsLCB0 aGlzIGlzIG5vdCByZWxhdGVkIHRvIEVQRSBidXQgdG8gQkdQLUxTIGJhc2Ugc3BlYyB3aGVyZSB0 aGUgQkdQLUxTIGlkZW50aWZpZXIgaXMgbG9jYWxseSBhc3NpZ25lZC4NCg0KVGhlcmVmb3JlLCBh IG5vZGUgcnVubmluZyBFUEUgYW5kIGRlc2NyaWJpbmcgW2l8ZV1CR1AgdG9wb2xvZ3ksIGRvZXNu 4oCZdCBrbm93IHRoZSBCR1AtTFMgaWRlbnRpZmllciBvZiBpdHMgcGVlcnMuDQoNCg0KPiA2LiAg ICAgICBTZWN0aW9uIDQuMzogDQo+IGEuICAgICAgIHZhbHVlcyBvZiB0aGUgZmxhZ3MgYXJlIHNw ZWNpZmllZCBvbmx5IGZvciB0aGUgUGVyLUFkai1TSUQuIEV4cGxpY2l0IHRleHQgc2hvdWxkIGJl IGxpc3RlZCBmb3IgcGVyLW5vZGUtU0lEIGFuZCBwZXItc2V0LVNJRC4NCj4gYi4gICAgICAiDQo+ ICAgIFRoZSBQZWVyLU5vZGUtU0lEIE1VU1QgYmUgcHJlc2VudCB3aGVuIEJHUC1MUyBpcyB1c2Vk IGZvciB0aGUgdXNlDQo+ICAgIGNhc2UgZGVzY3JpYmVkIGluIFtJLUQuaWV0Zi1zcHJpbmctc2Vn bWVudC1yb3V0aW5nLWNlbnRyYWwtZXBlXSBhbmQNCj4gICAgTUFZIGJlIG9taXR0ZWQgZm9yIG90 aGVyIHVzZSBjYXNlcy4iDQo+IElzIHRoZXJlIHJlYWxseSBhIG5lZWQgdG8gc3RhdGUgd2hhdCBv dGhlciB1c2UtY2FzZXMgbWlnaHQgZG8sIGNvbnNpZGVyaW5nIHRoYXQgdGhpcyBkb2MgaXMgc3Bl Y2lmaWMgdG8gQkdQLUxTIGZvciBTUi1FUEU/IFBlcmhhcHMgY2FuIGJlIHJld29yZGVkLiBTaW1p bGFybHkgZm9yICJQZWVyLUFkai1TSUQgYW5kIFBlZXItU2V0LVNJRCBTdWJUTFZzIE1BWSIgaW4g bmV4dCBwYXJhZ3JhcGguDQoNCg0KV2VsbCwgd2UgZG9u4oCZdCB3YW50IHRvIHNodXQgdGhlIGRv b3JzIHRvIG90aGVyIHVzZSBjYXNlcyB0aGF0IGNvdWxkIGxldmVyYWdlIHRoZSBzYW1lIGVuY29k aW5ncyBzbyB3ZSBqdXN0IHN0YXRlIHdoYXQgRVBFIHJlcXVpcmVzIGJ1dCBjZXJ0YWlubHksIG90 aGVyIG9wdGlvbnMgYXJlIGF2YWlsYWJsZS4NCg0KIA0KPiA3LiAgICAgICBUaGVyZSBpcyBzb21l IHJlcGV0aXRpb24gb2YgaW5mbyBiZXR3ZWVuIHNlY3Rpb25zIDQgJiA1LiBlZy4gV2hhdCBsb2Nh bCBhbmQgcmVtb3RlIG5vZGUgZGVzY3JpcHRvcnMgY29udGFpbi4gUGxlYXNlIHJld29yZCB0aGVz ZSBzZWN0aW9ucyB0byBhdm9pZCB0aGUgcmVwZXRpdGlvbiB3aGlsZSBzdGlsbCBwcmVzZW50aW5n IHRoZSBpbmZvLg0KPiAgDQo+IDguICAgICAgIFNlY3Rpb25zIDUuMSAmIDUuMjogaGF2ZSBsb3Rz IG9mIHJlcGV0aXRpdmUgdGV4dC4gVGFidWxhciBwcmVzZW50YXRpb24gb2YgdGhlIHRleHQgaW4g dGhlc2Ugc2VjdGlvbnMgd291bGQgYWxsb3cgZGVzY3JpYmluZyBwZXItbm9kZS1zaWQgYW5kIHBl ci1hZGotc2lkIHdpdGhvdXQgdGhlIHJlcGV0aXRpb24uDQoNCg0KV2VsbCwgdGhlc2Ugc2VjdGlv bnMgYXJlIHRoZSBjb3JlIG9mIHRoZSBkcmFmdDoNCi4gc2VjdGlvbiA0IGRlc2NyaWJlcyB0aGUg ZW5jb2Rpbmcgb2YgdGhlIFRMVnMvYXR0cmlidXRlcw0KLiBzZWN0aW9uIDUgZGVzY3JpYmUgaG93 IGEgU0lEIGlzIGNvbnN0cnVjdGVkLg0KDQpJIGtub3cgaXTigJlzIHF1aXRlIGEgYml0IG9mIGlu Zm9ybWF0aW9uIGJ1dCBzaW5jZSB34oCZcmUgc3VwcG9zZWQgdG8gYmUgZXhoYXVzdGl2ZSBpbiB0 aGUgd2F5IGVuY29kaW5nIGlzIGRvbmUsIEkgYmVsaWV2ZSB0aGVzZSBkZXRhaWxzIGFyZSB3cm90 aCB0byBiZSBtZW50aW9uZWQuDQoNCg0KPiA5LiAgICAgICBTZWN0aW9uIDk6IHR5cG8gaW4gbGFu Z3VhZ2UgaW4gZmlyc3Qgc2VudGVuY2UuDQo+ICANCj4gMTAuICAgU2VjdGlvbiAxMDogcGxlYXNl IGV4cGxpY2l0bHkgY2FsbCBvdXQgYW55IGFkZGl0aW9uYWwgKGJleW9uZCByZmM3NzUyKSBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyBvciBpbmNsdWRlIHRleHQgc3RhdGluZyB0aGF0IG5vbmUgZXhp c3QuDQo+ICANCj4gMTEuICAgVHlwb3MNCj4gYS4gICAgICAgIFNlY3Rpb24gMzoNCj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaS4gICAgICAgICAgICAiYW4gQkdQLUVQ RSIgLT4gImEgQkdQLUVQRSINCj4gYi4gICAgICBTZWN0aW9uIDQ6DQo+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGkuICAgICAgICAgICAgIkxpbmstdHlwZSIgTkxSSSAt PiAibGluay1zdGF0ZSIgTkxSST8NCg0KDQpSRkM3NzUyIHNlY3Rpb24gMy4yLiAgZGVmaW5lcyB0 aGUg4oCcTGluayBOTFJJ4oCdIHR5cGUgd2hpY2ggaXMgb25lIHBvc3NpYmxlIHR5cGUgZm9yIHRo ZSBMaW5rLVN0YXRlIE5MUkkuDQoNCnMuDQoNCg0KDQo+ICANCj4gUmVnYXJkcw0KPiBSYXZpDQoN Cg== From nobody Thu Apr 20 10:29:16 2017 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 CBA231314B2 for ; Thu, 20 Apr 2017 10:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.99 X-Spam-Level: X-Spam-Status: No, score=0.99 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, 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 Xf2comPmHAz5 for ; Thu, 20 Apr 2017 10:29:10 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::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 9A899129B40 for ; Thu, 20 Apr 2017 10:29:09 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id w50so16900351wrc.0 for ; Thu, 20 Apr 2017 10:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5xsVtPL4IE6FZh2rcxXr3laFJ3uEVpRsjq+CmPrue9w=; b=k8chyoyK6lBrI2K/StphX0A8ND2zz2xsCEQVFe/4gtj5qYe+IvATE7/Ux2eLQMVCmv UlPWkVJkzMHD+bqh7PvumlhXx/AkdY2BdBwE+IhziEh+glQ9ghO+tjb2TYlH6nmd4mFq kJF9zLUmChrN4GwmvAVoGRhbr4EbM03wEV7UVKvYMTPr1Bvg3+Dov3owwnSDILIcIrSW 8NhR2eZubcTjMdcOE9VZaJLv13HL1SW8kRnyZjZqDDpu+xfY7RLjZGZW9Vb5F+A+3e7M IklEIQhL7OJn541RNWbhZG9vsFdrUpw0Q/aj+3BsYmoetP2hi7/vzWg0U/C4cqeuPDAM LmsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5xsVtPL4IE6FZh2rcxXr3laFJ3uEVpRsjq+CmPrue9w=; b=PWTUQ4yPcvy8P1rFCkUNaeL77+6qB37+vUxuUjcgEsx7fz2cN3+zGO0bmDfIrzUZic COcU28ySPkZndgVpblRUaO/Wr2C32CFYXdKOT82mQIaaxU0i366n2bHrDoeBOKtwQF7H QgnsY/PNWvUZezQbBAvNHl51fStvF0a8hoKFotzooJdgxnS3EOx3/0A8i06tT4Bdmi7u 7jB+MyPKIZbXa2KTznO+TN0mJSngHHVZ03ud2VPgCG1Fvcml4DsbqxHIrv+60NGlUYz/ /hZxGx+hThWBd0uUn7K81leDnxhTbb0bzXkgygzchXksZUp43XVYNBlHjxYmJ9KXcrHa WyHw== X-Gm-Message-State: AN3rC/6L33GB2R+IRWmJ2FtPWyIl4gawvQMLrsjUsVTafEoqLpSg3Ee2 7uBICswbxiPqPkIKsN1hgewe8EwImg== X-Received: by 10.223.129.198 with SMTP id 64mr8696024wra.193.1492709348063; Thu, 20 Apr 2017 10:29:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.136.9 with HTTP; Thu, 20 Apr 2017 10:28:27 -0700 (PDT) In-Reply-To: <9CB1940B-3918-4D16-83E7-541EE08833C7@att.com> References: <9C5FD3EFA72E1740A3D41BADDE0B461FC61BA0CA@szxema506-mbs.china.huawei.com> <1490466710.627965665@f24.my.com> <9C5FD3EFA72E1740A3D41BADDE0B461FC61C7462@szxema506-mbs.china.huawei.com> <9C5FD3EFA72E1740A3D41BADDE0B461FC61D84C1@szxema506-mbs.china.huawei.com> <9CB1940B-3918-4D16-83E7-541EE08833C7@att.com> From: Tony Przygienda Date: Thu, 20 Apr 2017 10:28:27 -0700 Message-ID: To: "BRUNGARD, DEBORAH A" Cc: "Yemin (Amy)" , rtg-dir@ietf.org Content-Type: multipart/alternative; boundary=001a1148fdc271c58f054d9c7a76 Archived-At: Subject: Re: [RTG-DIR] [Reminder] RE: Routing directorate review of draft-ietf-mpls-ldp-mrt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 17:29:13 -0000 --001a1148fdc271c58f054d9c7a76 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Here's the review (sorry for delay, lots of material). Pls fwd to according mailing lists ---- 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-mpls-ldp-mrt Reviewer: Tony Przygienda Review Date: 4/20/17 Intended Status: Standards Track Summary: I have several major comments that either indicate technical inconsistencies in the MRT-FRR document set (7811/7812/igp/ldp drafts) or suggest additions to improve readability of those documents and prevent wrong assumptions on the reader's side. Major Comments: =C2=B7 A small section outlining the requirements of =E2=80=9Cdomai= n-alignment=E2=80=9D in MRT could be helpful, i.e. what are the assumptions as to congruency of LDP/IGP areas/MRT islands and features supported in each. A picture of where the proxy nodes fit in, where the rainbow labels are used, a GADAG root would improve readability. MRT has good amount of moving parts that relate in non-obvious ways. This comment is geared probably more toward RFC7812 than this document. =C2=B7 It seems that the implicit assumption that the IGP MRT suppo= rt is congruent with the LDP MRT support, i.e. LDP MRT capability is advertised IIF if the node supports MRT in IGP on the link (and vice versa)? Otherwise section 5.2 is ambiguous as in =E2=80=9Cis LDP on anything that will be on = red or blue assumed/a MUST=E2=80=9D or =E2=80=9CIGP shall not compute red/blue if = LDP peer is not MT-MRT-capable, i.e. take the link out the MRT topology=E2=80=9D ? If such= an assumption is made, spelling it out would improve readability of the document. =C2=B7 Proxy node attachment router in section in 5.1.2 is loosely introduced and would benefit from reference to Section 11.2 in 7812. A clear definition with distinction between the =E2=80=9Cproxy node=E2=80=9D = and =E2=80=9Cproxy node attachment" in the glossary (of RFC7812?) would help the reader of the document set. =C2=B7 I don=E2=80=99t see a specification how non-default profiles= would be supported in the future in this document. It seems implied that negotiating certain MT-IDs in LDP will imply certain profile values in the future but the document would gain readability if that is spelled out (I think RFC7812 does indicate that in 8.1 already so reference maybe enough). However when reading 5.1 of draft-ietf-isis-mrt-02 I see that the profile ID is explicity given with the topology ID which seem contradictory if topology IDs imply the profile used. =C2=B7 I find it surprising that the document does not describe in section 5 the interaction of different LDP modes and the MRT computations. Do we do unsolicited liberal, retain when MRT computed the next-hops and so on? Maybe one sentence along the lines of =E2=80=9CLDP mode must be the= same as unicast IGP forwarding mode=E2=80=9D would help clarify or the specific nec= essary modes listed. Minor comments: =C2=B7 For easy reference suggest to add =E2=80=9Ctwo-connected gra= ph=E2=80=9D to the glossary since it=E2=80=99s not a common term. Or refer to RFC7812 =C2=B7 Maybe same for =E2=80=9Ccut-vertex=E2=80=9D or refer to 7812 =C2=B7 Maybe same for =E2=80=9Ctopological ordering=E2=80=9D. Refer= ence to 7811 would be helpful for readability thanks --- tony On Wed, Apr 5, 2017 at 3:41 AM, BRUNGARD, DEBORAH A wrote: > It's ok Tony- > Thanks for doing- > Deborah > > Sent from my iPhone > > On Apr 4, 2017, at 9:47 PM, Yemin (Amy) wrote: > > I think the AD Deborah could allow additional days. > > Deborah, could you please confirm on this? > > > > Amy > > *From:* Tony Przygienda [mailto:tonysietf@gmail.com = ] > > *Sent:* Tuesday, April 04, 2017 11:47 PM > *To:* Yemin (Amy) > *Subject:* Re: [Reminder] RE: Routing directorate review of > draft-ietf-mpls-ldp-mrt > > > > Swamped with work, any chance you can grant me extension to 12th or so ? > > > > On Sun, Mar 26, 2017 at 9:22 PM, Yemin (Amy) wrote= : > > Thanks, Tony. > > > > Amy > ------------------------------ > > *=E5=8F=91=E4=BB=B6=E4=BA=BA**:* Tony Przygienda [tonysietf@gmail.com] > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4**:* 2017=E5=B9=B43=E6=9C=8826=E6=97= =A5 2:31 > *=E6=94=B6=E4=BB=B6=E4=BA=BA**:* Yemin (Amy) > *=E4=B8=BB=E9=A2=98**:* Re: [Reminder] RE: Routing directorate review of > draft-ietf-mpls-ldp-mrt > > Will review > > > > > > Sent from myMail for iOS > > > > Saturday, March 25, 2017, 01:09 -0700 from Yemin (Amy) < > amy.yemin@huawei.com>: > > Hi Tony, > > > > Could you reply if you could review the draft or not. > > Thanks. > > > > Amy > > *From:* Yemin (Amy) > *Sent:* Monday, March 20, 2017 2:20 PM > *To:* 'tonysietf@gmail.com' ; 'prz@zeta2.ch' < > prz@zeta2.ch> > *Cc:* 'BRUNGARD, DEBORAH A' ; 'Jonathan Hardwick' < > Jonathan.Hardwick@metaswitch.com> > *Subject:* Routing directorate review of draft-ietf-mpls-ldp-mrt > > > > Hi Tony, > > > > Please would you do a routing directorate review of this draft? > > https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-mrt/ > > > > > This is to accompany the IETF last call of this document. The ADs have > requested your comments by April, 7th, 2017. > > You can find some guidance and a review template at the following link: > > https://trac.ietf.org/trac/rtg/wiki/RtgDirGuidance > > > > > Please send your comments to the RTG Area Directors (rtg-ads@ietf.org) > and the draft authors, and copy the relevant WG mailing list and the > rtg-dir list. > > Please let me know if you can do it, or not. > > Many thanks > > Amy > > > ------------------------------ > > This e-mail and its attachments contain confidential information from > HUAWEI, which > is intended only for the person or entity whose address is listed above. > Any use of the > information contained herein in any way (including, but not limited to, > total or partial > disclosure, reproduction, or dissemination) by persons other than the > intended > recipient(s) is prohibited. If you receive this e-mail in error, please > notify the sender by > phone or email immediately and delete it! > > > > > > > > -- > > *We=E2=80=99ve heard that a million monkeys at a million keyboards could = produce > the complete works of Shakespeare; now, thanks to the Internet, we know > that is not true.* > > =E2=80=94Robert Wilensky > > --=20 *We=E2=80=99ve heard that a million monkeys at a million keyboards could pr= oduce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.* =E2=80=94Robert Wilensky --001a1148fdc271c58f054d9c7a76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here's the review (sorry for delay, lots of material).= Pls fwd to according mailing lists=C2=A0

----=C2=A0

I have= been selected as the Routing Directorate reviewer for this draft. The Rout= ing Directorate seeks to review all routing or routing-related drafts as th= ey pass through IETF last call and IESG review, and sometimes on special re= quest. The purpose of the review is to provide assistance to the Routing AD= s. For more information about the Routing Directorate, 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 ADs, it would be helpful if you c= ould consider them along with any other IETF Last Call comments that you re= ceive, and strive to resolve them through discussion or by updating the dra= ft.

Document:=C2=A0draft-ietf-mpls-ldp-mrt
Reviewer: Tony Przygienda
Review Date: 4/20/17Intended Status:=C2=A0Standards Track


= Summary:

<= span style=3D"font-size:11pt">=C2=A0

I have several ma= jor comments that either indicate technical inconsistencies in the MRT-FRR = document set (7811/7812/igp/ldp drafts) or suggest additions to improve rea= dability of those documents and prevent wrong assumptions on the reader'= ;s side.

<= span style=3D"font-size:11pt">=C2=A0


Major Comment= s:

=C2=A0

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0A small= section outlining the requirements of =E2=80=9Cdomain-alignment=E2=80=9D i= n MRT could be helpful, i.e. what are the assumptions as to congruency of L= DP/IGP areas/MRT islands and features supported in each. A picture of where= the proxy nodes fit in, where the rainbow labels are used, a GADAG root wo= uld improve readability. MRT has good amount of moving parts that relate in= non-obvious ways. This comment is geared probably more toward RFC7812 than= this document.=C2=A0

=C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It seems that the implicit assumption= that the IGP MRT support is congruent with the LDP MRT support, i.e. LDP M= RT capability is advertised IIF if the node supports MRT in IGP on the link= (and vice versa)? Otherwise section 5.2 is ambiguous as in =E2=80=9Cis LDP= on anything that will be on red or blue assumed/a MUST=E2=80=9D or =E2=80= =9CIGP shall not compute red/blue if LDP peer is not MT-MRT-capable, i.e. t= ake the link out the MRT topology=E2=80=9D ?=C2=A0 If such an assumption is= made, spelling it out would improve readability of the document.=C2=A0

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Proxy node attachment router in section in 5.1.2 is loo= sely introduced and would benefit from reference to=C2=A0Section 11.= 2 in 7812. A clear definition with distinction between the =E2=80=9Cproxy n= ode=E2=80=9D and =E2=80=9Cproxy node attachment" in the glossary (of R= FC7812?) would help the reader of the document set.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0I don= =E2=80=99t see a specification how non-default profiles would be supported = in the future in this document. It seems implied that negotiating certain M= T-IDs in LDP will imply certain profile values in the future but the docume= nt would gain readability if that is spelled out (I think RFC7812 does indi= cate that in 8.1 already so reference maybe enough). However when reading 5= .1 of draft-ietf-isis-mrt-02 I see =C2=A0that the profile ID is explicity g= iven with the topology ID which seem contradictory if topology IDs imply th= e profile used.=C2=A0

=C2=B7=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0I find it surprising that the document= does not describe in section 5 the interaction of different LDP modes and = the MRT computations. Do we do=C2=A0unsolicited=C2=A0 libe= ral, retain when MRT computed the next-hops and so on? =C2=A0= Maybe one sentence alon= g the lines of =E2=80=9CLDP mode must be the same as unicast IGP forwarding= mode=E2=80=9D would help clarify or the specific necessary modes listed.

=C2=A0

Minor comments:

=C2=A0

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0For easy reference suggest to add =E2=80=9Ctwo-connecte= d graph=E2=80=9D to the glossary since it=E2=80=99s not a common term. Or r= efer to =C2=A0RFC7812

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0Maybe same for = =E2=80=9Ccut-vertex=E2=80=9D or refer to 7812

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Maybe same for =E2=80=9Ctopological ordering=E2=80=9D. Reference to= 7811 would be helpful for readability=C2=A0



thanks=C2=A0


--- tony =C2=A0



On Wed, Apr 5, 2017 at 3:41 AM, BRUNGARD, DEBORAH A <db3546@att.com= > wrote:
It's ok Tony-
Thanks for doing-
Deborah

Sent from my iPhone

On Apr 4, 2017, at 9:47 PM, Yemin (Amy) <amy.yemin@huawei.com> wrote:

I think the AD Deborah could allow ad= ditional days.

Deborah, could you please confirm on = this?

=C2=A0

Amy

From: Tony Przygienda [mailto:tonysietf@gmail.com]
Sent: Tuesday, April 04, 2017 11:47 PM
To: Yemin (Amy) <amy.yemin@huawei.com>
Subject: Re: [Reminder] RE: Routing directorate review of draft-ietf= -mpls-ldp-mrt

=C2=A0

Swamped with work, any chance you can grant me exten= sion to 12th or so ?=C2=A0

=C2=A0

On Sun, Mar 26, 2017 at 9:22 PM, Yemin (Amy) <amy.yemin@huawei.com= > wrote:

Thanks, Tony.

=C2=A0

Amy

= =E5=8F=91=E4=BB=B6=E4=BA=BA: Tony Przygienda [= tonysietf@gmail.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B43=E6=9C=8826=E6=97=A5= 2:31
=E6=94=B6=E4=BB=B6=E4=BA=BA: Yemin (Amy)
=E4=B8=BB=E9=A2=98: Re: [Reminder] RE: Routing directorate review of draft-ietf-mpls-ldp-mrt

Will review

=C2=A0



Sent from myMail for iOS



Saturday, March 25, 2017, 01:09 -0700 from Yemin (Amy) <amy.yemin@huawei.com>:<= /u>

Hi Tony,

=C2=A0<= u>

Could you reply if you could review the dr= aft or not.

Thanks.

=C2=A0<= u>

Amy<= /u>

From: Yemin (Amy)
Sent: Monday, March 20, 2017 2:20 PM
To: 'to= nysietf@gmail.com' <tonysietf@gmail.com>; 'prz@zeta2.ch' <prz@zeta2.ch>
Cc: 'BRUNGARD, DEBORAH A' <db3546@att.com>; 'Jonathan Hardwick' &= lt;Jo= nathan.Hardwick@metaswitch.com>
Subject: Routing directorate review of draft-ietf-mpls-ldp-mrt

=C2=A0

Hi Tony,

=C2=A0

Please would you do a routing directorate re= view of this draft?

https://dat= atracker.ietf.org/doc/draft-ietf-mpls-ldp-mrt/

=C2=A0

This is to accompany the IETF last call of t= his document. The ADs have requested your comments by April, 7th, 2017.<= /u>

You can find some guidance and a review temp= late at the following link:

https://trac.ietf.org/trac= /rtg/wiki/RtgDirGuidance

=C2=A0

Please send your comments to the RTG Area Di= rectors (rtg-ads@ietf= .org) and the draft authors, and copy the relevant WG mailing list and = the rtg-dir list.

Please let me know if you can do it, or not.=

Many thanks

Amy

=C2=A0

This= e-mail and its attachments contain confidential information from HUAWEI, w= hich
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!

=C2=A0



=C2=A0

--

We=E2=80=99ve heard that a million monkeys at a millio= n keyboards could produce the complete works of Shakespeare; now, thanks to= the Internet, we know that is not true.

=E2=80=94Robert Wile= nsky




--
We=E2=80=99ve heard that a million monkeys at a million keyboards cou= ld produce the complete works of Shakespeare; now, thanks to the Internet, = we know that is not true.=E2=80=94Robert Wilensky<= br>
--001a1148fdc271c58f054d9c7a76-- From nobody Fri Apr 21 21:14:11 2017 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 ED53B126D85; Fri, 21 Apr 2017 21:14:08 -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 M7YSfuxl6o-y; Fri, 21 Apr 2017 21:14:07 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C70301201FA; Fri, 21 Apr 2017 21:14:06 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id q78so19379366vke.3; Fri, 21 Apr 2017 21:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=JfsRza3eF8itb21FwsS/lpxjAQBv4DtdA7mz3VUvexM=; b=W/raxoJkn0GyWcm936bU1xPNE4+TiwXdY31elH2Jk/pfaNUtNspb04z2EH90KSKihR XA/AASjtzsWF/BhvEEYzn0q8W2T56d9p17mN9zLnayCXpmB2HkmhG2rVoj/Obmg9uQqU Ay2DFRcDl159lnt76pX4Rw1EAHUrJitui6LBjJ0ISkhlt7VLziFLHJ+yHwQjIn703xdP T1EhnaP3QvtzvDUrgsLFBbcOwYqACcoF7o7uYsOWvpz6hu8v3b6azD8d1flS37KXHtgb 0zMXY53XVe9TZn7BKHBZtg8Q4ghJHwtwI5KKJojNhuGr8bJJ7FcYPjxoVoful0hymY1o dhJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=JfsRza3eF8itb21FwsS/lpxjAQBv4DtdA7mz3VUvexM=; b=eg5BvAoqFQ4Ai+I2SyQu6RD3yNEZA/+/5tudocEvr2lfy4b80Y4H2LwCanLbrwO32Y eAs2IFF95hTLzxypaU/f3JtI7Pj9eXGgV1XKyOGx/vowM9jyzMJHcykzeAy4mWxJkkVb A/9TrZiu4MZEPHDStOTS06cajKBu/5glsBz0oLmqsaFilDE9rSCJa527RN7Ausmg1UxM m4NzfCfsB1rR1jHyPu2XHFVq093uYHwYgguelbEXfr8VjOq2opkWTofHbgn3DHsbXTWD hTU2WqFoQGUIU4Ep4J5SaYzCgrH5xRFr9KLMITdAGL/+gntFk2CuOGwd4HCwJTxoEMrF k0XQ== X-Gm-Message-State: AN3rC/4Ug1DtKILFvtxT34TqM5UgPeOXGY4c+9hwvaLQrJReUmMm35SE WzzevynByLYN5tOO8UIGKKpgdlwxJQ== X-Received: by 10.31.233.131 with SMTP id g125mr51300vkh.34.1492834445826; Fri, 21 Apr 2017 21:14:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.16.8 with HTTP; Fri, 21 Apr 2017 21:14:05 -0700 (PDT) From: Ines Robles Date: Sat, 22 Apr 2017 01:14:05 -0300 Message-ID: To: draft-ietf-6man-rfc1981bis@ietf.org Cc: Jonathan Hardwick , "rtg-dir@ietf.org" , rtg-ads@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0940d2da1ea4054db99a96 Archived-At: Subject: [RTG-DIR] Review for draft-ietf-6man-rfc1981bis-06 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 04:14:09 -0000 --94eb2c0940d2da1ea4054db99a96 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Please find my review for "Path MTU Discovery for IP version 6 (draft-ietf-6man-rfc1981bis-06) I-D: ...........................................................................= ..................................................... Document: draft-ietf-6man-rfc1981bis-06.txt Reviewer: Ines Robles Review Date: April 21, 2017 Intended status: Standards Track Summary: This document describes Path MTU Discovery for IP version 6 I believe the draft is technically good. I have no =E2=80=9CMajor=E2=80=9D= issues with this I-D. I have some minor comments. Comments: 1- I think that it would be nice to add a graphical example that describes the process of the Path MTU Discovery (including a Packet Too Big Message). e.g. Figure 1 of RFC 5927[1]. 2- Section 1: 2.1- I would add a reference when you mention black hole connection. What about section 2.1 of [2] or [3]? 3- Section 2: 3.1- EMTU_S =3D> When it is defined, it references RFC6691. But this term i= s not mentioned in RFC6691. I would add additionally a reference to RFC 1122 [4] which defines EMTU_S. 3.2- I would add also the same references for EMTU_R. 4.Section 3: 4.1- In the first paragraph, I would add a reference to ICMPv6 the first time that ICMPv6 Packet Too Big message is mentioned. And I would add here also "(ICMPv6 PTB)" since it used further in the document. 4.2- In the first paragraph: "...to send smaller fragments or ..." --> I think it would be clearer "to send smaller packets or..." 4.3- Second Paragraph: "...process ends when the node's estimate..." -> "...process ends when the source node's estimate..."? 4.4- Last Paragraph: "can to appear" -> "can appear" . "...but is in fact..." -> "...but it is in fact..." 5. Section 4: 4.1- about this: "The node MUST reduce the size of the packets it is sending along the path". I would add an explanation to which size the packet should be reduced (maybe based in an initial example) 6.Section 5: 6.1- I would add a reference to RFC 1122 [4] when MMS_S is mentioned. 6.2- Section 5.5: "Some transport protocols are not allowed to repacketize when doing a retransmission..." I would add some examples. 7. Section 6: 7.1- What about to mention Blind Performance-Degrading Attack [5]? ---------------------------------------------------------------------------= ----------------------------------- Thank you, Ines. [1] https://tools.ietf.org/html/rfc5927#section-7.3 [2] https://tools.ietf.org/html/rfc2923 [3] https://tools.ietf.org/html/draft-jacquin-opsawg-icmp-blackhole-problem-00 [4] https://tools.ietf.org/html/rfc1122#page-58 [5] https://tools.ietf.org/html/rfc5927#section-7 --94eb2c0940d2da1ea4054db99a96 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,


Plea= se find my review for "Path MTU Discovery for IP version 6 (draft-ietf= -6man-rfc1981bis-06) I-D:

........................= ...........................................................................= .............................

Document: draft-ietf= -6man-rfc1981bis-06.txt

Reviewer: Ines Robles

Review Date: April 21, 2017

I= ntended status: Standards Track


Sum= mary:

This document describes Path MTU Discovery f= or IP version 6

=C2=A0I believe the draft is techn= ically good. I have no =E2=80=9CMajor=E2=80=9D issues with this I-D. I have= some minor comments.


Comments:

1- I think that it would be nice to add a graphical e= xample that describes the process of the Path MTU Discovery (including a Pa= cket Too Big Message). e.g. Figure 1 of RFC 5927[1].

2- Section 1:=C2=A0

2.1- I would add a reference wh= en you mention black hole connection. What about section 2.1 of [2] or [3]?=

3- Section 2:=C2=A0

3.1- EMT= U_S =3D> When it is defined, it references RFC6691. But this term is not= mentioned in RFC6691. I would add additionally a reference to RFC 1122 [4]= which defines EMTU_S.

3.2- I would add also the same = references for EMTU_R.
=C2=A0
4.Section 3:
4.1- In the first paragraph, I would add a reference to ICMPv6 the= first time that ICMPv6 Packet Too Big message is mentioned. And I would ad= d here also "(ICMPv6 PTB)" since it used further in the document.= =C2=A0

4.2- In the first paragraph: "...to send = smaller fragments or ..." --> I think it would be clearer "to = send smaller packets or..."

4.3- Second Paragraph= : "...process ends when the node's estimate..." -> ".= ..process ends when the source node's estimate..."?

=
= 4.4- Last Paragraph: "can to appear" -> "can appea= r" . "...but is in fact..." -> "...but it is in fact= ..."

5. Section 4:

<= span class=3D"gmail-Apple-tab-span" style=3D"white-space:pre"> 4.1- = about this: "The node MUST reduce the size of the packets it is sendin= g along the path". I would add an explanation to which size the packet= should be reduced (maybe based in an initial example)

=

6.Section 5:=C2=A0

6.1- I would ad= d a reference to RFC 1122 [4] when MMS_S is mentioned.=C2=A0

=
= 6.2- Section 5.5: "Some transport protocols are not allowed to = repacketize when doing a retransmission..." I would add some examples.=

7. Section 6:

7.1- What abou= t to mention Blind Performance-Degrading Attack [5]?
=C2=A0
=
----------------------------------------------------------------------= ----------------------------------------

Thank you= ,

Ines.




=
--94eb2c0940d2da1ea4054db99a96-- From nobody Fri Apr 21 21:16:03 2017 Return-Path: X-Original-To: rtg-dir@ietf.org Delivered-To: rtg-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C8812944A; Fri, 21 Apr 2017 21:16:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ines Robles To: Cc: ipv6@ietf.org, ietf@ietf.org, draft-ietf-6man-rfc1981bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149283456181.25913.15133934620501134310@ietfa.amsl.com> Date: Fri, 21 Apr 2017 21:16:01 -0700 Archived-At: Subject: [RTG-DIR] Rtgdir last call review of draft-ietf-6man-rfc1981bis-06 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 04:16:02 -0000 Reviewer: Ines Robles Review result: Has Nits Document: draft-ietf-6man-rfc1981bis-06.txt Reviewer: Ines Robles Review Date: April 21, 2017 Intended status: Standards Track Summary: This document describes Path MTU Discovery for IP version 6 I believe the draft is technically good. I have no “Major” issues with this I-D. I have some minor comments. Comments: 1- I think that it would be nice to add a graphical example that describes the process of the Path MTU Discovery (including a Packet Too Big Message). e.g. Figure 1 of RFC 5927[1]. 2- Section 1: 2.1- I would add a reference when you mention black hole connection. What about section 2.1 of [2] or [3]? 3- Section 2: 3.1- EMTU_S => When it is defined, it references RFC6691. But this term is not mentioned in RFC6691. I would add additionally a reference to RFC 1122 [4] which defines EMTU_S. 3.2- I would add also the same references for EMTU_R. 4.Section 3: 4.1- In the first paragraph, I would add a reference to ICMPv6 the first time that ICMPv6 Packet Too Big message is mentioned. And I would add here also "(ICMPv6 PTB)" since it used further in the document. 4.2- In the first paragraph: "...to send smaller fragments or ..." --> I think it would be clearer "to send smaller packets or..." 4.3- Second Paragraph: "...process ends when the node's estimate..." -> "...process ends when the source node's estimate..."? 4.4- Last Paragraph: "can to appear" -> "can appear" . "...but is in fact..." -> "...but it is in fact..." 5. Section 4: 4.1- about this: "The node MUST reduce the size of the packets it is sending along the path". I would add an explanation to which size the packet should be reduced (maybe based in an initial example) 6.Section 5: 6.1- I would add a reference to RFC 1122 [4] when MMS_S is mentioned. 6.2- Section 5.5: "Some transport protocols are not allowed to repacketize when doing a retransmission..." I would add some examples. 7. Section 6: 7.1- What about to mention Blind Performance-Degrading Attack [5]? From nobody Sat Apr 22 00:58:50 2017 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 C5A3F1292D0 for ; Sat, 22 Apr 2017 00:58:45 -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, 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.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEnil1Ipm3AG for ; Sat, 22 Apr 2017 00:58:43 -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 C1FFA120724 for ; Sat, 22 Apr 2017 00:58:42 -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 DLN12655; Sat, 22 Apr 2017 07:58:39 +0000 (GMT) Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 22 Apr 2017 08:58:38 +0100 Received: from DGGEML509-MBS.china.huawei.com ([169.254.4.133]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0301.000; Sat, 22 Apr 2017 15:58:36 +0800 From: "Yemin (Amy)" To: "rtg-dir@ietf.org" CC: Jonathan Hardwick Thread-Topic: Please add the coordinators email address into your white list Thread-Index: AdK7PjPKDQ7l0QAOSG2Cjw/JgNwq/A== Date: Sat, 22 Apr 2017 07:58:34 +0000 Message-ID: <9C5FD3EFA72E1740A3D41BADDE0B461FC6B9DC24@dggeml509-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.169.31.176] Content-Type: multipart/alternative; boundary="_000_9C5FD3EFA72E1740A3D41BADDE0B461FC6B9DC24dggeml509mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.58FB0D30.002C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.133, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 32499cfa6506d30a3ead58a9a617ecbf Archived-At: Subject: [RTG-DIR] Please add the coordinators email address into your white list X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 07:58:46 -0000 --_000_9C5FD3EFA72E1740A3D41BADDE0B461FC6B9DC24dggeml509mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Recently we found the notification mail can't be received on time as the ma= il was blocked by the reviewer's mailbox. It would be nice if the directorate could add Jon's and my email address in= to your white list. Thanks. The email addresses are: Jonathan.Hardwick@metaswitch.com and amy.yemin@huawei.com. BR, Jon & Amy ________________________________ This e-mail and its attachments contain confidential information from HUAWE= I, which is intended only for the person or entity whose address is listed above. An= y use of the information contained herein in any way (including, but not limited to, tot= al or partial disclosure, reproduction, or dissemination) by persons other than the inten= ded recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by phone or email immediately and delete it! --_000_9C5FD3EFA72E1740A3D41BADDE0B461FC6B9DC24dggeml509mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

Recently we found the notification mail can’t = be received on time as the mail was blocked by the reviewer’s mailbox= .

It would be nice if the directorate could add Jon= 217;s and my email address into your white list. Thanks.

The email addresses are: Jonathan.Hardwick@metaswitch.com and amy.yemin@huawei.com.

 

BR,

Jon & Amy

This e-mail and its attachments contain confidential inform= ation from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!

 

--_000_9C5FD3EFA72E1740A3D41BADDE0B461FC6B9DC24dggeml509mbschi_-- From nobody Mon Apr 24 11:47:54 2017 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 7A00F131938 for ; Mon, 24 Apr 2017 11:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 71Ee8pP62v7y for ; Mon, 24 Apr 2017 11:47:52 -0700 (PDT) Received: from gproxy9.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 4BD00131935 for ; Mon, 24 Apr 2017 11:47:52 -0700 (PDT) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 0BCFF1E062A for ; Mon, 24 Apr 2017 12:47:52 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id CJno1v00C2SSUrH01Jnrks; Mon, 24 Apr 2017 12:47:51 -0600 X-Authority-Analysis: v=2.2 cv=K+5SJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=AzvcPWV-tVgA:10 a=48vgC7mUAAAA:8 a=ao-CJebsniwK8E5KxfQA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Cc:To:Subject:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=nVqSZHKvyu2BswA8Jx9ibYncmFPV8yDTw48cGtuCTXs=; b=pGKDZvETacAkHGj8KFurhDXobZ tN4vq+fIJL/v2RXfijlBJXpq0m1TYjr1cJ4RhWDOfgCz6rII4h4JWmBT1wvoRuZ1IYfJi2k2bLrFI TbhUyeZMhYhTgFJcnaxi2uw4/; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:47768 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1d2j1Y-000432-2f; Mon, 24 Apr 2017 12:47:48 -0600 From: Lou Berger To: rtg-ads@ietf.org Cc: "rtg-dir@ietf.org" , draft-ietf-spring-resiliency-use-cases.all@ietf.org, spring@ietf.org Message-ID: <52f7d439-e0b3-e7c5-e0ab-c00569dad1a5@labn.net> Date: Mon, 24 Apr 2017 12:15:23 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1d2j1Y-000432-2f X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:47768 X-Source-Auth: lberger@labn.net X-Email-Count: 8 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: [RTG-DIR] RtgDir review: draft-ietf-spring-resiliency-use-cases-08 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 18:47: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 ​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-spring-resiliency-use-cases-08 Reviewer: Lou Berger Review Date: April 24 Intended Status: Informational Summary: I have some minor comments about this document that I think would be good, but not necessary, to be resolved before publication. Comments: This document is concise and clear. I only have minor/nit level issues that could be addressed before publication, but I don't think it critical as the document is being published as Informational. Major Issues: No major issues found. Minor Issues: - Section 2 mentions reversion, while sections 3 and 4 do not. This leaves reversion requirements open to interpretation. I suggest explicitly stating if reversion is a required option or not in sections 3 and 4 as well. - Section 2 mentions 1:1 style path protection. Past/other work on protection also allowed for / uses 1+1 style protection. Is 1+1 intentionally omitted? If not, I suggest allowing for it. Nits: > referred to as local protection techniques or Fast Reroute > techniques. References should be provided for each technique. > It is essential that the primary and backup path benefit from an end- > to-end liveness monitoring/verification. The method and mechanisms > that provide such liveness check are outside the scope of this > document. Given the importance of liveness monitoring, I think it would be worth mentioned an example of such. That's it! Lou From nobody Wed Apr 26 15:08:13 2017 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 40F4612940F for ; Wed, 26 Apr 2017 15:08:13 -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 3zd1u38lulCH for ; Wed, 26 Apr 2017 15:08:11 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 48D071294B3 for ; Wed, 26 Apr 2017 15:08:11 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id f76so13342729qke.2 for ; Wed, 26 Apr 2017 15:08:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=JG9Fl/6WXafCGNgUoyN1e2d3B62Mpu9sOVaw34VmCEA=; b=dDjnWY0r7g9cyDxOMZlh6zhSog6PxDEHlOwKQrxJPY/k9imdQAiEpWWJjVvAJuywCZ K/vfZSMaMoVE4JezI+8/U+CUNIa1lwvMH8YBDkGr6dKhMYQaGkulJ8UVIr0LSEPhHhIE MSGyNULV4xP8CsKIEBaObT/FkhR5c2uQ79Kajsc9Ozj+yw3r7v4EJxTxmdWA0rXhRk1k 8wAq/bMtBsyuvVUa8bTcpYKi8u6h3bjadcKFhZxD376JFmKKJHc1mcrmgWzRDkJYbS22 Qdmqn6Su/XXhPnxKOkHTO9cAjueJVO2wMss83697OllTzxr/qJ/iQ7z6bOqYv4yp9/LM VUAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JG9Fl/6WXafCGNgUoyN1e2d3B62Mpu9sOVaw34VmCEA=; b=euAkTaM81QyFwTf+BlnaLNFLzbb+/9P4S418qLUjqJv9wBLHc+UcbGoPrxJP08dQZg FY8dOlVNz1sTP9Q3f2JhCWpzVHz0OTX5DtsO9uGnHEfX2eAxVlWADPWsZSUPoUq81tF5 qcI1a9K/mYpsmnB5Cs8h9zXkiODb0vJbudo5/Ory23di8rlRyDmngMpxNI2mpJEFZl+s Bouk3bAfcaPbr1wf7094RoSQE0xKaAwP5WMft+ox0rbDQnEcbCKMIMLCP38UGnHbgqQn P2h1HIcoLtXe0EB3XJdgsL4D3NlYrcH+F15lz96Am+WRWMfGddM7o8YdAo6dMHvW4Qdh aIpA== X-Gm-Message-State: AN3rC/578Qhw89/4fZWa5x+y8BFhR3Ad7sl7lO8+io3bSnNv905wB+Pn pgczPcB9P1TEzQXTyPCuIVRym9hIzA== X-Received: by 10.55.207.208 with SMTP id v77mr2228307qkl.189.1493244490315; Wed, 26 Apr 2017 15:08:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.88.176 with HTTP; Wed, 26 Apr 2017 15:08:09 -0700 (PDT) From: Stig Venaas Date: Wed, 26 Apr 2017 15:08:10 -0700 Message-ID: To: rtg-dir@ietf.org, ospf@ietf.org, ospf-chairs@ietf.org, draft-ietf-ospf-segment-routing-extensions.all@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [RTG-DIR] RtgDir QA review: draft-ietf-ospf-segment-routing-extensions-12 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 22:08:13 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. This is just an early QA review. The draft is in good shape, but I did find some minor issues and nits. It is fairly readable, but it could be improved in a few places. Minor issues: In 3.1: The SR-Algorithm TLV is some places called a Sub-TLV. It might be good to be consistent. This is not clear in 3.1: The SR-Algorithm Sub-TLV is optional. It MAY only be advertised once in the Router Information Opaque LSA. Is this trying to say that it MUST NOT be advertised more than once? With the current wording this is not obviously that strict. I see some text regarding multiple SR-Algorithm sub-TLVs, but it also looks like one can have multiple algorithms in one sub-TLV. At least from the diagram. But I don't see any discussion about this. Is it OK to add multiple? When can it be done, what does it mean? What if routers don't support the exact same set of algorithms? The term "lowest flooding scope" is used a couple of places. I think I know what it means, but it might be good to point it out. Also, I'm used to seeing the term "smallest" rather than "lowest". I'm assuming they mean the same. In 3.2 there is this bullet point: The receiving router must adhere to the order in which the ranges are advertised when calculating a SID/label from a SID index. You probably should use MUST here. Section 4: In section 4 there is a range for advertising a range of prefixes. But it looks like it contains a single prefix length and it says the length is the length of the prefix. While it says range size is the number of prefixes. I don't understand from the text what really prefix length and range size means and how this should be used. I understand this is IPv4 only since OSPFv2, but rather than just saying IPv4 is 0, maybe refer to an IANA AF registry? This might be helpful if you want to use the same sub-TLV in OSPFv3 and use the same code for parsing etc. IANA has 1 for IPv4 though. Section 5: Is it intentional that the flags start in position 1 rather than 0? I see that the NP flag should be ignored when M is set. Then I see this text: As the Mapping Server does not specify the originator of a prefix advertisement, it is not possible to determine PHP behavior solely based on the Mapping Server advertisement. However, PHP behavior may safely be done in following cases: This seems not very precise. Could you say exactly what the behavior should be, rather than saying "behavior may be done"? Section 6: It might be good to make clear that other flag positions are reserved, set to 0 and ignored... Perhaps also point out that weight is in the range 0-255. I see this sentence: If the SID/Label Sub-TLV appears in the SID/Label Binding Sub-TLV more than once, instances other than the first will be ignored and Should it say MUST be ignored? Section 6.2 it says: All ERO Sub-TLVs must immediately follow the SID/Label Sub-TLV. All Backup ERO Sub-TLVs must immediately follow the last ERO Sub-TLV. Should these be normative MUSTs? In 6.2.1: It would be good for all of these to specify that other flags are reserved. Nits: The intro should perhaps mention LAN adjacency and binding SIDs? 2nd paragraph of section 2 is confusing. It sounds like the Opaque LSAs in 7684 were defined for SID in particular, but it is a generic mechanism. Perhaps SID was the motivation though? Section 6.1: It says: The ERO Metric Sub-TLV advertises the cost of an ERO path. It is used to compare the cost of a given source/destination path. A router SHOULD advertise the ERO Metric Sub-TLV in an advertised ERO TLV. Is the ERO TLV the ERO Sub-TLVs defined in 6.2? It would be good to point that out. In 8.4.2: Broadcast, NBMA or or hybrid Extra "or". Section 9: There are no new registries and most of the TLVs are already allocated? It seems there are a few new ones where it should probably say TBD, or say something about being suggested values. That was done in earlier sections. I see in some places it says "are allocated" here, while it says "suggested" in the definition of the TLV. Section 10: It says there are responses from 2 implementers, but I see 3. Section 11: Are these really all the potential security issues? I'm on vacation the next 2 weeks, so I may not reply to any emails during that period. Regards, Stig From nobody Thu Apr 27 05:24:52 2017 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 3A80B1288B8; Thu, 27 Apr 2017 05:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.59 X-Spam-Level: X-Spam-Status: No, score=-4.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" 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 ObPo0yuwab0H; Thu, 27 Apr 2017 05:24:48 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.164]) (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 2EFAC1273B1; Thu, 27 Apr 2017 05:24:47 -0700 (PDT) Received: from [85.158.138.179] by server-4.bemta-3.messagelabs.com id 98/5F-02192-C03E1095; Thu, 27 Apr 2017 12:24:44 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1VSf0gTcRTf9+7mLvP0nJrPYYTTIAstUWhEiWW FFKURBIZSt7rcaJuym7qCyvJH+SPQitS1mdmQ0qlhv2cFGhKOpLAkjFY5LacYQlKmgnXbzbL/ Pu993ufz3gceiUsH/WQkazSweh2jkfv5E0lRKdlxASMoc8NcTaiizXpCYb+8WzFxYRZTVF1cp +gz/8IVjbYvEsXryXlcMfVyGk8h0x6bnJI0q3UWS+sdsuAZ+EGxWqfMNR4Wq94NzeN5PwaRse hWEypCJW9QBfInCboMhzFHg7eQ0pcweHH3DSYUnxF03y+WVKBlpB+9BTpbnX4eHEpz0Hr+ple B058w6JwbQB4ihN4K50q7xcLQTrC4rxICjoeBLqsXE/RquD371WtE0VkwM+fwYkSvgBmHDfNg nA6H96PXvRhoGqxPXuECDoPxkQWxMF+JoKsxWehHQd1Hs8RzENBVONhbppFA7IFrNaO8gORxN NxzZwuQ17oKhYnjMPnU7ZvWwPepNiTYvMegvKvZd0MkXLNU+Pw7xNDXXCYWAsvA+bbcFz4S3B +eioUAOhh77iKEkMHQVz9KLBp96zX7wqSDu6qHqEYxpiWZTUvkpiVyE383TsdCh329MBIFVyq HJQJeA6Vmi2RpvxFJWtAajtUXsPq4hA3xSr06R2XQMmoNXyXGa1mOY3JYDaPk4o/kajsR/25n RCL0CD2oSO1BESQmD6NWdqNMaaAy9+gJFcOpDunzNSzXgyJJUg5UhIvngvVsDms8ptbwP7tIA xkgD6WUHpri8hgtp84RKAeKkoVTd4Z5gvYQqnzdX9nitw+glbIQColEImlAHqvXqg3/8xMonE TyECrRYx+g1hn+uk/wizF+MbFd5FlsYP5RsiIUY2M2zWTXm2sKg5yHBu8/m35b3NCf28w6T8U 1ZW1rj4i1aVz9B0L2JlMFho1p9+zbah3RQSd7kyofKg2BXcPzrqPV6c9ulEnHDbXH1oXvOhK8 f98yx1Dk5lhqx9UO5dl2++Tp5IzNq4yZz39ObV1QW7S/0ycTFoLrynf2p5Zk65bLCU7FJKzF9 RzzB9Ot41LoAwAA X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-2.tower-169.messagelabs.com!1493295880!112854805!1 X-Originating-IP: [52.33.64.93] X-StarScan-Received: X-StarScan-Version: 9.4.12; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 4639 invoked from network); 27 Apr 2017 12:24:43 -0000 Received: from ec2-52-33-64-93.us-west-2.compute.amazonaws.com (HELO EUR02-AM5-obe.outbound.protection.outlook.com) (52.33.64.93) by server-2.tower-169.messagelabs.com with AES256-SHA256 encrypted SMTP; 27 Apr 2017 12:24:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZICJtn6qIJeeCFO8GlFRaoVF9OQ5tr59GuqtRZ6COGE=; b=RVIMoV/UlmgRGKgEJTIjfG/mFUrbeyH09E3OeBgnMZ6yqDsK4GOcUilarl6t53I+lEjaN/Sh8EXiXhKPEeToWZFB7q3kzzPJhnuy0fSOo3yjz2oKMMok3gD9Dg1NxaR4WmR9fnI7Q75PZu0//xR7h50U2xYh/+RAZqUmNM4qa8s= Received: from AM4PR03MB1713.eurprd03.prod.outlook.com (10.167.88.15) by DB4PR03MB0846.eurprd03.prod.outlook.com (10.161.15.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Thu, 27 Apr 2017 12:24:39 +0000 Received: from AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::dd45:832a:e658:e737]) by AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::dd45:832a:e658:e737%14]) with mapi id 15.01.1047.019; Thu, 27 Apr 2017 12:24:38 +0000 From: Alexander Vainshtein To: "jefftant.ietf@gmail.com" , "chrisbowers.ietf@gmail.com" CC: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" , "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-rtgwg-backoff-algo@ietf.org" , "rtgwg@ietf.org" , "vainshtein.alex@gmail.com" Thread-Topic: Early RTG-DIR review of draft-ietf-rtgwg-backoff-algo-04 Thread-Index: AdK8QEEK4unKSUKcREikSjn35QwsHw== Date: Thu, 27 Apr 2017 12:24:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-microsoft-exchange-diagnostics: 1; DB4PR03MB0846; 7:tRL/FiN6zrBM6clcEGX6+BDnehNMYR0eP1exSEkX94sXd4BLmqll2mHWr4fbYYKWIgdWj8UVy6+yZd020LaiLS9O9sV6Kg052DXBWcbJq0IfrLzR8hKmTlXEd6GPl1qHhA4xa6bI1QU/0mdnYWhkrLuQa7aOOMyEoVdiH/Pq9vqvoLY+a+p1I0kgejjJuAwW11GjNkHLvyLka/1yoN5zkF0CxLRCm1gEQktBwKuEROKQHrW7mMkZP5G7QDEXsJU/32sg6xyRUZMrVrH4eSwMfL5Yt65FJ88VdYgk1ktDc5eaOJ0UGH+bFb2VUpyRuTlnlHovv/v8u5lsG6XUmnqHBg== x-ms-office365-filtering-correlation-id: b2417ce9-cd9f-4a2e-d08d-08d48d685fc0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DB4PR03MB0846; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(44800604510135)(120809045254105)(21748063052155)(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:DB4PR03MB0846; BCL:0; PCL:0; RULEID:; SRVR:DB4PR03MB0846; x-forefront-prvs: 029097202E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39400400002)(39410400002)(39840400002)(39850400002)(252514010)(2900100001)(8676002)(2906002)(3660700001)(606005)(6436002)(6116002)(790700001)(8936002)(3280700002)(3846002)(102836003)(54896002)(6306002)(9686003)(236005)(54906002)(55016002)(99286003)(53936002)(2501003)(50986999)(7696004)(54356999)(189998001)(86362001)(5250100002)(6506006)(81166006)(33656002)(74316002)(5660300001)(106356001)(7906003)(25786009)(4326008)(39060400002)(66066001)(9326002)(38730400002)(230783001)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR03MB0846; H:AM4PR03MB1713.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR03MB1713386BB8649B3813B8E24E9D100AM4PR03MB1713eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2017 12:24:38.7208 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR03MB0846 X-CFilter-Loop: Reflected Archived-At: Subject: [RTG-DIR] Early RTG-DIR review of draft-ietf-rtgwg-backoff-algo-04 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 12:24:51 -0000 --_000_AM4PR03MB1713386BB8649B3813B8E24E9D100AM4PR03MB1713eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sCgpJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSBh cyBhbiBlYXJseSByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIFJvdXRpbmcgRGlyZWN0b3Jh dGUgc2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yIHJvdXRpbmctcmVsYXRlZCBkcmFmdHMg YXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LCBhbmQg c29tZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVzdC4gSW4gdGhpcyBjYXNlIGFuIGVhcmx5IHJldmll dyBoYXMgYmVlbiByZXF1ZXN0ZWQgYnkgSmVmZiBUYW50c3VyYSDigJMgb25lIG9mIHRoZSBjby1j aGFpcnMgb2YgdGhlIFJUR1dHLgpUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3Zp ZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuICAgRm9yIG1vcmUgaW5mb3JtYXRpb24g YWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUg4oCLaHR0cDovL3RyYWMu dG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpcgoKRG9jdW1lbnQ6IGRyYWZ0 LWlldGYtcnRnd2ctYmFja29mZi1hbGdvLTA0ClJldmlld2VyOiBBbGV4YW5kZXIgKOKAnFNhc2hh 4oCdKSBWYWluc2h0ZWluClJldmlldyBEYXRlOiAyNy1BcHItMTcKSUVURiBMQyBFbmQgRGF0ZTog Ti9BCkludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIFRyYWNrCgpTdW1tYXJ5OgpJIGhhdmUgc29t ZSBtaW5vciBjb25jZXJucyBhYm91dCB0aGlzIGRvY3VtZW50IHRoYXQsIGZyb20gbXkgUE9WLCBz aG91bGQgYmUgcmVzb2x2ZWQgYmVmb3JlIHB1YmxpY2F0aW9uLgoKQ29tbWVudHM6ClRoZSBkcmFm dCBpcyB2ZXJ5IHdlbGwgd3JpdHRlbiwgYW5kLCB3aXRoIG9uZSBub3RhYmxlIGV4Y2VwdGlvbiwg ZWFzeSB0byB1bmRlcnN0YW5kLgpJdCByZXByZXNlbnRzIGFuIGF0dGVtcHQgdG8gc3RhbmRhcmRp emUgb25lIGFzcGVjdCBvZiBiZWhhdmlvciBvZiBsaW5rLXN0YXRlIHJvdXRpbmcgcHJvdG9jb2xz OiBkZWxheSBiZXR3ZWVuIHRoZSBmaXJzdCBJR1AgZXZlbnQgdGhhdCB0cmlnZ2VycyBuZXcgU1BG IGNvbXB1dGF0aW9uIGFuZCB0aGUgU1BGIGNhbGN1bGF0aW9uLiBVbnRpbCBub3csIHRoaXMgYmVl biBsZWZ0IGZvciB0aGUgaW1wbGVtZW50ZXJzIHRvIHBsYXkgd2l0aCBmcmVlbHkuIFRoZSByZXN1 bHRpbmcgZGlmZmVyZW5jZXMgaGF2ZSBiZWVuIGtub3duIGZvciBxdWl0ZSBzb21lIHRpbWUgdG8g cmVzdWx0IGluIHNvbWUgY2FzZSBpbiB0cmFuc2llbnQgbWljcm8tbG9vcHMuCgpUaGUgcmVzb2x1 dGlvbiBwcm9wb3NlZCBpbiB0aGlzIGRyYWZ0IGluY2x1ZGVzIGEgd2VsbC1kZWZpbmVkIEZTTSBh bmQgYSBmdWxsIHNldCBvZiB0dW5hYmxlIHBhcmFtZXRlcnMgKHRpbWVycykgdXNlZCBpbiB0aGlz IEZTTS4KVGhlIHJhbmdlIGFuZCBncmFudWxhcml0eSBvZiBhbGwgdGhlIHR1bmFibGUgcGFyYW1l dGVycyBhcmUgZXhwbGljaXRseSBkZWZpbmVkIGluIHRoZSBkb2N1bWVudCBzbyB0aGF0IHRoZSBv cGVyYXRvciB3b3VsZCBiZSBhYmxlIHRvIHR1bmUgaXRzIG5ldHdvcmsgdG8gdXNlIGV4YWN0bHkg dGhlIHNhbWUgU1BGIGRlbGF5IGFsZ29yaXRobSB3aXRoIGV4YWN0bHkgdGhlIHNhbWUgcGFyYW1l dGVycy4gKFRoZSBkZWZhdWx0IHZhbHVlcyBhcmUgbm90IGRlZmluZWQgYmVjYXVzZSBvbmUgc2l6 ZSBkb2VzIG5vdCBmaXQgYWxsIGluIHRoaXMgY2FzZSkuCgpJdCBzaG91bGQgYmUgbm90aWNlZCB0 aGF0IHRoZSBkcmFmdCBkb2VzIG5vdCBpbnRlbmQgdG8gcHJvdmlkZSBhIGNvbXByZWhlbnNpdmUg c29sdXRpb24gb2YgdGhlIG1pY3JvLWxvb3AgcHJvYmxlbXMuClJhdGhlciwgaXQgcHJvdmlkZXMg YSBjb21tb24gYmFzZWxpbmUgdXBvbiB3aGljaCBzcGVjaWZpYyBzb2x1dGlvbnMgZm9yIHRoZXNl IHByb2JsZW1zIGNhbiBiZSBidWlsdCAoZS5nLiwgc2VlIGRyYWZ0LWlldGYtcnRnd2ctdWxvb3At ZGVsYXk8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydGd3Zy11 bG9vcC1kZWxheS8/aW5jbHVkZV90ZXh0PTE+KS4KCk1ham9yIElzc3VlczogTm9uZSBmb3VuZC4K Ck1pbm9yIElzc3VlczoKCjEuICAgICAgIFRoZSBleGNlcHRpb24gdG8gZ29vZCByZWFkYWJpbGl0 eSBvZiB0aGUgZHJhZnQgcmVmZXJzIHRvIHRoZSB0ZXJtIOKAnHByb3hpbWF0ZSBmYWlsdXJlcy9J R1AgZXZlbnRz4oCdIHRoYXQgYXBwZWFycyA0IHRpbWVzIGluIHRoZSBkcmFmdC4gRW5nbGlzaCBp cyBub3QgbXkgbW90aGVyIHRvbmd1ZSwgYW5kIHRoZSByZWZlcmVuY2U8aHR0cHM6Ly93d3cubWVy cmlhbS13ZWJzdGVyLmNvbS90aGVzYXVydXMvcHJveGltYXRlPiBJ4oCZdmUgbG9va2VkIHVwIGRp ZCBub3QgaGVscCBtdWNoLiDigJxUZW1wb3JhbGx5IGNsb3Nl4oCdIChvciBzb21ldGhpbmcgYWxv bmcgdGhlc2UgbGluZXMpIGxvb2tzIGxpa2UgYSBzdWl0YWJsZSBhbHRlcm5hdGl2ZS4gKERvZXMg dGhpcyBjb21tZW50IHJ1biBzdHJpY3RseSBhZ2FpbnN0IHRoZSByZWNvbW1lbmRhdGlvbiBmb3Ig dGhlIFJURy1ESVIgcmV2aWV3ZXJzIOKAnHRvIGF2b2lkIHJhaXNpbmcgZXNvdGVyaWMgcXVlc3Rp b25zIG9mIEVuZ2xpc2ggdXNhZ2XigJ0/KQoKMi4gICAgICAgU2VjdGlvbiA1IG1lbnRpb25zIHN0 YXJ0aW5nIHRoZSBTUEZfVElNRVIgKHdpdGggb25lIG9mIHRoZSAzIHZhbHVlcyBkZWZpbmVkIGZv ciBpdCkgYXMgcGFydCBvZiB0aGUgcmVzcG9uc2UgdG8gc29tZSBGU00gZXZlbnRzIGlmIGl0IHdh cyBub3QgYWxyZWFkeSBydW5uaW5nIC0gIGJ1dCBpdCBkb2VzIG5vdCBzcGVjaWZ5IHdoYXQgaGFw cGVucyB3aGVuIHRoaXMgdGltZXIgZXhwaXJlcy4gSSBhc3N1bWUgdGhhdCBpdHMgZXhwaXJhdGlv biBsZWF2ZXMgdGhlIEZTTSBpbiBpdHMgY3VycmVudCBzdGF0ZSBhbmQgcmVzdWx0cyBpbiBydW5u aW5nIHRoZSBTUEYgY29tcHV0YXRpb24g4oCTIGlmIHRoaXMgaXMgY29ycmVjdCwgaXQgd291bGQg YmUgbmljZSB0byBzYXkgdGhhdCBleHBsaWNpdGx5LgoKMy4gICAgICAgU2VjdGlvbiA3IHJlY29t bWVuZHMgdGhhdCwgIGluIG9yZGVyIHRvIG1pdGlnYXRlIG1pY3JvLWxvb3AgcHJvYmxlbXMgdXNp bmcgdGhlIHByb3Bvc2VkIGFsZ29yaXRobSwg4oCcYWxsIHJvdXRlcnMgaW4gdGhlIElHUCBkb21h aW4sIG9yIGF0IGxlYXN0IGFsbCB0aGUgcm91dGVycyBpbiB0aGUgc2FtZSBhcmVhL2xldmVsLCBo YXZlIGV4YWN0bHkgdGhlIHNhbWUgY29uZmlndXJlZCAgdmFsdWVz4oCdIG9mIHRoZSByZWxldmFu dCB0aW1lcnMgLiBIb3dldmVyLCB0aGUgZHJhZnQgZG9lcyBub3Qgc3BlY2lmeSB3aGV0aGVyIHRo ZXNlIHRpbWVycyBzaG91bGQgYmUgY29uZmlndXJlZCBqdXN0IGF0IHRoZSBwcm90b2NvbCBpbnN0 YW5jZSBsZXZlbCBvciBhbHNvIGF0IHRoZSBsZXZlbCBvZiBlYWNoIHNwZWNpZmljIGFyZWEvbGV2 ZWwuIEZyb20gbXkgUE9WLCB0aGUgZ3JhbnVsYXJpdHkgb2YgY29uZmlndXJhdGlvbiBzaG91bGQg YmUgZGVmaW5lZCBpbiB0aGlzIGRyYWZ0IOKAkyBvbmUgd2F5IG9yIGFub3RoZXIuCgo0LiAgICAg ICBUaGUgbGF0ZXN0IHZlcnNpb25zIG9mIHRoZSBZQU5HIGRhdGEgbW9kZWwgZHJhZnRzIGZvciBJ Uy1JUyBhbmQgT1NQRiBhbHJlYWR5IGRlZmluZSB0aGUgdGltZXJzIGludHJvZHVjZWQgaW4gdGhp cyBkcmFmdC4gQnV0IHRoZXJlIGFyZSBubyByZWZlcmVuY2VzIHRvIHRoZXNlIGRyYWZ0cyBpbiB0 aGUgZG9jdW1lbnQuIEZyb20gbXkgUE9WIHN1Y2ggcmVmZXJlbmNlcyAoSW5mb3JtYXRpb25hbCBh bmQgdGhlcmVmb3JlIG5vbi1ibG9ja2luZykgd291bGQgYmUgdXNlZnVsIGZvciB0aGUgcmVhZGVy cywgYW5kIEkgc3VnZ2VzdCB0byBhZGQgdGhlbS4KCjUuICAgICAgIEkgaGF2ZSBzb21lIGNvbmNl cm5zIHJlZ2FyZGluZyBpbmNyZW1lbnRhbCBpbnRyb2R1Y3Rpb24gYW5kIGFjdGl2YXRpb24gb2Yg dGhlIHByb3Bvc2VkIGFsZ29yaXRobS4gVGhlIG9wZXJhdG9yIHRoYXQgcnVucyBhIHdlbGwtdHVu ZWQgbmV0d29yayBtYXkgZXhwZXJpZW5jZSB0cmFuc2llbnQgcHJvYmxlbXMgd2hlbiBzb21lIG9m IGl0cyByb3V0ZXJzIGFyZSBhbHJlYWR5IHVwZ3JhZGVkIGFuZCB1c2UgdGhlIHByb3Bvc2VkIGJh Y2stb2ZmIGFsZ29yaXRobSB3aGlsZSBzb21lIG90aGVycyBzdGlsbCBjYW5ub3QgZG8gdGhhdC4g U29tZSB0ZXh0IGV4cGxhaW5pbmcgcG90ZW50aWFsIGlzc3VlcyBpbiB0aGlzIHNjZW5hcmlvIGFu ZCwgaWYgcG9zc2libGUsIHRoZWlyIG1pdGlnYXRpb24sIHdvdWxkIGJlIG1vc3QgaGVscGZ1bC4K CjYuICAgICAgIFRoZSBleHBsYW5hdG9yeSB0ZXh0IGluIHRoZSBkcmFmdCBzZWVtcyB0byBzdHJv bmdseSBzdWdnZXN0IHRoYXQgIFNQRl9JTklUSUFMX0RFTEFZIDw9IFNQRl9TSE9SVF9ERUxBWSA8 PSAgU1BGX0xPTkdfREVMQVkg4oCTICBidXQgdGhpcyBpcyBub3QgZm9ybWFsaXplZCBhcyBhIHJl cXVpcmVtZW50IGFueXdoZXJlIGluIHRoZSB0ZXh0LiBGcm9tIG15IFBPViBzYXRpc2Z5aW5nIHRo aXMgcmVsYXRpb25zaGlwIHNob3VsZCBiZSBSRUNPTU1FTkRFRCB0byB0aGUgb3BlcmF0b3JzLgoK TklUUzoKCjEuICAgICAgIFNlY3Rpb24gMyBsaXN0cyAzIHBvc3NpYmxlIHZhbHVlcyBmb3IgdGhl IFNQRl9ERUxBWSB2YXJpYWJsZSBjYWxsZWQgSU5JVElBTF9TUEZfREVMQVksIFNIT1JUIFNQRl9E RUxBWSBhbmQgTE9OR19TUEZfREVMQVkuIFRoZW4sIGluIHRoZSBsYXN0IHBhcmEsIGl0IHJlZmVy cyB0byBhIHByZXZpb3VzbHkgdW5kZWZpbmVkIHZhbHVlLCBJTklUSUFMX1dBSVQuIFRoaXMgaXMg YW4gb2J2aW91cyB0eXBvIGFuZCBzaG91bGQgYmUgcmVwbGFjZWQgd2l0aCBJTklUSUFMX1NQRl9E RUxBWQoKMi4gICAgICAgT25lIG9mIHRoZSBwYXJhbWV0ZXJzIG9mIHRoZSBhbGdvcml0aG0gaXMg Y2FsbGVkIEhPTERfRE9XTl9JTlRFUlZBTCAoaW4gU2VjdGlvbiAzIGFuZCBTZWN0aW9uIDYpICB2 cy4gSE9MRERPV05fSU5URVJWQUwgaW4gU2VjdGlvbiA1LiBUaGlzIGFsc28gbG9va3MgbGlrZSBh biBvYnZpb3VzIHR5cG8sIGFuZCB0aGUgc2FtZSBuYW1lIHNob3VsZCBiZSB1c2VkIGFjcm9zcyB0 aGUgZG9jdW1lbnQuCgpJIGhhdmUgZGlzY3Vzc2VkIG15IGNvbmNlcm5zIGFib3V0IHRoZSBkcmFm dCB3aXRoIHRoZSBhdXRob3JzIHdobyBoYXZlIGJlZW4gbW9zdCBjb29wZXJhdGl2ZS4KSSBiZWxp ZXZlIHRoYXQgd2UgaGF2ZSByZWFjaGVkIGFuIGFncmVlbWVudCBvbiBhY2NlcHRhYmxlIHJlc29s dXRpb24gb2YgYWxsIGNvbmNlcm5zIGxpc3RlZCBhYm92ZS4KClJlZ2FyZHMsClNhc2hhCgpPZmZp Y2U6ICs5NzItMzkyNjYzMDIKQ2VsbDogICAgICArOTcyLTU0OTI2NjMwMgpFbWFpbDogICBBbGV4 YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKVGhpcyBl LW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250 YWlucyBpbmZvcm1hdGlvbiB3aGljaCBpcyAKQ09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUg cHJvcHJpZXRhcnkgdG8gRUNJIFRlbGVjb20uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgCnRy YW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9y IGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCAKYW5kIGFsbCBjb3BpZXMgdGhlcmVv Zi4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCg== --_000_AM4PR03MB1713386BB8649B3813B8E24E9D100AM4PR03MB1713eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+CjxoZWFkPgo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+CjxtZXRhIG5hbWU9IkdlbmVyYXRvciIg Y29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPgo8c3R5bGU+PCEt LQovKiBGb250IERlZmluaXRpb25zICovCkBmb250LWZhY2UKCXtmb250LWZhbWlseToiQ2FtYnJp YSBNYXRoIjsKCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQpAZm9udC1mYWNlCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsKCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bAoJe21hcmdpbjowY207CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cglmb250LXNpemU6MTEuMHB0 OwoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJY29sb3I6IzA1NjNDMTsKCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQK CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7Cgljb2xvcjojOTU0RjcyOwoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2 Lk1zb0xpc3RQYXJhZ3JhcGgKCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7CgltYXJnaW4tdG9wOjBj bTsKCW1hcmdpbi1yaWdodDowY207CgltYXJnaW4tYm90dG9tOjBjbTsKCW1hcmdpbi1sZWZ0OjM2 LjBwdDsKCW1hcmdpbi1ib3R0b206LjAwMDFwdDsKCWZvbnQtc2l6ZToxMS4wcHQ7Cglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9CnNwYW4uRW1haWxTdHlsZTE4Cgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtY29tcG9zZTsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm OwoJY29sb3I6d2luZG93dGV4dDsKCWZvbnQtd2VpZ2h0Om5vcm1hbDsKCWZvbnQtc3R5bGU6bm9y bWFsOwoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9CnNwYW4uRW1haWxTdHlsZTE5Cgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsK CWNvbG9yOiM0NDU0NkE7Cglmb250LXdlaWdodDpub3JtYWw7Cglmb250LXN0eWxlOm5vcm1hbDsK CXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQouTXNvQ2hwRGVmYXVsdAoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5OwoJZm9udC1zaXplOjEwLjBwdDsKCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30KQHBhZ2UgV29yZFNlY3Rpb24xCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 CgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30KZGl2LldvcmRTZWN0aW9uMQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30KLyogTGlzdCBEZWZpbml0aW9ucyAqLwpAbGlzdCBsMAoJe21z by1saXN0LWlkOjM3NzgyMjkxNTsKCW1zby1saXN0LXR5cGU6aHlicmlkOwoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOi0xMDkxMTQyMTQwIDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAz IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30KQGxpc3QgbDA6 bGV2ZWwxCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7Cgl0ZXh0LWluZGVudDotMTguMHB0O30KQGxpc3QgbDA6bGV2ZWwyCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsK CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQpA bGlzdCBsMDpsZXZlbDMKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsKCW1z by1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsK CXRleHQtaW5kZW50Oi05LjBwdDt9CkBsaXN0IGwwOmxldmVsNAoJe21zby1sZXZlbC10YWItc3Rv cDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDt9CkBsaXN0IGwwOmxldmVsNQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxv d2VyOwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7Cgl0ZXh0LWluZGVudDotMTguMHB0O30KQGxpc3QgbDA6bGV2ZWw2Cgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQpAbGlz dCBsMDpsZXZlbDcKCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsKCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQpAbGlzdCBsMDpsZXZlbDgKCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsKCW1zby1sZXZlbC10YWItc3RvcDpu b25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJdGV4dC1pbmRlbnQ6LTE4LjBw dDt9CkBsaXN0IGwwOmxldmVsOQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2Vy OwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJp Z2h0OwoJdGV4dC1pbmRlbnQ6LTkuMHB0O30KQGxpc3QgbDEKCXttc28tbGlzdC1pZDo3NDI2Nzg4 NjY7Cgltc28tbGlzdC10eXBlOmh5YnJpZDsKCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTA5MTE0 MjE0MCA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcx NSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9CkBsaXN0IGwxOmxldmVsMQoJe21zby1sZXZl bC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJdGV4dC1p bmRlbnQ6LTE4LjBwdDt9CkBsaXN0IGwxOmxldmVsMgoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmFscGhhLWxvd2VyOwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7Cgl0ZXh0LWluZGVudDotMTguMHB0O30KQGxpc3QgbDE6bGV2ZWwzCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7Cgl0ZXh0LWluZGVudDotOS4w cHQ7fQpAbGlzdCBsMTpsZXZlbDQKCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQpAbGlzdCBsMTps ZXZlbDUKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsKCW1zby1sZXZlbC10 YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9CkBsaXN0IGwxOmxldmVsNgoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJv bWFuLWxvd2VyOwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOnJpZ2h0OwoJdGV4dC1pbmRlbnQ6LTkuMHB0O30KQGxpc3QgbDE6bGV2ZWw3Cgl7bXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7Cgl0 ZXh0LWluZGVudDotMTguMHB0O30KQGxpc3QgbDE6bGV2ZWw4Cgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YWxwaGEtbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQpAbGlzdCBsMTpsZXZl bDkKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsKCW1zby1sZXZlbC10YWIt c3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsKCXRleHQtaW5kZW50 Oi05LjBwdDt9Cm9sCgl7bWFyZ2luLWJvdHRvbTowY207fQp1bAoJe21hcmdpbi1ib3R0b206MGNt O30KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4K PC9oZWFkPgo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIi Pgo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyw8 bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5n IERpcmVjdG9yYXRlIGFzIGFuIGVhcmx5IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91 dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1y ZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVT RyByZXZpZXcsIGFuZCBzb21ldGltZXMgb24gc3BlY2lhbAogcmVxdWVzdC4gSW4gdGhpcyBjYXNl IGFuIGVhcmx5IHJldmlldyBoYXMgYmVlbiByZXF1ZXN0ZWQgYnkgSmVmZiBUYW50c3VyYSDigJMg b25lIG9mIHRoZSBjby1jaGFpcnMgb2YgdGhlIFJUR1dHLjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNz aXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuJm5ic3A7Jm5ic3A7IEZvciBtb3JlIGluZm9ybWF0 aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIOKAi2h0dHA6Ly90 cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXI8bzpwPjwvbzpwPjwv cD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPkRvY3VtZW50PC9iPjogZHJhZnQtaWV0Zi1ydGd3Zy1iYWNrb2ZmLWFsZ28t MDQ8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+UmV2aWV3ZXI8L2I+OiBB bGV4YW5kZXIgKOKAnFNhc2hh4oCdKSBWYWluc2h0ZWluIDxvOnA+PC9vOnA+PC9wPgo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj5SZXZpZXcgRGF0ZTwvYj46IDI3LUFwci0xNyA8bzpwPjwvbzpwPjwv cD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+SUVURiBMQyBFbmQgRGF0ZTwvYj46IE4vQTxvOnA+ PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5JbnRlbmRlZCBTdGF0dXM8L2I+OiBT dGFuZGFyZHMgVHJhY2s8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPlN1bW1hcnk8L2I+OjxvOnA+ PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgc29tZSBtaW5vciBjb25jZXJu cyBhYm91dCB0aGlzIGRvY3VtZW50IHRoYXQsIGZyb20gbXkgUE9WLCBzaG91bGQgYmUgcmVzb2x2 ZWQgYmVmb3JlIHB1YmxpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+Q29tbWVudHM8 L2I+OjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZHJhZnQgaXMgdmVy eSB3ZWxsIHdyaXR0ZW4sIGFuZCwgd2l0aCBvbmUgbm90YWJsZSBleGNlcHRpb24sIGVhc3kgdG8g dW5kZXJzdGFuZC48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgcmVwcmVz ZW50cyBhbiBhdHRlbXB0IHRvIHN0YW5kYXJkaXplIG9uZSBhc3BlY3Qgb2YgYmVoYXZpb3Igb2Yg bGluay1zdGF0ZSByb3V0aW5nIHByb3RvY29sczogZGVsYXkgYmV0d2VlbiB0aGUgZmlyc3QgSUdQ IGV2ZW50IHRoYXQgdHJpZ2dlcnMgbmV3IFNQRiBjb21wdXRhdGlvbiBhbmQgdGhlIFNQRiBjYWxj dWxhdGlvbi4gVW50aWwgbm93LCB0aGlzIGJlZW4gbGVmdCBmb3IgdGhlIGltcGxlbWVudGVycwog dG8gcGxheSB3aXRoIGZyZWVseS4gVGhlIHJlc3VsdGluZyBkaWZmZXJlbmNlcyBoYXZlIGJlZW4g a25vd24gZm9yIHF1aXRlIHNvbWUgdGltZSB0byByZXN1bHQgaW4gc29tZSBjYXNlIGluIHRyYW5z aWVudCBtaWNyby1sb29wcy4gJm5ic3A7PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcmVzb2x1 dGlvbiBwcm9wb3NlZCBpbiB0aGlzIGRyYWZ0IGluY2x1ZGVzIGEgd2VsbC1kZWZpbmVkIEZTTSBh bmQgYSBmdWxsIHNldCBvZiB0dW5hYmxlIHBhcmFtZXRlcnMgKHRpbWVycykgdXNlZCBpbiB0aGlz IEZTTS48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHJhbmdlIGFuZCBn cmFudWxhcml0eSBvZiBhbGwgdGhlIHR1bmFibGUgcGFyYW1ldGVycyBhcmUgZXhwbGljaXRseSBk ZWZpbmVkIGluIHRoZSBkb2N1bWVudCBzbyB0aGF0IHRoZSBvcGVyYXRvciB3b3VsZCBiZSBhYmxl IHRvIHR1bmUgaXRzIG5ldHdvcmsgdG8gdXNlIGV4YWN0bHkgdGhlIHNhbWUgU1BGIGRlbGF5IGFs Z29yaXRobSB3aXRoIGV4YWN0bHkgdGhlIHNhbWUgcGFyYW1ldGVycy4gKFRoZSBkZWZhdWx0CiB2 YWx1ZXMgYXJlIG5vdCBkZWZpbmVkIGJlY2F1c2Ugb25lIHNpemUgZG9lcyBub3QgZml0IGFsbCBp biB0aGlzIGNhc2UpLjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgc2hvdWxkIGJlIG5vdGljZWQg dGhhdCB0aGUgZHJhZnQgZG9lcyBub3QgaW50ZW5kIHRvIHByb3ZpZGUgYSBjb21wcmVoZW5zaXZl IHNvbHV0aW9uIG9mIHRoZSBtaWNyby1sb29wIHByb2JsZW1zLiZuYnNwOwo8bzpwPjwvbzpwPjwv cD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmF0aGVyLCBpdCBwcm92aWRlcyBhIGNvbW1vbiBiYXNl bGluZSB1cG9uIHdoaWNoIHNwZWNpZmljIHNvbHV0aW9ucyBmb3IgdGhlc2UgcHJvYmxlbXMgY2Fu IGJlIGJ1aWx0IChlLmcuLCBzZWUKPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1ydGd3Zy11bG9vcC1kZWxheS8/aW5jbHVkZV90ZXh0PTEiPgpkcmFm dC1pZXRmLXJ0Z3dnLXVsb29wLWRlbGF5PC9hPikuPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5N YWpvciBJc3N1ZXM8L2I+OiBOb25lIGZvdW5kLjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+TWlu b3IgSXNzdWVzPC9iPjo8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRp cj0iTFRSIj48L3NwYW4+VGhlIGV4Y2VwdGlvbiB0byBnb29kIHJlYWRhYmlsaXR5IG9mIHRoZSBk cmFmdCByZWZlcnMgdG8gdGhlIHRlcm0g4oCcPGI+PGk+cHJveGltYXRlPC9pPjwvYj4gZmFpbHVy ZXMvSUdQIGV2ZW50c+KAnSB0aGF0IGFwcGVhcnMgNCB0aW1lcyBpbiB0aGUgZHJhZnQuIEVuZ2xp c2ggaXMgbm90IG15IG1vdGhlciB0b25ndWUsIGFuZCB0aGUKPGEgaHJlZj0iaHR0cHM6Ly93d3cu bWVycmlhbS13ZWJzdGVyLmNvbS90aGVzYXVydXMvcHJveGltYXRlIj5yZWZlcmVuY2U8L2E+IEni gJl2ZSBsb29rZWQgdXAgZGlkIG5vdCBoZWxwIG11Y2guIOKAnFRlbXBvcmFsbHkgY2xvc2XigJ0g KG9yIHNvbWV0aGluZyBhbG9uZyB0aGVzZSBsaW5lcykgbG9va3MgbGlrZSBhIHN1aXRhYmxlIGFs dGVybmF0aXZlLiAoRG9lcyB0aGlzIGNvbW1lbnQgcnVuIHN0cmljdGx5IGFnYWluc3QgdGhlIHJl Y29tbWVuZGF0aW9uIGZvcgogdGhlIFJURy1ESVIgcmV2aWV3ZXJzIOKAnHRvIGF2b2lkIHJhaXNp bmcgZXNvdGVyaWMgcXVlc3Rpb25zIG9mIEVuZ2xpc2ggdXNhZ2XigJ0/KTxvOnA+PC9vOnA+PC9w Pgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKPC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj5TZWN0aW9uIDUgbWVu dGlvbnMgc3RhcnRpbmcgdGhlIFNQRl9USU1FUiAod2l0aCBvbmUgb2YgdGhlIDMgdmFsdWVzIGRl ZmluZWQgZm9yIGl0KSBhcyBwYXJ0IG9mIHRoZSByZXNwb25zZSB0byBzb21lIEZTTSBldmVudHMg aWYgaXQgd2FzIG5vdCBhbHJlYWR5IHJ1bm5pbmcgLSZuYnNwOyBidXQKPGI+PGk+aXQgZG9lcyBu b3Qgc3BlY2lmeSB3aGF0IGhhcHBlbnMgd2hlbiB0aGlzIHRpbWVyIGV4cGlyZXM8L2k+PC9iPi4g SSBhc3N1bWUgdGhhdCBpdHMgZXhwaXJhdGlvbiBsZWF2ZXMgdGhlIEZTTSBpbiBpdHMgY3VycmVu dCBzdGF0ZSBhbmQgcmVzdWx0cyBpbiBydW5uaW5nIHRoZSBTUEYgY29tcHV0YXRpb24g4oCTIGlm IHRoaXMgaXMgY29ycmVjdCwgaXQgd291bGQgYmUgbmljZSB0byBzYXkgdGhhdCBleHBsaWNpdGx5 LjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQt aW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsKPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bh bj5TZWN0aW9uIDcgcmVjb21tZW5kcyB0aGF0LCZuYnNwOyBpbiBvcmRlciB0byBtaXRpZ2F0ZSBt aWNyby1sb29wIHByb2JsZW1zIHVzaW5nIHRoZSBwcm9wb3NlZCBhbGdvcml0aG0sIOKAnGFsbCBy b3V0ZXJzIGluIHRoZSBJR1AgZG9tYWluLCBvciBhdCBsZWFzdCBhbGwgdGhlIHJvdXRlcnMgaW4g dGhlIHNhbWUgYXJlYS9sZXZlbCwgaGF2ZSBleGFjdGx5IHRoZSBzYW1lIGNvbmZpZ3VyZWQmbmJz cDsKIHZhbHVlc+KAnSBvZiB0aGUgcmVsZXZhbnQgdGltZXJzIC4gSG93ZXZlciwgdGhlIGRyYWZ0 IGRvZXMgbm90IHNwZWNpZnkgd2hldGhlciB0aGVzZSB0aW1lcnMgc2hvdWxkIGJlIGNvbmZpZ3Vy ZWQganVzdCBhdCB0aGUgcHJvdG9jb2wgaW5zdGFuY2UgbGV2ZWwgb3IgYWxzbyBhdCB0aGUgbGV2 ZWwgb2YgZWFjaCBzcGVjaWZpYyBhcmVhL2xldmVsLiBGcm9tIG15IFBPViwgdGhlCjxiPjxpPmdy YW51bGFyaXR5IG9mIGNvbmZpZ3VyYXRpb248L2k+PC9iPiBzaG91bGQgYmUgZGVmaW5lZCBpbiB0 aGlzIGRyYWZ0IOKAkyBvbmUgd2F5IG9yIGFub3RoZXIuPG86cD48L286cD48L3A+CjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDps MCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+NC48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPlRoZSBsYXRlc3QgdmVyc2lvbnMgb2Yg dGhlIFlBTkcgZGF0YSBtb2RlbCBkcmFmdHMgZm9yIElTLUlTIGFuZCBPU1BGIGFscmVhZHkgZGVm aW5lIHRoZSB0aW1lcnMgaW50cm9kdWNlZCBpbiB0aGlzIGRyYWZ0LiBCdXQKPGI+PGk+dGhlcmUg YXJlIG5vIHJlZmVyZW5jZXMgdG8gdGhlc2UgZHJhZnRzIGluIHRoZSBkb2N1bWVudDwvaT48L2I+ LiBGcm9tIG15IFBPViBzdWNoIHJlZmVyZW5jZXMgKEluZm9ybWF0aW9uYWwgYW5kIHRoZXJlZm9y ZSBub24tYmxvY2tpbmcpIHdvdWxkIGJlIHVzZWZ1bCBmb3IgdGhlIHJlYWRlcnMsIGFuZCBJIHN1 Z2dlc3QgdG8gYWRkIHRoZW0uPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+NS48c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBkaXI9IkxUUiI+PC9zcGFuPkkgaGF2ZSBzb21lIGNvbmNlcm5zIHJlZ2FyZGluZyA8Yj4KPGk+ aW5jcmVtZW50YWwgaW50cm9kdWN0aW9uIGFuZCBhY3RpdmF0aW9uIG9mIHRoZSBwcm9wb3NlZCBh bGdvcml0aG08L2k+PC9iPi4gVGhlIG9wZXJhdG9yIHRoYXQgcnVucyBhIHdlbGwtdHVuZWQgbmV0 d29yayBtYXkgZXhwZXJpZW5jZSB0cmFuc2llbnQgcHJvYmxlbXMgd2hlbiBzb21lIG9mIGl0cyBy b3V0ZXJzIGFyZSBhbHJlYWR5IHVwZ3JhZGVkIGFuZCB1c2UgdGhlIHByb3Bvc2VkIGJhY2stb2Zm IGFsZ29yaXRobSB3aGlsZSBzb21lIG90aGVycwogc3RpbGwgY2Fubm90IGRvIHRoYXQuIFNvbWUg dGV4dCBleHBsYWluaW5nIHBvdGVudGlhbCBpc3N1ZXMgaW4gdGhpcyBzY2VuYXJpbyBhbmQsIGlm IHBvc3NpYmxlLCB0aGVpciBtaXRpZ2F0aW9uLCB3b3VsZCBiZSBtb3N0IGhlbHBmdWwuPG86cD48 L286cD48L3A+CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6 LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Ni48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOwo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPlRoZSBl eHBsYW5hdG9yeSB0ZXh0IGluIHRoZSBkcmFmdCBzZWVtcyB0byBzdHJvbmdseSBzdWdnZXN0IHRo YXQmbmJzcDsKPGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij5TUEZfSU5JVElBTF9ERUxBWSAmbHQ7PSBTUEZfU0hPUlRfREVMQVkgJmx0Oz0mbmJzcDsg U1BGX0xPTkdfREVMQVkKPC9zcGFuPjwvYj7igJMmbmJzcDsgYnV0IHRoaXMgaXMgbm90IGZvcm1h bGl6ZWQgYXMgYSByZXF1aXJlbWVudCBhbnl3aGVyZSBpbiB0aGUgdGV4dC4gRnJvbSBteSBQT1Yg c2F0aXNmeWluZyB0aGlzIHJlbGF0aW9uc2hpcCBzaG91bGQgYmUgUkVDT01NRU5ERUQgdG8gdGhl IG9wZXJhdG9ycy48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPk5JVFM8L2I+OjxvOnA+PC9vOnA+ PC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4w cHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzQiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsK PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj5TZWN0aW9uIDMg bGlzdHMgMyBwb3NzaWJsZSB2YWx1ZXMgZm9yIHRoZSBTUEZfREVMQVkgdmFyaWFibGUgY2FsbGVk IElOSVRJQUxfU1BGX0RFTEFZLCBTSE9SVCBTUEZfREVMQVkgYW5kIExPTkdfU1BGX0RFTEFZLiBU aGVuLCBpbiB0aGUgbGFzdCBwYXJhLCBpdCByZWZlcnMgdG8KPGI+PGk+YSBwcmV2aW91c2x5IHVu ZGVmaW5lZCB2YWx1ZSwgSU5JVElBTF9XQUlUPC9pPjwvYj4uIFRoaXMgaXMgYW4gb2J2aW91cyB0 eXBvIGFuZCBzaG91bGQgYmUgcmVwbGFjZWQgd2l0aCBJTklUSUFMX1NQRl9ERUxBWTxvOnA+PC9v OnA+PC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0x OC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzQiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsKPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj5PbmUgb2Yg dGhlIHBhcmFtZXRlcnMgb2YgdGhlIGFsZ29yaXRobSBpcyBjYWxsZWQKPGI+SE9MRF9ET1dOX0lO VEVSVkFMPC9iPiAoaW4gU2VjdGlvbiAzIGFuZCBTZWN0aW9uIDYpJm5ic3A7IHZzLiA8Yj5IT0xE RE9XTl9JTlRFUlZBTDwvYj4gaW4gU2VjdGlvbiA1LiBUaGlzIGFsc28gbG9va3MgbGlrZSBhbiBv YnZpb3VzIHR5cG8sIGFuZCB0aGUgc2FtZSBuYW1lIHNob3VsZCBiZSB1c2VkIGFjcm9zcyB0aGUg ZG9jdW1lbnQuPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgZGlzY3Vzc2VkIG15IGNvbmNl cm5zIGFib3V0IHRoZSBkcmFmdCB3aXRoIHRoZSBhdXRob3JzIHdobyBoYXZlIGJlZW4gbW9zdCBj b29wZXJhdGl2ZS4KPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYmVsaWV2 ZSB0aGF0IHdlIGhhdmUgcmVhY2hlZCBhbiBhZ3JlZW1lbnQgb24gYWNjZXB0YWJsZSByZXNvbHV0 aW9uIG9mIGFsbCBjb25jZXJucyBsaXN0ZWQgYWJvdmUuPG86cD48L286cD48L3A+CjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5S ZWdhcmRzLDxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TYXNoYTxvOnA+PC9v OnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T2ZmaWNlOiAmIzQzOzk3Mi0zOTI2NjMwMjxvOnA+PC9vOnA+PC9wPgo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5DZWxsOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm IzQzOzk3Mi01NDkyNjYzMDI8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RW1h aWw6Jm5ic3A7Jm5ic3A7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG86cD48L286 cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8L2Rpdj4K PGJyIGNsZWFyPSJib3RoIj4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPgo8QlI+ClRoaXMgZS1tYWls IG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMg aW5mb3JtYXRpb24gd2hpY2ggaXMgPEJSPgpDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBw cm9wcmlldGFyeSB0byBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyA8QlI+ CnRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25l IG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCA8QlI+CmFuZCBhbGwgY29waWVz IHRoZXJlb2YuPEJSPgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+CjwvYm9keT4KPC9odG1sPgoK --_000_AM4PR03MB1713386BB8649B3813B8E24E9D100AM4PR03MB1713eurp_-- From nobody Thu Apr 27 06:04:01 2017 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 2F3C612949D; Thu, 27 Apr 2017 06:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 7JmdsJXNDcNN; Thu, 27 Apr 2017 06:03:56 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0102.outbound.protection.outlook.com [104.47.40.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35D53129412; Thu, 27 Apr 2017 06:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=q4xGS640pHMcxB1W1HodFwGQAgEL5OXas2xOYSBRC1I=; b=Wz6aajMnlV/cIQtrbXuhmkuSi0KaWhmXODB04OZrvttv2NUVZWJegI+pbA0xcMQASEMLOJRtJROyQ/+atQS7yWq7QpNhe+Ujr18XQTqb5ou1jVQN5kfJSgAZqIcAXJ1Buc9Msm1oJWlKYvXRElthfElj3cucpLhIrPGBulHikfM= 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 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Thu, 27 Apr 2017 13:03:54 +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.1047.021; Thu, 27 Apr 2017 13:03:53 +0000 From: Jonathan Hardwick To: "draft-ietf-mpls-rfc3107bis@ietf.org" , "mpls-chairs@ietf.org" , "mpls@ietf.org" CC: "rtg-dir@ietf.org" Thread-Topic: Routing directorate review of draft-ietf-mpls-rfc3107-bis Thread-Index: AdK/UgoPnMchP/X0SOKBF6US5Kr0Pw== Date: Thu, 27 Apr 2017 13:03:53 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=metaswitch.com; x-originating-ip: [2620:104:4001:73:ada5:fc11:9d82:f5fe] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1911; 7:czp3mFeOOkx9I5b/i5cMBW5LYJU8V26gONvGcjmOzZ2cdNIZDVvxQ3lJe3+qMmPCAvBj1e3lpbfJITNEnmTH9Y7NB1S3OSKszoy1aHHC0dtrXHI7lm/sH2A/ts7ann3rSVi9K5NPu2DbpaLjLjL38n+TolK5NjZ63zTMGZSfaMpazDs8F9ZzVTcrrRkZ512lTrQlppnrwtZtK3LSRgK2NAF3LVZwUSu0xkq0uDXSQ3LDLIaJ0IOpZre4qVgzLGMHsbpmfkSQvYQpzRtAAWJounD9cRkC8zwA5NluMk30Hi6lSt0ZA6rKfQGMLPndi1kkx1Yb6F6C5yH5Qz2Zwb01Ng== x-ms-office365-filtering-correlation-id: bab56554-7c55-4931-caca-08d48d6ddb80 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BY2PR0201MB1911; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(6072148); SRVR:BY2PR0201MB1911; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1911; x-forefront-prvs: 029097202E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39840400002)(39450400003)(39850400002)(39410400002)(38730400002)(53936002)(4326008)(345774005)(8936002)(236005)(3660700001)(2501003)(81166006)(2906002)(9686003)(86362001)(25786009)(2201001)(7696004)(450100002)(2900100001)(3280700002)(790700001)(6116002)(102836003)(7906003)(74316002)(5660300001)(55016002)(606005)(6506006)(77096006)(122556002)(54896002)(8676002)(6436002)(54356999)(99286003)(230783001)(33656002)(9326002)(50986999)(6306002)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1911; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR0201MB19109FB5D0BF1F2FC02B8E5284100BY2PR0201MB1910_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2017 13:03:53.6942 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1911 Archived-At: Subject: [RTG-DIR] Routing directorate review of draft-ietf-mpls-rfc3107-bis X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 13:03:59 -0000 --_000_BY2PR0201MB19109FB5D0BF1F2FC02B8E5284100BY2PR0201MB1910_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8NCg0KDQpJIGhhdmUgYmVlbiBzZWxlY3RlZCB0byBkbyBhIHJvdXRpbmcgZGlyZWN0b3Jh dGUg4oCcZWFybHnigJ0gcmV2aWV3IG9mIHRoaXMgZHJhZnQuDQpodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1wbHMtcmZjMzEwN2Jpcy8NCg0KDQpUaGUgcm91dGlu ZyBkaXJlY3RvcmF0ZSB3aWxsLCBvbiByZXF1ZXN0IGZyb20gdGhlIHdvcmtpbmcgZ3JvdXAgY2hh aXIsIHBlcmZvcm0gYW4g4oCcZWFybHnigJ0gcmV2aWV3IG9mIGEgZHJhZnQgYmVmb3JlIGl0IGlz IHN1Ym1pdHRlZCBmb3IgcHVibGljYXRpb24gdG8gdGhlIElFU0cuICBUaGUgZWFybHkgcmV2aWV3 IGNhbiBiZSBwZXJmb3JtZWQgYXQgYW55IHRpbWUgZHVyaW5nIHRoZSBkcmFmdOKAmXMgbGlmZXRp bWUgYXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50LiAgVGhlIHB1cnBvc2Ugb2YgdGhlIGVhcmx5 IHJldmlldyBkZXBlbmRzIG9uIHRoZSBzdGFnZSB0aGF0IHRoZSBkb2N1bWVudCBoYXMgcmVhY2hl ZC4gIEFzIHRoaXMgZG9jdW1lbnQgaXMgaW4gd29ya2luZyBncm91cCBsYXN0IGNhbGwsIG15IGZv Y3VzIGZvciB0aGUgcmV2aWV3IHdhcyB0byBkZXRlcm1pbmUgd2hldGhlciB0aGUgZG9jdW1lbnQg aXMgcmVhZHkgdG8gYmUgcHVibGlzaGVkLiAgUGxlYXNlIGNvbnNpZGVyIG15IGNvbW1lbnRzIGFs b25nIHdpdGggdGhlIG90aGVyIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQoN Cg0KRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBs ZWFzZSBzZWUg4oCLaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtp L1J0Z0Rpcg0KDQoNCg0KQmVzdCByZWdhcmRzDQoNCkpvbg0KDQoNCg0KRG9jdW1lbnQ6IGRyYWZ0 LWlldGYtbXBscy1yZmMzMTA3LTAxDQoNClJldmlld2VyOiBKb25hdGhhbiBIYXJkd2ljaw0KDQpS ZXZpZXcgRGF0ZTogMjcgQXByaWwgMjAxNw0KDQpJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBU cmFjaw0KDQoNCg0KU3VtbWFyeQ0KVGhhbmsgeW91IGZvciB3cml0aW5nIHRoaXMgZG9jdW1lbnQu ICBJdCBwcm92aWRlcyBtdWNoLW5lZWRlZCBjbGFyaXR5IHRvIHRoZSBvcmlnaW5hbCBSRkMgMzEw Ny4NClRoaXMgZG9jdW1lbnQgaXMgdmVyeSB3ZWxsIHdyaXR0ZW4uICBJIHRoaW5rIHRoYXQgaXQg aXMgcmVhZHkgdG8gYmUgcHVibGlzaGVkLCBidXQgdGhlcmUgYXJlIGEgZmV3IHBvaW50cyBiZWxv dyB0aGF0IEkgd291bGQgbGlrZSB0byBkaXNjdXNzIGZvciBjbGFyaWZpY2F0aW9uLg0KSSBhbHNv IHNwb3R0ZWQgYSBmZXcgbml0cyB0aGF0IHNob3VsZCBiZSBmaXhlZCBhdCBzb21lIHBvaW50IGJl Zm9yZSBwdWJsaWNhdGlvbi4NCg0KQ29tbWVudHMgYW5kIFF1ZXN0aW9ucw0KDQoxKSBJbiBzZWN0 aW9uIDIuMSBpdCBzYXlzOg0K4oCcICAgSWYgdGhlIE11bHRpcGxlIExhYmVscyBDYXBhYmlsaXR5 IGZvciBhIGdpdmVuIEFGSS9TQUZJIGhhZCBiZWVuDQogICBleGNoYW5nZWQgb24gdGhlIGZhaWxl ZCBzZXNzaW9uLCBidXQgaXMgbm90IGV4Y2hhbmdlZCBvbiB0aGUNCiAgIHJlc3RhcnRlZCBzZXNz aW9uLCB0aGVuIGFueSBwcmVmaXhlcyBhZHZlcnRpc2VkIGluIHRoYXQgQUZJL1NBRkkgd2l0aA0K ICAgbXVsdGlwbGUgbGFiZWxzIE1VU1QgYmUgZXhwbGljaXRseSB3aXRoZHJhd24u4oCdDQoNCklm IEkgaGF2ZSB1bmRlcnN0b29kIHRoaXMgY29ycmVjdGx5LCBpdCByZXF1aXJlcyBhIHNwZWFrZXIg dG8gd2l0aGRyYXcgTkxSSSB0aGF0IGl0IHNlbnQgb24gdGhlIHByZXZpb3VzIHNlc3Npb24gYnV0 IHRoYXQgaXQgaGFzIG5vdCBzZW50IG9uIHRoZSByZXN0YXJ0ZWQgc2Vzc2lvbiAoYmVjYXVzZSB0 aGUgbmVnb3RpYXRlZCBzZXNzaW9uIGNhcGFiaWxpdGllcyBjaGFuZ2VkKS4NCihhKSBXaHkgZG9l cyBpdCBuZWVkIHRvIGRvIHRoYXQg4oCTIGlzbuKAmXQgdGhlIE5MUkkgaW1wbGljaXRseSB3aXRo ZHJhd24gd2hlbiB0aGUgRU9SIG1hcmtlciBpcyBzZW50Pw0KKGIpIFRoaXMgc2VlbXMgdG8gY29u dHJhZGljdCBzZWN0aW9uIDIuNCB3aGljaCBzYXlzIOKAnE5vdGUgdGhhdCBsYWJlbC9wcmVmaXgg YmluZGluZ3MgdGhhdCB3ZXJlIG5vdCBhZHZlcnRpc2VkIG9uIHRoZSBnaXZlbiBzZXNzaW9uIGNh bm5vdCBiZSB3aXRoZHJhd24gYnkgdGhpcyBtZXRob2Qu4oCdDQoNCg0KMikgSW4gc2VjdGlvbiAy LjEgaXQgc2F5czoNCuKAnEEgQkdQIHNwZWFrZXIgU0hPVUxEIE5PVCBzZW5kIGFuIFVQREFURSB0 aGF0IGJpbmRzIG1vcmUgbGFiZWxzIHRvIGEgZ2l2ZW4gcHJlZml4IHRoYW4gaXRzIHBlZXIgaXMg Y2FwYWJsZSBvZiByZWNlaXZpbmfigJ0g4oCTIHdoeSBpc27igJl0IHRoYXQgTVVTVCBOT1Q/DQoN Cg0KMykgSW4gc2VjdGlvbiAyLjQgaXQgc2F5czoNCuKAnFRvIGRvIHNvLCBpdCBtYXkgc2VuZCBh IEJHUCBVUERBVEUgbWVzc2FnZSB3aXRoIGFuIE1QX1VOUkVBQ0hfTkxSSSBhdHRyaWJ1dGUu4oCd DQpTaG91bGQgdGhhdCBiZSDigJxpdCBNVVNUIHNlbmTigJ0/DQoNCg0KNCkgSW4gc2VjdGlvbiA1 OiBhbHRob3VnaCBzb21lIGltcGxlbWVudGF0aW9ucyB0cmVhdCBTQUZJIDEgYW5kIFNBRkkgNCBy b3V0ZXMgYXMgY29tcGFyYWJsZSwgSSBiZWxpZXZlIHRoYXQgdGhleSBzaG91bGQgYWx3YXlzIGJl IHRyZWF0ZWQgYXMgaW5kZXBlbmRlbnQsIGluIHRoZSBmb2xsb3dpbmcgc2Vuc2U6DQpTdXBwb3Nl IGEgc3BlYWtlciBTMSBzZW5kcyBhIFNBRkkgMSByb3V0ZSBhbmQgdGhlbiBhIFNBRkkgNCByb3V0 ZSB0byB0aGUgc2FtZSBwcmVmaXggUC4gIFRoZSBTQUZJIDQgcm91dGUgTVVTVCBOT1QgYmUgdHJl YXRlZCBieSB0aGUgcmVjZWl2aW5nIHNwZWFrZXIgYXMgYW4gaW1wbGljaXQgd2l0aGRyYXcgb2Yg dGhlIFNBRkkgMSByb3V0ZS4gIElmIFMxIHN1YnNlcXVlbnRseSBzZW5kcyBhbiBleHBsaWNpdCB3 aXRoZHJhdyBvZiB0aGUgU0FGSSA0IHJvdXRlLCB0aGlzIE1VU1QgTk9UIGltcGxpY2l0bHkgd2l0 aGRyYXcgdGhlIFNBRkkgMSByb3V0ZSwgYW5kIHZpY2UgdmVyc2EuDQpBbSBJIGNvcnJlY3Q/ICBJ IGhhdmUgc2VlbiBpbXBsZW1lbnRhdGlvbnMgdGhhdCB2aW9sYXRlIHRoaXMgc28gSSB0aGluayBp dCBpcyB3b3J0aCBzcGVsbGluZyBvdXQgc29tZXdoZXJlIGluIHRoaXMgc2VjdGlvbi4NCg0KDQo1 KSBJbiBzZWN0aW9uIDcgaXQgc2F5czoNCuKAnCBJZiBhIEJHUCBpbXBsZW1lbnRhdGlvbiwgbm90 IGNvbmZvcm1hbnQgd2l0aCB0aGUgY3VycmVudCBkb2N1bWVudCwNCmVuY29kZXMgbXVsdGlwbGUg bGFiZWxzIGluIHRoZSBOTFJJIGJ1dCBoYXMgbm90IHNlbnQgYW5kIHJlY2VpdmVkIHRoZQ0KIk11 bHRpcGxlIExhYmVscyIgQ2FwYWJpbGl0eSwgYSBCR1AgaW1wbGVtZW50YXRpb24gdGhhdCBkb2Vz IGNvbmZvcm0NCndpdGggdGhlIGN1cnJlbnQgZG9jdW1lbnQgd2lsbCBsaWtlbHkgcmVzZXQgdGhl IEJHUCBzZXNzaW9uLuKAnQ0KDQpXb3VsZG7igJl0IHRoYXQgcHJldmVudCBpbmNyZW1lbnRhbCBk ZXBsb3ltZW50IG9mIHRoaXMgUkZDIGludG8gYSBuZXR3b3JrIHRoYXQgaXMgaW5pdGlhbGx5IGNv bXBvc2VkIG9mIHN1Y2ggaW1wbGVtZW50YXRpb25zPyAgQmVjYXVzZSBpdCBzZWVtcyB0byByZXF1 aXJlIHRoYXQgYm90aCBlbmRzIG9mIGVhY2ggQkdQIHNlc3Npb24gbXVzdCBiZSB1cGdyYWRlZCBz aW11bHRhbmVvdXNseSwgb3IgZWxzZSB0aGUgQkdQIHNlc3Npb25zIHdpbGwgYWxsIHJlc2V0Lg0K DQoNCk5pdHMNCg0KU2VjdGlvbiAyOiBNaXNzaW5nIGNsb3NlLXBhcmVudGhlc2lzIG9uIOKAnChb UkZDNDc2MF3igJ0g4oCTIHRoaXMgb2NjdXJzIHR3aWNlIGluIHRoaXMgc2VjdGlvbg0KU2VjdGlv biAyLjE6IHMvIGFuIHByZWZpeGVzIGFkdmVydGlzZWQvIGFueSBwcmVmaXhlcyBhZHZlcnRpc2Vk Lw0KU2VjdGlvbiAyLjE6IEZpZ3VyZSAxIGFwcGVhcnMgcXVpdGUgYSBsb25nIHdheSBkaXN0YW50 IGZyb20gdGhlIHRleHQgdGhhdCByZWZlcmVuY2VzIGl0LiAgSSBzdWdnZXN0IG1vdmluZyBpdCB0 byBpbW1lZGlhdGVseSBhZnRlciB0aGUgcGFyYWdyYXBoIGl0IGlzIHJlZmVyZW5jZWQgZnJvbS4N ClNlY3Rpb24gMi4xOiBzL01VU1QgQkUvTVVTVCBiZS8NClNlY3Rpb24gMy4xOiBzL2RpZmZlcmVu dCBwYXRoIGlkZW50aWZpZXJzLi4vZGlmZmVyZW50IHBhdGggaWRlbnRpZmllcnMuLyAgKGkuZS4g cmVtb3ZlIHN0cmF5IGV4dHJhIHBlcmlvZCkNClNlY3Rpb24gMy4yLjE6IOKAnHVzaW5nIHRoZSBw cm9jZWR1cmUgb2YgRmlndXJlIDTigJ0gc2hvdWxkIGJlIOKAnHVzaW5nIHRoZSBwcm9jZWR1cmUg b2YgU2VjdGlvbiAyLjTigJ0uDQpEaXR0byBpbiBzZWN0aW9uIDMuMi4yLg0KU2VjdGlvbiA0OiBz L1MgYSBsYXllciAyIGVuY2Fwc3VsYXRpb24vYSBsYXllciAyIGVuY2Fwc3VsYXRpb24vIChpLmUu IGRlbGV0ZSBzdHJheSDigJhT4oCZKQ0KDQo= --_000_BY2PR0201MB19109FB5D0BF1F2FC02B8E5284100BY2PR0201MB1910_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWlu VGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRl eHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJh Z3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCglt YXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0K CW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUzt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpz cGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdC IiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SGVsbG88bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSBoYXZlIGJlZW4gc2VsZWN0ZWQgdG8gZG8gYSByb3V0aW5nIGRpcmVjdG9yYXRlIOKA nGVhcmx54oCdIHJldmlldyBvZiB0aGlzIGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1tcGxzLXJmYzMxMDdiaXMvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLW1wbHMtcmZjMzEwN2Jpcy88L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPlRoZSByb3V0aW5nIGRpcmVjdG9yYXRlIHdpbGwsIG9uIHJlcXVlc3QgZnJvbSB0aGUgd29y a2luZyBncm91cCBjaGFpciwgcGVyZm9ybSBhbiDigJxlYXJseeKAnSByZXZpZXcgb2YgYSBkcmFm dCBiZWZvcmUgaXQgaXMgc3VibWl0dGVkIGZvciBwdWJsaWNhdGlvbiB0byB0aGUgSUVTRy4mbmJz cDsgVGhlIGVhcmx5IHJldmlldyBjYW4gYmUgcGVyZm9ybWVkIGF0IGFueSB0aW1lIGR1cmluZyB0 aGUgZHJhZnTigJlzIGxpZmV0aW1lDQogYXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50LiZuYnNw OyBUaGUgcHVycG9zZSBvZiB0aGUgZWFybHkgcmV2aWV3IGRlcGVuZHMgb24gdGhlIHN0YWdlIHRo YXQgdGhlIGRvY3VtZW50IGhhcyByZWFjaGVkLiZuYnNwOyBBcyB0aGlzIGRvY3VtZW50IGlzIGlu IHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsLCBteSBmb2N1cyBmb3IgdGhlIHJldmlldyB3YXMgdG8g ZGV0ZXJtaW5lIHdoZXRoZXIgdGhlIGRvY3VtZW50IGlzIHJlYWR5IHRvIGJlIHB1Ymxpc2hlZC4m bmJzcDsgUGxlYXNlDQogY29uc2lkZXIgbXkgY29tbWVudHMgYWxvbmcgd2l0aCB0aGUgb3RoZXIg d29ya2luZyBncm91cCBsYXN0IGNhbGwgY29tbWVudHMuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPkZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl LCBwbGVhc2Ugc2VlIOKAizxhIGhyZWY9Imh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEv cnRnL3RyYWMvd2lraS9SdGdEaXIiPmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRn L3RyYWMvd2lraS9SdGdEaXI8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkJlc3Qg cmVnYXJkczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Sm9uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkRvY3VtZW50OiBkcmFmdC1pZXRmLW1wbHMtcmZjMzEw Ny0wMTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UmV2aWV3ZXI6IEpv bmF0aGFuIEhhcmR3aWNrPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5S ZXZpZXcgRGF0ZTogMjcgQXByaWwgMjAxNzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+SW50ZW5kZWQgU3RhdHVzOiBTdGFuZGFyZHMgVHJhY2s8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+U3VtbWFyeTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhhbmsgeW91IGZvciB3cml0aW5nIHRoaXMgZG9jdW1lbnQuJm5ic3A7IEl0IHByb3ZpZGVz IG11Y2gtbmVlZGVkIGNsYXJpdHkgdG8gdGhlIG9yaWdpbmFsIFJGQyAzMTA3LjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBkb2N1bWVudCBpcyB2ZXJ5IHdlbGwgd3Jp dHRlbi4mbmJzcDsgSSB0aGluayB0aGF0IGl0IGlzIHJlYWR5IHRvIGJlIHB1Ymxpc2hlZCwgYnV0 IHRoZXJlIGFyZSBhIGZldyBwb2ludHMgYmVsb3cgdGhhdCBJIHdvdWxkIGxpa2UgdG8gZGlzY3Vz cyBmb3IgY2xhcmlmaWNhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgYWxzbyBzcG90dGVkIGEgZmV3IG5pdHMgdGhhdCBzaG91bGQgYmUgZml4ZWQgYXQgc29tZSBw b2ludCBiZWZvcmUgcHVibGljYXRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvbW1lbnRz IGFuZCBRdWVzdGlvbnM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MSkgSW4gc2VjdGlvbiAyLjEg aXQgc2F5czo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnCZuYnNwOyZu YnNwOyBJZiB0aGUgTXVsdGlwbGUgTGFiZWxzIENhcGFiaWxpdHkgZm9yIGEgZ2l2ZW4gQUZJL1NB RkkgaGFkIGJlZW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZu YnNwOyBleGNoYW5nZWQgb24gdGhlIGZhaWxlZCBzZXNzaW9uLCBidXQgaXMgbm90IGV4Y2hhbmdl ZCBvbiB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyByZXN0YXJ0ZWQgc2Vzc2lvbiwgdGhlbiBhbnkgcHJlZml4ZXMgYWR2ZXJ0aXNlZCBpbiB0aGF0 IEFGSS9TQUZJIHdpdGg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyZuYnNwOyBtdWx0aXBsZSBsYWJlbHMgTVVTVCBiZSBleHBsaWNpdGx5IHdpdGhkcmF3bi7igJ08 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgSSBoYXZlIHVuZGVyc3Rvb2QgdGhpcyBjb3JyZWN0 bHksIGl0IHJlcXVpcmVzIGEgc3BlYWtlciB0byB3aXRoZHJhdyBOTFJJIHRoYXQgaXQgc2VudCBv biB0aGUgcHJldmlvdXMgc2Vzc2lvbiBidXQgdGhhdCBpdCBoYXMgbm90IHNlbnQgb24gdGhlIHJl c3RhcnRlZCBzZXNzaW9uIChiZWNhdXNlIHRoZSBuZWdvdGlhdGVkIHNlc3Npb24gY2FwYWJpbGl0 aWVzIGNoYW5nZWQpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KGEpIFdo eSBkb2VzIGl0IG5lZWQgdG8gZG8gdGhhdCDigJMgaXNu4oCZdCB0aGUgTkxSSSBpbXBsaWNpdGx5 IHdpdGhkcmF3biB3aGVuIHRoZSBFT1IgbWFya2VyIGlzIHNlbnQ/PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4oYikgVGhpcyBzZWVtcyB0byBjb250cmFkaWN0IHNlY3Rpb24g Mi40IHdoaWNoIHNheXMg4oCcTm90ZSB0aGF0IGxhYmVsL3ByZWZpeCBiaW5kaW5ncyB0aGF0IHdl cmUgbm90IGFkdmVydGlzZWQgb24gdGhlIGdpdmVuIHNlc3Npb24gY2Fubm90IGJlIHdpdGhkcmF3 biBieSB0aGlzIG1ldGhvZC7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yKSBJbiBzZWN0aW9uIDIuMSBpdCBzYXlz OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCcQSBCR1Agc3BlYWtlciBT SE9VTEQgTk9UIHNlbmQgYW4gVVBEQVRFIHRoYXQgYmluZHMgbW9yZSBsYWJlbHMgdG8gYSBnaXZl biBwcmVmaXggdGhhbiBpdHMgcGVlciBpcyBjYXBhYmxlIG9mIHJlY2VpdmluZ+KAnSDigJMgd2h5 IGlzbuKAmXQgdGhhdCBNVVNUIE5PVD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zKSBJbiBzZWN0aW9uIDIuNCBpdCBz YXlzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCcVG8gZG8gc28sIGl0 IG1heSBzZW5kIGEgQkdQIFVQREFURSBtZXNzYWdlIHdpdGggYW4gTVBfVU5SRUFDSF9OTFJJIGF0 dHJpYnV0ZS7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNob3VsZCB0 aGF0IGJlIOKAnGl0IE1VU1Qgc2VuZOKAnT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40KSBJbiBzZWN0aW9uIDU6IGFs dGhvdWdoIHNvbWUgaW1wbGVtZW50YXRpb25zIHRyZWF0IFNBRkkgMSBhbmQgU0FGSSA0IHJvdXRl cyBhcyBjb21wYXJhYmxlLCBJIGJlbGlldmUgdGhhdCB0aGV5IHNob3VsZCBhbHdheXMgYmUgdHJl YXRlZCBhcyBpbmRlcGVuZGVudCwgaW4gdGhlIGZvbGxvd2luZyBzZW5zZTo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1cHBvc2UgYSBzcGVha2VyIFMxIHNlbmRzIGEgU0FG SSAxIHJvdXRlIGFuZCB0aGVuIGEgU0FGSSA0IHJvdXRlIHRvIHRoZSBzYW1lIHByZWZpeCBQLiZu YnNwOyBUaGUgU0FGSSA0IHJvdXRlIE1VU1QgTk9UIGJlIHRyZWF0ZWQgYnkgdGhlIHJlY2Vpdmlu ZyBzcGVha2VyIGFzIGFuIGltcGxpY2l0IHdpdGhkcmF3IG9mIHRoZSBTQUZJIDEgcm91dGUuJm5i c3A7IElmIFMxIHN1YnNlcXVlbnRseSBzZW5kcyBhbiBleHBsaWNpdCB3aXRoZHJhdw0KIG9mIHRo ZSBTQUZJIDQgcm91dGUsIHRoaXMgTVVTVCBOT1QgaW1wbGljaXRseSB3aXRoZHJhdyB0aGUgU0FG SSAxIHJvdXRlLCBhbmQgdmljZSB2ZXJzYS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFtIEkgY29ycmVjdD8mbmJzcDsgSSBoYXZlIHNlZW4gaW1wbGVtZW50YXRpb25zIHRo YXQgdmlvbGF0ZSB0aGlzIHNvIEkgdGhpbmsgaXQgaXMgd29ydGggc3BlbGxpbmcgb3V0IHNvbWV3 aGVyZSBpbiB0aGlzIHNlY3Rpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NSkgSW4gc2VjdGlvbiA3IGl0IHNheXM6 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPuKAnCBJZiBhIEJHUCBpbXBsZW1lbnRhdGlvbiwgbm90IGNv bmZvcm1hbnQgd2l0aCB0aGUgY3VycmVudCBkb2N1bWVudCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tR0IiPmVuY29kZXMgbXVsdGlwbGUgbGFiZWxzIGluIHRoZSBOTFJJIGJ1dCBoYXMgbm90IHNl bnQgYW5kIHJlY2VpdmVkIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+JnF1b3Q7TXVs dGlwbGUgTGFiZWxzJnF1b3Q7IENhcGFiaWxpdHksIGEgQkdQIGltcGxlbWVudGF0aW9uIHRoYXQg ZG9lcyBjb25mb3JtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj53aXRoIHRoZSBjdXJyZW50 IGRvY3VtZW50IHdpbGwgbGlrZWx5IHJlc2V0IHRoZSBCR1Agc2Vzc2lvbi7igJ08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPldvdWxkbuKAmXQgdGhhdCBwcmV2ZW50IGluY3JlbWVudGFs IGRlcGxveW1lbnQgb2YgdGhpcyBSRkMgaW50byBhIG5ldHdvcmsgdGhhdCBpcyBpbml0aWFsbHkg Y29tcG9zZWQgb2Ygc3VjaCBpbXBsZW1lbnRhdGlvbnM/Jm5ic3A7IEJlY2F1c2UgaXQgc2VlbXMg dG8gcmVxdWlyZSB0aGF0IGJvdGggZW5kcyBvZiBlYWNoIEJHUCBzZXNzaW9uIG11c3QgYmUgdXBn cmFkZWQgc2ltdWx0YW5lb3VzbHksIG9yIGVsc2UgdGhlIEJHUA0KIHNlc3Npb25zIHdpbGwgYWxs IHJlc2V0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk5pdHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VjdGlvbiAy OiBNaXNzaW5nIGNsb3NlLXBhcmVudGhlc2lzIG9uIOKAnChbUkZDNDc2MF3igJ0g4oCTIHRoaXMg b2NjdXJzIHR3aWNlIGluIHRoaXMgc2VjdGlvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+U2VjdGlvbiAyLjE6IHMvIGFuIHByZWZpeGVzIGFkdmVydGlzZWQvIGFueSBwcmVm aXhlcyBhZHZlcnRpc2VkLzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2Vj dGlvbiAyLjE6IEZpZ3VyZSAxIGFwcGVhcnMgcXVpdGUgYSBsb25nIHdheSBkaXN0YW50IGZyb20g dGhlIHRleHQgdGhhdCByZWZlcmVuY2VzIGl0LiZuYnNwOyBJIHN1Z2dlc3QgbW92aW5nIGl0IHRv IGltbWVkaWF0ZWx5IGFmdGVyIHRoZSBwYXJhZ3JhcGggaXQgaXMgcmVmZXJlbmNlZCBmcm9tLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VjdGlvbiAyLjE6IHMvTVVTVCBC RS9NVVNUIGJlLzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VjdGlvbiAz LjE6IHMvZGlmZmVyZW50IHBhdGggaWRlbnRpZmllcnMuLi9kaWZmZXJlbnQgcGF0aCBpZGVudGlm aWVycy4vJm5ic3A7IChpLmUuIHJlbW92ZSBzdHJheSBleHRyYSBwZXJpb2QpPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWN0aW9uIDMuMi4xOiDigJx1c2luZyB0aGUgcHJv Y2VkdXJlIG9mIEZpZ3VyZSA04oCdIHNob3VsZCBiZSDigJx1c2luZyB0aGUgcHJvY2VkdXJlIG9m IFNlY3Rpb24gMi404oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGl0 dG8gaW4gc2VjdGlvbiAzLjIuMi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlNlY3Rpb24gNDogcy9TIGEgbGF5ZXIgMiBlbmNhcHN1bGF0aW9uL2EgbGF5ZXIgMiBlbmNhcHN1 bGF0aW9uLyAoaS5lLiBkZWxldGUgc3RyYXkg4oCYU+KAmSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_BY2PR0201MB19109FB5D0BF1F2FC02B8E5284100BY2PR0201MB1910_-- From nobody Fri Apr 28 03:57:14 2017 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 9BDBA129438; Fri, 28 Apr 2017 03:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7AN_NFIRGRI; Fri, 28 Apr 2017 03:57:04 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A482C129422; Fri, 28 Apr 2017 03:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3424; q=dns/txt; s=iport; t=1493376825; x=1494586425; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gOZkV0kV8e92f86lK9KWsRqnuvEaxy08dWc6Eu/Uzp0=; b=b3OHV9qWuuwvuv3D1zMSDic1yiyvf9pBqYulQdFz9iTJCe5j9mQ9WsUq kZhtm5dB+bqMhp3BtMFyS7kFvse4u3KA9fvKe7BlrpRSRUt8PgExeZpGH kSwsUuqxqRC8j5YpAGALXM7g4MWxZZ4h/NOzirRTlm4lxcqcIHabWmdUO w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AkAgCKHgNZ/5FdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VhgQwHg2GKGJEtIZVsgg8shXgCGoQUPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?VAQEBAQIBIxFFBQsCAQgOBgQCAiYCAgIwFRACBA4FihcIDq4CgiaLBQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAR2BC4VUgV4rC4JkhCg3gwYugjEFnVABhxiLc4ICVYR?= =?us-ascii?q?iiiWUJgEfOIEKbxVWAYZddQGGXoENAQEB?= X-IronPort-AV: E=Sophos;i="5.37,387,1488844800"; d="scan'208";a="419157108" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Apr 2017 10:53:43 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v3SArh0L006036 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Apr 2017 10:53:43 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 28 Apr 2017 06:53:42 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Fri, 28 Apr 2017 06:53:42 -0400 From: "Stefano Previdi (sprevidi)" To: Lou Berger CC: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-spring-resiliency-use-cases.all@ietf.org" , "spring@ietf.org" Thread-Topic: RtgDir review: draft-ietf-spring-resiliency-use-cases-08 Thread-Index: AQHSvStPgbckbBbQm0KLwaNzhINY1KHa5BsA Date: Fri, 28 Apr 2017 10:53:42 +0000 Message-ID: <6F302925-DB12-451F-8738-40A2E891E404@cisco.com> References: <52f7d439-e0b3-e7c5-e0ab-c00569dad1a5@labn.net> In-Reply-To: <52f7d439-e0b3-e7c5-e0ab-c00569dad1a5@labn.net> 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.61.162.46] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-spring-resiliency-use-cases-08 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 10:57:07 -0000 SGkgTG91LA0KDQp0aGFua3MgZm9yIHRoZSBjb21tZW50LiBJIGludGVncmF0ZWQgdGhlbSBpbiB0 aGUgbmV3IHZlcnNpb24gSeKAmWxsIHN1Ym1pdCBhc2FwLg0KDQpUaGFua3MuDQpzLg0KDQoNCj4g T24gQXByIDI0LCAyMDE3LCBhdCA2OjE1IFBNLCBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0 PiB3cm90ZToNCj4gDQo+IEhlbGxvLA0KPiANCj4gSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhl IFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuDQo+IFRoZSBSb3V0 aW5nIERpcmVjdG9yYXRlIHNlZWtzIHRvIHJldmlldyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJl bGF0ZWQNCj4gZHJhZnRzIGFzIHRoZXkgcGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJ RVNHIHJldmlldywgYW5kDQo+IHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVlc3QuIFRoZSBwdXJw b3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZQ0KPiBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0 aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcNCj4gRGlyZWN0 b3JhdGUsIHBsZWFzZSBzZWUNCj4g4oCLaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9y dGcvdHJhYy93aWtpL1J0Z0Rpcg0KPiANCj4gQWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHBy aW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0DQo+IHdvdWxkIGJlIGhl bHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgSUVU Rg0KPiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0byBy ZXNvbHZlIHRoZW0gdGhyb3VnaA0KPiBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBkcmFm dC4NCj4gDQo+IERvY3VtZW50OiBkcmFmdC1pZXRmLXNwcmluZy1yZXNpbGllbmN5LXVzZS1jYXNl cy0wOA0KPiBSZXZpZXdlcjogTG91IEJlcmdlcg0KPiBSZXZpZXcgRGF0ZTogQXByaWwgMjQNCj4g SW50ZW5kZWQgU3RhdHVzOiBJbmZvcm1hdGlvbmFsDQo+IA0KPiBTdW1tYXJ5Og0KPiANCj4gICAg SSBoYXZlIHNvbWUgbWlub3IgY29tbWVudHMgYWJvdXQgdGhpcyBkb2N1bWVudCB0aGF0IEkgdGhp bmsgd291bGQgYmUNCj4gZ29vZCwgYnV0IG5vdCBuZWNlc3NhcnksIHRvIGJlIHJlc29sdmVkIGJl Zm9yZSBwdWJsaWNhdGlvbi4NCj4gDQo+IENvbW1lbnRzOg0KPiANCj4gVGhpcyBkb2N1bWVudCBp cyBjb25jaXNlIGFuZCBjbGVhci4gIEkgb25seSBoYXZlIG1pbm9yL25pdCBsZXZlbCBpc3N1ZXMN Cj4gdGhhdCBjb3VsZCBiZSBhZGRyZXNzZWQgYmVmb3JlIHB1YmxpY2F0aW9uLCBidXQgSSBkb24n dCB0aGluayBpdA0KPiBjcml0aWNhbCBhcyB0aGUgZG9jdW1lbnQgaXMgYmVpbmcgcHVibGlzaGVk IGFzIEluZm9ybWF0aW9uYWwuDQo+IA0KPiBNYWpvciBJc3N1ZXM6DQo+IA0KPiAJTm8gbWFqb3Ig aXNzdWVzIGZvdW5kLg0KPiANCj4gTWlub3IgSXNzdWVzOg0KPiANCj4gLSBTZWN0aW9uIDIgbWVu dGlvbnMgcmV2ZXJzaW9uLCB3aGlsZSBzZWN0aW9ucyAzIGFuZCA0IGRvIG5vdC4NCj4gIFRoaXMg bGVhdmVzIHJldmVyc2lvbiByZXF1aXJlbWVudHMgb3BlbiB0byBpbnRlcnByZXRhdGlvbi4NCj4g IEkgc3VnZ2VzdCBleHBsaWNpdGx5IHN0YXRpbmcgaWYgcmV2ZXJzaW9uIGlzIGEgcmVxdWlyZWQN Cj4gIG9wdGlvbiBvciBub3QgaW4gc2VjdGlvbnMgMyBhbmQgNCBhcyB3ZWxsLg0KPiANCj4gLSBT ZWN0aW9uIDIgbWVudGlvbnMgMToxIHN0eWxlIHBhdGggcHJvdGVjdGlvbi4gIFBhc3Qvb3RoZXIg d29yaw0KPiAgb24gcHJvdGVjdGlvbiBhbHNvIGFsbG93ZWQgZm9yIC8gdXNlcyAxKzEgc3R5bGUg cHJvdGVjdGlvbi4gIElzDQo+ICAxKzEgaW50ZW50aW9uYWxseSBvbWl0dGVkPyBJZiBub3QsIEkg c3VnZ2VzdCBhbGxvd2luZyBmb3IgaXQuDQo+IA0KPiBOaXRzOg0KPiANCj4+ICByZWZlcnJlZCB0 byBhcyBsb2NhbCBwcm90ZWN0aW9uIHRlY2huaXF1ZXMgb3IgRmFzdCBSZXJvdXRlDQo+PiAgdGVj aG5pcXVlcy4NCj4gDQo+IFJlZmVyZW5jZXMgc2hvdWxkIGJlIHByb3ZpZGVkIGZvciBlYWNoIHRl Y2huaXF1ZS4NCj4gDQo+PiAgIEl0IGlzIGVzc2VudGlhbCB0aGF0IHRoZSBwcmltYXJ5IGFuZCBi YWNrdXAgcGF0aCBiZW5lZml0IGZyb20gYW4gZW5kLQ0KPj4gICB0by1lbmQgbGl2ZW5lc3MgbW9u aXRvcmluZy92ZXJpZmljYXRpb24uICBUaGUgbWV0aG9kIGFuZCBtZWNoYW5pc21zDQo+PiAgIHRo YXQgcHJvdmlkZSBzdWNoIGxpdmVuZXNzIGNoZWNrIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0 aGlzDQo+PiAgIGRvY3VtZW50Lg0KPiANCj4gR2l2ZW4gdGhlIGltcG9ydGFuY2Ugb2YgbGl2ZW5l c3MgbW9uaXRvcmluZywgSSB0aGluayBpdCB3b3VsZCBiZSB3b3J0aA0KPiBtZW50aW9uZWQgYW4g ZXhhbXBsZSBvZiBzdWNoLg0KPiANCj4gVGhhdCdzIGl0IQ0KPiBMb3UNCj4gDQoNCg== From nobody Fri Apr 28 13:26:44 2017 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 0D89B129535; Fri, 28 Apr 2017 13:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 TenPJjYE7TZZ; Fri, 28 Apr 2017 13:26:32 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0100.outbound.protection.outlook.com [104.47.42.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CA2E129A9D; Fri, 28 Apr 2017 13:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OE1rNn1zEIhqX0O4QYUIDaPIvu9Bh9Z+mhKHkvE/rX0=; b=bXlTalcZkuk+8ppJ25WrXeOsijEsOuowGy/AB2J1hO3NSkGZmD9oR+MQdUKhCTn2BWoS52ishV5VyPVfuZsiinjKIO3Bqnzr6MZKNE6wQrPdd19RCYNXUKEYRbsVrm8O62WW4nPG8DD9BeNMkEZ0GSDIXpuboG+vUOzrBJESWaI= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from pvakharwala-sslvpn-nc.jnpr.net (66.129.241.11) by BN3PR05MB2497.namprd05.prod.outlook.com (10.167.3.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1; Fri, 28 Apr 2017 20:24:01 +0000 From: "John G. Scudder" Content-Type: multipart/mixed; boundary="Apple-Mail=_E8A9E5BB-0E2D-42E0-BE69-AE11A09B0D3B" Date: Fri, 28 Apr 2017 16:23:57 -0400 Message-ID: CC: , , To: MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BN6PR13CA0041.namprd13.prod.outlook.com (10.171.172.27) To BN3PR05MB2497.namprd05.prod.outlook.com (10.167.3.26) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fbdf7874-23b5-4514-73ec-08d48e7482ab X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:BN3PR05MB2497; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 3:6wHCXzN8zgMd1JRplCwcVVcrlN2ljRtZBrkdYs3UfG3tYGUv04kGjjt96x7KJKa3a23PPs6AfZL8CmyU0Cs5VOOuYILr8huV6TABeveR/jWqVdT8WsRKgA4WX8e2Bs4cvDWWpZy7yj+UiugQIZUJRDvk2bBZ4le593JBgOU+3pT8RniJZkrqipnIvGtxWECUy1vLwdlR8tjxMqSJu3JVg9rQb5xud7WpMtD2WHN1aCK3h//nSjv1xbutaNyiNYG5AiyswAMND5jBAloQNZsNU6JIlvoaMovM/uoiW/oc2mO9elhp2UWZIYtNiC9urV05QN/kELzDnNhWBTMuwqJMn3YynJae3rG/1c21RnlCEsU=; 25:d+DbAmaaChHNGGPtoxly4NdGTyOl1zqSTI8xPztEFZBZZLGg6AktirKjypP9aM7/c3sUc635BFcuso4DFrKHEyCi3ALoPkomnoi4++Q5BAhctuRvD6iJZ1ebyFL+px5tVwRyHYmtbbpJXqfPAlUeEHZNOEmA64elFwB4TqSVe48fvzTs7U51hC2vCJPfdW7iI9q1VGRuvqxhQrTs6KWY/n/VXNWLmSkWOFih6IfVeDmoL4aoQL6JmTg4jA9vWKaeDK0gtiGNTtu5TV/nXiAqdq6XsL1Gq24r8jJrgrzg8OsVQDT86m5m1p7F2IOtZt5/0ejaM48E/NFXmxD32hEEG88lTPtmxJNnnZub6+3vx9KDUDIMW6BaHDmMIDNLsEJ9flNfTN1VEGDQrmuJV2oVbdQxYOrGFXsZhYMLZ9dvIXhU/ltai69d8AENpFgmy8nacoz+NsN6EJ39nkz4Om6M5aMxNfX0qySjh1nGdrC+ik8giRI44//fbu86gLi82597hJxfiWx6zcsqx3fF1D3WIg== X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 31:rkESdtDaXki/nBdsbAy/ObbrDZZuXwLdIKBYuXhmgG/IizKRODIvAXYhGHzkgSSDsRdthcAz6pci9vmHKqtME+wOoWvSrUQTTpr71VCchg9u37W+Irm61rsO95KMf6AQsJ4ya7Gw4BtAfMezQxrTp5RLs20ZqR4KSHgahEm5OxDKEKk4FYvS9dqAlFfAHp+cKjyf72dc1latI/jSbVJPRS6fqS10Uqu1fUfFLZqdAUJ0U2L7TQYcIrkroMvXpQ/R79CfPJ0h7vU/LoaYKAvKLL48e6TNMBGrXJGNRWAIpLOIQtxbp2W7CeL/bQi1O88uj8g80mdWTMBkxzvwRQXyfA== X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 20:Xd4SQBlVTb/jJr52SG2WKBbP49+CBbVMgT1ipsoLqW9Jh4sx3+WmpeDmBIC9qKspwhUgW+Q57/4VXzqLWFyI4GU0cWVSpJFct55+MwRsIfPx9xMK8Q271uqrFxZ+ho6OQtEWmh5wyN6BoedMqKP8bCvxGrn3GtIQpZYNlKMXIvfWGqaemrpOtB1vz08Ys9SxgJ9w5yUk0nAlam8cuWk6wiuXQCCz0davKxIDVonGD69R1RW7R5AXao1Qdmsd4IXWR5Ufezs32eb8Vb344yiQtZbpppS3JuvevvnkFhMRIVORCu/t9LbNmlZztlKXDb7ySzO+K6PB0CoBWYKNCGLqrejziY0cgj/X1TGUQKhbwzJTshzUQfbCD+oE9zAQOjrFcYlh8dmTnH3wGn5cujdOvO8vRfwO8qgp3VOYwQqW5UxpLbHOVNoE+UDe7f79+hOxT+XtFfOH6LsUae4a8RMeW7wNm7sJ4gaFhzlYYsDJTF9o3GSuXolsQX1mPEJ6lPBVbZNZ+V05s9TDNJlkyQqELaaf9lWBLi1MWlgVKgyVWDx06ORy4T8X3nd7MYsKW2QnPBiHWE05IVoroFIQ7jGe6tfpcsKLg/ttIM74XWBKCbc= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(20161123558100)(20161123555025)(6072148); SRVR:BN3PR05MB2497; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2497; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 4:D7FDyDUGlKo4AhqgcJ1ZGaA2IMSsvaoX/3knDPcVFoa9WxEjg6+SOBjBSMfYfD7Oe5jjlziw9IqtNpWzuFw2XcrPx7ohkgaSkouG8cVPH4fy5wGAIiLDCQqvWWlVmla4ebKlPAOtkmhTzETjmElWW738nZOG0VkvOv4KLTNt0uBgVQ+VHrqRhE8Ha0VBLL3fQ4smV44V9IfNdpRM/ztmhaxkRkdMCMmJnM+avKz47NJiDa9gbG4DiRUl2wlga1TjzRs+hw4DpB3jZlSGeuEt6/TAbGpk81D9jCiN4n7pCQhF09yTLWLzSTEH+HCyj+RuVNabqedtVSwgnM16BUf2gn8lB8V3JSQ30106XkA5P7y8furaYRta84j8jPcATAFMz6c1Hk+vjBsiQF1JRa72g93UslOGsaXPAV5Jg2UinH0NKtYkp985hrC31QVtSuYqWXYugSxMqu7JX5eFQI1qSa8CNgEBcLWE+BrDBVG06uSbDotdPKU9GLlEsABrCbAN5TnMcU0cloBAqEyyGavV7N3QnSZfYUrERJ1EsGk8JkqVl/SC6/G2ACVQHQxhqg/SlFGY5TT8NszELVzISno0VMvsP4kSu808fdL1T/teF2k7svMlQlEgTpGk31dbpMk6B7Ylko39teH8ButLGAfV6vEUEL7nfqqxEqqCm8Mk2zOY9m0yWGugYFEwy8jdoK7BIAHQAPHm0lwqOpwoK8wD4xyeA2p5acYXWGvRVdySVipTMDrZaWLYdmphQmXHVmbVvzCaUOmffb2RJNkIDcG/TULVX/u8YbhYzCeQjgMA3RGiiT3T9ZMRy8aFyaxiMh7D9Qz8YtVZJATM8UeeluJhkiTxvQVzuP5Z8DW3f36gXcD/HHviE34gLDhBAHBe4sOj X-Forefront-PRVS: 029174C036 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39840400002)(39850400002)(39450400003)(39410400002)(39400400002)(39860400002)(53754006)(305945005)(86362001)(50986999)(4610100001)(7736002)(512874002)(5660300001)(69556001)(2351001)(6512007)(189998001)(6916009)(21480400002)(6486002)(6666003)(568964002)(82746002)(54906002)(6306002)(6506006)(1720100001)(84326002)(83716003)(450100002)(4326008)(33656002)(6116002)(25786009)(3846002)(36756003)(5890100001)(81166006)(66066001)(53936002)(8676002)(53416004)(50226002)(38730400002)(2906002)(42186005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2497; H:pvakharwala-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2497; 23:jPZaZVXAkycox8oH2ZjPABEiCGCRV2lDIEanz5dPo?= =?us-ascii?Q?G7InMzZFX1S15VSO66UVrikD0YyXpnn+GiDqJ/sN/uywyrFEGe9K/WFwCsd4?= =?us-ascii?Q?mhc9rnzq0fKv2AI0jbzUi207AWTluwmapWCksIr9ZtCqtMYrL3ifzZXyLhsL?= =?us-ascii?Q?Lsl4IzabXTQAHfn0h1UbG3RQjotFQA+LpWxfZPtJQe/nF0vjxWZfXYBFFTjr?= =?us-ascii?Q?NTX+TxhfDL8PIyz4bDHCYJj0JwgrLMkHZDSNxADsuYL45keW3Nr14peD760J?= =?us-ascii?Q?Vo0OwPVBU9HjhynUPJDRj2UCysSJOrCoWM0MWwtKlsUcRqLVQlNiNz8D16s0?= =?us-ascii?Q?XZ4UTyiRTkuCnAhPKtVL4TCpfo6i58nvGyeCQeWG7V9iVD+O6HT2Zin73mI8?= =?us-ascii?Q?hhckk+E4ur2ZYkzb8sduIuNdf7HHs90jCOoGb+rVYcNGn4O4xw9qCedbMNmo?= =?us-ascii?Q?pmt/pzfe/x+ci1zl/YlHAa4uG3Q64yUg33cev8Eup/MS7Sz6VQRjgLq2plr3?= =?us-ascii?Q?xJfgAqSDyVa1VDtBLlj6CoYIam85MmDrcXH8cltwhftW+NyceUO0StOfNd1M?= =?us-ascii?Q?C1Y5eMpDc4DGb4R0SqzFVA1p/ityDB22KsFnOCRVryHnfwH3huEnZfjMPp/y?= =?us-ascii?Q?1EeDXgRws4zBo3tW0Pwwh1NAX/rRhCX5cei0on9kUqwQCpRTUXNWeztK5/D0?= =?us-ascii?Q?07JSdvhJCeoyJsrGuEye9hOekByNPgrujZhj8getgkpY/FoKzQc6Z3FrLCJi?= =?us-ascii?Q?ssXfZbRjSLuGl/EcKoHw5UpvQeLc3LyoZGhtkc894yz2agFQRGQzbkG7FRv5?= =?us-ascii?Q?KaqTZqfNMNA8ySTWye6HEBWcnP/AjalYa8WaglRTfUZyk3oOpCKSN5P2ZLSA?= =?us-ascii?Q?aka18Q8aSuk91So0jn4eHbgJr12FqMDb5xhl4KK/6Xru2+V19C/7U4+9SJIs?= =?us-ascii?Q?6idQpkzf8hliy02iWRSEoUHJOYFd+DBIcI1yNNZW4kDKOvx1L5UcThAt9y6c?= =?us-ascii?Q?UuKyiaFniHVpMQFSuFLYIcm9byIK6sDGhEdLml1OH1qjjFmdcoXel5RZQK2G?= =?us-ascii?Q?4OWvaDtQfy2UNDTSa2EHK5yo4zgATrR1I7k+9ANvb0OprcFlGrdIIsnvd/EM?= =?us-ascii?Q?ysA+EendGfOdNYsHnxR/1bf+3X96TH9AKUqgv4OmCXZ5rR12vEAoO+z0t417?= =?us-ascii?Q?EC+IxCawv8apPHzI9E3eTLhsRTDvN9J8YPNX7ATo54biO5oYMmtCvk1gtOCc?= =?us-ascii?Q?fguPVqrvChydopKnrY=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 6:EZqVowQncv/t6uhZkRMB5G7oYnCVPk5MlKDBDxm1TWa4YvoC5VvTZdOufx2SRIulBhgGczJxzNnUdmH/TTxPY+JGoMpT91hUBBdYmyX/kSZ7vtEkNB+g94JYvi1aSu+dvcX9m08E3FqvTD7Kn2GZmL49tnhKY6pYFyi6+vhPwGMNu6sbOuVEuN3yk8EuwF5IEq80l2goHDjWjUc+5PrEXzCFJuCpm1mYCIAyvBOVHGHINnketWlueTxj3b6og+46LYCnqMZLPqQ1BUqz2hA/OH8CnsGvfG/d5tQoqutAWfNWkqO/ySb1kTra8SbJOFO7TrDEG4IWgLd3rGPDkPxEPSYTGIYdMXkWMYHnYgKSj6zkiWnowHcozpjP+Paihcr5J9gqV2sBpZ4F2eAEurM9/hYrDLQxqTiPjCfcLe2/hkgoUPDCAbLl57vR9RwcDi6jSSKCbYleQtAXRycilOJEDiLoSSTRkkSzRjwhXhUKUcABKEZ78cjx7Tt+SSacNTh68kLt3rkel/SAZ4oCLsAkXsQisvJ03YfafF8e9F1ihqo=; 5:D+nr+x/Z2bDkEXSSu7Q/ke5mgAoPhjYw/vWg7lmCxJuEmV6USXwRo/Sq1I4AY82Wp03kU3jYJVKK5l1D1GiF9kDlXoRA72Xqfmi7QrZavIxZ3oJx0WOVFdlcoepDedmdF2ADpR9vsVdvRJAhcam29Zkd0BlF35gUAYRARgATQ2g=; 24:yRa7yg/l3By36udBfEXiF3lyg/vJIeXuGkNCfevFNHmz1p4DfI3vPkhJGX/rHku7UaUnG+uQ2iJssUnHcQSe+y9Gwctm22czH3M9xm2DXTo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 7:oK2gwTvS9ivKjPlc0vluqO7hxyy+hPf124VeN4xkrFhqri98z3VwrdoygIIo9+VibSzK+PyQ59OKRHLo8OLgXsLbuWsQiT6oIGml0z9d0cjKsxU18xHZvHQxkc2+PmEDfcxYp16DJSJuxCrI4aQQc2d/r7AAEfzYbQgOVvEMs76jKdlZexP2mcBZ8VZRt8LKSsKKDiGQ8xJaQGixzKR3lipnr0AjPTGU/5LbkvaVvY5rXRAbgxlqNTtgaypAQhSIzCNLjQoIF0pvBuDFDzskk9AiK1dycrVK70HXAB5X3hasThYwQUdUzInQQlCbIDLS6hDEWk6BoPN7/OiYDq694Q== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Apr 2017 20:24:01.8101 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2497 Archived-At: Subject: [RTG-DIR] Routing Directorate review of draft-ietf-rtgwg-ni-model-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 20:26:37 -0000 --Apple-Mail=_E8A9E5BB-0E2D-42E0-BE69-AE11A09B0D3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi All, =20 I have been selected to do a routing directorate aQA review of this = draft. https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ni-model/ =20 The QA review is described = (https://trac.ietf.org/trac/rtg/wiki/RtgDirDocQa) as: "The WG Draft Quality Assurance process exists to provide cross-WG and = expert review early in the IETF process after a WG has adopted a WG = draft or while the WG is deciding to adopt a draft. Since a WG adopts a = draft as a good starting point for the work, providing early excellent = review of such drafts allows for good technical discussion and the = ability to enhance the WG draft to solve identified issues. The earlier = in the process that substantial issues (technical or editorial) are = resolved, the more quickly and smoothly a WG draft is likely to = proceed." =20 For more information about the Routing Directorate, please see = =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Document: draft-ietf-rtgwg-ni-model-02.txt=20 Reviewer: John Scudder Review Date: April 28, 2017 Summary:=20 I found the document easy to follow, clear and almost painless to read, = thank you. Note that my level of Yang expertise is pretty low, so you should be = looking elsewhere for a critique of anything other than the grossest = Yang-specific aspects of the document. (I found the schema-mount example = in section 3.2 particularly opaque.) Comments and Questions: 1. There's a significant amount of duplication of explanatory and = background text between this document and draft-ietf-rtgwg-lne-model-01. = In reading it, I tried to consider whether it would be OK to cut out = some of the text explaining what an LNE is, but on the whole I think = it's better left in -- the document would have been more difficult to = read without having that context in-line. However, it does lead to the = question, is there some good reason the two documents are separate, = instead of a single document? The duplication between them suggests = there's at least some motivation to refactor them into one. (I realize = there may be many reasons to keep them separate, including "seriously, = John? The cost/benefit just isn't there", but I had to ask.) 2. The abstract is almost a copy of the abstract for = draft-ietf-rtgwg-lne-model-01. Comments in #1 above notwithstanding, I = do think brevity is the soul of wit when it comes to an abstract, so I = suggest removing the LNE definition here, and just define the stuff = *this* doc is about. (Similar suggestion applies to the companion doc's = abstract.) 3. It seems to me the "TBD" for network-instance-policy represents a = significant open issue and deserves to be included in your open issues = list (section 1.1). Other TBDs sprinkled throughout don't seem to rise = to this level, but of course do represent open issues. 4. Speaking of network instance policy, although since it's left TBD = there's not much to be said, the examples you give (RTs, RDs, VNIs, VPLS = neighbors) mostly don't seem like what I think of as "policy". I suppose = it's one of the most overloaded terms in our industry, so maybe someone = else does think of it that way, but this choice of terminology was a = speed bump for my understanding of the doc. 5. The example given in section 3.2 doesn't seem to follow the same = pattern as the one given in section 3. I'm too much of a Yang neophyte = to know if there might be some Yang feature in play that makes this make = sense, but on the face of it the example in section 3 seems to tell me = I'm supposed to bind a network-instance-name to a specific instance of = an interface (so, if:interfaces/if:interface), whereas what I see in 3.2 = is a network-instance-name at the if:interfaces level -- which doesn't = make a lot of intuitive sense, either. Minor Issues and Nits: 6. I've edited various minor suggestions into a copy of = draft-ietf-rtgwg-ni-model-02.txt and attached it, you can look at them = using your diff tool of choice. 7. This sentence isn't quite right: Network instance policies are used to control how NI information is represented at the device level, VRF routing policies, and VRF/VSI identifiers. Without knowing your intent I'm not able to offer you a rewrite. = Possibly it would be enough to reorder the items in your list, to put = the big compound one at the end, as in "Network instance policies are = used to control VRF routing policies, VRF/VSI identifiers, and how NI = information is represented at the device level"?=20 8. This sentence no verb: For layer 3, this consistent with the routing-instance definition in ietf-routing Again, without knowing your intent I can't offer a rewrite. Maybe the = verb "to be" is what you want? --Apple-Mail=_E8A9E5BB-0E2D-42E0-BE69-AE11A09B0D3B Content-Disposition: attachment; filename="draft-ietf-rtgwg-ni-model-02.txt" Content-Type: text/plain; name="draft-ietf-rtgwg-ni-model-02.txt" Content-Transfer-Encoding: quoted-printable Network Working Group L. Berger Internet-Draft LabN Consulting, L.L.C. Intended status: Standards Track C. Hopps Expires: September 14, 2017 Deutsche Telekom A. Lindem Cisco Systems D. Bogdanovic March 13, 2017 YANG Network Instances draft-ietf-rtgwg-ni-model-02 Abstract This document defines a network instance module. This module along with the logical network element module can be used to manage the logical and virtual resource representations that may be present on a network device. Examples of common industry terms for logical resource representations are Logical Systems or Logical Routers. Examples of common industry terms for virtual resource representations are Virtual Routing and Forwarding (VRF) instances and Virtual Switch Instances (VSIs). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 14, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Berger, et al. Expires September 14, 2017 [Page 1] =0C Internet-Draft YANG NIs March 2017 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Status of Work and Open Issues . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Network Instances . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Network Instance Policy . . . . . . . . . . . . . . . . . 6 3.2. Network Instance Management . . . . . . . . . . . . . . . 7 3.3. Network Instance Instantiation . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Network Instance Model . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 16 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction This document defines the second of two new modules that are defined to support the configuration and operation of network devices that allow for the partitioning of resources from both, or either, management and networking perspectives. Both make use of the YANG functionality enabled by YANG Schema Mount [I-D.ietf-netmod-schema-mount]. Two forms of resource partitioning are supported: The first form, which is defined in [I-D.ietf-rtgwg-lne-model], provides a logical partitioning of a network device where each partition is separately managed as essentially an independent network element which is 'hosted' by the base network device. These hosted network elements are referred to as logical network elements, or LNEs, and are supported by the logical-network-element module defined in [I-D.ietf-rtgwg-lne-model]. The module is used to identify LNEs and associate resources from the network-device with each LNE. LNEs themselves are represented in YANG as independent network devices; each accessed independently. Optionally, and when supported by the Berger, et al. Expires September 14, 2017 [Page 2] =0C Internet-Draft YANG NIs March 2017 implementation, they may also be accessed from the host system. Examples of vendor terminology for an LNE include logical system or logical router, and virtual switch, chassis, or fabric. The second form, which is defined in this document, provides support = for what is commonly referred to as Virtual Routing and Forwarding (VRF) instances as well as Virtual Switch Instances (VSI), see [RFC4026]. In this form of resource partitioning multiple control plane and forwarding/bridging instances are provided by and managed via a single (physical or logical) network device. This form of resource partitioning is referred to as Network Instances and is supported by the network-instance module defined below. Configuration and operation of each network-instance is always via the network device and the network-instance module. This document was motivated by, and derived from, [I-D.ietf-rtgwg-device-model]. 1.1. Status of Work and Open Issues The top open issues are: 1. This document will need to match the evolution and standardization of [I-D.openconfig-netmod-opstate] or [I-D.ietf-netmod-opstate-reqs] by the Netmod WG. 2. Overview In this document, we consider network devices that support protocols and functions defined within the IETF Routing Area, e.g, routers, firewalls and hosts. Such devices may be physical or virtual, e.g., a classic router with custom hardware or one residing within a server-based virtual machine implementing a virtual network function (VNF). Each device may sub-divide their resources into logical network elements (LNEs) each of which provides a managed logical device. Examples of vendor terminology for an LNE include logical system or logical router, and virtual switch, chassis, or fabric. Each LNE may also support virtual routing and forwarding (VRF) and virtual switching instance (VSI) functions, which are referred to below as a network instances (NIs). This breakdown is represented in Figure 1. Berger, et al. Expires September 14, 2017 [Page 3] =0C Internet-Draft YANG NIs March 2017 ,''''''''''''''''''''''''''''''''''''''''''''''`. | Network Device (Physical or Virtual) | | ..................... ..................... | | : Logical Network : : Logical Network : | | : Element : : Element : | | :+-----+-----+-----+: :+-----+-----+-----+: | | :| Net | Net | Net |: :| Net | Net | Net |: | | :|Inst.|Inst.|Inst.|: :|Inst.|Inst.|Inst.|: | | :+-----+-----+-----+: :+-----+-----+-----+: | | : | | | | | | : : | | | | | | : | | :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: | | | | | | | | | | | | | | | `'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|''''' | | | | | | | | | | | | Interfaces Interfaces Figure 1: Module Element Relationships A model for LNEs is described in [I-D.ietf-rtgwg-lne-model] and the model for network instances is covered in Section 3. For more information on how these models may be used within an overall device model structure, see [I-D.ietf-rtgwg-device-model]. The interface management model [RFC7223] is an existing model that is impacted by the definition of LNEs and network instances. This document and [I-D.ietf-rtgwg-lne-model] define augmentations to the interface module to support LNEs and NIs. Similar elements, although perhaps only for LNEs, may also need to be included as part of the definition of the hardware and QoS modules. Interfaces are a crucial part of any network device's configuration and operational state. They generally include a combination of raw physical interfaces, link-layer interfaces, addressing configuration, and logical interfaces that may not be tied to any physical interface. Several system services, and layer 2 and layer 3 protocols may also associate configuration or operational state data with different types of interfaces (these relationships are not shown for simplicity). The interface management model is defined by [RFC7223]. The logical-network-element and network-instance modules augment the existing interface management model in two ways: The first, by the logical-network-element module, adds an identifier which is used on physical interface types to identify an associated LNE. The second, by the network-instance module, adds a name which is used on interface or sub-interface types to identify an associated network instance. Similarly, this name is also added for IPv4 and IPv6 types, as defined in [RFC7277]. Berger, et al. Expires September 14, 2017 [Page 4] =0C Internet-Draft YANG NIs March 2017 The interface related augmentations are as follows: module: ietf-logical-network-element augment /if:interfaces/if:interface: +--rw bind-lne-name? string module: ietf-network-instance augment /if:interfaces/if:interface: +--rw bind-network-instance-name? string augment /if:interfaces/if:interface/ip:ipv4: +--rw bind-network-instance-name? string augment /if:interfaces/if:interface/ip:ipv6: +--rw bind-network-instance-name? string The following is an example of envisioned combined usage. The interfaces container includes a number of commonly used components as examples: +--rw if:interfaces | +--rw interface* [name] | +--rw name string | +--rw lne:bind-lne-name? string | +--rw ethernet | | +--rw ni:bind-network-instance-name? string | | +--rw aggregates | | +--rw rstp | | +--rw lldp | | +--rw ptp | +--rw vlans | +--rw tunnels | +--rw ipv4 | | +--rw ni:bind-network-instance-name? string | | +--rw arp | | +--rw icmp | | +--rw vrrp | | +--rw dhcp-client | +--rw ipv6 | +--rw ni:bind-network-instance-name? string | +--rw vrrp | +--rw icmpv6 | +--rw nd | +--rw dhcpv6-client The [RFC7223] defined interface model is structured to include all interfaces in a flat list, without regard to logical or virtual instances (e.g., VRFs) supported on the device. The bind-lne-name and bind-network-instance-name leaves provide the association between an interface and its associated LNE and NI (e.g., VRF or VSI). Berger, et al. Expires September 14, 2017 [Page 5] =0C Internet-Draft YANG NIs March 2017 3. Network Instances The network instance container is used to represent virtual routing and forwarding instances (VRFs) and virtual switching instances (VSIs), [RFC4026]. VRFs and VSIs are commonly used to isolate routing and switching domains, for example to create virtual private networks, each with their own active protocols and routing/switching policies. The model represents both core/provider and virtual instances. Network instances reuse and build on [RFC8022] and are shown below: module: ietf-network-instance +--rw network-instances +--rw network-instance* [name] +--rw name string +--rw type? identityref +--rw enabled? boolean +--rw description? string +--rw network-instance-policy | ... +--rw root? yang-schema-mount | ... augment /if:interfaces/if:interface: +--rw bind-network-instance-name? string augment /if:interfaces/if:interface/ip:ipv4: +--rw bind-network-instance-name? string augment /if:interfaces/if:interface/ip:ipv6: +--rw bind-network-instance-name? string A network instance is identified by a `name` string. This string is used both as an index within the network-instance module and to associate resources with a network instance as shown above in the interface augmentation. Type is used to indicate the type of NI, = such as L3-VRF, VPLS, L2-VSI, etc. Network instance policy and root are discussed in greater detail below. 3.1. Network Instance Policy Network instance policies are used to control how NI information is represented at the device level, VRF routing policies, and VRF/VSI identifiers. Examples include BGP route targets (RTs) and route distinguishers (RDs), virtual network identifiers (VN-IDs), VPLS neighbors, etc. The structure is expected to be: Berger, et al. Expires September 14, 2017 [Page 6] =0C Internet-Draft YANG NIs March 2017 module: ietf-network-instance +--rw network-instances +--rw network-instance* [name] +--rw network-instance-policy (TBD) 3.2. Network Instance Management Modules that may be used to represent network instance specific information will be available under `root`. As with LNEs, actual module availability is expected to be implementation dependent. The use-schema mechanism defined as part of the Schema Mount module [I-D.ietf-netmod-schema-mount] is expected to be the primary method used to identify supported modules. Resource related control and assignment is expected to be managed at the network-device level, not the network instance level, based on the `bind-network-instance-name` augmentation mentioned above. Mounted modules will access such information, as well as any other information contained within a module at the device root, by using the parent-reference mechanism defined in [I-D.ietf-netmod-schema-mount]. As an example, consider the case where a network instance with a `name` of "green" is defined on a network device. In this case the following logical structure might be made available: +--rw yanglib:modules-state [RFC7895] +--rw if:interfaces [RFC7223] | +--rw bind-network-instance-name=3D"green" string +--rw network-instances +--rw network-instance* [name] +--rw name=3D"green" string +--rw type? identityref +--rw enabled=3Dtrue boolean +--rw description=3D"The Green VRF" string +--rw network-instance-policy | ... (RT=3D1000:1, RD=3D1.2.3.4) +--rw root? yang-schema-mount with a corresponding logical structure in the schema-mount module: Berger, et al. Expires September 14, 2017 [Page 7] =0C Internet-Draft YANG NIs March 2017 module: ietf-yang-schema-mount +--ro schema-mounts : +--ro mount-point* [module name] | +--ro module=3D"ietf-network-instance" | +--ro name=3D"root" | +--ro config=3Dtrue | +--ro (schema-ref)? | +--:(use-schema) | +--ro use-schema* [name] | +--ro name=3D"ni-vrf" : : : +--ro schema* [name] +--ro name=3D"ni-vrf" string +--ro module* [name revision] | +--ro name=3D"mm:network-services" : : | +--ro name=3D"nn:oam-protocols" : : | +--ro name=3D"oo:routing" : : | +--ro name=3D"pp:mpls" : : +--ro mount-point* [network-instance] : All modules that represent control-plane and data-plane information may be present at the `root`, and be accessible via paths modified per [I-D.ietf-netmod-schema-mount]. The list of available modules is expected to be implementation dependent, as is the method used by an implementation to support NIs. 3.3. Network Instance Instantiation Network instances may be controlled by clients using existing list operations. When list entries are created, a new instance is instantiated. The models mounted under a NI root are expected to be dependent on the server implementation. When a list entry is deleted, an existing network instance is destroyed. For more information see [RFC7950] Section 7.8.6. 4. Security Considerations TBD Berger, et al. Expires September 14, 2017 [Page 8] =0C Internet-Draft YANG NIs March 2017 5. IANA Considerations This document registers a URI in the IETF XML registry [RFC3688]. Following the format in RFC 3688, the following registration is requested to be made. URI: urn:ietf:params:xml:ns:yang:ietf-network-instance Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. This document registers a YANG module in the YANG Module Names registry [RFC6020]. name: ietf-network-instance namespace: urn:ietf:params:xml:ns:yang:ietf-network-instance prefix: ni reference: RFC XXXX 6. Network Instance Model The structure of the model defined in this document is described by the YANG module below. file "ietf-network-instance@2017-03-13.yang" module ietf-network-instance { yang-version 1.1; // namespace namespace "urn:ietf:params:xml:ns:yang:ietf-network-instance"; prefix ni; // import some basic types import ietf-interfaces { prefix if; } import ietf-ip { prefix ip; } import ietf-yang-schema-mount { prefix yangmnt; } Berger, et al. Expires September 14, 2017 [Page 9] =0C Internet-Draft YANG NIs March 2017 // meta organization "IETF Routing Area Working Group (rtgwg)"; contact "Routing Area Working Group - "; description "This module is used to support multiple network instances within a single physical or virtual device. Network instances are commonly known as VRFs (virtual routing and forwarding) and VSIs (virtual switching instances)."; revision "2017-03-13" { description "Initial revision."; reference "RFC TBD"; } // extension statements feature bind-network-instance-name { description "Network Instance to which an interface instance is bound"; } // identity statements identity network-instance-type { description "Base identity from which identities describing network instance types are derived"; } identity ipv4-interface-protocol-type { description "Base identity for derivation of IPv4 interface protocols"; } identity ipv6-interface-protocol-type { description "Base identity for derivation of IPv6 interface protocols"; } // typedef statements // grouping statements Berger, et al. Expires September 14, 2017 [Page 10] =0C Internet-Draft YANG NIs March 2017 grouping interface-ip-common { description "interface-specific configuration for IP interfaces, IPv4 and IPv6"; } grouping ipv4-interface-protocols { container ipv4-interface-protocols { list ipv4-interface-protocol { key "type"; leaf type { type identityref { base ipv4-interface-protocol-type; } mandatory true; description "ARP, ICMP, VRRP, DHCP Client, etc."; } description "List of IPv4 protocols configured on an interface"; } description "Container for list of IPv4 protocols configured on an interface"; } description "Grouping for IPv4 protocols configured on an interface"; } grouping ipv6-interface-protocols { description "Grouping for IPv6 protocols configured on an interface."; container ipv6-interface-protocols { description "Container for list of IPv6 protocols configured on an interface."; list ipv6-interface-protocol { key "type"; description "List of IPv6 protocols configured on an interface"; leaf type { type identityref { base ipv6-interface-protocol-type; } Berger, et al. Expires September 14, 2017 [Page 11] =0C Internet-Draft YANG NIs March 2017 mandatory true; description "ND, ICMPv6, VRRP, DHCPv6 Client, etc."; } } } } grouping network-instance-policy { description "Network instance policies such as route distinguisher, route targets, VPLS ID and neighbor, Ethernet ID, etc. "; reference "RFC 4364 - BGP/MPLS Virtual Private Networks (VPNs) RFC 6074 - Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs) RFC 7432 - BGP MPLS-Based Ethernet VPN"; container network-instance-policy { description "Network Instance Policy -- details TBD, perhaps based on BESS model"; } } // top level device definition statements container network-instances { description "Network instances each of which have an independent IP/IPv6 addressing space and protocol instantiations. For layer 3, this consistent with the routing-instance definition in ietf-routing"; reference "RFC 8022 - A YANG Data Model for Routing Management"; list network-instance { key name; description "List of network-instances"; leaf name { type string; description "device scoped identifier for the network instance"; } leaf type { type identityref { base network-instance-type; } description Berger, et al. Expires September 14, 2017 [Page 12] =0C Internet-Draft YANG NIs March 2017 "The network instance type -- details TBD Likely types include core, L3-VRF, VPLS, L2-cross-connect, L2-VSI, etc."; } leaf enabled { type boolean; default "true"; description "Flag indicating whether or not the network instance is enabled."; } leaf description { type string; description "Description of the network instance and its intended purpose"; } uses network-instance-policy; yangmnt:mount-point root { description "Root for models supported per network instance. This will typically not be an inline type mount point."; } } } // augment statements augment "/if:interfaces/if:interface" { description "Add a node for the identification of the logical network instance (which is within the interface's identified logical network element) associated with the IP information configured on an interface"; leaf bind-network-instance-name { type string; description "Network Instance to which an interface is bound"; } } augment "/if:interfaces/if:interface/ip:ipv4" { description Berger, et al. Expires September 14, 2017 [Page 13] =0C Internet-Draft YANG NIs March 2017 "Add a node for the identification of the logical network instance (which is within the interface's identified physical or virtual device) associated with the IP information configured on an interface"; leaf bind-network-instance-name { type string; description "Network Instance to which IPv4 interface is bound"; } } augment "/if:interfaces/if:interface/ip:ipv6" { description "Add a node for the identification of the logical network instance (which is within the interface's identified physical or virtual device) associated with the IP information configured on an interface"; leaf bind-network-instance-name { type string; description "Network Instance to which IPv6 interface is bound"; } } // rpc statements // notification statements } 7. References 7.1. Normative References [I-D.ietf-netmod-schema-mount] Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- ietf-netmod-schema-mount-04 (work in progress), March 2017. [I-D.ietf-rtgwg-lne-model] Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic, "YANG Logical Network Elements", draft-ietf-rtgwg-lne- model-01 (work in progress), October 2016. Berger, et al. Expires September 14, 2017 [Page 14] =0C Internet-Draft YANG NIs March 2017 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC7223] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, . [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC 7277, DOI 10.17487/RFC7277, June 2014, . 7.2. Informative References [I-D.ietf-netmod-opstate-reqs] Watsen, K. and T. Nadeau, "Terminology and Requirements for Enhanced Handling of Operational State", draft-ietf- netmod-opstate-reqs-04 (work in progress), January 2016. [I-D.ietf-rtgwg-device-model] Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, "Network Device YANG Organizational Models", draft-ietf- rtgwg-device-model-01 (work in progress), October 2016. [I-D.openconfig-netmod-opstate] Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling of Operational State Data in YANG", draft-openconfig- netmod-opstate-01 (work in progress), July 2015. [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, March 2005, . [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . Berger, et al. Expires September 14, 2017 [Page 15] =0C Internet-Draft YANG NIs March 2017 [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing Management", RFC 8022, DOI 10.17487/RFC8022, November 2016, . Appendix A. Acknowledgments The Routing Area Yang Architecture design team members included Acee Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger, Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. The RFC text was produced using Marshall Rose's xml2rfc tool. Berger, et al. Expires September 14, 2017 [Page 16] =0C Internet-Draft YANG NIs March 2017 Appendix B. Contributors Contributors' Addresses TBD Authors' Addresses Lou Berger LabN Consulting, L.L.C. Email: lberger@labn.net Christan Hopps Deutsche Telekom Email: chopps@chopps.org Acee Lindem Cisco Systems 301 Midenhall Way Cary, NC 27513 USA Email: acee@cisco.com Dean Bogdanovic Email: ivandean@gmail.com Berger, et al. Expires September 14, 2017 [Page 17] --Apple-Mail=_E8A9E5BB-0E2D-42E0-BE69-AE11A09B0D3B-- From nobody Sat Apr 29 07:45:10 2017 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 F0D8B1294F4 for ; Sat, 29 Apr 2017 07:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 IbmPi8M7MZ-0 for ; Sat, 29 Apr 2017 07:45:07 -0700 (PDT) Received: from gproxy8.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) (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 C710E126B6E for ; Sat, 29 Apr 2017 07:44:50 -0700 (PDT) Received: from cmgw2 (unknown [10.0.90.83]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id AB8311AB0D5 for ; Sat, 29 Apr 2017 08:44:48 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id EEkk1v00R2SSUrH01EkndU; Sat, 29 Apr 2017 08:44:48 -0600 X-Authority-Analysis: v=2.2 cv=Ibz3YSia c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=AzvcPWV-tVgA:10 a=48vgC7mUAAAA:8 a=L35N5iEh9iDEk8KDZvMA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=qybVsJO03rxB1XJvQxF8c9T7KVhEoh00ytwIwW+TbqU=; b=Wg2nSRidEOotoppil5XMcwwMLS ZoRLGIdu9O3/Td576oSGyrTfVC0vJGSLr7B+62bg2sGtAvYKNJ7KuYH30H5Iin3dULh0Ut+hDNI46 INOCU0vzewook2y/RVrlrQf1r; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:56054 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1d4Tc2-0005bT-GK; Sat, 29 Apr 2017 08:44:44 -0600 To: "John G. Scudder" , draft-ietf-rtgwg-ni-model@ietf.org References: Cc: rtg-dir@ietf.org, rtgwg-chairs@ietf.org, rtgwg@ietf.org From: Lou Berger Message-ID: <4298c8ad-d44e-6f37-b321-4bf62b6eb145@labn.net> Date: Sat, 29 Apr 2017 10:44:31 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1d4Tc2-0005bT-GK X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:56054 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [RTG-DIR] Routing Directorate review of draft-ietf-rtgwg-ni-model-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Apr 2017 14:45:09 -0000 Thanks for the review! We'll address your (much appreciated!) comments as part of our next planned update which will also include: - update to next rev of schema mount (which gates this works) - more informational text / examples Thanks, Lou On 4/28/2017 4:23 PM, John G. Scudder wrote: > Hi All, > > I have been selected to do a routing directorate aQA review of this draft. > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ni-model/ > > The QA review is described (https://trac.ietf.org/trac/rtg/wiki/RtgDirDocQa) as: > > "The WG Draft Quality Assurance process exists to provide cross-WG and expert review early in the IETF process after a WG has adopted a WG draft or while the WG is deciding to adopt a draft. Since a WG adopts a draft as a good starting point for the work, providing early excellent review of such drafts allows for good technical discussion and the ability to enhance the WG draft to solve identified issues. The earlier in the process that substantial issues (technical or editorial) are resolved, the more quickly and smoothly a WG draft is likely to proceed." > > For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Document: draft-ietf-rtgwg-ni-model-02.txt > Reviewer: John Scudder > Review Date: April 28, 2017 > > Summary: > > I found the document easy to follow, clear and almost painless to read, thank you. > > Note that my level of Yang expertise is pretty low, so you should be looking elsewhere for a critique of anything other than the grossest Yang-specific aspects of the document. (I found the schema-mount example in section 3.2 particularly opaque.) > > > Comments and Questions: > > 1. There's a significant amount of duplication of explanatory and background text between this document and draft-ietf-rtgwg-lne-model-01. In reading it, I tried to consider whether it would be OK to cut out some of the text explaining what an LNE is, but on the whole I think it's better left in -- the document would have been more difficult to read without having that context in-line. However, it does lead to the question, is there some good reason the two documents are separate, instead of a single document? The duplication between them suggests there's at least some motivation to refactor them into one. (I realize there may be many reasons to keep them separate, including "seriously, John? The cost/benefit just isn't there", but I had to ask.) > > 2. The abstract is almost a copy of the abstract for draft-ietf-rtgwg-lne-model-01. Comments in #1 above notwithstanding, I do think brevity is the soul of wit when it comes to an abstract, so I suggest removing the LNE definition here, and just define the stuff *this* doc is about. (Similar suggestion applies to the companion doc's abstract.) > > 3. It seems to me the "TBD" for network-instance-policy represents a significant open issue and deserves to be included in your open issues list (section 1.1). Other TBDs sprinkled throughout don't seem to rise to this level, but of course do represent open issues. > > 4. Speaking of network instance policy, although since it's left TBD there's not much to be said, the examples you give (RTs, RDs, VNIs, VPLS neighbors) mostly don't seem like what I think of as "policy". I suppose it's one of the most overloaded terms in our industry, so maybe someone else does think of it that way, but this choice of terminology was a speed bump for my understanding of the doc. > > 5. The example given in section 3.2 doesn't seem to follow the same pattern as the one given in section 3. I'm too much of a Yang neophyte to know if there might be some Yang feature in play that makes this make sense, but on the face of it the example in section 3 seems to tell me I'm supposed to bind a network-instance-name to a specific instance of an interface (so, if:interfaces/if:interface), whereas what I see in 3.2 is a network-instance-name at the if:interfaces level -- which doesn't make a lot of intuitive sense, either. > > > Minor Issues and Nits: > > 6. I've edited various minor suggestions into a copy of draft-ietf-rtgwg-ni-model-02.txt and attached it, you can look at them using your diff tool of choice. > > 7. This sentence isn't quite right: > > Network instance policies are used to control how NI information is > represented at the device level, VRF routing policies, and VRF/VSI > identifiers. > > Without knowing your intent I'm not able to offer you a rewrite. Possibly it would be enough to reorder the items in your list, to put the big compound one at the end, as in "Network instance policies are used to control VRF routing policies, VRF/VSI identifiers, and how NI information is represented at the device level"? > > 8. This sentence no verb: > > For layer 3, > this consistent with the routing-instance > definition in ietf-routing > > Again, without knowing your intent I can't offer a rewrite. Maybe the verb "to be" is what you want? > > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From nobody Sun Apr 30 05:20:04 2017 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 AA48312954C; Sun, 30 Apr 2017 05:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.098 X-Spam-Level: X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2O2pOEl2fkE0; Sun, 30 Apr 2017 05:19:53 -0700 (PDT) Received: from mgw030.noc.ntt.com (mgw030.noc.ntt.com [210.160.55.3]) by ietfa.amsl.com (Postfix) with ESMTP id 4A442129454; Sun, 30 Apr 2017 05:18:23 -0700 (PDT) Received: from c0044i0.coe.ntt.com (c0044i0.nc.agilit-hosting.com [10.18.161.13]) by mgw030.noc.ntt.com (NTT Com MailSV) with ESMTP id 296831C581DD; Sun, 30 Apr 2017 21:18:22 +0900 (JST) Received: from C0039I0.coe.ntt.com (10.18.160.43) by c0044i0.coe.ntt.com (10.18.161.13) with Microsoft SMTP Server (TLS) id 14.3.339.0; Sun, 30 Apr 2017 21:18:21 +0900 Received: from C0561I0.coe.ntt.com ([169.254.1.133]) by C0039I0.coe.ntt.com ([10.18.160.43]) with mapi id 14.03.0339.000; Sun, 30 Apr 2017 21:18:21 +0900 From: Tomonori Takeda To: "'rtg-ads@ietf.org'" CC: "'rtg-dir@ietf.org'" , "'draft-ietf-rtgwg-spf-uloop-pb-statement.all@ietf.org'" , "'rtgwg@ietf.org'" Thread-Topic: RTG-DIR QA review: draft-ietf-rtgwg-spf-uloop-pb-statement-03.txt Thread-Index: AdLA7qLGXj0F8yDgRaK42VOyHjaunAAvOLJg Date: Sun, 30 Apr 2017 12:18:20 +0000 Message-ID: References: In-Reply-To: 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-rtgwg-spf-uloop-pb-statement.all@ietf.org, rtgwg@ietf.org x-originating-ip: [10.25.153.185] Content-Type: text/plain; charset="iso-2022-jp" MIME-Version: 1.0 Archived-At: Subject: Re: [RTG-DIR] RTG-DIR QA review: draft-ietf-rtgwg-spf-uloop-pb-statement-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2017 12:19:57 -0000 # Resend since it seems my previous email was not delivered correctly... Hi, I have been selected as the Routing Directorate QA reviewer for this draft. Document: draft-ietf-rtgwg-spf-uloop-pb-statement-03.txt Reviewer: Tomonori Takeda Review Date: April 29, 2017 Intended Status: Standards Track Here are my comments. Overall, the document is well organized and clear about problem statement and analysis of SPF triggers and SPF delays impact on micro-loops. Some specific comments. 1) The document is intended to be Standards Track. I do not think it is common for such analysis document to be Standards Track. 2) Just a nits, but in page 12, it says "In the figure 5", but it seems figures are not numbered. 3) In Section 4.2. Exponential backoff, it is not clear what is a condition (or conditions) to move from FM to BM. Thanks, Tomonori Takeda