> If I were writing these things, I would put the registration for each of > those types in the companion document. That way, a reader could judge the > safety and utility of the proposed usage. Otherwise, the registration itself > is not understandable.
I found putting them in one document, as an implementor, was extremely useful. Because if I do multiple LCAF features, I want to see how the designs can work either side-by-side or integrated with each other. Here is an example. There is no reason that one leg of an RLE could not be an Explicit Locator Path. > Asked backwards, why is there value in putting a bunch of IDs that are not > needed in base implementation into a spec that does not explain what they are > for? The LCAF, in a coarse matter, describes what an LCAF coding could be used for. And the companion document goes into way more detail and precisely specs the operation. Dino > > Yours, > Joel > > On 9/10/13 11:01 AM, Dino Farinacci wrote: >>> 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
