On 04/11/2016 13:35, Toerless Eckert wrote: > On Tue, Nov 01, 2016 at 01:59:17PM +1300, Brian E Carpenter wrote: >> I will read that carefully, but for me that doesn't need justification, >> because >> we need the ANI to be self-contained, so depending on mDNS seems wrong. (In >> fact, why wouldn't configuring mDNS/DNS-SD/DNS be an autonomic function >> itself?) > > Just justification why to use GRASP instead of CDP/LDP/mDNS based on > the rule "ANIMA should reuse first, and invent only when reuse is not > a sufficient solution to meet requirements". > > For example: for GRASP inside ACP we didn't need to put in justification > because > nobody ever claimed that there are equivalent prior IETF solutions. > >> And that's the problem. GRASP discovery and flooding need sockets that >> supports link-local multicast sending and receiving for each physical >> interface. >> >> Currently the GRASP code finds out how many physical interfaces it has >> and for each one creates a multicast sending socket. It also has a socket >> that listens for incoming link-local multicasts on all physical interfaces. >> I don't see how to do that using the ACP interfaces that you describe. > > 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. 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? > - 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). > 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. > In Linux the closest equivalent are network contexts. ACP could be one > network context. Compared to router-OS, linux is more secure/constrained: > Processes only have access to one network context. So you'd have to run > separate GRASP processes. Which may be a good thing. Yes. Actually I run multiple GRASP kernels all the time for my testing scenarios; it works nicely. > >>> All packets, unicast or multicast that are sent into or >>> received from those interfaces are protected/encrypted by the fact that >>> they are transmitted >>> encrypted by the seleted ACP channel encryption protocol. >> >> Yes, and I'd like the LL multicast traffic to be protected too. >> But as far as I can see that needs explicit support in the ACP >> to emulate LL multicast sockets. The ideal would be that the ACP >> simply emulates LL interfaces, so that GRASP could treat them exactly >> like physical interfaces. > > 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. > >> 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
