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 protected] & [email protected]
From: Liyizhou
Date: 2021-10-20 15:14
To: Brian E Carpenter; [email protected]
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:[email protected]] On Behalf Of Brian E Carpenter
Sent: Wednesday, October 20, 2021 9:37 AM
To: [email protected]
Cc: Anima WG <[email protected]>
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, [email protected] 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 protected]
> 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
[email protected]
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
