Re: [lisp] Capabilities Type LCAF - a proposal

[Damien Saucez <[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 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 <[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