Re: [Lsr] AD Review of draft-ietf-lsr-ospf-prefix-originator-07

["Ketan Talaulikar (ketant)" <[e-mail]>]

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


-----邮件原件-----
发件人: [e-mail] [mailto:[e-mail]] 代表 Alvaro Retana
发送时间: 2021年2月13日 20:36
收件人: [e-mail]
抄送: [e-mail]; John Scudder; Christian Hopps; [e-mail]
主题: [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
[e-mail]
https://www.ietf.org/mailman/listinfo/lsr