Re: [lisp] AD Evaluation: draft-ietf-lisp-introduction

[Brian Haberman <[e-mail]>]

Albert,
     That all works for me.

Regards,
Brian


On 1/20/15 8:00 AM, Albert Cabellos wrote:
> Hi
> 
> Thanks, please see inline my replies (removed text for which we all agree):
> 
> 
>> [snip]
>>
> 
> 
>>>
>>>>> * The discussion of SMR should contain a reference to 6830 or a
>>>>> brief discussion of how the SMR is used.
>>>>>
>>>
>>> Could you please elaborate further this comment?
>>>
>>> "Solicit-Map-Request (SMR):  SMR is an explicit mechanism to update
>>> mapping information.  In particular a special type of Map-Request can
>>> be sent on demand by ETRs to request refreshing a mapping. Upon
>>> reception of a SMR message, the ITR must refresh the bindings by
>>> sending a Map-Request to the Mapping System."
>>
>> There are more interesting conditions/rules for the use of SMR that are
>> only found in RFC 6830.  I am suggesting adding a reference to 6830 at
>> this point so readers know where to go to find more info on the SMR.
>>
>>
> Agreed, I´ll add a sentence.
> 
> Further uses of SMRs are documented in [RFC6830].
> 
> 
>>>
>>>>> 8. Section 5
>>>>>
>>>>> * I would suggest having a reference to both the MIP and the NEMO
>>>>> specs when discussing mobility.  LISP has the potential to
>>>>> operate in a manner conducive with NEMO if the xTR acts as the
>>>>> NEMO Mobile Router.
>>>>
>>>> Well if we do that then there are a ton of other cases where a xTR
>>>> can be co-located with other functions (i.e. a simple reference is
>>>> say a wifi AP). So singlingly out MIP/NEMO seems to be favoring
>>>> these technologies versus others. Why would we want to do that?
>>>>
>>>> Plus, it raises questions more than simplifies the understanding of
>>>> LISP. This is an intro document.
>>>
>>> What about adding the following sentence at the end of section 5?
>>>
>>> The decoupled identity and location provided by LISP allows it to
>>> operate with other layer 2 and layer 3 mobility solutions.
>>
>> The text talks about both network (NEMO) and host (MIP) mobility.  I am
>> not concerned with LISP interacting with those protocols, I am thinking
>> of how LISP replaces those protocols.  The descriptions in Section 5
>> align with very well (i.e., the first paragraph describes LISP replacing
>> NEMO and the second paragraph describes LISP replacing MIP).  My
>> proposal was to simply add references in those paragraphs to the
>> mobility protocol that LISP is approximately.
>>
>> I do like your proposed addition in order to highlight that LISP will
>> not interfere with other mobility solutions.
>>
>>
> What about adding two sentences at the end of each paragraph:
> 
> This functionality is similar to [RFC NEMO].
> This functionality is similar to [RFC MIP] [RFC MIPv6].
> 
>  [snip]
> 
>>>> 10. I am surprised that there are 2 Security Consideration
>>>>> sections (7 & 9).  I am even more surprised that one says
>>>>> "Nothing new here" and the other actually discusses potential
>>>>> issues with the LISP approach.
>>>>>
>>>
>>> My fault, Section 7 should be “LISP Security Considerations”
>>>
>>> Section 9 describes the security considerations for the document
>>> itself.
>>
>> I think maintaining two security consideration sections will be
>> confusing.  Either document that *this* document introduces no new
>> security issues or have the security considerations section summarize
>> the security impacts of LISP.
>>
>>
> Agreed, will do the latter (so Section 9 is now Section 7).
> 
> 
> 
>> Regards,
>> Brian
>>
>>
>>
>>
>