Hi John, Using this latest thread to respond since it captures all the open comments.
Please check inline below and we'll update the draft once we reach a conclusion on this. -----Original Message----- From: Aijun Wang <[email protected]> Sent: 08 April 2021 07:41 To: 'John Scudder' <[email protected]>; 'The IESG' <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Subject: RE: [Lsr] John Scudder's No Objection on draft-ietf-lsr-ospf-prefix-originator-11: (with COMMENT) Hi, John: -----Original Message----- From: [email protected] <[email protected]> On Behalf Of John Scudder via Datatracker Sent: Thursday, April 8, 2021 8:38 AM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Subject: [Lsr] John Scudder's No Objection on draft-ietf-lsr-ospf-prefix-originator-11: (with COMMENT) John Scudder has entered the following ballot position for draft-ietf-lsr-ospf-prefix-originator-11: 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: ---------------------------------------------------------------------- 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”." [KT] Ack - will update the abstract in the next version and add : " These extensions do not change the core OSPF route computation functionality but provide useful information for network analysis, troubleshooting and use-case like traffic engineering (especially on a controller or an application external to OSPF)." 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. [KT] "Ignore" is indeed really the basic option available in OSPF when receiving semantically invalid information within a TLV in an LSA. We cannot discard or change it and neither can we ignore/discard the entire LSA on this account. We normally recommend raising error logs, however in this case since OSPF itself is not processing the information, it seemed better to leave it to the actual user of the information. 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." [KT] There are two scenarios (that come to mind) where this may happen (a) when the originating node does not support the extensions of draft and (b) when the information is being supressed either at the originating node or an ABR based on some policy (for say abstraction). In case of (a) - the operator has to be aware of this and figure out how to handle the use-case in such deployments. In case of (b), it was the specific operator action that causes this scenario and we assume that they would have figured out how to handle the use-case. So it really depends on the use-case and here there can be multiple use-cases. Based on these two scenarios, one can see why omitting entirely would be a problem. We could have signalled that information is partial, but it is was not considered given the scenarios above and the possibly myriad use-cases. That said, if it is really required then a new TLV can be introduced in the future to indicate this. [WAJ] My understanding is that such advertisement is dynamic. Once there is new originator for this prefix, the ABR should update the information associated with this prefix. It seems there is no way for the ABR to judge when it have collected all of these information or not? [KT] I believe John's comment was different from Ben's query/comment about the "discovery" or "transient" phase for ECMP paths. Thanks, Ketan _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
