Re: [lisp] Capabilities Type LCAF - a proposal

[Dino Farinacci <[e-mail]>]

> 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 <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lisp
>