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

[Albert Cabellos <[e-mail]>]

El 10/09/2013 10:30, Joel M. Halpern escribió:
> 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.)
>

This is precisely the reason to standardize a flexible LCAF, there is no 
obligation to implement all the LCAFs defined, but just the ones that 
are used by a particular ITR. Pretty much like XML and the XML applications.
> 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.

> 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.)
>
Fully agree with this, two of the main reasons are flexiblity and to 
reduce the deployment cost of new applications of LISP. With the 
flexible LCAF we only need to update the ITR, not the mapping system. 
This is an important barrier for experimentation or new uses right now. 
Otherwise and as you mention, we will have to face and endless amount of 
LCAF types, one for each LISP use.

Regards

Albert

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