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:[email protected]] On Behalf Of Michael Richardson
Sent: Wednesday, October 27, 2021 2:07 AM
To: Anima WG <[email protected]>
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 <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
