On Fri, Nov 04, 2016 at 08:33:43PM +1300, Brian E Carpenter wrote:
> > GRASP should have a separate socket for each interface
>
> How many interfaces do you mean? With no ACP, GRASP knows a reasonably
> small number of physical interfaces, and has to open a socket for each of
> the to send LL multicasts, and it has to listen for LL multicast from
> all of them, which as far as I know requires a separate socket that is bound
> to the relevant multicast address.
If each physcial interface connects to one ACP neighbor, the number
of logical ACP interfaces would be the same as the number of physical
interfaces. If an interface is a LAN connecting to N ACP neighbors,
you would have N ACP virtual interfaces, one for each such neighbor.
In an implementation of ACP that i could imagine.
Of course, on a LAN with N ACP neighbors, those would be eg: routers
interconnected via a switch, so if that switch was autonomic itself, then
you should only see one ACP neighbor, the switch. That the point of the
discussion about GRASP instead of mDNS for ACP discovery, and of course,
on the switch, we'd need to figure out how to intercept the ACP messages
to make that work.
> In addition it has to open unicast sockets as and when needed, which may
> be bound to any kind of address. (In the limited instances they will
> be restricted to link-local unicast, but that's a special case.)
>
> I am still missing enough detail about the interfaces and socket options
> that the ACP will provide to know how this will change when the ACP
> is there. If there are, e.g., 400 autonomic nodes in the ACP and my node
> has 4 physical interfaces, each of which has 10 link-local neighbors,
> how many interfaces will the ACP offer me? 4, 40, 400?
Never 400. 4 if the L2 switches on the LANs are ACP capable, 40
otherwise.
> > - but use that
> > socket both for sending and receiving. No shared socket for reception.
>
> Why not? There's no problem identifying the source interface for a multicast,
> it comes right back in recvfrom() (at least on Windows or Linux).
I probably should not have used "should" when i was recommending
a separate socket per interface but instead:
-> To me the logic of dealing with multiple interfaces wold be most
easy if an implementation could have a separate socket for each
interface, physcial and ACP-channel (aka: per ACP neighbor).
With that approach, its clear at the socket level, which sockets
belong to which security domain, and you do not have to
enforce that via filtering when you receive messages.
Socket API is a lot of confusing complexity. I haven't played with LL
IP6 myself on linux, so i can only guess:
- Lets assume you bind your socket to the LL IPv6 address of an interface
via what the API doc calls the "scope ID" (which really is a zone ID).
You should then be able to send/receive only from/to that interface.
- I am not sure what impact this has on multicast. I was hoping that you
could still do the setsockopt to add the GRASP LL IPv6 multicasr group,
and in that API call you'd equally indicate your LL IPv6 addr and
would then send and receive IPv6 LL multicast only on that interface.
I have not tested this, so this is right now just conjecture.
> > GARSP only needs to figure out which interface is physcial and which
> > is ACP. On router-OSs, each interface would be assigned to a VRF, so
> > it's easy to enumerate the interfaces of eg: the ACP being one VRF.
>
> I would assume that the adjacency table would provide that sort of clue.
> To make my code agnostic about Winsock vs POSIX, I just use the interface
> numbers, not the names, and they should be system-wide unique.
Have to look at your code..
> > Right. But this is not a new ACP thing. Any existing IETF protocol
> > implementation that uses link-local addresses and runs on any type of
> > any form of physical or virtual interface needs some form of interface
> > representation at the API level to send/receive LL packets. Thats why
> > i am somewhat hesitant to add explanatory text for this to the ACP
> > draft. It's supposed to be implied by the IPv6 addressing model and
> > common practice in IETF documents that its not regurgitated too much.
>
> No, it doesn't need much text but it really isn't obvious at all from
> the ACP draft, I assure you.
Can you propose text ?
Cheers
Toerless
> >> If you want, I can point you the exact Python code that handles this
> >> in the prototype.
> >
> > Please do. Just not sure when i'll find time.
>
> Let me do that when I'm back from my short vacation.
>
> Rgds
> Brian
>
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
