Re: [Lsr] AD Review of draft-ietf-ospf-te-link-attr-reuse-10

Peter Psenak <ppsenak@cisco.com> Fri, 15 May 2020 09:18 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 2338A3A07C3; Fri, 15 May 2020 02:18:30 -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 1roQMX0cU3X4; Fri, 15 May 2020 02:18:28 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10DD73A07CB; Fri, 15 May 2020 02:18:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5611; q=dns/txt; s=iport; t=1589534307; x=1590743907; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=rIkHqlzVvLofuqag0UhjDJIVqhDxlk+tZFm62pDK8q0=; b=V16fMttXklpBm45WzgdmWu9NOUXaZqRRz7nhPlbZQKBe7XIUjoXwH3Xo k5RYTy7usXXgUc8OjTGMt4782Fqrj7HwIe1ES+QNwn83TYwZpHj6GtrJq OhVtC/u+CrZIOKDORzbAYjsH1sU+mIG3cIuBXI3tAFs3tahFn1Pt7fzAM E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BEBABsXb5e/xbLJq1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUeDcCAShFGJAYdkJZtkCwEBAQ4vBAEBhEQCgjo4EwIDAQE?= =?us-ascii?q?LAQEFAQEBAgEFBG2FYoVyAQUdBg8BBUEQCw4KAgImAgJXBgEMCAEBgyKCfbB?= =?us-ascii?q?BdoEyhVGDe4FAgQ4qjFyBQT+BEAEnDIJdPodigmAEjimkXoJYgnOVSQYdgl2?= =?us-ascii?q?Ib4RbiDGEeJA8nXKBaSKBVjMaCBsVgyVPGA2QTBeOJz8DZwIGAQcBAQMJjzM?= =?us-ascii?q?BAQ?=
X-IronPort-AV: E=Sophos;i="5.73,394,1583193600"; d="scan'208";a="26226974"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 May 2020 09:18:23 +0000
Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id 04F9ILWO026349; Fri, 15 May 2020 09:18:22 GMT
To: Alvaro Retana <aretana.ietf@gmail.com>, "draft-ietf-ospf-te-link-attr-reuse@ietf.org" <draft-ietf-ospf-te-link-attr-reuse@ietf.org>
Cc: "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, Yingzhen Qu <yingzhen.qu@futurewei.com>
References: <CAMMESszKgJdgm+cbm4OeV9sG12Aic4T1GeT+6RkLYbxHwLWqLQ@mail.gmail.com> <6e1f3647-5c1f-4c31-27b7-82fe576d2c96@cisco.com> <CAMMESsxxKBL4hOAvzvTwxqUra_2wEig1ZPRgzKVJ82=q=jqVeg@mail.gmail.com>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <5f5e22bd-3253-62b7-44aa-1f8d675a706f@cisco.com>
Date: Fri, 15 May 2020 11:18:22 +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: <CAMMESsxxKBL4hOAvzvTwxqUra_2wEig1ZPRgzKVJ82=q=jqVeg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/6phdE3EAgLDBHUJq9Y7ZjzveZx8>
Subject: Re: [Lsr] AD Review of draft-ietf-ospf-te-link-attr-reuse-10
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: Fri, 15 May 2020 09:18:30 -0000

Hi Alvaro,

