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

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