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?

    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

duzongpeng@foxmail.com & duzongpeng@chinamobile.com

From: Liyizhou
Date: 2021-10-20 15:14
To: Brian E Carpenter; draft-yizhou-anima-l2-acp-based-ani@ietf.org
CC: Anima WG
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
Cc: Anima WG <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 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
> 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
https://www.ietf.org/mailman/listinfo/anima

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