IETF Logo Mail Archive

Re: [Anima] RPL alternatives in ACP?

"Liubing (Leo)" <leo.liubing@huawei.com> Thu, 08 June 2017 09:19 UTC

Return-Path: <leo.liubing@huawei.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6C5129C73 for <anima@ietfa.amsl.com>; Thu, 8 Jun 2017 02:19:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level:
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDN69rR5stP8 for <anima@ietfa.amsl.com>; Thu, 8 Jun 2017 02:19:15 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A913129B7A for <anima@ietf.org>; Thu, 8 Jun 2017 02:19:15 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIC86771; Thu, 08 Jun 2017 09:19:13 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 8 Jun 2017 10:19:11 +0100
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Thu, 8 Jun 2017 17:19:08 +0800
From: "Liubing (Leo)" <leo.liubing@huawei.com>
To: "Roberta Maglione (robmgl)" <robmgl@cisco.com>, "anima@ietf.org" <anima@ietf.org>
Thread-Topic: [Anima] RPL alternatives in ACP?
Thread-Index: AQHS32/QIeRiasoAA0KDMBX/JFMH2qIYzKwAgAHI8+A=
Date: Thu, 08 Jun 2017 09:19:07 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2F488F5@nkgeml514-mbx.china.huawei.com>
References: <192aefd6-1c4e-57e8-bdcb-71fd130248a4@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2F4251B@nkgeml514-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2F48216@nkgeml514-mbx.china.huawei.com> <eab968f0-6bbd-33f7-8b6f-b2e953d78f62@gmail.com> <f6e60282c5cf436584b29837b3b0ba44@XCH-RCD-009.cisco.com>
In-Reply-To: <f6e60282c5cf436584b29837b3b0ba44@XCH-RCD-009.cisco.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.191.175]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.59391691.0151, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 9474b64c3d6a54abca8c4ee2d2946f5c
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/Xwtp0fO3stCwrbbaqJ4xX1HBEkc>
Subject: Re: [Anima] RPL alternatives in ACP?
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Jun 2017 09:19:18 -0000

Hi Roberta,

Thanks for your comments. Inline.

> -----Original Message-----
> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Roberta
> Maglione (robmgl)
> Sent: Wednesday, June 07, 2017 8:23 PM
> To: anima@ietf.org
> Subject: Re: [Anima] RPL alternatives in ACP?
> 
> 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.

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

> 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.)
> >
> > 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:anima-bounces@ietf.org] 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
> >> Anima@ietf.org
> >> https://www.ietf.org/mailman/listinfo/anima
> > _______________________________________________
> > Anima mailing list
> > Anima@ietf.org
> > https://www.ietf.org/mailman/listinfo/anima
> 
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
> 
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

v2.23.0 | Report a Bug | By Email