Note: This ballot was opened for revision 09 and is now closed.
Thank you to Watson Ladd for the SECDIR review.
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.
A note for the IESG: This is in the shepherd writeup: -- BEGIN -- (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. -- END -- As I said on another document on this week's docket, this is increasingly common. There are three questions being asked, but only one is being answered, and not the most important one at that. I'd really like it if this started getting caught someplace in the review process before IESG Evaluation. Or, if we don't actually care about the answer anymore, we should simplify or remove the question.
I'm balloting No Objection, but I really would like a response... 1: I'm assuming I'm just missing something obvious here, but Section 2.2 sayeth: "A received Prefix Source Router Address Sub-TLV that has an invalid length (i.e. not consistent with the prefix's address family) or a Router Address containing an invalid IPv4 or IPv6 address (dependent on address family of the associated prefix) MUST be considered invalid and ignored. " What is an "invalid IPv4" address here? If the length is 4, and the route address is 00000001 or 0xc0a80001, how do you know that that's not what I'm using? Again, I suspect that there is something obvious that I'm missing here... 2: This presumable has the side effect of increasing the size of the lsdb, possibly by a fairly large margin. It seems like it would have been nice to include an operational considerations section noting this, and, while you are at it, that this document will significantly aid in debugging....
Thanks for the update to the document and the discussion. Many points are resolved, remaining discussion summarized below. And by the way, I wondered the same as Ben regarding "In the ECMP case is there a way to correlate (order of appearance?) the listed router-IDs with the listed reachable addresses?" 1. I've cleared my discuss but as mentioned in earlier email, would still suggest an update to the abstract: "I would prefer to see a sentence in the abstract as well, since for some people the abstract is the only look they’ll take at the document and for them, the question of “what is it for?” isn’t answered. I don’t insist on this, but I recommend it. The additional sentence, if you choose to add it, could be something like “this information does not change route computation but is expected to be useful for network analysis and troubleshooting”." 2. Section 2.1: For intra-area prefix advertisements, the Prefix Source OSPF Router- ID Sub-TLV MUST be considered invalid and ignored if the OSPF Router ID field is not the same as Advertising Router field in the containing LSA. Similar validation cannot be reliably performed for inter-area and external prefix advertisements. As discussed with Ketan, I'm not sure if "ignored" is vague only to me, or if it might be to other readers of the spec. I leave it to the authors' discretion whether and how to elaborate. 4. Section 3: When an ABR generates inter-area prefix advertisements into its non- backbone areas corresponding to an inter-area prefix advertisement from the backbone area, the only way to determine the originating node information is based on the Prefix Source OSPF Router-ID and Prefix Source Router Address Sub-TLVs present in the inter-area prefix advertisement originated into the backbone area by an ABR from 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. What is it supposed to do if there are N contributing routes but it can only determine the information for M < N of the contributors? Ketan replied (my paraphrase) that in such a case partial information is sent. My further question was "OK. And it’s considered fine that that information for some, but not all, of the contributors is included? It seems potentially problematic that the route only includes partial information, but the consumer of the route has no way to know this. The other obvious choices would have been to omit the information altogether if only partial information was available, or to mark it as partial somehow."
Thank you for the work put into this document. Easy to see the added value for trouble shooting ! Please find below some non-blocking COMMENT points (but replies would be appreciated). I hope that this helps to improve the document, Regards, -éric Thanks for fixing Warren Kumari's question in the latest -10. -- Section 1 -- Is the reference to RFC 5329 correct ? I fail to see the link of TE with this document. Should it be made clearer that the OSPFv3 router ID is a 32-bit value hence cannot be used in an IPv6-only network ? "it does not necessarily represent a reachable address for the router" is slightly ambiguous. -- Section 2.2 -- Thanks for fixing Warren Kumari's question in the latest -10. -- Section 4 -- Suggestion: made the sentence "A rogue node that can inject prefix..." in a separate paragraph.
Thanks for this. Not a comment that requires addressing in the text, but considering section 5 on the operational impact: Is there an OSPF YANG model that is being updated to cover any additional configuration required to enable this functionality on a subset of prefixes, and/or are any changes to the operational YANG data model required to express the prefix source? Regards, Rob