Hi John,
Thanks for your review and comments. Please check inline below. -----Original Message----- From: John Scudder via Datatracker <nore...@ietf.org> Sent: 07 April 2021 02:36 To: The IESG <i...@ietf.org> Cc: draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Christian Hopps <cho...@chopps.org>; aretana.i...@gmail.com; cho...@chopps.org Subject: John Scudder's Discuss on draft-ietf-lsr-ospf-prefix-originator-10: (with DISCUSS and COMMENT) John Scudder has entered the following ballot position for draft-ietf-lsr-ospf-prefix-originator-10: Discuss 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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Although the document is largely clear and well-written (thanks for that), I was left with one burning question: what are these sub-TLVs *for*? There’s no specification for what the router is supposed to do with them, only how to originate them. The only clue I get is buried down in Section 5: The identification of the node that is originating a specific prefix in the network may aid in debugging of issues related to prefix reachability within an OSPF network. If their purpose is to act as debugging aids, I think you should at least say so briefly in the abstract and introduction. If they have some purpose beyond that, it’s missing from the doc. [KT] I see that Aijun has responded on this one and we can use that thread for further discussion on this point. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1. Section 2: This document defines the Prefix Source OSPF Router-ID and the Prefix Source Router Address Sub-TLVs for inclusion of the Router ID and a reachable address information for the router originating the prefix as a prefix attribute. I found this sentence difficult to read. I think removing the redundant word “information” would help a little. Beyond that, it might help to break it into a couple sentences, as in: “This document defines the Prefix Source OSPF Router-ID and the Prefix Source Router Address Sub-TLVs. They are used, respectively, to include the Router ID of, and a reachable address of, the router that originates the prefix as a prefix attribute.” [KT] Will update with your text proposal. Thanks. 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. What does it mean for the sub-TLV to be ignored? Since you haven’t specified any processing of the Sub-TLVs, there’s seemingly no ignoring to be done locally [KT] The ignoring part is for the user of the information. Since the days of RSVP-TE (RFC3630), we've had OSPF flooding information about TE topology opaquely (i.e. not using for OSPF computations) while it is being used by for computation of RSVP-TE tunnel paths/LSPs. The same applies here. — so does this mean the sub-TLV isn’t even supposed to be stored? Flooded? [KT] Per OSPF protocol, we have to store it and flood it - since the information is not "malformed" or "not parsable". 3. Section 3: If the originating node is advertising an OSPFv2 Router Address TLV [RFC3630] or an OSPFv3 Router IPv6 Address TLV [RFC5329], then the same address MUST be used in the Router Address field of the Prefix Source Router Address Sub-TLV. When the originating node is not advertising such an address, implementations can determine a unique and reachable address (i.e., advertised with the N-flag set [RFC7684] or N-bit set [RFC8362]) belonging to the originating node to set in the Router Address field. As I read this, if there’s no Router Address TLV, then the implementation has to use something it advertised with the N-flag set. I infer this because you used “i.e.” (which essentially means “in other words”). If you do mean the parenthetical to be limiting, why not make it a MUST? If you don’t mean it to be limiting, shouldn’t it be “e.g.” or better still, “for example”? (Looking at RFC 7684 it doesn’t seem as though it should be limiting, because RFC 7684 § 2.1 says the N-flag is optional even for local routes.) [KT] It was not meant to be normative/limiting. Will update to use "for example". 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? [KT] Consider that there are N contributing routes at the ABR and B of them were contributing to the "best reachability" (where N >= B). Out of those B routes, if only M advertisements are including the prefix origin info (where B >= M). Then the ABR does a single inter-area prefix advertisement that will include the M prefix origin info. This is conveyed by the two sentences in bold in the text above. Also, should “node” be “nodes” (last word of last sentence)? [KT] Ack 5. Section 5, nit: Consideration should be given to the operation impact of the increase s/operation/operational/ [KT] Ack Thanks, Ketan
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
