[Lsr] AD Review of draft-ietf-ospf-lls-interface-id-05
Alvaro Retana <aretana.ietf@gmail.com> Fri, 07 September 2018 14:19 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 EEEDB130F1E; Fri, 7 Sep 2018 07:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 z_e-SoasO8EW; Fri, 7 Sep 2018 07:19:37 -0700 (PDT)
Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 D3BE3126CB6; Fri, 7 Sep 2018 07:19:33 -0700 (PDT)
Received: by mail-oi0-x22b.google.com with SMTP id l202-v6so27503202oig.7; Fri, 07 Sep 2018 07:19:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc; bh=2IsNwHzO9XwVEFs1aBvkvmFxmUn1v0u7FyZSTHas7e0=; b=CTcptMYQl2FgcK3NNvg/+orUfv4UTLvk7el7RpVf0ezEyVyF2teZq2GeA4KWXN7GMi Obg8IxulTdyOrLqqlW7Psp790FRAb3XwkUmx7xeLXGbMhjnCHu50Tddd9ZMuYLEBxW// 29L2ZSnRMCtF9MH102eBsaI3ymBc58WGkY20J7h7epYDbo/+CtVWYvMp1uMexyLrbKI3 rnNmueqmJLCOEHhYguKnEc7NkAaD9llSXYNCU5RdALoz+Rak24v7YJG9LpGifJ5c8xQ/ vb9J+7XL9WKmw05OCNq9tk0PULxSOyyU5CXUNumVNULYX3kL1fS79EZ0343fW8zs1WHU DVtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc; bh=2IsNwHzO9XwVEFs1aBvkvmFxmUn1v0u7FyZSTHas7e0=; b=OMikSY7m9ZIx8vwJsCZOytYf2Wl3pdpk1oBTjkGR3Ipj9DAbvYGJb0haS2lUIt/p63 Uk8FZ2LptAjhGDhVaLar9Ta0ySK6vh0CgMmyXWlSMYIbBuW8xsdN1Ix6xZT4auzIkG7g gEPg14oKlxsUrKlS4YT1CIhFHMuUL2uPnWT5kBTxkiZxXrFlT/n+RK+us6gzDjEjCESX KeHV9M+hPZBKwxVLQeq7u/gH5JRz+eZW1GZQgpBEJKRFFmJSvQiF7hvNKW273noPuy7v ZdvbJ1fKBOz4KpIvLY7aVlUxlNnIR/kx9Ec9i+1YeZYGWnpcxcxW79toVDdlBqBM6fpV KaxA==
X-Gm-Message-State: APzg51ANXVD/RbBOkyiPe3mzwZ/mQL7ajlxMxxoS5f3PE/kteKjdK6ph mEbrrLq83WFAoZtmtvhXd+CY6G2WvZDSJHIx3211qA==
X-Google-Smtp-Source: ANB0VdauIy7BwPl8GXUhx8jzJHocNVItJl1lF5Yg5A8ak7hbGjr7ZSUFI9PtrpOvg57w/gt5LuZP3BbiJSD5YZfMYV0=
X-Received: by 2002:aca:7c5:: with SMTP id 188-v6mr9070500oih.58.1536329972705; Fri, 07 Sep 2018 07:19:32 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 7 Sep 2018 10:19:31 -0400
From: Alvaro Retana <aretana.ietf@gmail.com>
X-Mailer: Airmail (506)
MIME-Version: 1.0
Date: Fri, 07 Sep 2018 10:19:31 -0400
Message-ID: <CAMMESswVF0p_tmJRSynqzHwx=v8FbPjQ9qX0=0ad=1x4LeQr4g@mail.gmail.com>
To: draft-ietf-ospf-lls-interface-id@ietf.org
Cc: "lsr@ietf.org" <lsr@ietf.org>, lsr-chairs@ietf.org, Yingzhen Qu <yingzhen.qu@huawei.com>
Content-Type: multipart/alternative; boundary="00000000000047ed38057548b2b0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/qkfi-1K3pOof6qgic4tD4Mij1Bc>
Subject: [Lsr] AD Review of draft-ietf-ospf-lls-interface-id-05
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, 07 Sep 2018 14:19:52 -0000
Dear authors: I just finished reading this document. I have put some comments inline (below). The main issue that I have with this document is that it is not clear where the Interface ID comes from. I think it is important to clearly specify that to achieve consistent and interoperable implementations. While I am not opposed to this work, the justification (in §2) is weak. The Abstract says that "in some cases it is useful to know the...Remote Interface ID". What are those cases? It would be nice if some applications were mentioned (in the Introduction, for example) -- maybe talk about the parallel link application more prominently. Do we need to specify how a router can disambiguate parallel links using this new extension? It may not be obvious to everyone...and there are no other drafts referring to this one (IOW, no other applications are documented). I'll wait for (at least) some discussion before starting the IETF Last Call. Thanks!! Alvaro. [The line numbers come from idnits.] ... 14 Abstract 16 Every OSPF interface is assigned an identifier, Interface ID, which 17 uniquely identifies the interface on the router. In some cases it is 18 useful to know the Interface ID assigned by the adjacent router on 19 its side of the adjacency (Remote Interface ID). [nit] Suggestion: "...useful to know the Remote Interface ID (the assigned Interface ID on the remote side of the adjacency)." ... 80 1. Introduction 82 Every OSPF interface is assigned an Interface ID, which uniquely 83 identifies the interface on the router. For example, some 84 implementations MAY be able to use the MIB-II IfIndex [RFC2863] as 85 the Interface ID. [major] The MAY is out of place because it is only stating a fact (as part of an example). s/MAY/may 87 Local/Remote Interface Identifiers MAY be flooded by OSPF [RFC2328] 88 as defined in [RFC4203]. From the perspective of the advertising [major] Again, just stating a fact. s/MAY/may 89 router, the Local Interface Identifier is a known value, however the 90 Remote Interface Identifier needs to be learnt before it can be 91 advertised. [RFC4203] suggests to use TE Link Local LSA [RFC3630] to 92 communicate the Local Interface Identifier to neighbors on the link. 93 Though such mechanism works, it has some drawbacks. 95 This draft proposes an extension to OSPF link-local signalling 96 [RFC5613] to advertise the Local Interface Identifier. 98 2. Interface ID Exchange using TE Opaque LSA [nit] This section might flow better as a sub-section of 1. 100 Usage of the Link Local TE Opaque LSA to propagate the Local 101 Interface Identifier to the neighbors on the link is described in 102 [RFC4203]. This mechanism has following problems: [nit] s/has following problems/has the following problems [nit] Why are the next 2 paragraphs indented? 104 LSAs can only be flooded over an existing adjacency that is in 105 Exchange state or greater. The adjacency state machine progresses 106 independently on each side of the adjacency and, as such, may 107 reach the Full state on one side before the TE Link Opaque LSA 108 arrives. The consequence is that link can be initially advertised 109 without the Remote Interface Identifier. Later, when the TE Link 110 Opaque LSA arrives, the link must be advertised again, this time 111 with the valid Remote Interface Identifier. Implementations may 112 choose to wait before advertising the link, but there is no 113 guarantee that the neighbor will ever advertise the TE Link Opaque 114 LSA with the Interface Identifier. In summary, the existing 115 mechanism does not guarantee that the Remote Interface Identifier 116 is known at the time the link is advertised. [nit] LLS is optional...so it is not guaranteed either. 118 The TE Opaque LSA is defined for MPLS Traffic Engineering, but the 119 knowledge of the Remote Interface Identifier is useful also for 120 cases where MPLS TE is not used. One example is the lack of a 121 valid 2-way connectivity check for parallel point-to-point links 122 between OSPF routers. 124 3. Interface ID Exchange using OSPF LLS 126 To address the problems described earlier and to allow the Interface 127 Identifier exchange to be part of the neighbor discovery process, we 128 propose to extend OSPF link-local signalling to advertise the Local 129 Interface Identifier in OSPF Hello packets. [major] Does having the "exchange to be part of the neighbor discovery process" mean that this TLV should only be attacked to Hellos? What should the router do if the TLV is received in a DD packet? 131 3.1. Local Interface Identifier TLV ... 150 Local Interface Identifier: The value of the local Interface 151 Identifier. [major] Where does the interface id come from? Will it always be 32 bits long? Is the assumption that it is the ifIndex? 153 Local Interface Identifier TLV signalling using LLS is applicable to 154 all OSPF interface types other than virtual links. 156 4. Backward Compatibility with RFC 4203 158 Implementations which support Local Interface ID signalling using LLS 159 MUST prefer the Local Interface ID value received through LLS over 160 the value received through Link Local TE Opaque LSA if both are 161 received from the same OSPF router. 163 Implementations which support Local Interface ID signalling via Link 164 Local TE Opaque LSA MAY continue to do so to ensure backward 165 compatibility. If they also support Local Interface ID signalling 166 using LLS as described herein, they SHOULD signal the same Local 167 Interface ID via both mechanisms. [major] The first sentence applies to supporting both mechanisms, right? IOW, it is meant if Local Interface ID signaling via Link Local TE Opaque LSA is supported *in addition to* the new LLS mechanism. Please be clear. [I'm asking because this document can't standardize the behavior if *only* the Local Interface ID signalling via Link Local TE Opaque LSA is supported.] [major] Using SHOULD doesn't guarantee backwards compatibility. Why isn't that a MUST? ... 176 5. IANA Considerations ... 182 Following values is allocated: [nit] s/values/value 184 o 18 - Local Interface Identifier TLV 186 6. Security Considerations 188 The security considerations for "OSPF Link-Local Signaling" [RFC5613] 189 also apply to the Local Interface Identifier TLV described herein. 190 The current usage of a neighbor's Local Interface Identifier is to 191 disambiguate parallel links between OSPF routers. Hence, 192 modification of the advertised Local Interface Identifier TLV may 193 result in the wrong neighbor interface identifier being advertised in 194 the OSPFv2 Extended Link LSA [RFC8379] and could prevent the link 195 from being used. If authentication is being used in the OSPF routing 196 domain [RFC5709], then the Cryptographic Authentication TLV [RFC5613] 197 SHOULD also be used to protect that contents of the Link-Local 198 Signaling (LLS) block. [minor] Is the reference to rfc8379 correct? [major] Why only SHOULD? IOW, if authentication is being used, why wouldn't an operator not want to also protect the LLS block? 200 Implementations must assure that malformed LLS TLVs and Sub-TLVs 201 permutations do not result in errors which cause hard OSPF failures. [major] What does this last paragraph mean? Any why is it not a MUST (instead of must). 203 7. Contributors [nit] Empty section.
- [Lsr] AD Review of draft-ietf-ospf-lls-interface-… Alvaro Retana