[Rift] comments on draft-ietf-rift-rift-11

[[e-mail]]

Hi authors,






This draft is well-written. Thank you very much for your work on this draft!


I have some questions and comments:





=============================


1. In section 4.1.2.1, there is the "fallen leaf" definition.

And in section 4.1.3, there is also a definition for "fallen leaf": 

"We define a "Fallen Leaf" as a leaf that can be reached by only a

   subset, but not all, of Top-of-Fabric nodes due to missing

   connectivity."

The fallen leaf definition seems like different though in fact the meaning is the same.

So changing the wording in section 4.1.3 may be better, such as don't use the word "define".




=============================

2. In section 3.1, The definition of "Leaf" is "A node without southbound adjacencies.".

In section 4.1.3, the cases description for do not require particular action are:

"If a southern link on a leaf node goes down, then connectivity to ..." ,

"If a southern link on a leaf node goes down, then connectivity through that leaf is...",

Is the "southern link" in section 4.1.3 means the connection to servers?


And it seems like the two paragraphs of "If a southern link on a leaf node..."are almost the same. Is it duplicated?




=============================


3. In section 4.2.2.1,


"3. SEND_LIE: create a new LIE packet

 ...

 3.  setting `you_are_not_flood_repeater` to computed value"




In fact "you_are_flood_repeater" is used in the following sections, though there is no ambiguity,  unified word would be better.




=============================

4. In Section 4.2.3.3.1,


The last paragraph, 

"TIDEs and TIREs MUST NOT be re-flooded the way TIEs of other nodes

   are are MUST be always generated by the node itself and cross only to

   the neighboring node."

Nit:


are are/ are and




=============================

5. In section 4.2.3.3.1.2.2 TIDE Processing

"b. for every HEADER in TIDE do

  ...

  6.  if DBTIE.HEADER < HEADER then

    I)    if originator is this node then bump_own_tie else

      i.     if this is a North TIE header from a northbound

                        neighbor then override DBTIE in LSDB with HEADER"

Is this a nit? 


a North TIE header from a northbound neighbor/ a North TIE header from a southbound neighbor?




==============================

6. In section 4.2.3.3.1.3.1.  TIRE Generation

"There is not much to say here.  Elements from ..."

If it's better to remove the sentence "There is not much to say here."?




==============================

7. In section 4.2.3.5.  'Flood Only Node TIEs' Bit

"RIFT includes an optional ECN mechanism to prevent ..."

Reader may not understand the acronym "ECN", "ECN (Explicit Congestion Notification)" may be better.




==============================

8. In section 4.2.3.7, 

The emulation of "checksum behavior" is not very clearly to me. I am not sure I got the difference between computing checksum and fill in a specific field like tranditional link-state protocol and computing checksum and fill it in the sequence field.

If more descriptions can be added for it?




==============================

9. In section 4.2.3.8,

" The term "all other nodes at X's' level" describes obviously just the

   nodes at the same level in the PoD with a viable lower level ..."

How do we understand the words "with a viable lower level"? Is it "with a viable lower level reflection"?




==============================

10. In section 4.2.3.9,

"... is (similar to) a NP-Complete problem and a globally..."

What is NP? Network Processor?




==============================

11. In section 4.2.3.9,

"let G be a grandparent node of N, reachable transitively via a

      parent P over adjacencies ADJ(N, P) and ADJ(P, G).  Observe that N

      does not have enough information to check bidirectional

      reachability of A(P, G);"

Shoud a unified abbreviation "A" or "ADJ" be used?




==============================

12. In section 4.3.3.1,

In proceeding sections it's clear that the newest one is preferred. But the comparison rules with "older" description are in rule 1 and 4. 

There is no clear sentence that describes the result leading by these rules.




==============================

13. In section 4.3.3.4,

LISP is mentioned in this section, but there is no reference to LISP protocol in the document. 

IMO it's better to add the reference to LISP (rfc6830bis) in informative references section or rfc6830 in normative references.




==============================

14. In figure 2, 29, 32, 33 and 34, the "Spine" losts the "e". But it is not even a nit.




==============================

15. In section 4.4.1,

I am confused with "Level Provisioning", is this configured in each level? It seems like it should be configured on each node, right? 

If it's right, I am also confused with the integrity and flexibility comparison in figure 30. It seems like the integrity of "Level Provisioning" is beyond "FAM".




==============================

16. In section 4.4.3,

"Remaining TIE Lifetime:  32 bits.  In case of anything but TIEs this

      field MUST be set to all ones and Origin ..."

If the "TIEs" should be "LIEs"?




==============================

17. In section 4.4.4 Weak nonces,

I remember that a good nonce example was presented in previous IETF meeting. 

It may be better to add a simple example in this section to make it more easier to understand.




==============================

18. In section 5.3,

"The mechanism to resolve this scenario hinges on ToF 21's Sout TIEs ..."

sout/south




Thanks,

Sandy