[Lsr] Benjamin Kaduk's No Objection on draft-ietf-lsr-ospf-prefix-originator-10: (with COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Wed, 07 April 2021 06:08 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: lsr@ietf.org
Delivered-To: lsr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C29C3A414A; Tue, 6 Apr 2021 23:08:11 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org, lsr-chairs@ietf.org, lsr@ietf.org, Christian Hopps <chopps@chopps.org>, aretana.ietf@gmail.com, chopps@chopps.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.27.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <161777569111.16216.18390599109395230994@ietfa.amsl.com>
Date: Tue, 06 Apr 2021 23:08:11 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/g27Sgn_mONJl04PQebH_TkxEZSM>
Subject: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-lsr-ospf-prefix-originator-10: (with COMMENT)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 07 Apr 2021 06:08:12 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-lsr-ospf-prefix-originator-10: 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-lsr-ospf-prefix-originator/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In the ECMP case is there a way to correlate (order of appearance?) the listed router-IDs with the listed reachable addresses? Are there cases where you might choose to only advertise one but not the other of the prefix source Router-ID and address? Section 2.1 The parent TLV of a prefix advertisement MAY include more than one Prefix Source OSPF Router-ID sub-TLV, one corresponding to each of the Equal-Cost Multi-Path (ECMP) nodes that originated the given prefix. Is there any subtlety (or complexity, I guess) to how the advertising node knows about the other ECMP nodes advertising the same prefix? For example, would there be some transient discovery stage when first setting up the ECMP advertisement and only a subset of the ECMP nodes are actually listed in some advertisements that go out? Section 3 another non-backbone area. The ABR performs its prefix calculation to determine the set of nodes that contribute to the best prefix reachability. It MUST use the prefix originator information only from this set of nodes. The ABR MUST NOT include the Prefix Source OSPF Router-ID or the Prefix Source Router Address Sub-TLVs when it is unable to determine the information of the best originating node. I feel like this text might be hiding some subtlety as to the nature of determining the "nodes that contribute to the best prefix reachability" -- is this a concept that is well established in the core OSPF RFCs already (and thus doesn't need further explanation)? Section 4 We often consider privacy considerations as part of the security considerations section. Since routers are to some extent inherently "well known", they themselves may not have much privacy considerations but there may be something to say about propagating additional information about the internal structure of a given network. My understanding is that OSPF areas are all under a common administrative domain, so this mostly only seems relevant to the case of AS-external advertisement. One potential consideration would be if there is value in hiding that a set of prefixes are all advertised by the same router (the "linkability" of the prefixes, if you well). (Hmm, I guess this is somewhat related to the existing operational considerations discussion, but not entirely equivalent.) If we go into more detail on potential use cases, we might accordingly be able to go into more detail on the consequences of a rouge node injecting incorrect prefix source information. Section 5 protocol. Based on deployment design and requirements, a subset of prefixes may be identified for which the propagation of the originating node information across area boundaries is disabled at the ABRs. Per my previous comment, is this even more important at ASBRs than ABRs? NITS Section 1 The identification of the originating router for a prefix in OSPF varies by the type of the prefix and is currently not always possible. [...] (nit) my intuition is suggesting that the intent is that the "procedures for identification" vary and are not always possible; is that correct? (It seems to me that "the identification of the originating router varies by the type of prefix" would indicate that the actual identifier used for even the same advertising router will be different for the different type of prefix being advertised, which doesn't seem to be what the subsequent discussion describes.) address for the router. The IPv4/IPv6 Router Address as defined in [RFC3630] and [RFC5329] for OSPFv2 and OSPFv3 respectively provide an address to reach that router. (nit) Is it useful to indicate that these are TLVs, here? the core OSPF route computation functionality. They provide useful information for topology analysis and traffic engineering, especially on a controller when this information is advertised as an attribute of the prefixes via mechanisms such as Border Gateway Protocol Link- State (BGP-LS) [RFC7752] [I-D.ietf-idr-bgp-ls-segment-routing-ext]. The draft-ietf-idr-bgp-ls-segment-routing-ext reference seems rather unmotivated by the current prose leading up to it. Per John's Discuss some further exposition on the expected use case might help.
- [Lsr] Benjamin Kaduk's No Objection on draft-ietf… Benjamin Kaduk via Datatracker
- Re: [Lsr] Benjamin Kaduk's No Objection on draft-… Ketan Talaulikar (ketant)
- Re: [Lsr] Benjamin Kaduk's No Objection on draft-… Benjamin Kaduk
- Re: [Lsr] Benjamin Kaduk's No Objection on draft-… Ketan Talaulikar (ketant)