This is an OPS-DIR review of OSPF Link Traffic Engineering Attribute Reuse (draft-ietf-ospf-te-link-attr-reuse)

This ID describes application-specific attribute advertisements for use in OSPF.

I found this ID hard to read and recommend that it be reviewed for readability.

I have a basic question about this proposal – the ID describes specific advertisements to be used when particular applications want to make use of specific link attributes and says that other applications should not make of the information in the advertisement without saying why such use would be a problem.  I can imagine some reasons but it seems to me that it would be good if this document just explained the problem it is trying to solve.

Some specific issues in the document

Page 6 – the text says “Standard Application Identifier Bit Mask: Optional set of bits, where each bit represents a single standard application.  Bits are defined in [I-D.ietf-isis-te-app].”  - it seems to me that this should be in an IANA registry for extensibility but it does not seem to be in the referenced ID but I could not actually tell

Page 6 – text says “The bits are repeated here for informational purpose”  maybe point to a IANA registry or say “current assignments”

Page 6 – text says “If the link attribute advertisement is limited to be used by a specific set of applications”  - maybe say “intended” rather than “limited” since I do not see a way to actually limit a future application from eavesdropping on the advertisement 

Page 7 – the text says “If the SABM or UDABM length is other than 0, 4, or 8, the ASLA sub-TLV MUST be ignored by the receiver.”  - it would seem to be useful operations-wise to say that an indication of an error should be recorded somewhere

Page 7 – a “User Defined Application Identifier” is introduced but never described – what uses it and what is it used for

Section 11 – I found this discussion of the relationship between the existence of a particular advertisement and the possible existence of an application to use that advertisement to be quite confusing – if the existence of a particular advertisement does not indicate that any application is listening why not just say that?

Section 12.1 – it would help to say what problem is trying to be solved – why is the use of RSVP-TE LSA advertisements a problem?

Section 12.3.3 – I could not tell if this section is saying that the application specific attribute advertisements could not be used if there is even a single legacy router present of if the presence of such a router means that the application specific attribute advertisements can be used but the old advertisements must also be used
Section 14 – it might help to say how new Sub-TLV types can be added to the registry