Subject: [Rift] WGLC for draft-ietf-rift-applicability-03

From: Jeff Tantsura <[email-masked]>
Date: Wed, 9 Dec 2020 20:13:41 -0800

Dear RIFT,

The authors have requested  WGLC for draft-ietf-rift-applicability.

There was consensus that document is ready for the last call.
Please indicate support or no-support by December 28, 2020.

IPR:
If you are listed as a document author or contributor and haven’t responded to the IPR call, please respond to this
email of whether or not you are aware of any relevant IPR.
The response needs to be sent to the RIFT mailing list.
The document will not advance to the next stage until a response has been
received from each author and each individual that has contributed to the document.

Cheers,
Jeff and Jeffrey

---

From: <[email-masked]>
Date: Thu, 10 Dec 2020 14:04:35 +0800 (CST)

Dear RIFT & Chairs,

I am not aware of any relevant IPR as the editor.

Best Regards,

Yuehua Wei

M: +86 13851460269 E: [email-masked]

原始邮件

发件人：JeffTantsura
收件人：[email-masked];
抄送人：[email-masked];[email-masked];
日 期 ：2020年12月10日 12:14
主 题 ：[Rift] WGLC for draft-ietf-rift-applicability-03

_______________________________________________
RIFT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rift

Dear RIFT,

 
 IPR:
 
 Cheers,
 Jeff and Jeffrey

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 10 Dec 2020 08:59:08 +0000

Hello Jeff

The document explains how to use RIFT and describes operations in RIFT that are subject to the declaration of IPR in https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-rift-rift
I expect we do not need to repeat that here, do we?

Apart from that, I’m not aware of IPR that applies to the draft.

Keep safe;

Pascal

From: RIFT <[email-masked]> On Behalf Of Jeff Tantsura
Sent: jeudi 10 décembre 2020 05:14
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Rift] WGLC for draft-ietf-rift-applicability-03

Dear RIFT,

IPR:

Cheers,
Jeff and Jeffrey

---

From: <[email-masked]>
Date: Thu, 10 Dec 2020 17:04:17 +0800 (CST)

Hi chairs and RIFTers, 

As co-author I am not aware of any relevant IPR.

Thanks,

Sandy

原始邮件

发件人：JeffTantsura
收件人：[email-masked];
抄送人：[email-masked];[email-masked];
日 期 ：2020年12月10日 12:14
主 题 ：WGLC for draft-ietf-rift-applicability-03

Dear RIFT,

 
 IPR:
 
 Cheers,
 Jeff and Jeffrey

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 10 Dec 2020 14:01:20 +0000

Dear co authors

I went through the document again for the WGLC.

I found we’re missing some informational references;

In
“

                     the granularity of the timing information.

   It is not envisioned in the short term that the average fabric

   supports a Precision Time Protocol,

“
Please add (IEEEstd1588] after “Precision Time Protocol”.

The current IEEE Std 1588 is found at https://standards.ieee.org/standard/1588-2019.html, published last June, but we want a dateless reference, typically like:

“
      <reference anchor="IEEEstd1588" target="https://standards.ieee.org/standard/1588-2019.html" quoteTitle="true" derivedAnchor="IEEEstd1588" >
         <front>
            <title> IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems
            </title>
            <author>
                                <organization> IEEE standard for Information Technology
                                </organization>
            </author>
            <date/>
         </front>
      </reference>
“

In ”

                                                                   This provides not
   only a sequence counter but also a lifetime and a security token that
   may be used to protect the ownership of an address. “

Please add (RFC8928] after “of an address”.

About

“   If NMS wants to access ToF2, ToF2's loopback address needs to be

   injected into its Prefix South TIE.  Otherwise, the traffic from NMS

   may be sent to ToF1.

   And in case of failure between ToF2 and spine nodes, ToF2's loopback

   address must be sent all the way down to the leaves.

“

This is also happening if the ToF is partitioned in multiple planes.

The may be advantages in telling the leaves (ToR) about the Superspine (ToF). For example we could control the ECMP and avoid a broken plane.

Also the drawing use the term SPINE when we tried to use ToP as much as we could. Bottom line is we’re talking about the level below the ToF, whatever that is.
And that level must form a ceiling through which all packets from below must pass, and that gets all the loopback information for all the ToF nodes.

Suggestion to change the text above to:

“

   If NMS wants to access ToF2, ToF2's loopback address needs to be

   injected into its Prefix South TIE. This TIE must be seen by all

   nodes at the level below - the SPINE nodes in Fig 9 – that must

   forum a ceiling for all the traffic coming from below (South).

   Otherwise, the traffic from NMS may follow the default route to

   the wrong ToF Node, e.g., ToF1.

   In a fully connected ToF, in case of failure between ToF2 and a

   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. The idea is that this is mostly

   control traffic and should not alter the load balancing

   properties of the fabric.

“

Typos

gets flooded on more hop
->
gets flooded one more hop

The most import component for ZTP is the automatic level derivation
->
The most important component for ZTP is the automatic level derivation

Voila!

Pascal

Dear RIFT,

IPR:

Cheers,
Jeff and Jeffrey

---

From: <[email-masked]>
Date: Mon, 14 Dec 2020 09:49:35 +0800 (CST)

Thank you Pascal, 

will reflect the comments to a new version.

Best Regards,

Yuehua Wei

原始邮件

发件人：PascalThubert(pthubert)
收件人：[email-masked];
抄送人：[email-masked];[email-masked];
日 期 ：2020年12月10日 22:02
主 题 ：Re: [Rift] WGLC for draft-ietf-rift-applicability-03

Dear co authors

 

 

 

In

“

                     the granularity of the timing information.    It is not envisioned in the short term that the average fabric    supports a Precision Time Protocol, 

“

 

 

“

         <front>

            </title>

            <author>

                                </organization>

            </author>

            <date/>

         </front>

      </reference>

“

 

In ”                                                                    This provides not 

 

 

 

About

“   If NMS wants to access ToF2, ToF2's loopback address needs to be    injected into its Prefix South TIE.  Otherwise, the traffic from NMS    may be sent to ToF1.      And in case of failure between ToF2 and spine nodes, ToF2's loopback    address must be sent all the way down to the leaves. “ 

 

 

 

 

 

“

   If NMS wants to access ToF2, ToF2's loopback address needs to be    injected into its Prefix South TIE. This TIE must be seen by all    nodes at the level below - the SPINE nodes in Fig 9 – that must    forum a ceiling for all the traffic coming from below (South).    Otherwise, the traffic from NMS may follow the default route to    the wrong ToF Node, e.g., ToF1.      In a fully connected ToF, in case of failure between ToF2 and a    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. The idea is that this is mostly    control traffic and should not alter the load balancing    properties of the fabric. “ 

Typos

gets flooded on more hop

->

 

->

 

Voila!

Pascal

 

 

Dear RIFT,

 
 IPR:
 
 Cheers,
 Jeff and Jeffrey