Last Call Review of draft-ietf-mpls-ldp-mrt-05
review-ietf-mpls-ldp-mrt-05-rtgdir-lc-przygienda-2017-04-20-00

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 <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 additional days.
>
> Deborah, could you please confirm on this?
>
>
>
> Amy
>
> *From:* Tony Przygienda [mailto:tonysietf@gmail.com <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
>
>
>
> 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) <amy.yemin@huawei.com> 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' <tonysietf@gmail.com>; 'prz@zeta2.ch' <
> prz@zeta2.ch>
> *Cc:* 'BRUNGARD, DEBORAH A' <db3546@att.com>; '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/
>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dmpls-2Dldp-2Dmrt_&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=QPzfSKiJk8VBP1mieYBoPRdjO-IAl2SJ3eWoKw1yAZ0&s=lvMJ6m4iPoRt849E-0JZLXIb60OKHx8X3T3zo1F9nso&e=>
> > > > 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 >
<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ietf.org_trac_rtg_wiki_RtgDirGuidance&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=QPzfSKiJk8VBP1mieYBoPRdjO-IAl2SJ3eWoKw1yAZ0&s=lyE88Wt1dwavAB6p_eIOt7gWjugzwpDWs90LoWA2e5k&e=>
> > > > 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