[prev in list] [next in list] [prev in thread] [next in thread]
List: ms-ospf
Subject: Re: [Lsr] Warren Kumari's No Record on draft-ietf-lsr-ospf-prefix-originator-09: (with COMMENT)
From: Warren Kumari <warren () kumari ! net>
Date: 2021-03-31 20:32:07
Message-ID: CAHw9_i+U+beEhR1918iCdN3DYzbKpkZa-U0FyOzHYKZRo-7Nxg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
... 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 <warren@kumari.net> wrote:
>
>
> On Wed, Mar 31, 2021 at 2:46 AM Ketan Talaulikar (ketant) <
> ketant@cisco.com> 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 <noreply@ietf.org>
>> Sent: 31 March 2021 00:53
>> To: The IESG <iesg@ietf.org>
>> Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org; lsr-chairs@ietf.org;
>> lsr@ietf.org; Christian Hopps <chopps@chopps.org>; aretana.ietf@gmail.com;
>> chopps@chopps.org
>> 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
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="ltr"><div class="gmail_default" \
style="font-family:verdana,sans-serif">... 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...</div><div class="gmail_default" \
style="font-family:verdana,sans-serif">W</div></div><br><div class="gmail_quote"><div \
dir="ltr" class="gmail_attr">On Wed, Mar 31, 2021 at 4:29 PM Warren Kumari <<a \
href="mailto:warren@kumari.net">warren@kumari.net</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div \
style="font-family:verdana,sans-serif"><br></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 31, 2021 at 2:46 AM \
Ketan Talaulikar (ketant) <<a href="mailto:ketant@cisco.com" \
target="_blank">ketant@cisco.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">Hi Warren,<br> <br>
Thanks for your review and please check inline below. Will look forward to your \
inputs on how best to incorporate them in the draft.<br> <br>
-----Original Message-----<br>
From: Warren Kumari via Datatracker <<a href="mailto:noreply@ietf.org" \
target="_blank">noreply@ietf.org</a>> <br>
Sent: 31 March 2021 00:53<br>
To: The IESG <<a href="mailto:iesg@ietf.org" \
target="_blank">iesg@ietf.org</a>><br>
Cc: <a href="mailto:draft-ietf-lsr-ospf-prefix-originator@ietf.org" \
target="_blank">draft-ietf-lsr-ospf-prefix-originator@ietf.org</a>; <a \
href="mailto:lsr-chairs@ietf.org" target="_blank">lsr-chairs@ietf.org</a>; <a \
href="mailto:lsr@ietf.org" target="_blank">lsr@ietf.org</a>; Christian Hopps <<a \
href="mailto:chopps@chopps.org" target="_blank">chopps@chopps.org</a>>; <a \
href="mailto:aretana.ietf@gmail.com" target="_blank">aretana.ietf@gmail.com</a>; <a \
href="mailto:chopps@chopps.org" \
target="_blank">chopps@chopps.org</a><br>
Subject: Warren Kumari's No Record on draft-ietf-lsr-ospf-prefix-originator-09: \
(with COMMENT)<br> <br>
Warren Kumari has entered the following ballot position for<br>
draft-ietf-lsr-ospf-prefix-originator-09: No Record<br>
<br>
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.)<br> <br>
<br>
Please refer to <a href="https://www.ietf.org/iesg/statement/discuss-criteria.html" \
rel="noreferrer" target="_blank">https://www.ietf.org/iesg/statement/discuss-criteria.html</a><br>
for more information about IESG DISCUSS and COMMENT positions.<br>
<br>
<br>
The document, along with other ballot positions, can be found here:<br>
<a href="https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/" \
rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/</a><br>
<br>
<br>
<br>
----------------------------------------------------------------------<br>
COMMENT:<br>
----------------------------------------------------------------------<br>
<br>
I'm balloting No Objection, but I really would like a response...<br>
<br>
1: I'm assuming I'm just missing something obvious here, but Section 2.2 \
sayeth:<br> "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. "<br> <br>
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...<br> [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. \
<a href="https://tools.ietf.org/html/rfc3630#section-2.4.1" rel="noreferrer" \
target="_blank">https://tools.ietf.org/html/rfc3630#section-2.4.1</a>) would be \
invalid. Not sure if we should just remove the "invalid" part here or to \
attempt to go about specifying it.<br></blockquote><div><br></div><div><div \
style="font-family:verdana,sans-serif">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. <a \
href="https://tools.ietf.org/html/rfc3630#section-2.4.1" \
target="_blank">https://tools.ietf.org/html/rfc3630#section-2.4.1</a>) 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. </div><br></div><div> \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px \
solid rgb(204,204,204);padding-left:1ex"> <br>
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....<br> [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:<br> <br>
Implementations MAY support the selection of specific prefixes for<br>
which the originating node information needs to be included with<br>
their prefix advertisements.<br>
<br>
Implementations MAY provide control on ABRs to selectively disable<br>
the propagation of the originating node information across area<br>
boundaries.<br></blockquote><div><br></div><div><div \
style="font-family:verdana,sans-serif">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... </div><br></div><div> \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px \
solid rgb(204,204,204);padding-left:1ex"> <br>
[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?<br> <br>
The primary use case for the extensions proposed in this document is<br>
to be able to identify the originator of a prefix in the network. In<br>
cases where multiple prefixes are advertised by a given router, it is<br>
also useful to be able to associate all these prefixes with a single<br>
router even when prefixes are advertised outside of the area in which<br>
they originated. It also helps to determine when the same prefix is<br>
being originated by multiple routers across \
areas.<br></blockquote><div><br></div><div><div \
style="font-family:verdana,sans-serif">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 :-)</div></div><div> \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px \
solid rgb(204,204,204);padding-left:1ex"> <br>
Thanks,<br>
Ketan<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div \
dir="ltr">The computing scientist's main challenge is not to get confused by \
the<br>complexities of his own making. <br> -- E. W. Dijkstra</div></div></div> \
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" \
class="gmail_signature"><div dir="ltr">The computing scientist's main challenge is \
not to get confused by the<br>complexities of his own making. <br> -- E. W. \
Dijkstra</div></div></div>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic