Re: [Lsr] AD Review of draft-ietf-ospf-te-link-attr-reuse-10
Alvaro Retana <aretana.ietf@gmail.com> Thu, 14 May 2020 17:26 UTC
Return-Path: <aretana.ietf@gmail.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 76B713A0B66; Thu, 14 May 2020 10:26:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Ye0mGZI112lQ; Thu, 14 May 2020 10:26:58 -0700 (PDT)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6BDD3A0B84; Thu, 14 May 2020 10:26:57 -0700 (PDT)
Received: by mail-wm1-x335.google.com with SMTP id u16so33800384wmc.5; Thu, 14 May 2020 10:26:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=LBeVhbdQkoMf+zSYzRgv1lVzXT9mcvPMa0fyuABVS+o=; b=rguTVgF1qqs/rLkUjGoQFsfmpznxVUFq/9KbSNhutYuUjKF9U2cDBsUp1WCmrfJEDR JYUw7k2QSdkos7hTmMENLLf24BXC8R3zY6X2eRp0qscCIumQXZOGsczoW0FCcD+BMm87 BTjmXb6GyZRabD51VoQDajlbNYa9em/VtuJNYcRV46nYxGr09QLhe0ayd7Q3ZL8isOZJ EmZvrC2irC+BsdNJcnOQ6ObvSHjxBWLvFIgCNxO5npK9yiFi+wB7U8mG3cqxB28D6bFV xguGilrmta4ZyRwgZA8iVRImwpjb8Wni6IgHi8RhEaCoEarBrGZIkBhcOOlu+NFU0NsX QY0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=LBeVhbdQkoMf+zSYzRgv1lVzXT9mcvPMa0fyuABVS+o=; b=hHqjgf3A7UHNjlpIXwXIIZ5+TeviSvSiLIOCqFz4lKTAmub4DXEHCuNJqGeOEDe2QI BPvxF8A9cARv0Ro8AvDSMhjzrIMrSNnLg0Sa6oHJQIA+0YuO7+bmd4R/8mmogHkxlDl8 6wHNqfdUotTfJZitosYuvyQXFGxuvUI7MySdt0bsTzdAdsB+tq3YK6Zj0hPA2626tM8x 4Rli/+PmfDI+ZgX8kUrTTCD2H6yw5yudHk6znia8lk2EKVchQXb4fA1MOarjDDbyKVlk oroeClFg8jLXtcWQPWfTnFg6w4b2YhWiIB3f4VKu9J5ZsHPgaNAaipnJjK6kHL6DCFOf dbfA==
X-Gm-Message-State: AGi0PuavhlSoqn9zWUVARNtT+/pxbF6Y99qIhDv0FLT2xfjv4OC1PQ+0 D52etyY/anTldcGEmKEpisE4Eq3DcCsH5OHavMv4+ZH8
X-Google-Smtp-Source: APiQypKLqebw7q3LPwniMRWLrmmhMl8qEHMFZvQU6rNLXGXrYKlXloHPfKH5w3Lcpi7zlpiLjOvis8/TpPrJgjqUBWQ=
X-Received: by 2002:a7b:c207:: with SMTP id x7mr26856542wmi.79.1589477215930; Thu, 14 May 2020 10:26:55 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 14 May 2020 10:26:54 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <6e1f3647-5c1f-4c31-27b7-82fe576d2c96@cisco.com>
References: <CAMMESszKgJdgm+cbm4OeV9sG12Aic4T1GeT+6RkLYbxHwLWqLQ@mail.gmail.com> <6e1f3647-5c1f-4c31-27b7-82fe576d2c96@cisco.com>
MIME-Version: 1.0
Date: Thu, 14 May 2020 10:26:54 -0700
Message-ID: <CAMMESsxxKBL4hOAvzvTwxqUra_2wEig1ZPRgzKVJ82=q=jqVeg@mail.gmail.com>
To: Peter Psenak <ppsenak@cisco.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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Iw0yGVdUtl4a9-pmlrVMJCQ6xoY>
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: Thu, 14 May 2020 17:27:00 -0000
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? [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 ... 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 ... 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. ... 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... ... 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 ... 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?
- [Lsr] AD Review of draft-ietf-ospf-te-link-attr-r… Alvaro Retana
- Re: [Lsr] AD Review of draft-ietf-ospf-te-link-at… Peter Psenak
- Re: [Lsr] AD Review of draft-ietf-ospf-te-link-at… Peter Psenak
- Re: [Lsr] AD Review of draft-ietf-ospf-te-link-at… Alvaro Retana
- Re: [Lsr] AD Review of draft-ietf-ospf-te-link-at… Peter Psenak