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

From: Alvaro Retana <[email-masked]>
Date: Sat, 13 Feb 2021 06:36:01 -0600

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

...
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

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.

[FYI] The second sub-tLV is not included in the BGP-LS extension draft
-- I will send a note to the authors.

...
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?

...
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?

[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.

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.

[minor] "...one corresponding to each of the Equal-Cost Multi-Path
(ECMP) nodes that originated the given prefix."   Is that the only
case?

[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?

...
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"?

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.

[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?

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).

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?)?

[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

[major] What should the receiver do if the information is not the same?

[major] "MAY support mechanisms to determine a reachable address"  I
don't understand how this action can be optional.

[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?

...
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

[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?

[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.

...
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).

...
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:

   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

...
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.

...
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.

...
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.

[End of Review]