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 rev. no specific revision (document currently at 13)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-04-08
Requested 2015-03-21
Draft 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 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
Review review-ietf-idr-ls-distribution-10-opsdir-lc-pignataro-2015-04-19
Reviewed rev. 10 (document currently at 13)
Review result Has Nits
Review completed: 2015-04-19

Review
review-ietf-idr-ls-distribution-10-opsdir-lc-pignataro-2015-04-19

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