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

Liyizhou <liyizhou@huawei.com> Thu, 28 October 2021 03:59 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 EADC33A078C for <anima@ietfa.amsl.com>; Wed, 27 Oct 2021 20:59:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jGjbR5xx0cWv for <anima@ietfa.amsl.com>; Wed, 27 Oct 2021 20:59:17 -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 186013A07A5 for <anima@ietf.org>; Wed, 27 Oct 2021 20:59:17 -0700 (PDT)
Received: from fraeml703-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HfsC524hdz67bJm; Thu, 28 Oct 2021 11:54:57 +0800 (CST)
Received: from kwepeml100006.china.huawei.com (7.221.188.192) by fraeml703-chm.china.huawei.com (10.206.15.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.15; Thu, 28 Oct 2021 05:59:08 +0200
Received: from kwepeml500003.china.huawei.com (7.221.188.182) by kwepeml100006.china.huawei.com (7.221.188.192) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Thu, 28 Oct 2021 11:59:07 +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; Thu, 28 Oct 2021 11:59:07 +0800
From: Liyizhou <liyizhou@huawei.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, Anima WG <anima@ietf.org>
Thread-Topic: [Anima] I-D Action: draft-yizhou-anima-l2-acp-based-ani-00.txt
Thread-Index: AQHXxL87hT/5hOAYtkuQqb43ioGX8avallyAgAqCdQCAApfygA==
Date: Thu, 28 Oct 2021 03:59:06 +0000
Message-ID: <08dfbe37ed2c4b1a94d5be81cb4b8623@huawei.com>
References: <163463033712.25024.851885585891035829@ietfa.amsl.com> <7095c13c-1ad2-3b6e-25f2-657faa06fbaa@gmail.com> <32375.1635271594@localhost>
In-Reply-To: <32375.1635271594@localhost>
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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/saOedEC7efWUXHAlzjBBlABtrAY>
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: Thu, 28 Oct 2021 03:59:22 -0000

Hi Michael,

Thank you for your careful reading. It takes me some time to have some more thinking on the draft.

You are right that most devices have management interface with L3 capability.

The difficulty we met was when IPv4 is in use the management interface needs to get to DHCP server first to get its IP. DHCP is a BUM traffic. 
RFC3927 defined a self-configured IPv4 address, but AFAIK it is implemented in some host OS but not on network nodes.
The expected L2ACP in my mind has the function of L2 loop-free reachability before the management interface of the nodes obtains IP via DHCP. 

I understand an IPv6 link-local address can be used for ACP even when the data plane is IPv4. I tried to talk to some engineers/admins if they would like to use it in such a way. Some think it is ok. 
But quite a number of them feel not so comfortable and hard (or not so willing) to understand to build ACP in ipv6 while keep using IPv4 data plane. And some of the admins are used to use the IPv4 management addresses simply because they are short and remembering them is part of their habit already.
The admin is usually very careful about the change of style in managing their network. They may want to use telnet to check the node from time to time. So the fact that addresses to be remembered have to be short is more important to them than I thought.  

Anima is for operation and maintenance. We can try to change the habit of admins gradually , at the same time I am thinking it may also be worthwhile to give a reasonable tool to those who would like to use it in a more old fashion way. 

I agree with the comments about the scale of SMB and small branch. 
"No L3 physical interfaces" basically refers to L2 physical interface. I think the more correct text should be something like "the interface cannot or is not configured to automatically get IP address without any external exchange."  


Yizhou

-----Original Message-----
From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael Richardson
Sent: Wednesday, October 27, 2021 2:07 AM
To: Anima WG <anima@ietf.org>
Subject: Re: [Anima] I-D Action: draft-yizhou-anima-l2-acp-based-ani-00.txt


I read through draft-yizhou-anima-l2-acp-based-ani-00.txt.
I don't really understand the applicability.

It says:

>   However
>   there are some cases which require L2 ACP functions in ANI.  The L2
>   ACP is used in such cases that the managed network is a reletively
>   small layer 2 network where the network nodes have no L3 physical
>   interfaces and the network manager would like to use and verify the
>   L2 topology and reachability first for some management purpose.

The claim is that there are no L3 "physical interfaces"
I don't really know what means.

How is management done?  I guess that there is no SNMP, no SSH, no YANG, and no web interface into these devices?
Many of the L1 DWDM devices that I have worked with have managment interfaces that provide all of these L3 kind of things (Some don't: They are purely physical/optical devices with no management at
all.)

> In SOHO or SMB case, the network is not large and the network nodes
>    have less resource.  They are pure layer 2 nodes or nodes to be
>   enrolled as layer 2 first to form the initial simple topology for
>   cabling verification.  In this case, autonomic network management
>   with the layer 2 network nodes is required.  Figure 1 shows a typical
>   example of layer 2 network.
>
>   For small branch, the number of hosts is usually less than 200, and
>   the number of WiFi AP and access switches are both less than 10.

SOHO/SMB cases do not have 200 hosts.  They have 20 hosts max, with a single AP, and every single one (the one) of the "switches" has an L3 interface on which there is a web interface.
For a small branch office, those numbers seem reasonable, but I think that every single one of those devices has a L3 management interface.

While there are many L2/L3 1/10/100Gbps switches have a 100Mb/s L3-only management for an OOB network connection, they are all capable of having a management L3 interface attached to any of the L2 "VLANs" which may be created.  Some are annoying/stupid, and can only attach to vlan1, but that's increasingly uncommon.

So:
  1) I agree that we need an ACP discovery (DULL) mechanism that does not
  rely on broadcast frames.

  2) I also agree that some links might benefit from using MACsec rather than
  IPsec for seperation across the physical links.

Both of these mechanisms will reveal the state of L2 connectivity.

I do not agree that we need any kind of L2-ACP.  We don't need to move ethernet frames around like this.  Anyway, I think 802.1q already provides for that.  yeah, STP sucks.  Don't use STP with redundant voice links.
For management links, it is okay.  It's just really hard to debug.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide