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

Just one comment here:

> But quite a number of them feel not so comfortable and hard (or not so willing) to understand to build ACP in ipv6

They do not need to understand IPv6 or do anything except check that the IPv6 stack is enabled in all devices. The ACP will deploy itself without requiring any manual configuration of IPv6 addressing or routing. It's much easier than deploying IPv6 for the dataplane.

Do you think your contacts can be persuaded to read the ANIMA article https://ipj.dreamhosters.com/wp-content/uploads/2021/10/243-ipj.pdf ? It was 
written exactly for such operators.

I do agree that there are use cases for an L2 ACP, but to really compete it must be easier to deploy than RFC8994 and equally secure. If you accept security via a shared secret, we can also solve the problem at layer 3.5 with ad hoc encryption.

Regards
    Brian

On 28-Oct-21 16:59, Liyizhou wrote:
> 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
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
> 