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

Peter Psenak <> Tue, 23 June 2020 17:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2AF2B3A0874; Tue, 23 Jun 2020 10:13:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WXjaEKCXRm-C; Tue, 23 Jun 2020 10:13:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B1C563A0873; Tue, 23 Jun 2020 10:13:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5798; q=dns/txt; s=iport; t=1592932401; x=1594142001; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=o9DMCrLlUms9Rem/xIFu8a4Zvtap8kZIaIFjhdSzMv4=; b=aWvJx22Uit6DPcWr+KA+ufnhlOhG30oCMtmVHxvZKyPN5AlH/PL7MmDW M1GYYUqruBGydHJ9nCWfCjpk6VP1Dhy1tpp387XoNBu4jxnZTo26eDiXc qhyxKGVycEIekDp+o6DtvpROa/cN0yX3aKVEtdhYQrPsEgwg17nDGS899 Q=;
X-IronPort-AV: E=Sophos;i="5.75,272,1589241600"; d="scan'208";a="27316307"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Jun 2020 17:13:19 +0000
Received: from [] ( []) by (8.15.2/8.15.2) with ESMTP id 05NHDHnT032765; Tue, 23 Jun 2020 17:13:18 GMT
To: Robert Wilton <>, The IESG <>
Cc:,,, Acee Lindem <>, Yingzhen Qu <>,
References: <>
From: Peter Psenak <>
Message-ID: <>
Date: Tue, 23 Jun 2020 19:13:18 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Lsr] Robert Wilton's No Objection on draft-ietf-ospf-te-link-attr-reuse-15: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Jun 2020 17:13:23 -0000

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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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,
> 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: