Re: [Lsr] Robert Wilton's No Objection on draft-ietf-ospf-te-link-attr-reuse-15: (with COMMENT)

[Peter Psenak <[e-mail]>]

Hi Rob,

On 23/06/2020 12:42, Robert Wilton via Datatracker wrote:
> Robert Wilton has entered the following ballot position for
> draft-ietf-ospf-te-link-attr-reuse-15: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reuse/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Discuss cleared.  Thank you for addressing my comments.
> 
> Two possible nits in section 5:
> 
>     If the same attribute is advertised in more than single ASLA sub-TLVs
>     with the application listed in the Application Bit Masks, the
>     application SHOULD use the first instance of advertisement and ignore
>     any subsequent advertisements of that attribute.
> 
> Propose changing "single" to "one".
> 
>     If link attributes are advertised associated with zero length
>     Application Identifier Bit Masks for both standard applications and
>     user defined applications, then any Standard Application and/or any
>     User Defined Application is permitted to use that set of link
>     attributes.
> 
> Propose changing "associated with" to "with associated" or just "with"

I have fixed these.

I'll wait for more changes before posting a new version.


thanks,
Peter
> 
> Thanks,
> Rob
> 
> Previous discuss comments:
> 
> I found parts of this document hard to understand, but I'm not familiar with
> the specifics of the protocols.
> 
> This discuss is in the vein of "I think that folks might struggle to implement
> this correctly/consistently".   In particular I had some questions/concerns
> about section 5 which, if clarified, would probably help this document.
> 
> In Section 5:
> 
>     The ASLA sub-TLV is an optional sub-TLV and can appear multiple times
>     in the OSPFv2 Extended Link TLV and OSPFv3 Router-Link TLV.  The ASLA
>     sub-TLV MUST be used for advertisement of the link attributes listed
>     at the end on this section if these are advertised inside OSPFv2
>     Extended Link TLV and OSPFv3 Router-Link TLV.  It has the following
>     format:
> 
> I think that it would be useful to clarify when/why the ASLA sub-TLV can be
> included multiple times.  I.e. when different applications want to control
> different link attributes.
> 
>     Standard Application Identifier Bits are defined/sent starting with
>     Bit 0.  Undefined bits which are transmitted MUST be transmitted as 0
>     and MUST be ignored on receipt.  Bits that are not transmitted MUST
>     be treated as if they are set to 0 on receipt.  Bits that are not
>     supported by an implementation MUST be ignored on receipt.
> 
> It was not clear to me what it means if the SABM (or UDABM) fields are entirely
> empty.  This paragraph states that they are treated as if they are 0, but
> sections 8 and 11 imply that if the field is omitted then it acts as if all
> applications are allowed.  Section 12.2 implies that if the field is omitted
> then it is as if all applications are allowed unless there there is another
> ASLA with the given application bit set, in which case it is treated as being a
> 0 again.  I think that this document would be helped if the specific behaviour
> was defined in section 5, retaining the justification/clarification in the
> subsequent sections.
> 
> It is also not entirely clear to me exactly how the bits are encoded on the
> wire.  My assumption is that if bit 0 is set, then this would sent the highest
> bit of the first byte.  E.g. 0x80?  Is that correct?  If not, then I think that
> the document needs more text, if so, then an example of the encoding may still
> aid readability.
> 
>     User Defined Application Identifier Bits have no relationship to
>     Standard Application Identifier Bits and are not managed by IANA or
>     any other standards body.  It is recommended that bits are used
>     starting with Bit 0 so as to minimize the number of octets required
>     to advertise all UDAs.
> 
> Doesn't this need more constraints to ensure easy interop (i.e. bits default to
> 0).  Otherwise, it would seem that anyone is allowed to put any value in this
> field that they like that could harm interop, or otherwise it might be tricky
> to compare a 4 byte UDABM to an 8 byte UDABM?
> 
>     This document defines the initial set of link attributes that MUST
>     use the ASLA sub-TLV if advertised in the OSPFv2 Extended Link TLV or
>     in the OSPFv3 Router-Link TLV.  Documents which define new link
>     attributes MUST state whether the new attributes support application
>     specific values and as such MUST be advertised in an ASLA sub-TLV.
>     The link attributes that MUST be advertised in ASLA sub-TLVs are:
> 
> I think that I get what this means, but I find the last two sentences slightly
> jarring given than the ASLA TLV is optional.  Perhaps predicate both of these
> constraints with "(if supproted)".  E.g., something like,
> 
>   Documents which define new link
>   attributes MUST state whether the new attributes support application
>   specific values and as such MUST be advertised in an ASLA sub-TLV (if
>   supported). The link attributes that MUST be advertised in ASLA sub-TLVs (if
>   supported) are:
> 
> 
> 
> 
>