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

["Pascal Thubert (pthubert)" <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]<mailto:[e-mail]>> 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: [phone] E: [e-mail]<mailto:[e-mail]>


原始邮件
发件人：SamitaChakrabartiviaDatatracker
收件人：[e-mail]<mailto:[e-mail]>;
抄送人：[e-mail]<mailto:[e-mail]>;[e-mail]<mailto:[e-mail]>;[e-mail]<mailto:[e-mail]>;
日 期 ：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
[e-mail]<mailto:[e-mail]>
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=