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

Peter Psenak <ppsenak@cisco.com> Tue, 23 June 2020 17:13 UTC

Return-Path: <ppsenak@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF2B3A0874; Tue, 23 Jun 2020 10:13:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXjaEKCXRm-C; Tue, 23 Jun 2020 10:13:21 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C563A0873; Tue, 23 Jun 2020 10:13:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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 aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Jun 2020 17:13:19 +0000
Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id 05NHDHnT032765; Tue, 23 Jun 2020 17:13:18 GMT
To: Robert Wilton <rwilton@cisco.com>, The IESG <iesg@ietf.org>
Cc: draft-ietf-ospf-te-link-attr-reuse@ietf.org, lsr-chairs@ietf.org, lsr@ietf.org, Acee Lindem <acee@cisco.com>, Yingzhen Qu <yingzhen.qu@futurewei.com>, aretana.ietf@gmail.com
References: <159290897935.30181.13224873437776050484@ietfa.amsl.com>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <9e96222b-5c98-1bb3-211d-b33bc7cb7c2d@cisco.com>
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: <159290897935.30181.13224873437776050484@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/4_A2nwKqyCE7rf4DOIC2qOIgxIo>
Subject: Re: [Lsr] Robert Wilton's No Objection on draft-ietf-ospf-te-link-attr-reuse-15: (with COMMENT)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=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 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:
> 
> 
> 
> 
>