Hi Alvaro, Thanks for your detail review and comments. We've update the draft to address your comments and the version 8 posted below.
https://www.ietf.org/archive/id/draft-ietf-lsr-ospf-prefix-originator-08.txt Please check inline below for responses. Thanks, Ketan -----邮件原件----- 发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Alvaro Retana 发送时间: 2021年2月13日 20:36 收件人: draft-ietf-lsr-ospf-prefix-origina...@ietf.org 抄送: lsr-cha...@ietf.org; John Scudder; Christian Hopps; lsr@ietf.org 主题: [Lsr] AD Review of draft-ietf-lsr-ospf-prefix-originator-07 Dear authors: Thank you for working on this document. I have some comments (below) that I would like to see addressed before starting the IETF Last Call. Thanks! Alvaro. [Line numbers from idnits.] ... 70 1. Introduction ... 77 The identification of the originating router for a prefix in OSPF 78 varies by the type of the prefix and is currently not always 79 possible. For intra-area prefixes, the originating router is 80 identified by the advertising Router ID field of the area-scoped LSA 81 used for those prefix advertisements. However, for the inter-area 82 prefixes advertised by the Area Border Router (ABR), the advertising 83 Router ID field of their area-scoped LSAs is set to the ABR itself 84 and the information about the router originating the prefix 85 advertisement is lost in this process of prefix propagation across 86 areas. For Autonomous System (AS) external prefixes, the originating 87 router may be considered as the Autonomous System Border Router 88 (ASBR) and is identified by the advertising Router ID field of the 89 AS-scoped LSA used. However, the actual originating router for the 90 prefix may be a remote router outside the OSPF domain. Similarly, 91 when an ABR performs translation of Not-So-Stubby Area (NSSA) 92 [RFC3101] LSAs to AS-external LSAs, the information associated with 93 the NSSA ASBR (or the router outside the OSPF domain) is not conveyed 94 across the OSPF domain. [minor] s/advertising Router ID field/Advertising Router field/g [KT] Ack ... 102 The primary use case for the extensions proposed in this document is 103 to be able to identify the originator of the prefix in the network. 104 In cases where multiple prefixes are advertised by a given router, it 105 is also useful to be able to associate all these prefixes with a 106 single router even when prefixes are advertised outside of the area 107 in which they originated. It also helps to determine when the same 108 prefix is being originated by multiple routers across areas. [nit] s/of the prefix/of a prefix [KT] Ack 110 This document proposes extensions to the OSPF protocol for inclusion 111 of information associated with the router originating the prefix 112 along with the prefix advertisement. These extensions do not change 113 the core OSPF route computation functionality. They provide useful 114 information for topology analysis and traffic engineering, especially 115 on a controller when this information is advertised as an attribute 116 of the prefixes via mechanisms such as Border Gateway Protocol Link- 117 State (BGP-LS) [RFC7752]. [minor] "advertised...via...BGP-LS" Please add an Informative reference to draft-ietf-idr-bgp-ls-segment-routing-ext. [KT] Ack [FYI] The second sub-tLV is not included in the BGP-LS extension draft -- I will send a note to the authors. [KT] I am also co-author on that draft and will respond on that one. ... 127 2. Protocol Extensions 129 This document defines the Prefix Source Router-ID and the Prefix 130 Originator Sub-TLVs for inclusion of the Router ID and a reachable 131 address information for the router originating the prefix as a prefix 132 attribute. [major] I understand that the 2 sub-TLVs are optional and complement each other. Is there an expectation for both to be present? Should (SHOULD/MUST) both be present? What if they're not? [KT] There is no dependency between the two and hence either one or both of them may be advertised. ... 134 2.1. Prefix Source Router-ID Sub-TLV ... 161 o OSPF Router ID : the OSPF Router ID of the OSPF router that 162 originated the prefix advertisement in the OSPF domain. [major] Should there be a relationship between the router ID and the Advertising Router field in the LSA containing the prefix? What does it mean if the router ID doesn't match? [KT] The value MUST match for intra-area. So we can clarify this part and if it does not match then the sub-TLV can be ignored. For external (e.g. Type 5), we cannot determine because we don't know if it was not translated from Type 7 to Type 5 by an NSSA ABR. Same way we cannot figure this out reliably for inter-area prefix advertisements. Not sure if there is anything we can say other than intra-area. [major] Even though this document doesn't specify any OSPF-in-the-network action based on the new information, it does say that the information is useful for "topology analysis and traffic engineering", which means that the values may have an impact on route calculation (at a controller). I'm asking the questions about matching values because (if they don't) then it would be relatively easy for a rogue node to introduce non-congruent values which could have an effect on the controller's decision. [KT] We need to remember that we are talking about a prefix advertisement - a rogue would need to make a prefix advertisement first (which is considered for OSPF routing) and only then comes the part when this sub-TLV value is mismatched. Isn't the first part a bigger issue? 164 A prefix advertisement MAY include more than one Prefix Source 165 Router-ID sub-TLV, one corresponding to each of the Equal-Cost Multi- 166 Path (ECMP) nodes that originated the given prefix. [major] "prefix advertisement...more than one Prefix Source Router-ID sub-TLV" I guess you mean that the TLV (not just the advertisement) can include more than one of these sub0-TLVs, right? Please be specific. [KT] Ack [minor] "...one corresponding to each of the Equal-Cost Multi-Path (ECMP) nodes that originated the given prefix." Is that the only case? [KT] Yes. Am I missing any other possible scenario? [mayor] "MAY include more than one Prefix Source Router-ID sub-TLV" This statement seems to be appropriate for only a subset of prefixes: ones that can in fact have multiple originators -- for example, external routes. But it doesn't seem applicable to prefixes originated from a single router, for example a loopback address. What should a receiver of a single-origin prefix (one that should not have been originated by multiple origins) do if multiple sub-TLVs are received? [KT] It is also applicable for intra-area routes - i.e. anycast prefixes. Same goes for inter-area - ECMP. ... 172 2.2. Prefix Originator Sub-TLV ... 198 o Router Address: A reachable IPv4 or IPv6 router address for the 199 router that originated the IPv4 or IPv6 prefix advertisement. 200 Such an address would be semantically equivalent to what may be 201 advertised in the OSPFv2 Router Address TLV [RFC3630] or in the 202 OSPFv3 Router IPv6 Address TLV [RFC5329]. [minor] "semantically equivalent" The text in §3 says that the addresses are the same -- what is "semantically equivalent", and is that different from "the same"? [KT] There are implementation which allow different loopback (i.e. node) addresses being specified/used for the TE Router-ID. So semantically indicates have similar properties (e.g. cannot be anycast) but does not have to be the same address technically. 204 A prefix advertisement MAY include more than one Prefix Originator 205 sub-TLV, one corresponding to each of the Equal-Cost Multi-Path 206 (ECMP) nodes that originated the given prefix. [] Same questions as above. 208 A received Prefix Originator Sub-TLV that has an invalid length (not 209 4 or 16) or a Router Address containing an invalid IPv4 or IPv6 210 address (dependent on address family of the associated prefix) MUST 211 be considered invalid and ignored. Additionally, reception of such 212 Sub-TLV SHOULD be logged as an error (subject to rate-limiting). [major] "invalid length (not 4 or 16)" While it may be obvious to most, please clarify that 4 is the only valid length when using OSPFv2. [KT] Ack [minor] Should there be any type of correspondence between the prefix and the address-family used? IOW, should an IPv6 prefix be associated to an IPv6 Router Address? What if it's not? [KT] It should be consistent with the address family. I'll clarify in the text. 214 [RFC7794] provides similar functionality for the Intermediate System 215 to Intermediate System (IS-IS) protocol. [nit] This sentence is not needed, please take it out. Note that looking at rfc7794 may bring up other questions about the functionality, for example as related to the use of the flags. Also, the functionality in rfc7794 is equivalent to Prefix Source Router-ID Sub-TLV, and not to the Prefix Originator Sub-TLV (unless you're only explicitly thinking of the case where the N-flag is set). [KT] Sure. I will take it out. 217 3. Elements of Procedure ... 223 The OSPF Router ID of the Prefix Source Router-ID is set to the OSPF 224 Router ID of the node originating the prefix in the OSPF domain. [] I asked the question above about the relationship between the router ID and the Advertising Router. [major] Should this text use Normative language (MUST?)? [KT] Ack - please see further below. [major] What if the values don't match, in the cases that they have to? 226 If the originating node is advertising an OSPFv2 Router Address TLV 227 [RFC3630] or an OSPFv3 Router IPv6 Address TLV [RFC5329], then that 228 value is set in the Router Address field of the Prefix Originator 229 Sub-TLV. When the originating node is not advertising such an 230 address, implementations MAY support mechanisms to determine a 231 reachable address (e.g., advertised with the N-flag set [RFC7684] or 232 N-bit set [RFC8362] and either matching the OSPF Router ID or the 233 highest IP address) belonging to the originating node to set in the 234 Router Address field. [minor] "then that value is set" Which value? s/then that value is set/then the same address MUST be used [KT] I would use SHOULD - please see my previous comment about them being semantically equivalent but not necessary have to be the same (e.g. if an implementation provided a separate knob for it). [major] What should the receiver do if the information is not the same? [KT] There is no strict requirement for the two to be identical in Prefix Originator sub-TLV. [major] "MAY support mechanisms to determine a reachable address" I don't understand how this action can be optional. [KT] An implementation can choose not to advertise this sub-TLV - it is optional and hence we are not mandating. The address just has to be a reachable address of that node. [minor] "advertised with the N-flag set" Are you suggesting that if the N-flag is set then the Prefix Originator Sub-TLV doesn't need to be present? I know it was just an example, but it raises the question of: what if the N-flag is set and the Prefix Originator Sub-TLV is present, and the addresses don't match? [KT] This is about which address may be picked for advertisement in the Prefix Originator sub-TLV - picking a node address with N-flag set indicates that it is associated with that node and also that it is not anycast. ... 240 When an ABR generates inter-area prefix advertisements into its non- 241 backbone areas corresponding to an inter-area prefix advertisement 242 from the backbone area, the only way to determine the originating 243 node information is based on the Prefix Source Router-ID and Prefix 244 Originator Sub-TLVs present in the inter-area prefix advertisement 245 originated into the backbone area by an ABR for another non-backbone 246 area. The ABR performs its prefix calculation to determine the set 247 of nodes that contribute to the best prefix reachability. It MUST 248 use the prefix originator information only from this set of nodes. 249 The ABR MUST NOT include the Prefix Source Router-ID or the Prefix 250 Originator Sub-TLVs when it is unable to determine the information of 251 the best originating node. [nit] s/for another non-backbone area/from another non-backbone area [KT] ack [major] "The ABR performs its prefix calculation to determine the set of nodes that contribute to the best prefix reachability." How? Part of the specification seems to be missing, or is this a byproduct of running SPF? [KT] Yes - this is the SPF computation in base protocol. [major] What is "the best originating node"? I guess it is the originator of the best route -- but the text before talks about multiple originators potentially contributing to it. [KT] This is the base OSPF SPF computation. The multiple comes from ECMP. ... 257 Implementations MAY support the propagation of the originating node 258 information along with a redistributed prefix into the OSPF domain 259 from another routing domain. The details of such mechanisms are 260 outside the scope of this document. Such implementations MAY also 261 provide control on whether the Router Address in the Prefix 262 Originator Sub-TLV is set as the ABSR node address or as the address 263 of the actual node outside the OSPF domain that owns the prefix. [major] Because the details are out of scope: s/MAY/may (in both cases). [KT] ack ... 270 4. Security Considerations 272 Since this document extends the OSPFv2 Extended Prefix LSA, the 273 security considerations for [RFC7684] are applicable. Similarly, 274 since this document extends the OSPFv3 E-Intra-Area-Prefix-LSA, E- 275 Inter-Area-Prefix-LSA, E-AS-External LSA and E-NSSA-LSA, the security 276 considerations for [RFC8362] are applicable. [major] The Introduction mentioned somewhere that the new sub-TLVs are informational, and that there is no impact on route calculations. Please add something related to that. Also, rfc7684 already requests the same: [KT] Ack. OSPFv2 applications utilizing these OSPFv2 extensions must define the security considerations relating to those applications in the specifications corresponding to those applications. ... 278 5. IANA Considerations 280 This document requests IANA for the allocation of the codepoint from 281 the "OSPFv2 Extended Prefix TLV Sub-TLVs" registry under the "Open 282 Shortest Path First v2 (OSPFv2) Parameters" registry. [nit] s/codepoint/codepoints/g [KT] ack ... 317 7.1. Normative References ... 328 [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 329 RFC 3101, DOI 10.17487/RFC3101, January 2003, 330 <https://www.rfc-editor.org/info/rfc3101>. [minor] This reference can be Informative. [KT] ack ... 341 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 342 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 343 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 344 March 2016, <https://www.rfc-editor.org/info/rfc7794>. [minor] If kept, this reference should be Informative. [KT] I've removed it now. ... 355 7.2. Informative References 357 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 358 (TE) Extensions to OSPF Version 2", RFC 3630, 359 DOI 10.17487/RFC3630, September 2003, 360 <https://www.rfc-editor.org/info/rfc3630>. 362 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., 363 "Traffic Engineering Extensions to OSPF Version 3", 364 RFC 5329, DOI 10.17487/RFC5329, September 2008, 365 <https://www.rfc-editor.org/info/rfc5329>. [major] These references must be Normative. [KT] ack. [End of Review] _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
