Re: [Lsr] Warren Kumari's No Record on draft-ietf-lsr-ospf-prefix-originator-09: (with COMMENT)

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

Hi Warren,

Thanks for your review and please check inline below. Will look forward to your inputs on how best to incorporate them in the draft.

-----Original Message-----
From: Warren Kumari via Datatracker <[e-mail]> 
Sent: 31 March 2021 00:53
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Christian Hopps <[e-mail]>; [e-mail]; [e-mail]
Subject: Warren Kumari's No Record on draft-ietf-lsr-ospf-prefix-originator-09: (with COMMENT)

Warren Kumari has entered the following ballot position for
draft-ietf-lsr-ospf-prefix-originator-09: No Record

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

I'm balloting No Objection, but I really would like a response...

1: I'm assuming I'm just missing something obvious here, but Section 2.2 sayeth:
"A received Prefix Source Router Address Sub-TLV that has an invalid length (i.e. not consistent with the prefix's address family) or a Router Address containing an invalid IPv4 or IPv6 address (dependent on address family of the associated prefix) MUST be considered invalid and ignored. "

What is an "invalid IPv4" address here? If the length is 4, and the route address is 00000001 or 0xc0a80001, how do you know that that's not what I'm using? Again, I suspect that there is something obvious that I'm missing here...
[KT] I did some digging around and was not really able to find a good reference to what would be "invalid IPv4" in this context. 0x00000001 would be invalid but 0xc0a80001 would be valid. A multicast or ClassE or 0xffffffff would also be invalid. Basically, any address that cannot be used as Router Address (i.e. https://tools.ietf.org/html/rfc3630#section-2.4.1) would be invalid. Not sure if we should just remove the "invalid" part here or to attempt to go about specifying it.

2: This presumable has the side effect of increasing the size of the lsdb, possibly by a fairly large margin. It seems like it would have been nice to include an operational considerations section noting this, and, while you are at it, that this document will significantly aid in debugging....
[KT] Almost all of the protocol extensions do result in increase of the LSDB size. However, depending on the use-case, these extensions may be used for select prefixes (e.g. the leaf networks to which traffic/service flows are destined to). The Sec 3 does have the following text that touches upon mitigation for this scaling part:

   Implementations MAY support the selection of specific prefixes for
   which the originating node information needs to be included with
   their prefix advertisements.

   Implementations MAY provide control on ABRs to selectively disable
   the propagation of the originating node information across area
   boundaries.

[KT] Regarding the debugging part - I agree. Should we add an operational considerations section here or just include this aspect in the introduction within the following text?

   The primary use case for the extensions proposed in this document is
   to be able to identify the originator of a prefix in the network.  In
   cases where multiple prefixes are advertised by a given router, it is
   also useful to be able to associate all these prefixes with a single
   router even when prefixes are advertised outside of the area in which
   they originated.  It also helps to determine when the same prefix is
   being originated by multiple routers across areas.

Thanks,
Ketan