On 12/11/2016 15:52, Michael Richardson wrote: > > Toerless Eckert <[email protected]> wrote: > >> Which, I have to point out, is not a consensus position; design teams > >> propose, they don't decide. I'm waiting to see the next draft before I > >> raise this issue on the WG list. > > > Right. I guess we've now posted all drafts we can before the deadline, > > so let me change this mail threads subject to get the discussion > > started. > > ... > > > b) I have just posted ACP draft -04 in which i have reversed the choice > > of mDNS for ACP discovery by neighbors from the -03 text which had > > mDNS. So -04 defines to use (DULL) GRASP for ACP discovery with more > > details. > > Cool. I think that this is the right way. I am just not certain that we > need a TCP reply to the M_DISCOVERY... the simple fact of receiving the > multicast M_DISCOVERY tells one about the peer. > That would be some new mode of GRASP, I think though. > > > I am not sure i understand the documentation ask. The ACP has a bunch > > of (virtual) interfaces. In the most simple implementation option, each > > ACP channel to an ACP neighbor is its own (p2p) L3 interface in the > > ACP. And thats all the interfaces the ACP has. > > Ditto. > > > Ues, i am mostly interested in use-case explanations Michael has in > > mind. > > > The other piece was that Michael was trying to figure out how to avoid > > using LL multicast and instead use unicast: > > It wasn't so much that I want to avoid the "LL" multicast, so much as that > it's kinda redundant, as the ACP is a p2p system. Both ends know where the > other end is, might as well just leave a TCP connection up between them. > It's basically the same as a BGP4 in many ways...
I don't care how it's implemented inside the ACP. The GRASP engine has to send its discovery and floood messages to all on-link neighbours, and no off-link neighbours, so it needs to *look like* a LL multicast socket, whatever the ACP VRF does internally. > BC> Given how ACP interfaces are p2p secured interfaces to neigbhors, you > BC> could know upfront the LL IPv6 address of the neighbor on the > BC> interface, but there is really no framework in IETF protocols that > BC> leverages this optimization for p2p links, so i don't think we should > BC> bother doing it. Its work without RoI. That wasn't BC. > > I see it as simplying myself. > > > The big security risk though is GLOBAL UNICAST MUST NOT BE > > PERMITTED as a replacement for LL multicast. Thats an attack > > vector. And typical socket software code is usually victim to > > Agreed. Sure. Who ever suggested that? Brian _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
