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

zhang.zheng@zte.com.cn Wed, 20 May 2020 05:59 UTC

Return-Path: <zhang.zheng@zte.com.cn>
X-Original-To: rift@ietfa.amsl.com
Delivered-To: rift@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC803A3AC4 for <rift@ietfa.amsl.com>; Tue, 19 May 2020 22:59:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5tVIliAhLmg for <rift@ietfa.amsl.com>; Tue, 19 May 2020 22:59:19 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36B1A3A3AC3 for <rift@ietf.org>; Tue, 19 May 2020 22:59:14 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.164.217]) by Forcepoint Email with ESMTPS id E386348632BF34BEC20C; Wed, 20 May 2020 13:59:12 +0800 (CST)
Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id 9866930D1A5E14D7E69F; Wed, 20 May 2020 13:59:12 +0800 (CST)
Received: from njxapp04.zte.com.cn ([10.41.132.203]) by mse-fl1.zte.com.cn with SMTP id 04K5x5Gw057508; Wed, 20 May 2020 13:59:05 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn)
Received: from mapi (njxapp04[null]) by mapi (Zmail) with MAPI id mid203; Wed, 20 May 2020 13:59:05 +0800 (CST)
Date: Wed, 20 May 2020 13:59:05 +0800
X-Zmail-TransId: 2afc5ec4c72934d8b02e
X-Mailer: Zmail v1.0
Message-ID: <202005201359050787768@zte.com.cn>
In-Reply-To: <520E6EFE-1E1E-41B5-8B10-61F7838AE13D@juniper.net>
References: 202005191616153734043@zte.com.cn, 520E6EFE-1E1E-41B5-8B10-61F7838AE13D@juniper.net
Mime-Version: 1.0
From: zhang.zheng@zte.com.cn
To: prz@juniper.net
Cc: alankar_sharma@comcast.com, pthubert@cisco.com, brunorijsman@gmail.com, fl0w@yandex-team.ru, aretana.ietf@gmail.com, jefftant.ietf@gmail.com, zzhang@juniper.net, rift@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 04K5x5Gw057508
Archived-At: <https://mailarchive.ietf.org/arch/msg/rift/q2_SVgDnl5Ob870SNm3drPc-Mgs>
Subject: Re: [Rift] comments on draft-ietf-rift-rift-11
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Routing in Fat Trees <rift.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rift>, <mailto:rift-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rift/>
List-Post: <mailto:rift@ietf.org>
List-Help: <mailto:rift-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rift>, <mailto:rift-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 May 2020 05:59:23 -0000

Hi Tony,






Thank you very much for your quick response!


And thank you for the accepted comments.


Please find my comments in line for some responds with Sandy>.






Thanks,


Sandy









原始邮件



发件人:AntoniPrzygienda <prz@juniper.net>
收件人:张征00007940;alankar_sharma@comcast.com <alankar_sharma@comcast.com>;pthubert@cisco.com <pthubert@cisco.com>;brunorijsman@gmail.com <brunorijsman@gmail.com>;fl0w@yandex-team.ru <fl0w@yandex-team.ru>;
抄送人:aretana.ietf@gmail.com <aretana.ietf@gmail.com>;jefftant.ietf@gmail.com <jefftant.ietf@gmail.com>;Jeffrey (Zhaohui)Zhang <zzhang@juniper.net>;rift@ietf.org <rift@ietf.org>;
日 期 :2020年05月20日 00:55
主 题 :Re: [Rift]  comments on draft-ietf-rift-rift-11






Hey Sandy, thanks, iline


 

That’s intentional. There was a complain that 4.1.2.1 did not define “fallen leaf” in the context of the section and it was added

Sandy> OK.

Correct, that should not be leaf, changed to “node”. Redundancy was already removed (I’m working on version -12 that will be published right before it goes to IESG reviews again [not
 sure whether chairs forwarded for 2nd review yet])

Sandy> I am not sure if it should be the second review. IMO it's not necessary if the modification only addresses these comments.

Good catch, left from previous schema version

Done

No, it’s not. Spec explains it in flooding somewhere else, basically you have to reconverge in pathological cases where multiple levels go down in an orchestrated fashion and old northbound
 information may persist

Sandy> Oh. It means that in common cases it will not occur, but in some pathological situation it may occur, right?

Ack

Ack

Nope, it’s not RIFT specific. Issue well understood and implementation specific but we metion is since people were questioning the way it’s done in RIFT

Sandy> OK. So it's a optional way to choose 16-bit in sequence to be checksum, right?

Lower level always reflects, so yes but saying it again would state a tautology, not helpful.

Sandy> OK.

Non-polynomial, well-known terem in computer science.https://en.wikipedia.org/wiki/NP-completeness

Sandy> Thank you! I misunderstood it.

Yes, good catch

Yes, they are. The comment has been made before. Read 4.3.3. in its entirety carefully and you’ll see it’s water-tight.

Sandy> Yes. I read all the section and I understand it. But somebody may only read the section 4.3.3.1 to get the comparison rule. So it may be better by only add one sentence: "The newest one is always preferred."

Done

Space

Hard to really classifiy since rift allows to mix configured and unconfigured nodes just fine. Yes, it’s kind of FAM

Sandy> Thanks for clarification. So if the figure will be adjust a little?

Nope, that’s correct

If you want example, write the text please

Sandy> May like this? "For example, simple incremental computation rule can be used. In case of node A is incremental by multiplying 5, node B is incremental by plus 3, then A/B can decide that the packet from B/A is not valid because the value is not incremental correctly according to the rules."

Ack


 


--- tony


 



From: "zhang.zheng@zte.com.cn" <zhang.zheng@zte.com.cn>
Date: Tuesday, May 19, 2020 at 1:32 AM
To: Antoni Przygienda <prz@juniper.net>, "Sharma, Alankar" <alankar_sharma@comcast.com>, "pthubert@cisco.com" <pthubert@cisco.com>, "brunorijsman@gmail.com" <brunorijsman@gmail.com>, Dmitry Afanasiev <fl0w@yandex-team.ru>
Cc: "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>, "jefftant.ietf@gmail.com" <jefftant.ietf@gmail.com>, Zhaohui Zhang <zzhang@juniper.net>, "rift@ietf.org" <rift@ietf.org>
Subject: [Rift]  comments on draft-ietf-rift-rift-11



 



[External Email. Be cautious of content]


 

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

 






Juniper Business Use Only