> 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
We have companion documents (that are not working group chartered documents). Here are some examples: (1) The draft-ermagen-nat-travesal draft states how to use the NAT-Traversal LCAF type. (2) The draft-farinacci-lisp-te draft states how to use the Explicit Locator Path (ELP) LCAF type. (3) The draft-codas-lisp-re draft states how to use the Replication List Entry (RLE) LCAF type. (4) The draft-ietf-lisp-ddt draft stats how to use the Security LCAF type for LISP-DDT-sec. > 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. So I would suspect that the JSON Data Model Type would have a companion document. > 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 Correct. > 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.) This is generally true but I am finding more use-cases, where people just want to store data in the RLOC LCAF encoding for easier management and network-self-documentation. > 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 The LCAF document doesn't say how the JSON Data Model LCAF will be used so we can't assume it is for the case you state above. > 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.) What we have done in two cases for similar compatibility issues is this: (1) For wanting to store Geo-Coordinates with RLOCs for ITRs that do not understand it, you encode the Geo-Coordinates LCAF type along with an AFI=1 or AFI=2 RLOC address in a AFI-List LCAF RLOC record. Then the ITR that doesn't understand the first AFI in the AFI-List (the Geo-Coordinate encoding), skips over it and goes to the next AFI in the AFI-List LCAF, where low and behold, there is an address it can encapsulate to. (2) The above is done for ELP encodings too. Dino > 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
