> 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 didn't have anything specific in mind. I just wanted an ITR/ETR pair to know if they could do a feature and what to do if one supported the feature and the other one did not. > 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 Always reply, but state what you support so the capabilities bits can be compared at the ITR to see what is in common. > saying "bad luck no match for the capability"? If 0 locators then it There is always a baseline for what you support. That is what is in RFC 6830. So if an ITR wanted Geo-Coordinates returned in a RLOC-record, and the ETR did not support that, it would return an RLOC-record with a single-tuple (with just an AFI-encoded RLOC address) versus the two-tuple (with the AFI-encoded RLOC address and the LCAF-encoded Geo-Coordinates). And then the ITR would just encapsulate to the RLOC as it does today. > 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? There is no need for a new message. That would complicate matters and create more combinations to deal with when receiving responses. Dino > > 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
