Re: [Anima] ACP [was I-D Action: draft-ietf-anima-grasp-13.txt - SONN]

[Michael Richardson <[e-mail]>]

Brian E Carpenter <[e-mail]> wrote:
    > If the VRF simply emulates multicast sending, that is a trvial
    > stateless process, and the GRASP state goes like N(interfaces).

Again, the ACP VRF is a set of PPP links over IPsec tunnels.
It will show up as interfaces with seperate ifindex.
(Replacing IPsec with another IP-level security mechanism won't change this)

A long time ago, I asked carefully if it was intended that GRASP to be
providing application layer multicast (vs supporting multicast across the ACP
via PIM or MPL), and the response I got was that GRASP would do it.

And GRASP do it the right thing now, so I'm really lost as to what the
concern is.

Putting on my ISP architect hat:

In a realistic ISP situations, the occurances of having more than
one or two ACP peers on a single physical link is pretty rare.
The exception would be at access networks that look like ethernet. (Cable,
FTTH, GPONs).

xDSL networks tend to use PPPoE, so have a seperate interface per CPE device.
b2b ISPs that use GPON tend to split off the customer traffic into seperate
VLANs, although both they and Cable networks usually put the GPON
terminals/Cable_modem management into a VLAN seperate from the customer
traffic.   At this point, these networks are using TR-069 for management
with a transition from SOAP to NETCONF apparently on the way.

So for initial deployment of ACP, I expect not to see more than 3-4 devices
per link.  The interface between the access devices and the core devices may
initially have a higher fan-out, until one looks at the actual wires, and
realizes that the layer-2 switching hardware in between ought to be involved
in the ACP, and then the ACP devolves to point to point ethernet cables.

Whether Metro-Ethernet rings will be presented to the ACP as a single link
with many nodes (ignoring all the layer-2 topology), or whether the layer-2
topology will be revealed will, I think be a question of evolution.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-