Re: [Last-Call] [E] Re: [Iot-directorate] Iotdir last call review of draft-ietf-rift-applicability-03

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Pascal ,
Thanks for the detailed explanation on the differences between RIFT and RPL.
As mentioned earlier, practically today I don't see any impact of RIFT on low-power IoT networks  which is mainly discussed at IETF.
However, it might be useful to add a paragraph  either in the main body or in the Appendix to capture your analysis discussed here.
I don't have any other comments.
Best regards,
-Samita


On Wed, Jan 20, 2021 at 12:41 AM Pascal Thubert (pthubert) <pthubert@xxxxxxxxx> wrote:
Dear Samita 

The design of RIFT inherits the anisotropic design of a default route upwards (north); it also inherits the capability to inject external  host routes at the leaf using WiND. Both protocols are meant for large scale, and WiND enables device mobility at the edge the same way in both cases.

I’d think that the main difference is that wi  RPL there’s a single Root whereas RIFT has many ToF nodes. The adds immense power for ECMP leaf to leaf, and additional complexity with the need to disaggregate. 

Also RIFT uses Link State flooding northwards, and is not designed for low power. 

Still nothing prevents that the IP devices connected at the leaf are IoT devices. 

A network that serves high speed/ high power IoT devices should typically provide deterministic capabilities. The fat tree is highly reliable but doesn’t provide hard guarantees. As long as it is non blocking the result is the same; but there can be load unbalances and incast that will impact the traffic. Note that the load balancing is not RIFT’s problem, but it is key to serve IoT correctly.

Take care,

Pascal

Le 20 janv. 2021 à 05:56, Chakrabarti, Samita <samita.chakrabarti@xxxxxxxxxxx> a écrit :


Hi Yuehua,

That was a question to the authors. I am sure Pascal Thubert, one of the authors can help.
What I meant is the typically IOT network of special devices (sensors, cameras,  mini-robots etc. battery operated devices)  form  a separate network (mesh or  RPL-RFC6550  like DAG) which runs  IOT routing protocols, but the network is connected to the regular IP(v6/v4) network through a gateway which can speak to both sides. Now the question is - if this scenario requires any special applicability mentioning in this draft or not? 

Thanks for your prompt response,
-Samita

On Tue, Jan 19, 2021 at 8:16 PM <wei.yuehua@xxxxxxxxxx> wrote:

Dear Samita Chakrabarti,

Thank you for the comments.

I will fix the definition and term issue which has been raised by several reviewers.

About the  IoT applicability, would you please offer me more information about IoT network concerning "a root gateway/switch of
a IoT  network"?


Thank you.


Best Regards,

 

魏月华 Yuehua Wei

M: +86 13851460269 E: wei.yuehua@xxxxxxxxxx


原始邮件
发件人:SamitaChakrabartiviaDatatracker
日 期 :2021年01月20日 01:14
主 题 :Iotdir last call review of draft-ietf-rift-applicability-03
Reviewer: Samita Chakrabarti
Review result: Ready with Nits

I have reviewed  draft-ietf-rift-applicability from IoT point of view.

The document describes routing in the Fat Tree ( mostly CLOS architecture)
applicability. I do not find any impact of this work on the IETF IoT networks.
The document methods and RIFT/Fat trees generally are not used in IETF IoT
protocols.  However RPL uses  directed graphs with a different protocol.  I did
not see any direct IoT applicability of this document to IoT networks. However,
 for larger IoT devices and switches one might extract some ideas out of this
document in the future.  Though I don't see direct IoT applicability, I still
wish to ask a question to the authors: will they view a root gateway/switch of
a IoT  network  to act as a leaf in the fat tree architecture ( example: DC
scenario) ?  If so, please consider adding a paragraph on IoT applicability in
RIFT.

In general, the document is full of acronyms that might be too familiar with
the routing area group ( PoD, TOF, ...), but it will help if the document has a
definition of terms section or a pointer to such document in the beginning ;
alternately, it can  add the acronyms in the relevant diagrams to understand
their usage.



--
Iot-directorate mailing list
Iot-directorate@xxxxxxxx
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_iot-2Ddirectorate&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=pWMzx7FsqijEJPyfMBfn-HJss-wVVTf0K5y-cxCTXL8&m=r0RnyF5_YfoOjDsulOZzbPiTJgF2X0QeztKL85meS84&s=0nQPW9Fvbw6Pe3vUh8aln_MHMOuu5mwVfULNBl_knKA&e=
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux