[Rift] comments on draft-wei-rift-applicability-02

I already sent a separate e-mail to express my support for adopting this as a working group document. (I forgot to mention that I am not aware of any undisclosed IPR.)

Here are my comments on the draft itself:

In general, this is a very well written document. 

[Editorial] Figure 1 label: use "RIFT" instead of "Rift".

"And RIFT eliminates the disadvantages of Link-State or Distance Vector: [...] Automatic Neighbor Detection." Can you rephrase or elaborate? It seems to me that legacy LS and DV also do "automatically detect neighbors". Maybe you mean "Automatic Detection of Miscabled Neighbors"?

[Editorial] "There are a bunch of more advantages" -> "There are additional advantages"

[Editorial] "This observations hold not only in case of RIFT but in the generic case of dynamic routing on Clos variants with multiple planes and failures in bi-sectional bandwidth, especially on the leafs." -> not sure what this sentence adds; suggest removing it.

The section "Vertical Shortcuts" is somewhat ambiguous. On the one hand it says that vertical shortcuts are supported. But on the other hand, it gives some general indications that they are a bad idea without getting too much into the details. Let's be clear. Either we support them and spell out what the disadvantages are. Or we don't support them and just say so.

I am not sure what an "isomorphic equivalent of a Clos topology" is. How is it different from just a regular Clos topology?

[Editorial] "rely on 1:/+1 protection schemes" -> "rely on 1:1 or 1+1 protection schemes"

"RIFT is neither IP specific and hence any link addressing connecting internal device subnets is conceivable." -> Can you elaborate? RIFT as it is defined today is in fact IP specific; it currently does not support any address families beyond IPv4 and IPv6.

[General comment] The document mentions "minimize blast radius" several times. It would be good to add a sentence somewhere to explain why (i.e. what attribute of RIFT causes it to have a smaller blast radius than traditional LS and DV protocols?)

"RIFT inherently solves many difficult problems associated with" -> This is a bit too vague. Be more specific (just list the specific problems, as is done later in the section.)

"Many further operational and design points collected over many years of routing protocol deployments have been incorporated in RIFT" -> This is a bit too vague. Be more specific (just list the specific enhancements, as is done later in the section.)

I would add two topics:

(1) We should mention that leaf nodes cannot reliably ping spine nodes (because they only have a default route). This is something to be aware of for operations. (Maybe you already mentioned it somewhere and I missed it.)

(2) We should mention something about upgrading software on the network. Currently, it is quite likely that the major version of the schema will have to be bumped when there is any significant enhancement to the the protocol. The capability negotiation mechanism has not yet proven itself (all changes in the protocol so far have been major version bumps.)

— Bruno

> On Feb 3, 2020, at 2:22 PM, Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org> wrote:
> 
> Hi,
> 
> This starts a two-week adoption call for draft-wei-rift-applicability-02, ending on February 17.
> 
> Authors - please explicitly respond to the list if you're aware of any undisclosed IPRs.
> Others - if you're aware of any undisclosed IPRs, please respond to the list as well.
> 
> Thanks!
> Jeffrey
> 
> _______________________________________________
> RIFT mailing list
> RIFT@ietf.org
> https://www.ietf.org/mailman/listinfo/rift