Subject: [Anima] RPL alternatives in ACP? (was: Regarding ACP routing protocol)

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 7 Jun 2017 04:04:57 +0000

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-masked]] 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-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: "Michael H. Behringer" <[email-masked]>
Date: Wed, 7 Jun 2017 11:23:29 +0200

Bing, I´m afraid that´s a can of worms... Homenet has been stalled for a 
long time, and quite a few IETFs were only about the fight "my routing 
protocol is better than yours". I´m afraid if we enter this discussion, 
we have 2 years of arguments ahead for no obvious benefit.

Let me ask the other way round: With the specs as they are, what will 
NOT work?

My view: Unless we have a real good reason, we should not enter this 
debate...

Michael

---

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Wed, 7 Jun 2017 12:23:12 +0000

Hello Bing,
I'm not sure I fully understand and agree with what you are trying to say with this sentence: 

> But in some closed solutions, multi-vendor interoperation is not the No.1 consideration for customers.

If you think that multi-vendor interoperability is not needed what's the point of making a standard? Why discussing it here? You could make your own choice for protocol without asking for WG opinion/consensus.

Roberta

On 07/06/2017 06:04, 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.)
>
>> 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.
>>
>> 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
>>

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 7 Jun 2017 21:04:36 +0200

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

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Jun 2017 16:37:40 -0400

> If you think that multi-vendor interoperability is not needed what's
    > the point of making a standard? Why discussing it here? You could make
    > your own choice for protocol without asking for WG opinion/consensus.

Exactly, well said.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 7 Jun 2017 16:04:29 -0500

>     > your own choice for protocol without asking for WG opinion/consensus.
I think the quote is taken out of context, that is not the main message in
Bing's mail as far as I understood.

>> OSPFv3-autoconf, I think ACP could be more widely adopted in non-IoT
network devices.

Behcet

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 8 Jun 2017 09:19:07 +0000

Hi Roberta,

Thanks for your comments. Inline.

> From: Anima [mailto:[email-masked]] On Behalf Of Roberta
> Maglione (robmgl)
> Sent: Wednesday, June 07, 2017 8:23 PM
> To: [email-masked]
> Subject: Re: [Anima] RPL alternatives in ACP?
> 
> Hello Bing,
> If you think that multi-vendor interoperability is not needed what's the point
> of making a standard? Why discussing it here? You could make your own
> choice for protocol without asking for WG opinion/consensus.

My thought (maybe wrong) is that it's about perception of the user/customers: is a non-RPL ACP still be "the ACP"?
In other words, when using some other IGPs that some old-fashion developers/customers are more familiar with and have more confidence, and it could be still identified as standard ACP, maybe it's good for the adoption of this technology? Especially when users don't care about multi-vendor interoperability in some scenarios.

But to be clarified, I do like RPL from technical aspect. The above thought is kind of compromise to peoples' perception when promoting a new technology.

Best regards,
Bing

> about why we choosed RPL for routing.
> seem lacking the support of RPL.
> >
> another traditional IGP literally legal in the ACP document? (e.g.
> would potentially cause interoperation issues. But in some closed solutions,
> widely adopted in non-IoT network scenarios.
> >
> > Any comments/eggs? :)
> >
> > B.R.
> > Bing
> >