> First, we will like to see a 5-tuple LCAF to allow mapping lookups based on > flows. In the attached TXT there is a proposed format. It allows to perform > exact match flow lookups, as well as best match lookups using port range and > prefix mask length. The proposed 5-tuple LCAF is based on current types 4 and > 12, and can be a new type itself, or be merged with those types.
At the risk of adding too many new LCAFs with too many combinations, this is what I propose. (1) Change Type 4 to include port ranges. (2) Use Type 4 and Type 12 together in a AFI-List type. That should serve all purposes. > Second, we find interesting to have a generic (self-defined) LCAF type. A > format like that will allow complex and/or experimental LISP applications. We > aim for a binary JSON-like format. This LCAF type almost needs no definition, > just a new LCAF type number and an agreement on the binary specification to > use. Personally, I like the Universal Binary JSON Specification > (http://ubjson.org/). I think we should call it the JSON LCAF type so an EID or RLOC encoding is known to be JSON tuples. But I think they way this will be used is to use a regularly encoded EID and what is returned is a JSON encoded RLOC. Also, I am not sure that binary coding is required. I can imagine some people wanting a XML encoding as well. And that would be in ascii or unicode. I will propose text and the working group can comment on the text. Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
