On 11/06/2017 03:20, Michael Richardson wrote:
>
> 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)
Yes, I understand that, which is why I was asking about the number of
interfaces that a GRASP instance will see in the earlier thread that
I referenced. I still need to see an API for the adjacency table to
be certain, but I believe I understand how GRASP will use those
interfaces.
> 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.
Right, there is absolutely no need for a multicast routing protocol.
> And GRASP do it the right thing now, so I'm really lost as to what the
> concern is.
Efficiency, basically. Reading on...
> 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.
OK, let's work with that. If a node has 4 interfaces and 4 GRASP neighbours
per interface, your model will have the GRASP core replicating each discovery
and flood message 16 times, because it will see 16 ACP interfaces. So there
will be 16 separately encrypted messages. That's not a disaster. But for
discovery, there will also be 16 potential responses, all of which
have to be waited for and collected up. It will work (although I wouldn't
recommend coding it the way I coded the prototype, because it would also
generate 16 threads). It just doesn't feel optimal.
Anyway my real request, before I feel ready for an ACP WGLC, is to see
at least notionally what the ACP's API will look like, including the
API for the adjacency table.
Thanks
Brian
> 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 =-
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
