Reviewer: Kyle Rose Review result: Ready with Nits This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@xxxxxxxx if you reply to or forward this review. This document describes a mechanism for specifying per-application attributes for link state routing using IS-IS. It proposes no routing functionality changes to applications making use of such attributes, only enabling the ability to choose which attributes in an advertisement apply to a particular application, and consequently I see no specifically transport-related issues in this draft. Nonetheless, I have a few comments. * Update language? There are several places in which it is possible that normative language in prior RFCs is revised. For example, in section 6.1, the last paragraph states: New applications which future documents define to make use of the advertisements defined in this document MUST NOT make use of legacy advertisements. This looks like it was written in such a way as to avoid requiring such updates, but it would be good to confirm that there is no normative language in older documents that would conflict with this requirement. * Encoding In section 4.1, the bit masks are defined with a 7 bit length field for which only 4 bits are useful (values 0-8). It may make sense to keep the 3 high order bits as "reserved" and set to zero, but either way it would be nice to understand the justification for whatever design decision is made. You go to some length to save space (e.g., a zero-length SABM means "all applications") but always include an octet for UDABM length, which I presume will be zero outside the lab in most cases. How much does an extra octet cost? If it's a lot, you could use the three high-order bits to represent the first three applications (RSVP-TE, SRTE, and LFA) and save yourself an octet until a fourth application appears. For that matter, how likely are you to get to 256 standardized applications under IS-IS? The fallback from application-specific advertisements to legacy advertisements is not entirely clear. It sounds like: - An application is to use the legacy advertisements if there is at least one application specific advertisement for that application with L=1, in which case *all* advertisements for that application must also have L=1. - An application is to use the application-specific advertisements if there is at least one application specific advertisement for that application with L=0, in which case *all* advertisements for that application must also have L=0, *and* that application is to ignore all legacy advertisements. In effect, use of legacy advertisements vs. app-specific advertisements is all-or-nothing. If that's the case, wouldn't a top-level TLV specifying a legacy mask for applications be more compact, less redundant, and further reduce the overall number/size of advertisements? Anyway, I'm out of my element, so feel free to ignore these comments if I'm way off the mark. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