please see inline (##PP)

On 14/05/2020 19:26, Alvaro Retana wrote:
> On May 5, 2020 at 6:08:27 AM, Peter Psenak wrote:
> 
> 
> Peter:
> 
> Hi!
> 
> 
> ...
>> I tried to address all of them, some have been resolved during ISIS
>> draft review, in which case I took the same resolution for this draf.
>>
>> Please see inline, look for ##PP
> 
> 
> There's only one outstanding comment that I don't think was answered
> -- or at least I missed the meaning of the answer.  Please see below.
> 
> 
> I am also including some comments based on -11.  Except for the
> Normative language in §12.1, all the comments are basically
> nits/suggestions.
> 
> 
> I am starting the IETF Last Call for this document and
> draft-ietf-isis-te-app.  We can work on these remaining comments while
> we do that.
> 
> Thanks!
> 
> Alvaro.
> 
> 
> 
> ...
>> 434 6. Local Interface IPv6 Address Sub-TLV
>>
>> [major] The Local/Remote Interface IPv6 Address Sub-TLVs (rfc5329) can
>> include multiple addresses for a link. It seems to me that it could
>> be possible for different applications to use different addresses. If
>> that is the case, then it seems that these sub-TLVs should not be
>> application independent. Why are they not considered to be
>> application specific?
>>
>> [minor] Why are IPv4 addresses not considered?
>>
>> ##PP
>> IPv4 local address is part of the basic spec.
>> IPv6 remote address has been added in rfc8379.
> 
> For IPv4: what basic spec?
> 
> For IPv6: rfc8379 doesn’t seem to relate to the questions — am I
> missing something?

##PP
interface's IP address is part of the Router-LSA's link data - RFC2328, 
section A.4.2.

> 
> 
> 
> 
> 
> [Line numbers from idnits]
> 
> draft-ietf-ospf-te-link-attr-reuse-11
> 
> ...
> 168	4.1.  OSPFv2 Extended Link Opaque LSA and OSPFv3 E-Router-LSA
> ...
> 184	   3.  There is clear distinction between link attributes used by RSVP-
> 185	       TE and link attributes used by other OSPFv2 or OSPFv3
> 186	       applications.
> 
> [nit] s/is clear distinction/is a clear distinction

##PP
fixed
> 
> 
> ...
> 203	   TE link attributes used for RSVP-TE/GMPLS continue use OSPFv2 TE
> 204	   Opaque LSA [RFC3630] and OSPFv3 Intra-Area-TE-LSA [RFC5329].
> 
> [nit] s/continue use/continue to use

##PP
fixed
> 
> 
> ...
> 213	5.  Advertisement of Application Specific Values
> ...
> 252	      SABM Length: Standard Application Identifier Bit-Mask Length in
> 253	      octets.  The legal values are 0, 4 or 8.  If the Standard
> 254	      Application Bit-Mask is not present, the Standard Application Bit-
> 255	      Mask Length MUST be set to 0.
> 
> 257	      UDABM Length: User Defined Application Identifier Bit-Mask Length
> 258	      in octets.  The legal values are 0, 4 or 8.  If the User Defined
> 259	      Application Bit-Mask is not present, the User Defined Application
> 260	      Bit-Mask Length MUST be set to 0.
> 
> [minor] "The legal values are 0, 4 or 8."  Should the statement be
> Normative ("MUST be...")?  I know there is a sentence below about
> ignoring the sub-TLV if a different value is received -- IOW, just a
> suggestion.

##PP
Changed to MUST be

> 
> 
> ...
> 319	      - Unidirectional Link Dela [RFC7471]
> 
> 321	      - Min/Max Unidirectional Link Delay [RFC7471]
> 322	      - Unidirectional Delay Variation [RFC7471]
> 
> [nit] There seems to be a line missing...

##PP
sorry, what line is missing? There is a page break there.


> 
> 
> ...
> 532	12.1.  Use of Legacy RSVP-TE LSA Advertisements
> 
> 534	   Bit Identifiers for Standard Applications are defined in Section 5.
> 535	   All of the identifiers defined in this document are associated with
> 536	   applications which were already deployed in some networks prior to
> 537	   the writing of this document.  Therefore, such applications have been
> 538	   deployed using the RSVP-TE LSA advertisements.  The Standard
> 539	   Applications defined in this document MAY continue to use RSVP-TE LSA
> 540	   advertisements for a given link so long as at least one of the
> 541	   following conditions is true:
> 
> [major] s/MAY/may

##PP
ok, changed to may

> 
> 
> ...
> 651	12.3.4.  Use of Application Specific Advertisements for RSVP-TE
> 
> 653	   The extensions defined in this document support RSVP-TE as one of the
> 654	   supported applications.  It is however RECOMMENDED to advertise all
> 655	   link-attributes for RSVP-TE in the existing OSPFv2 TE Opaque LSA
> 656	   [RFC3630] and OSPFv3 Intra-Area-TE-LSA [RFC5329] to maintain backward
> 657	   compatibility.  RSVP-TE can eventually utilize the application
> 658	   specific advertisements for newly defined link attributes, which are
> 659	   defined as application specific.
> 
> [minor] "It is however RECOMMENDED to advertise all link-attributes
> for RSVP-TE in the existing..."  The application specific
> advertisements can be used and result in duplicate information.  The
> ISIS draft includes some sample steps to eliminate redundancy and get
> rid of the legacy advertisements -- can we add something similar here?

##PP
not really. We do NOT want to do what ISIS does in OSPF. ISIS has a 
problem with the amount of data they can advertise in the TLV. OSPF does 
not have that issue and as such we are NOT trying to get rid of the old 
advertisements for RSVP TE to avoid duplication.

thanks,
Peter

> 
>