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

> 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
>>>> 
>> 
>> 