Re: [Lsr] Opsdir last call review of draft-ietf-ospf-te-link-attr-reuse-12

["Acee Lindem (acee)" <[e-mail]>]

Hi Scott, 

On 5/27/20, 11:17 AM, "Scott Bradner via Datatracker" <[e-mail]> wrote:

    Reviewer: Scott Bradner
    Review result: Not Ready

    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.

We had a lengthy discussion of the requirements in the working group and I'm not sure why you are asking what problem this is solving when it is clearly stated in the abstract and further elaborated in the "Introduction".  A side benefit is that we will not have to advertise the OSPF TE LSAs which would need to be correlated with the LSAs for applications. Perhaps that should also be stated. See one more inline below. 

    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?

Perhaps the LSR WG COULD have solved the problem with the existing RSVP-TE LSAs. However, this was not the consensus of the WG and the, IMO, the resultant encodings would have been sub-optimal. The resultant information would have been spread over more LSAs and you would have more chicken and egg situations with the correlation of LSAs. Now, with OSPFv3 Extended LSAs, all the required information is advertised in a single LSAs. 

Thanks,
Acee

    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