Dino, Sorry for the delay, I see this proposition just now.
Do you propose this capability in the context of VPN and/or NSC? I would have a question, if there is capability, it means that there is a possibility to meet no capability so in this case what is replied? An record with 0 locators? no answer? a special answer saying "bad luck no match for the capability"? If 0 locators then it is a negative reply but conceptually this is not a negative reply. If no answer, then the requester will keep continuing sending requests. If a new message, what kind of message? Thanks, Damien Saucez On 12 Sep 2013, at 20:29, Dino Farinacci <[email protected]> wrote: > So wouldn't be useful if an ITR which sends a Map-Request to the mapping > system, could say "I know Mr. ETR that you have registered a bunch of stuff > to the mapping system, but can you return just the stuff I care about and > more importantly the stuff I support in my implementation?". > > So I was thinking (and talking to several others about this), if we could > have a Capabilities Type LCAF that is encoded in an address field of the > Map-Request. I would like to propose that it get encoded in the ITR-RLOCs > field of a Map-Request. This way, each ITR in the ITR-RLOCs list could tell a > Map-Replier what they support. > > I would propose that the Capabilities Type LCAF be encoded as a bit-string. > Where each bit position indicates the LCAF Type value. We would have 2 > fields, an EID field and a RLOC field so it can be conveyed which Types are > supported for EID encoded fields or RLOC encoded fields in any LISP control > message. > > It would be required of every implementation to support the Capabilities Type > LCAF if nothing else would be supported. That would get the implementations > to do the general parsing work so they could skip over LCAFs they don't > understand and get to the ones they do understand while conveying what they > support. > > Also I find that this may be useful for this world of multiple > encapsulations. Rather than register UDP port numbers, a decapsulator could > convey what encapsulations it supports (i.e. L3-LISP, L2-LISP, VXLAN, NVGRE, > IPsec, GRE, whatever-new-thing-nv03-comes-up-with). > > The Capabilities Type LCAF could also be used by the mapping system. So when > an ETR sends an Info-Request, an Info-Reply from the map-server could tell > the registering system what LCAFs it supported. Ditto, for asking > map-resolvers what types of EID encodings they could support (maybe the > mapping system can support more LCAF encodings then the map-resolvers, so you > can choose a different map-resolver if you wanted more). > > And arguably, the Capabilities Type LCAF could be put in RLOC-probes. It > could go anywhere with the address you wanted to encode as a 2-tuple. > > Comments? > > If people are interested I can draft up the details for the -03 version. Or > if you think we should post the -03 version just with the current changes, I > can do that. And also comment if you think we should go with the JSON Data > Model Type for -03 or put it into -04 with perhaps this Capabilities LCAF. > > Thanks, > Dino > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
