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 ​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-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: · A small section outlining the requirements of “domain-alignment” 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. · It seems that the implicit assumption that the IGP MRT support 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 “is LDP on anything that will be on red or blue assumed/a MUST” or “IGP shall not compute red/blue if LDP peer is not MT-MRT-capable, i.e. take the link out the MRT topology” ? If such an assumption is made, spelling it out would improve readability of the document. · 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 “proxy node” and “proxy node attachment" in the glossary (of RFC7812?) would help the reader of the document set. · I don’t 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. · 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 “LDP mode must be the same as unicast IGP forwarding mode” would help clarify or the specific necessary modes listed. Minor comments: · For easy reference suggest to add “two-connected graph” to the glossary since it’s not a common term. Or refer to RFC7812 · Maybe same for “cut-vertex” or refer to 7812 · Maybe same for “topological ordering”. Reference 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 > ------------------------------ > > *发件人**:* Tony Przygienda [tonysietf@gmail.com] > *发送时间**:* 2017年3月26日 2:31 > *收件人**:* Yemin (Amy) > *主题**:* 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’ve 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.* > > —Robert Wilensky > > -- *We’ve 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.* —Robert Wilensky