[Rift] Shepherd review of draft-ietf-rift-applicability

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi,

As part of the shepherd review, I have the following questions/comments. Some are minor editorial nits.

   Node TIE should NOT be confused with a North
   TIE since "node" defines the type of TIE rather than its direction.

Should this be the following?

   N-TIE should not be confused with a Node TIE - the "N-" denotes
   "North-" not "Node-".

For the following:

   This is an acronym for a "Prefix Topology Information Element" and it
   contains all prefixes directly attached to this node in case of a
   North TIE and in case of South TIE the necessary default routes the
   node advertises southbound.

Should "default routes" be "default and disaggregated routes"?

   ... RIFT can employ to ultimately
   calculate routes of which Dijkstra algorithm is a possible one.

The above does not read well to me. Is some wording missing?

   Clos [CLOS] topologies (called commonly a fat tree/network in modern
   IP fabric considerations as homonym to the original definition of the
   term Fat Tree [FATTREE])have gained prominence in today's networking,

Missing a " " in the last line.

   Today's current routing protocols were geared towards a network with
   an irregular topology with isotropic properties, and low degree of
   connectivity.

"Today's current ... were" sounds strange. How about "Other routing protocols are"?

   *  They tend to need extensive configuration or provisioning during
      bring up and re-dimensioning.

"re-dimensioning" lacks context. What does it mean? "reconfiguration"?

   The N-TIEs contain a link-state topology description of lower levels
   and S-TIEs carry simply default routes for the lower levels.

"default and disaggregated routes"?

   RIFT also eliminates major disadvantages of link-state and distance-
   vector with:
   *  Reduced and balanced flooding
   *  Automatic neighbor detection

Does link-state routing not have auto neighbor detection?

   *  Can utilize all paths through fabric without looping
   ...
   *  Supports non-equal cost multipath ...

Aren't the above two the same/related?

4.2.1.  Horizontal Links

   RIFT is not limited to pure Clos divided into PoD and multi-planes
   but supports horizontal (East-West) links below the top of fabric
   level.  Those links are used only for last resort northbound routes
   when a spine loses all its northbound links or cannot compute a
   default route through them.

   A possible configuration is a "ring" of horizontal links at a level.
   In presence of such a "ring" in any level (except Top of Fabric (ToF)
   level) neither North SPF (N-SPF) nor South SPF (S-SPF) will provide a
   "ring-based protection" scheme since such a computation would have to
   deal necessarily with breaking of "loops" in Dijkstra sense; an
   application for which RIFT is not intended.

   A full-mesh connectivity between nodes on the same level can be
   employed and that allows N-SPF to provide for any node loosing all
   its northbound adjacencies (as long as any of the other nodes in the
   level are northbound connected) to still participate in northbound
   forwarding.

I struggled a bit with the second paragraph above. Is the following understanding of all three paragraphs correct?

