Brian E Carpenter <[email protected]> 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 <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
