> Speaking personally, I find the notion of treating the ITR capability as a > LCAF included in the request message to be very undesirable. It clearly can > work. But it looks like a fairly bad misuse of the tools. One which will > cause us trouble down the road.
Perhaps you are right. That and the previous lack of interest, is why I let the effort go and didn't persue it further. Dino > > Yours, > Joel > > On 11/20/13 1:17 PM, Dino Farinacci wrote: >>> 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 >> _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
