[prev in list] [next in list] [prev in thread] [next in thread]
List: ms-ospf
Subject: Re: [Lsr] Clarification on co-existance of dynamic flooding aware and not aware nodes
From: tony.li () tony ! li
Date: 2019-03-07 15:46:41
Message-ID: E1035EAC-D40D-4D2D-8E87-A04B37330DF9 () tony ! li
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> Well unless they know by design to always flood when peer is not dynamic flooding \
> capable.
That would be an extremely detailed piece of corner case coding. ;-)
>
> Yes today this seems to be consider transient and rather an exception (example \
> bootstraping or incremental deployment). My main point was should this be also a \
> valid and legal deployment model ?
Yes, certainly.
> The draft is actually on one hand says the above and on the other indicates that \
> dynamic flooding could be enabled and run only on part of the area:
> Flooding that is initiated by nodes that support Dynamic Flooding
> will remain within the flooding topology until it reaches a legacy
> node, which will resume legacy flooding.
I don't see that this is contradictory. Rather it is endorsing it.
> See TORs are one case .. but there are ideas to run dynamic protocols to the hosts \
> too. I have heard there was even a volunteer to write ISIS-lite to be used on hosts \
> :)
I would…. discourage that concept.
> However If you mandate that all of the members must be included in the flooding \
> graph the leaders may get a little bit busy from time to time.
The leader will be busy regardless. Recognizing that something is a legacy node and \
special-casing it is not a significant win. The cost comes in exploring the topology. \
Handling two link nodes is pretty much the same, regardless of whether it's a legacy \
node or not.
> Of course one option is to just split those into separate areas or levels, but \
> keeping it at single one could be considered attractive.
Splitting it would cause massive confusion, so I agree with keeping it to a single \
area.
Tony
[Attachment #5 (unknown)]
<html><head><meta http-equiv="Content-Type" content="text/html; \
charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote \
type="cite" class=""><div class="">Well unless they know by design to always flood \
when peer is not dynamic flooding capable. </div></blockquote><div><br \
class=""></div><div>That would be an extremely detailed piece of corner case coding. \
;-)</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" \
class=""><div class=""><br class=""></div><div class="">Yes today this seems to be \
consider transient and rather an exception (example bootstraping or incremental \
deployment). My main point was should this be also a valid and legal deployment model \
?</div></div></div></blockquote><br class=""></div><div><br class=""></div><div>Yes, \
certainly.</div><div><br class=""></div><div><br class=""></div><div><blockquote \
type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""> The draft \
is actually on one hand says the above and on the other indicates that dynamic \
flooding could be enabled and run only on part of the area:</div><div class=""><br \
class=""></div><pre class="gmail-newpage" style="font-size: 13.3333px; margin-top: \
0px; margin-bottom: 0px; break-before: page;"> Flooding that is initiated by nodes \
that support Dynamic Flooding will remain within the flooding topology until it \
reaches a legacy node, which will resume legacy \
flooding.</pre></div></div></blockquote><div><br class=""></div><div><br \
class=""></div><div>I don't see that this is contradictory. Rather it is \
endorsing it.</div><div><br class=""></div><br class=""><blockquote type="cite" \
class=""><div dir="ltr" class=""><div class="">See TORs are one case .. but there are \
ideas to run dynamic protocols to the hosts too. I have heard there was even a \
volunteer to write ISIS-lite to be used on hosts :)</div></div></blockquote><div><br \
class=""></div><div><br class=""></div><div>I would…. discourage that \
concept.</div><div><br class=""></div><br class=""><blockquote type="cite" \
class=""><div dir="ltr" class=""><div class="">However If you mandate that all of the \
members must be included in the flooding graph the leaders may get a little bit busy \
from time to time.</div></div></blockquote><div><br class=""></div><div><br \
class=""></div><div>The leader will be busy regardless. Recognizing that \
something is a legacy node and special-casing it is not a significant win. The cost \
comes in exploring the topology. Handling two link nodes is pretty much the \
same, regardless of whether it's a legacy node or not.</div><div><br \
class=""></div><br class=""><blockquote type="cite" class=""><div dir="ltr" \
class=""><div class="">Of course one option is to just split those into separate \
areas or levels, but keeping it at single one could be considered \
attractive.</div></div></blockquote><br class=""></div><div><br \
class=""></div><div>Splitting it would cause massive confusion, so I agree with \
keeping it to a single area.</div><div><br class=""></div><div>Tony</div><div><br \
class=""></div><br class=""></body></html>
_______________________________________________
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