Hi Bing
Sorry if i overlooked some email. Somehow there must be better tooling that
just a humonguous
mailing list to track todo items. If i just knew what ;-))
Did the people whom you discussed this with read Appendix A of the ACP draft ?
If they did, what where the comments ? From wha you write, it sounded as if
there was
no discussion about the requirements that resulted in the choice of RPL but
only about
past experience and extrapolating from it. Thats a logic by which you build
cars with
wings instead of airplanes ;-)
I would very much like to help making people understand why we choose RPL and
maybe the arguments in appendix A do not yet represent the best possible text.
I for once could think of a lot more explanation of details that might help, but
i would like to extend he text only upon actually understanding what argument
would help to further the discussion.
Beside what Roberta said:
If we wanted to define solutions to support multiple IGPs for the ACP in an
interoperable
fashion, we would need IMHO to go all the way into the bootstrap protocol to be
able to query the device about the supported routing protocol choices and only
permitting
it into the domain if the routing protocol used by the domain is suported. And
i am not
sure i would get approval on such a complex extension to the bootstrap protocol
from
the other bootstrap authors. Aka: The whole concept of multi-IGP support would
first need
to be nailed down a lot more.
And even if we would achieve that goal: i can see no option to NOT make ONE
protocol the
MTI (mandatory to implement) option, and RPL is the best compromise with the
largest
applicability across small/IoT to large/ent/SP networks in a zero-touch
autoconfiguring environment.
Cheers
Toerless
On Wed, Jun 07, 2017 at 04:04:57AM +0000, Liubing (Leo) wrote:
> Hi ACP co-authors,
>
> (Maybe you missed my last mail "Regarding ACP routing protocol", let me
> re-post it with a clearer title and CC to you.)
>
> When I discuss ACP with some product people, they are always curious about
> why we choosed RPL for routing.
> I understand the benefits of RPL in ACP, it is lightweight and much more
> scalable in a single routing area, but most of the non-IoT network devices
> seem lacking the support of RPL.
>
> So, please pardon my iteration on this problem, can we possibly make another
> traditional IGP literally legal in the ACP document? (e.g. ISIS-autoconf or
> OSPFv3-autoconf) I know supporting multiple protocols would potentially cause
> interoperation issues. But in some closed solutions, multi-vendor
> interoperation is not the No.1 consideration for customers. If ACP allows
> ISIS-autoconf or OSPFv3-autoconf, I think ACP could be more widely adopted in
> non-IoT network scenarios.
>
> Any comments/eggs? :)
>
> B.R.
> Bing
>
> > -----Original Message-----
> > From: Anima [mailto:[email protected]] On Behalf Of Liubing (Leo)
> > Sent: Tuesday, May 23, 2017 5:53 PM
> > To: Anima WG
> > Subject: [Anima] Regarding ACP routing protocol
> >
> > Hi all,
> >
> > When I discuss ACP with some product people, they are always curious
> > about why we choose RPL for routing.
> > I understand the benefits of RPL in ACP, it is lightweight and much more
> > scalable in a single routing area, but most of the non-IoT network devices
> > seem like lack the support of RPL.
> >
> > So, please pardon my iteration on this problem, can we possibly make
> > another more traditional IGP literally legal in the ACP document? (e.g.
> > ISIS-autoconf or OSPFv3-autoconf) I know supporting multiple protocols
> > would potentially cause interoperation issue. But in some closed solutions,
> > multi-vendor interoperation is not the No.1 consideration for customers. If
> > ACP allows ISIS-autoconf or OSPFv3-autoconf, I think ACP could be more
> > widely adopted in non-IoT network devices.
> >
> > Any comments? Or eggs :)
> >
> > B.R.
> > Bing
> >
> > _______________________________________________
> > Anima mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/anima
>
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
