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

[Warren Kumari <[e-mail]>]

... and apparently I'd lied to you, both in the Ballot itself, and also in
this thread. I'd said that I had balloted NoObjection, but apparently  I'd
hit No Comment instead. I'm fixing it now; mentioning just for the record...
W

On Wed, Mar 31, 2021 at 4:29 PM Warren Kumari <[e-mail]> wrote:

>
>
> On Wed, Mar 31, 2021 at 2:46 AM Ketan Talaulikar (ketant) <
> [e-mail]> wrote:
>
>> 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.
>>
>
> I'd suggest just removing it -- trying to specify what "invalid" means in
> this case will likely lead to madness. If you really want to keep it, I'd
> suggest just saying something along the lines of "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 any address
> that cannot be used as Router Address (i.e.
> https://tools.ietf.org/html/rfc3630#section-2.4.1) MUST be considered
> invalid and ignored." If it were me, I'd just delete the last bit, and back
> away slowly.... Actually, I'm not even sure that ignoring it *is* the right
> answer. If I look through $whatever and see a Router Address of 0xffffffff,
> it is "meaningless", but possibly it is evidence that something, somewhere,
> is horribly borked, and I should probably go investigate.
>
>
>
>>
>> 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.
>>
>
> Noted (and that all extensions do increase the LSDB size) -- this
> extension is *possibly* different in that it seems that it has larger
> scope. Whatever the case, a simple "This may provide information hiding,
> and also limit the increase of the LSDB size" or "Consideration should be
> given to the operational impact of the increase in LSDB size" somewhere
> would make me a happy bunny. Note that my ballot is a NoObjection
> (non-blocking), and I will not be overly sad if you ignore this...
>
>
>
>>
>> [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.
>>
>
> Either. I'd personally like an operational considerations section (hey,
> I'm an OpsAD, I *always* want an Operational Consideration section :-)),
> but I'm also fine with this just being stuffed elsewhere in the document.
> If you**do** add an operational consideration section it would be a perfect
> place for the above comment :-)
>
>
>>
>> Thanks,
>> Ketan
>>
>>
>
> --
> The computing scientist’s main challenge is not to get confused by the
> complexities of his own making.
>   -- E. W. Dijkstra
>


-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra