>> 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
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