1. east-west links below TOF provide last resort northbound routes (1st paragraph) - BTW should it be "northbound forwarding" instead of "northbound route"?
2. a full mesh east-west links between nodes at the same level provides last resort northbound forwarding for all the nodes (3rd paragraph) (extending on #1)
3. however, a ring of horizontal links does not provide ring-based protection (2nd paragraph)

If so, it may be better to move the 3rd paragraph up, and change the previous 2nd paragraph to the following:

   Note that a "ring" of horizontal links at any level below ToF does
   not provide a "ring-based protection" scheme since the SPF computation
   would have to deal necessarily with breaking of "loops" in Dijkstra sense - an
   application for which RIFT is not intended.

In the following:

   *  Southbound, RIFT operates as a distance-vector protocol, whereby
      the control packets are flooded only one-hop, interpreted, and the
      consequence of that computation is what gets flooded one more hop
      south.  In the most common use-cases, a ToF node can reach most of
      the prefixes in the fabric.  If that is the case, the ToF node
      advertises the fabric default and disaggregates the prefixes that
      it cannot reach.

Perhaps changing "consequence" to "result"?
In the last sentence, perhaps say "negatively disaggregates" (if I understand it correctly)?

      In the general case, what gets advertised south is in more
      details:

Perhaps change to "... what get advertised south are:"? (remove the "in more details")

4.2.3.  Generalizing to any Directed Acyclic Graph

   RIFT is an anisotropic routing protocol, meaning that it has a sense
   of direction (northbound, southbound, east-west) and that it operates
   differently depending on the direction.
   ...
   A Directed Acyclic Graph (DAG) provides a sense of north (the
   direction of the DAG) and of south (the reverse), which can be used
   to apply RIFT.  For the purpose of RIFT, an edge in the DAG that has
   only incoming vertices is a ToF node.

I initially struggled a bit with the second paragraph above. Connecting to the section title, perhaps the following wording is better:

   Since a Directed Acyclic Graph (DAG) provides a sense of north (the
   direction of the DAG) and of south (the reverse), it can be used to
   apply RIFT - an edge in the DAG that has only incoming vertices is a
   ToF node.

In the following:

   RIFT is not strictly limited to Clos topologies.  The protocol only
   requires a sense of "compass rose directionality" either achieved
   through configuration or derivation of levels.  So, conceptually,
   shortcuts between levels could be included.  Figure 2 depicts an
   example of a shortcut between levels.  In this example, sub-optimal
   routing will occur when traffic is sent from L0 to L1 via S0's
   default route and back down through A0 or A1.  In order to ensure
   that, only default routes from A0 or A1 are used, all leaves would be
   required to install each others routes.

Should "ensure" be "avoid"?

   Commercial edifices are often cabled in topologies that are either
   Clos or its isomorphic equivalents.  The Clos can grow rather high
   with many floors.

If I understand it correctly, better change "floors" to "levels". We're talking about commercial buildings here, so "floor" may be confused as "building floors", which I don't think it is referring to.

   RIFT is neither IP specific and hence any link addressing
   connecting internal device subnets is conceivable.

s/neither/not/

   *  RIFT negotiates automatically BFD per link allowing this way for
      IP and micro-BFD [RFC7130] to replace Link Aggregation Groups
      (LAGs) which do hide bandwidth imbalances in case of constituent
      failures.

I find it a bit hard to parse the above. Perhaps break it down a bit?

   Without disaggregation mechanism, when linkSL6 fails, the packet from
   leaf121 to prefix122 will probably go up through linkSL5 to linkTS3
   then go down through linkTS4 to linkSL8 to Leaf122 or go up through
   linkSL5 to linkTS6 then go down through linkTS4 and linkSL8 to
   Leaf122 based on pure default route.  It's the case of suboptimal
   routing or bow-tieing.

I think it should be changed to the following:

   Without disaggregation mechanism, when linkSL6 fails, the packet from
   leaf121 to prefix122 *may* go up through linkSL5 to linkTS3
   then go down through linkTS4 to linkSL8 to Leaf122 or go up through
   linkSL5 to linkTS6 then go down through *linkTS8* and linkSL8 to
   Leaf122 based on pure default route.  *This is* the case of suboptimal
   routing or bow-tieing.

The '*' mark the changes. The second change is to fix a mistake (I think).

   It's the case of black-holing.

s/It's/This is/

   ... that is, on the one
   hand, the SystemID of the node that must be unique in the RIFT
   network, and on the other hand the level of the node in the Fat Tree,
   which determines which peers are northwards "parents" and which are
   southwards "children".

Perhaps change to the following:

   ... including SystemID of the node that must be unique in the RIFT
   network and the level of the node in the Fat Tree,
   which determines which peers are northwards "parents" and which are
   southwards "children".

The "but" wording in the following is a bit strange:

   ... it is
   recommended to configure the level of all the nodes but those that
   are forced as leaves to avoid an undesirable interaction between ZTP
   and the manual configuration.

Do you mean "those that are forced as leaves" do not need configuration? But then how are they "forced as leaves" w/o configuration?

   A RIFT node may also be configured to confine it to the leaf role
   with the LEAF_ONLY flag.  A leaf node can also be configured to
   support leaf-2-leaf procedures with the LEAF_2_LEAF flag.  In either
   case the node cannot be TOP_OF_FABRIC and its level cannot be
   configured.  RIFT will fully configure the node's level after it is
   attached to the topology and ensure that the node is at the "bottom
   of the hierarchy" (southernmost).

s/fully configure/fully determine/


   ... So the ToF nodes can exchange the full list of
   prefixes that exist in the fabric and figure when a ToF node lacks
   reachability and to existing prefix.

Is an "out" needed after "figure", and should "and to existing prefix" be "to some prefixes"?

   ... In the case of Negative Disaggregation, the last ToF
   node(s) that injects the route may also incur an incast issue; this
   problem would occur if a prefix that becomes totally unreachable is
   disaggregated, but doing so is mostly useless and is not recommended.

What does "so" refer to, in the last sentence above?

   It is not envisioned in the short term that the average fabric
   supports a Precision Time Protocol [IEEEstd1588], and the precision
   that may be available with the Network Time Protocol [RFC5905], in
   the order of 100 to 200ms, may not be necessarily enough to cover,
   e.g., the fast mobility of a Virtual Machine.

I struggled with the above paragraph. Perhaps reword to the following?

   It is not envisioned that an average fabric supports Precision Time Protocol
   [IEEEstd1588] in the short term, nor that the precision available with
   the Network Time Protocol [RFC5905] (in the order of 100 to 200ms)
   may not be necessarily enough to cover, e.g., the fast mobility of a Virtual Machine.

Maybe even change the double negative.

   RIFT doesn't precondition that nodes of the fabric have reachable
   addresses.  But the operational purposes to reach the internal nodes
   may exist.

s/purposes/reasons/?

   In a fully connected ToF, in case of failure between ToF2 and spine
   nodes, ToF2's loopback address must be disaggregated recursively all
   the way to the leaves.

   In a partitioned ToF, a TOF node is only reachable within its Plane,
   and the disaggregation to the leaves is also required.  A possible
   alternative is to use the ring that interconnects the ToF nodes to
   transmit packets between them for their loopback addresses only...

If I understand it correctly, the above two paragraphs should be as following (the ring alternative to recursive disaggregation applies to both fully connected ToF and partitioned ToF):

   In case of failure between ToF2 and spine
   nodes, ToF2's loopback address must be disaggregated recursively all
   the way to the leaves. In a partitioned ToF, even with recursive disaggregation
   a ToF node is only reachable within its plane.

   A possible alternative to recursive disaggregation is to use a ring
   that interconnects the ToF nodes to
   transmit packets between them for their loopback addresses only...

For the following:

   If a controller is attaching to the RIFT domain from ToF, it usually
   uses dual-homing connections.  The loopback prefix of the controller
   should be advertised down by the ToF and spine to leaves.  If the
   controller loses link to ToF, make sure the ToF withdraw the prefix
   of the controller(use different mechanisms).

What does "(use different mechanisms)" mean?

5.12.  Internet Connectivity With Underlay

s/With/Within/?

   In case that an internet access request comes from a leaf and the
   internet gateway is another leaf ...

Where else could the internet access request come from? With the request from a non-leaf, don't you also need the default route to be advertised by the internet gateway?

   If the traffic comes from ToF to Leaf111 or Leaf121 which has anycast
   prefix PrefixA.  RIFT can deal with this case well.

s/. RIFT/, RIFT/

   The adds huge
   capabilities for leaf-2-leaf ECMP paths, but additional complexity
   with the need to disaggregate.  Also RIFT uses Link State flooding
   northwards, and is not designed for low-power operation.

s/The/This/
Why is low-poer operation mentioned all? It's not like that we'll run RIFT on IOTs? The following only talks about IOT being attached to leaves:

   Still nothing prevents that the IP devices connected at the Leaf are
   IoT (Internet of Things) devices, which typically expose their
   address using WiND - which is an upgrade from 6LoWPAN ND [RFC6775]. 

And are the following specific to IOT?

   A network that serves high speed/ high power IoT devices should
   typically provide deterministic capabilities for applications such as
   high speed control loops or movement detection.  The Fat Tree is
   highly reliable, and in normal condition provides an equilatent
   multipath operation; but the ECMP doesn't provide hard guarantees for
   either delivery or latency.  As long as the fabric is non-blocking
   the result is the same; but there can be load unbalances resulting in
   incast and possibly congestion loss that will prevent the delivery
   within bounded latency.

   This could be alleviated with Packet Replication, Elimination and
   Reordering (PREOF) [RFC8655] leaf-2-leaf but PREOF is hard to provide
   at the scale of all flows, and the replication may increase the
   probability of the overload that it attempts to solve.

Thanks!
Jeffrey