Last Call Review of draft-ietf-ospf-prefix-link-attr-07
review-ietf-ospf-prefix-link-attr-07-opsdir-lc-pignataro-2015-08-13-00

Request Review of draft-ietf-ospf-prefix-link-attr
Requested rev. no specific revision (document currently at 13)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-08-13
Requested 2015-08-03
Draft last updated 2015-08-13
Completed reviews Genart Last Call review of -06 by Suresh Krishnan (diff)
Genart Telechat review of -10 by Suresh Krishnan (diff)
Opsdir Last Call review of -07 by Carlos Pignataro (diff)
Opsdir Last Call review of -10 by Ron Bonica (diff)
Assignment Reviewer Carlos Pignataro
State Completed
Review review-ietf-ospf-prefix-link-attr-07-opsdir-lc-pignataro-2015-08-13
Reviewed rev. 07 (document currently at 13)
Review result Has Nits
Review completed: 2015-08-13

Review
review-ietf-ospf-prefix-link-attr-07-opsdir-lc-pignataro-2015-08-13

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 defines a mechanisms to associate additional attributes with prefixes or links using Opaque LSAs. These extensions can be in turn used by various applications like Segment Routing and BIER.

This document is very well written, comprehensive, and complete — thank you!

Summary: Ready with nits

Comments prefaced with “CMP”.

Major:

None.


Minor:

2.1.  OSPFv2 Extended Prefix TLV
   If this TLV is advertised multiple times for the same prefix in the
   same OSPFv2 Extended Prefix Opaque LSA, only the first instance is
   used by receiving OSPFv2 Routers.  This situation SHOULD be logged as
   an error.
…
3.1.  OSPFv2 Extended Link TLV
   If this TLV is advertised multiple times in the same OSPFv2 Extended
   Link Opaque LSA, only the first instance is used by receiving OSPFv2
   Routers.  This situation SHOULD be logged as an error.

CMP: Are there any cases in which logging of this error is not useful? In other words, are these two instances a MUST be logged as an error (instead of SHOULD)? Just asking.

4.  Backward Compatibility

   Since opaque OSPFv2 LSAs are optional and backward compatible
   [OPAQUE], the extensions described herein are fully backward
   compatible.  However, future OSPFv2 extensions utilizing these
   extensions must address backward compatibility of the corresponding
   functionality.

CMP: Thanks for including backwards compatibility considerations! This is an important manageability aspect.
CMP: I believe that “future OSPFv2 extensions utilizing these extensions MUST address backward compatibility”. That is, “MUST” instead of “must”. While there is no negative effect simply on receiving a non understood opaque LSA, the functionality that it supports might have made assumptions, which can actually result in negative effects. This MUST should take care of thinking about that.


Nits:

CMP: What follows are nits and editorials.

2.1.  OSPFv2 Extended Prefix TLV
…
   Prefix Length
      Length in of the prefix in bits.

CMP: double preposition.

      Flags: 1 octet field.  The following flags are defined:

     0  1  2  3  4  5  6  7
   +--+--+--+--+--+--+--+--+
   |A |N |  |  |  |  |  |  |
   +--+--+--+--+--+--+--+—+

CMP: The “Flags” heading and the text underneath it are mis-indented, making it harder to parse.

   Address Prefix
      The prefix itself encoded as an even multiple of 32-bit words,
      padded with zeroed bits as necessary.  This encoding consumes
      ((PrefixLength + 31) / 32) 32-bit words.  The default route is
      represented by a prefix of length 0.

CMP: I am not sure I understand the “even multiple of words”. A PrefixLength of 1 gives, according to the formula, 1 32-bit word (odd). (?) Further, I assume the encoding formula needs round up as well.

5.  Implementation Status

CMP: Thanks for including this! Pity Wireshark is not listed (and not coded in the public trunk). From a manageability consideration, ability to dissect the extension is really useful and necessary.

Hope these help,

— Carlos.

_______________________________________________
OPS-DIR mailing list
OPS-DIR at ietf.org


https://www.ietf.org/mailman/listinfo/ops-dir




Attachment:


signature.asc




Description:

 Message signed with OpenPGP using GPGMail