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

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Oct 2021 14:37:03 +1300

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, [email-masked] 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
> [email-masked]
> 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
>

---

From: Liyizhou <[email-masked]>
Date: Wed, 20 Oct 2021 07:14:34 +0000

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:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Wednesday, October 20, 2021 9:37 AM
To: [email-masked]
Cc: Anima WG <[email-masked]>
Subject: Re: [Anima] I-D Action: draft-yizhou-anima-l2-acp-based-ani-00.txt

Hi,

Also you write:

Regards
   Brian Carpenter

On 19-Oct-21 20:58, [email-masked] wrote:
> Internet-Draft directories: http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 

_______________________________________________
Anima mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/anima

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 26 Oct 2021 23:10:14 +0800

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?

    IMHO, the shared secret may be initially used when joining into the ACP plane, just like a token. 

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

Best Regards
Zongpeng Du

[email-masked] & [email-masked]
 
From: Liyizhou
Date: 2021-10-20 15:14
To: Brian E Carpenter; [email-masked]
CC: Anima WG
Subject: Re: [Anima] I-D Action: draft-yizhou-anima-l2-acp-based-ani-00.txt
Hi Brian and all,

 

 

 

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

 

Also you write:

 

 
Regards
   Brian Carpenter

---

From: Michael Richardson <[email-masked]>
Date: Tue, 26 Oct 2021 14:06:34 -0400

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-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Richardson <[email-masked]>
Date: Tue, 26 Oct 2021 14:09:21 -0400

Liyizhou <[email-masked]> wrote:
    > A campus network may contain the different types of equipment, L2
    > switches,

unmanaged L2 switches?
Or managed L2 switches with L3 addresses for their control plane?

    > 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.

Yes. It's a regular disaster when loops form and the STP turns off the wrong
port, and then the network breaks.

    > Then a collection of the physical connection/topology would
    > be required to check to see if the cabling is correctly made.

SNMP/YANG collection of LLDP adjacency data would seem to be the correct process here.

    > 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.

That seems like the wrong way to do things.

---

From: Liyizhou <[email-masked]>
Date: Wed, 27 Oct 2021 02:36:43 +0000

Hi Zongpeng,

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

Rgds,
Yizhou

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, October 26, 2021 11:10 PM
To: Liyizhou <[email-masked]>; Brian E Carpenter <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: Re: [Anima] I-D Action: draft-yizhou-anima-l2-acp-based-ani-00.txt

Hi Yizhou and Brian,

    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.

Best Regards
Zongpeng Du
________________________________
[email-masked]<mailto:[email-masked]> & [email-masked]<mailto:[email-masked]>

From: Liyizhou<mailto:[email-masked]>
Date: 2021-10-20 15:14
To: Brian E Carpenter<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
CC: Anima WG<mailto:[email-masked]>
Subject: Re: [Anima] I-D Action: draft-yizhou-anima-l2-acp-based-ani-00.txt
Hi Brian and all,

Yizhou

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

Hi,

Also you write:

Regards
   Brian Carpenter

On 19-Oct-21 20:58, [email-masked]<mailto:[email-masked]> wrote:
> [email-masked]<mailto:[email-masked]>

_______________________________________________
Anima mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/anima

_______________________________________________
Anima mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/anima

---

From: Liyizhou <[email-masked]>
Date: Thu, 28 Oct 2021 03:59:06 +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:[email-masked]] On Behalf Of Michael Richardson
Sent: Wednesday, October 27, 2021 2:07 AM
To: Anima WG <[email-masked]>
Subject: Re: [Anima] I-D Action: draft-yizhou-anima-l2-acp-based-ani-00.txt

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.)

>   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:

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.

---

From: Liyizhou <[email-masked]>
Date: Thu, 28 Oct 2021 06:58:10 +0000

Hi Michael,

Please see inlines with [yz]. Thanks.

Yizhou

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

unmanaged L2 switches?

[yz] Right, also corrected in another email. It refers to something like "the interface cannot or is not configured to automatically get IP address without any external exchange."  

    > quite common that all the nodes are enrolled as layer 2 to form a layer

Yes. It's a regular disaster when loops form and the STP turns off the wrong port, and then the network breaks.

[yz] Yes. We normally want to turn on STP on access ports and turn them off on trunk ports. Before getting plugged, it may not be so clear which ports will be used as trunk ports. So when turning off STP, there is a risk of loop though we basically trust network admin can do correct cabling.
The ambition is to form a L2 ACP without requiring STP and without requiring IP reachability first in the management plane. Too ambitious? 

[yz] It can be done in this way. But again, it requires IP reachability first.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Oct 2021 15:41:37 +1300

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:
> 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.
> 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.