Speaking personally, I have some concerns about this.
I think my concerns can be lumped into two related categories. Bother
are about interoperability.
Firstly, I find the registration of LCAFs without any explanation of how
or why they would be used to be awkward. I know that some members of
the WG like to have everything in one document. But this is why we
maintain registries. Once we have defined LCAFs, it is quite sensible
for documents which need LCAFs to add them to the registry, with the
explanation of how and why the particular LCAF is beign defined.
Note that unlike base protocol mechanisms, the set of LCAFs is not
something that all implementations need to understand. A LISP
implementation that is never going to do 5-tuple lookup does not need to
know about LCAFs that are designed to handle that. And conversely
defining new LCAFs ought in my view create an obligation for new
behavior in all LISP devices. (I don't think the authors intend that
kind of obligation.)
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?
If we are assuming particular deployment models, we need to describe
that. (Which leads to the question as to why it is in this document.)
I may be in the rough on these concerns.
Yours,
Joel
On 9/10/13 12:35 AM, Dino Farinacci wrote:
Folks, I compiled all the input I received for updates to the LCAF draft. Find
enclosed the updated draft and a diff file.
Deadline is tomorrow but we can have discussion before I post. So if there are
any changes or comments, I can add them into the -03 draft. So I am not that
worried about missing the deadline.
Changes include:
B.1. Changes to draft-ietf-lisp-lcaf-03.txt
o Submitted September 2013.
o Updated references and author's affliations.
o Added Instance-ID to the Multicast Info Type so there is relative
ease in parsing (S,G) entries within a VPN.
o Add port range encodings to the Application Data LCAF Type.
o Add a new JSON LCAF Type.
o Add Address Key/Value LCAF Type to allow attributes to be attached
to an address.
Dino
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
