Re: [lisp] draft-ietf-lisp-lcaf-03 available for discussion (but not posted)

[Dino Farinacci <[e-mail]>]

>> On a related note, I find very general LCAFs a cause for concern. Particular the JSON LCAF, which seems to allow the mapping system to reprogram the packet processing hardware on the fly seems excessive.  I understand it is neat for experimentation.  But how does something injecting a JSON LCAF have a reasonable judgment about whether the ITR which will receive it will be able to implement the processing required?
> 
> Beyond the LCAF type, we can include a fixed size type that will tell the ITR if it is able to implement the processing required. From there we can define types that can be only used intra-domain or that are maningful inter-domain, again like XML applications.

It has been suggested before that we should define an LCAF type that identifies the capabilities an xTR can support. It should be clear what an ETR supports by what it registers, but one cannot tell if the ITR can use the information an ETR has registered. 

So I am not sure how this could be useful. I guess an ITR could register "I support AFI=1 and Geo only" and if the ETR registered {AFI=1, AFI-2, Geo, and ELP}, that it would only return in a Map-Reply to the ITR {AFI=1 and Geo}.

Just thinking out loud.

Dino