Re: [Rift] AD Review of draft-ietf-rift-rift-12 (Part 1)

[Jordan Head <[e-mail]>]

Hi Alvaro,

Starting to work through these and the rest of your comments.

For this one, I'll remove any implicit (e.g. "_typical_ link-state protocols" - i.e. OSPF/IS-IS) or explicit (e.g. BGP) comparisons to a _specific_ protocol, but comparing things to generic (protocol agnostic) link-state or distance vector behavior might still be necessary.

Thanks
Jordan

On 2/8/23, 8:00 AM, "Alvaro Retana" <[e-mail] <mailto:[e-mail]>> wrote:


[External Email. Be cautious of content]




On August 15, 2022 at 8:00:08 AM, Jordan Head wrote:


Hi!




> 208 * automatic pruning and load balancing of topology flooding
> 209 exchanges over a sufficient subset of links which resolves the
> 210 traditional problem of link-state protocol struggling with densely
> 211 meshed graphs due to high volume of flooding traffic
> 212 (Section 4.2.3.9),
>
> [major] "...which resolves the traditional problem of link-state
> protocol struggling" Comparing with other protocols -- and the
> problem is not described anyway.
>
> Suggestion>
> * automatic pruning and load balancing of topology flooding
> exchanges over a sufficient subset of links (Section 4.2.3.9),
>
> jhead>> I think the problem is stated but could be a bit clearer.
> jhead>> Let's use your suggestion and simply add a clarifying statement as I
> jhead>> think it carries weight here.
> jhead>> "automatic pruning and load balancing of topology flooding exchanges
> jhead>> over a sufficient subset of links (Section 4.2.3.9). This resolves
> jhead>> scaling and convergence challenges caused by increased levels of
> jhead>> flooding when typical link-state protocols are used in densely meshed
> jhead>> graphs."


I want to get rid of any comparisons with "typical link-state
protocols". rift is not a typical link-state protocol, so its
specification should stand alone.


There are mentions of other protocols elsewhere, please take a look.


Thanks!


Alvaro.




Juniper Business Use Only