Re: [Anima] I-D Action: draft-yizhou-anima-l2-acp-based-ani-00.txt

Liyizhou <liyizhou@huawei.com> Wed, 27 October 2021 02:36 UTC

Return-Path: <liyizhou@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 EE3183A074B; Tue, 26 Oct 2021 19:36:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 YhIjzXdDlx2i; Tue, 26 Oct 2021 19:36:50 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 906163A0744; Tue, 26 Oct 2021 19:36:49 -0700 (PDT)
Received: from fraeml708-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HfCRc3L1tz67vlM; Wed, 27 Oct 2021 10:33:32 +0800 (CST)
Received: from kwepeml500003.china.huawei.com (7.221.188.182) by fraeml708-chm.china.huawei.com (10.206.15.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Wed, 27 Oct 2021 04:36:45 +0200
Received: from kwepeml500003.china.huawei.com (7.221.188.182) by kwepeml500003.china.huawei.com (7.221.188.182) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Wed, 27 Oct 2021 10:36:43 +0800
Received: from kwepeml500003.china.huawei.com ([7.221.188.182]) by kwepeml500003.china.huawei.com ([7.221.188.182]) with mapi id 15.01.2308.015; Wed, 27 Oct 2021 10:36:43 +0800
From: Liyizhou <liyizhou@huawei.com>
To: "duzongpeng@foxmail.com" <duzongpeng@foxmail.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, "draft-yizhou-anima-l2-acp-based-ani@ietf.org" <draft-yizhou-anima-l2-acp-based-ani@ietf.org>
CC: "anima@ietf.org" <anima@ietf.org>
Thread-Topic: Re: [Anima] I-D Action: draft-yizhou-anima-l2-acp-based-ani-00.txt
Thread-Index: AQHXxL87hT/5hOAYtkuQqb43ioGX8avallyAgACc+ECACjoVFoAAvsYg
Date: Wed, 27 Oct 2021 02:36:43 +0000
Message-ID: <a1cf792124bd4fa3975b3a3a3267fa5e@huawei.com>
References: <163463033712.25024.851885585891035829@ietfa.amsl.com>, <7095c13c-1ad2-3b6e-25f2-657faa06fbaa@gmail.com>, <b267b71a0ee04522a218620c57d126c6@huawei.com> <2021102623101401264926@foxmail.com>
In-Reply-To: <2021102623101401264926@foxmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.98.176]
Content-Type: multipart/alternative; boundary="_000_a1cf792124bd4fa3975b3a3a3267fa5ehuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/6V652KwaWE9n45ZdKhg2IfD2uQ4>
Subject: Re: [Anima] I-D Action: draft-yizhou-anima-l2-acp-based-ani-00.txt
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 27 Oct 2021 02:36:55 -0000

Hi Zongpeng,

Thank you for your email. Please see inlines with [yz] below.

Rgds,
Yizhou

From: duzongpeng@foxmail.com [mailto:duzongpeng@foxmail.com]
Sent: Tuesday, October 26, 2021 11:10 PM
To: Liyizhou <liyizhou@huawei.com>; Brian E Carpenter <brian.e.carpenter@gmail.com>; draft-yizhou-anima-l2-acp-based-ani@ietf.org
Cc: anima@ietf.org
Subject: Re: Re: [Anima] I-D Action: draft-yizhou-anima-l2-acp-based-ani-00.txt

Hi Yizhou and Brian,

I agree that we can refer to related works before.


    It is interesting that we can provide a L2 ACP for the GRASP. In this L2 ACP, does the MAC forwarding table is used for packet forwarding?
[yz] I would like to see it is some kind of specific grasp message over L2 frame. As some earlier drafts suggested LLDP, it looks like a good way.


    IMHO, the shared secret may be initially used when joining into the ACP plane, just like a token.
[yz] If I remember correctly, MacSec was brought up before. That might be also a useful approach.

    After that, other secrets obtained from the ANIMA network can be used in communications.




Best Regards
Zongpeng Du
________________________________
duzongpeng@foxmail.com<mailto:duzongpeng@foxmail.com> & duzongpeng@chinamobile.com<mailto:duzongpeng@chinamobile.com>

From: Liyizhou<mailto:liyizhou@huawei.com>
Date: 2021-10-20 15:14
To: Brian E Carpenter<mailto:brian.e.carpenter@gmail.com>; draft-yizhou-anima-l2-acp-based-ani@ietf.org<mailto:draft-yizhou-anima-l2-acp-based-ani@ietf.org>
CC: Anima WG<mailto:anima@ietf.org>
Subject: Re: [Anima] I-D Action: draft-yizhou-anima-l2-acp-based-ani-00.txt
Hi Brian and all,

Thanks for pointing to the drafts. I did aware the l2acp-scenarios draft, but not the quads-grasp.

