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