https://datatracker.ietf.org/doc/html/draft-barkai-lisp-pems
> On Nov 21, 2022, at 20:33, Dino Farinacci <[email protected]> wrote: > > Yes, everything you can define the better. Even a "socket" since its an > overloaded term. Plus you want to define terms based on how the document is > going to use them. So defining "EID" in the context of your document would > make the ideas more clear. Like an EID in this spec defines an object versus > a host. Added > > I don't think there is a standard format for describing the API. Just calls > and input and output parameter descriptions you should include. Added QueueRead(EID, Frame) ChannelWrite(EID, EID, Frame) > > As for eBPF, just describe what filters you are need to use to associate > packet flows with an EID. And that this is a local matter and the flows are > NOT put in the mapping system like it could be for the Multi-Tuple draft. Queues receive: [[ Frame Packets ] Source EID, Socket EID] RTR RLOC, Current Host RLOC] Channels send : [[ Frame Packets ] Socket EID, Theme EID] Current Host RLOC, RTR RLOC] > > I am not sure who you are referring to but I know a lot of people that use > eBPF. You should google for a list name and propose they review the document > and definitely invite them to IETF. > ok > Dino > >>
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