Also Michael has another related document draft-richardson-anima-l2-friendly-acp-02.

Looks like this topic is of great interest, at the same time it might deserve some more discussion on a clear usage scenario of L2.

As section 7 of RFC8994 shows, supporting ACP on L2 switches can be met by making the L2 ports look like (L3) ACP aware interfaces. IPv6 link-local unicast and multicast are to be used. It is ACP on L2 port.

What I would like to go a bit further to discuss is L2 based ACP rather than ACP on L2 port.

A campus network may contain the different types of equipment, L2 switches, L3 routers, hybrid L2/L3 switches. To make things easy, it is quite common that all the nodes are enrolled as layer 2 to form a layer 2 topology. Then a collection of the physical connection/topology would be required to check to see if the cabling is correctly made. That is to say, assuming using link-local unicast and multicast address to reach each L2 port brings extra requirements to L2 devices as L2 ports may never use those IP addresses for their real data plane forwarding.

So L2ACP in the document basically tries to describe a need of a separate control plane reachable using traditional layer 2 (for example, with MAC address, or even physical port number, without requiring IP addresses). RPL is used as ACP L3 routing. So very likely it would not be a convenient approach in L2ACP usage. A loop free mechanism coupled with L2ACP can be used for this separate plane. (The real data forwarding can still use STP for loop-free forwarding. )

That's the difference I see between L2ACP and (L3) ACP on L2 port.

Worth a revisiting of this topic or a waste of time?


Yizhou

-----Original Message-----
From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E Carpenter
Sent: Wednesday, October 20, 2021 9:37 AM
To: draft-yizhou-anima-l2-acp-based-ani@ietf.org<mailto:draft-yizhou-anima-l2-acp-based-ani@ietf.org>
Cc: Anima WG <anima@ietf.org<mailto:anima@ietf.org>>
Subject: Re: [Anima] I-D Action: draft-yizhou-anima-l2-acp-based-ani-00.txt

Hi,

This is an interesting draft and I think the topic is important. Can you please compare with draft-carpenter-anima-l2acp-scenarios-02? Unfortunately we did not get much response to that draft 2 years ago.

I don't really understand this statement:

  The DULL instance of GRASP is used to discover neighbours.

DULL allows GRASP discovery, but this discovers ASAs handling a particular GRASP Objective. It is not designed to discover GRASP-capable nodes as such; GRASP doesn't need that. I've been running GRASP over L2 for 4 or 5 years, with no such neighbour discovery.

Also you write:

  Therefore similar functions of topology
  collection and loop-free topology creation is required for L2 ACP.

I don' think that is needed. On a single link, there is no need to know topology. When there are multiple links, the GRASP relaying procedures for M_FLOOD and M_DISCOVER (which are link-local multicast packets) prevent loops. Normal IPv6 routing takes care of unicast packets.

The essential problem with using L2 as an ACP is security. Apart from security, GRASP works perfectly over L2, as long as it supports native link-local multicast.

So, did you look at the L2-independent security proposed in draft-carpenter-anima-quads-grasp? It describes quite strong security for GRASP over any layer 2, but it needs a shared secret. BRSKI and the standard ACP avoid that defect. As far as I can see, that is the entire problem of any L2 ACP solution. If you can avoid a shared secret without BRSKI, that would be great, but I'm not sure it's possible. In fact QUADS is more general than L2; it also secures GRASP on a routed network.

(The code for QUADS security is built into my GRASP code. It is documented at page 22 in https://github.com/becarpenter/graspy/raw/master/graspy.pdf)

Regards
   Brian Carpenter

On 19-Oct-21 20:58, internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>         Title           : Requirement and a Reference Model of L2 ACP based ANI
>         Authors         : Yizhou Li
>                           Yujing Zhou
>                           Li Shen
> Filename        : draft-yizhou-anima-l2-acp-based-ani-00.txt
> Pages           : 7
> Date            : 2021-10-19
>
> Abstract:
>    This document discusses the scenarios, requirements and a reference
>    model of ANI (Autonomic Networking Infrastructure) to be constructed
>    in a layer 2 network using L2 Autonomic Control Plane (ACP) and the
>    related functions.  It expands the applicability of ANI to L2 network
>    and maintains the same infrastructure.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-yizhou-anima-l2-acp-based-ani/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-yizhou-anima-l2-acp-based-
> ani-00
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org<mailto:I-D-Announce@ietf.org>
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

_______________________________________________
Anima mailing list
Anima@ietf.org<mailto:Anima@ietf.org>
https://www.ietf.org/mailman/listinfo/anima

_______________________________________________
Anima mailing list
Anima@ietf.org<mailto:Anima@ietf.org>
https://www.ietf.org/mailman/listinfo/anima