Last Call Review of draft-ietf-idr-ls-distribution-10
review-ietf-idr-ls-distribution-10-opsdir-lc-pignataro-2015-04-19-00

Request Review of draft-ietf-idr-ls-distribution
Requested revision No specific revision (document currently at 13)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-04-08
Requested 2015-03-21
Authors Hannes Gredler , Jan Medved , Stefano Previdi , Adrian Farrel , Saikat Ray
I-D last updated 2015-04-19
Completed reviews Genart Last Call review of -10 by Alexey Melnikov (diff)
Secdir Last Call review of -10 by Matthew A. Miller (diff)
Opsdir Last Call review of -10 by Carlos Pignataro (diff)
Rtgdir Early review of -05 by Acee Lindem (diff)
Assignment Reviewer Carlos Pignataro
State Completed
Request Last Call review on draft-ietf-idr-ls-distribution by Ops Directorate Assigned
Reviewed revision 10 (document currently at 13)
Result Has nits
Completed 2015-04-19
review-ietf-idr-ls-distribution-10-opsdir-lc-pignataro-2015-04-19-00
Hi!

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.
 These comments were written with the intent of improving the operational
aspects of the IETF drafts. Comments that are not addressed in last call may be
included in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last call comments.

This document is on the Standards Track, and specifies the distribution of IGP
LS and TE information using BGP.

This document includes a comprehensive Manageability Considerations section.

Thank you for a very well written document!

Summary: Ready with minor issues

Major:

None.

Minor:

   (A) The same node must not be represented by two keys (otherwise one

   node will look like two nodes).

   (B) Two different nodes must not be represented by the same key

   (otherwise, two nodes will look like one node).

Are these “must not” or “MUST NOT”?

Nits:

The document has the “hiccups”, see the duplicates:

   from different routing universes.  Table Table 3 lists the

   'Identifier' values that are defined as well-known in this draft.

Duplicate “Table”.

   Router-IDs [RFC5305], [RFC6119].  These auxiliary Router-IDs MUST be

   included in the link attribute described in Section Section 3.3.2.

Duplicate “Section”.

   In section Section 3.2.1.4 a set of sub-TLVs is described, which

   allows specification of a flexible key for any given Node/Link

Duplicate “Section”.

   The following 'Link Attribute' TLVs are are valid in the LINK_STATE

   attribute:

Duplicate “are”.

   Generation of the MPLS Protocol Mask TLV is only valid for

   originators which have local link insight, like for example Protocol-

   IDs 'Static' or 'Direct' as per Table 2.  The 'MPLS Protocol Mask’

s/which/that/

   IGP Flags TLV contains IS-IS and OSPF flags and bits originally

   assigned tothe prefix.  The IGP Flags TLV is encoded as follows:

s/tothe/to the/

   All the following Registries are BGP-LS specific and shall be

   acessible under the following URL: "

http://www.iana.org/assignments/

s/acessible/accessible/

Hope these help,

— Carlos.

Attachment:

signature.asc

Description:

 Message signed with OpenPGP using GPGMail