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

Brian Haberman <brian@innovationslab.net> Tue, 20 January 2015 13:09 UTC

Return-Path: <brian@innovationslab.net>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE681B2A33 for <lisp@ietfa.amsl.com>; Tue, 20 Jan 2015 05:09:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uehm-tF87wT0 for <lisp@ietfa.amsl.com>; Tue, 20 Jan 2015 05:09:49 -0800 (PST)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5D751B2A2D for <lisp@ietf.org>; Tue, 20 Jan 2015 05:09:49 -0800 (PST)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id A967888126; Tue, 20 Jan 2015 05:09:49 -0800 (PST)
Received: from clemson.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 4D57A71C0002; Tue, 20 Jan 2015 05:09:48 -0800 (PST)
Message-ID: <54BE539A.5060602@innovationslab.net>
Date: Tue, 20 Jan 2015 08:09:46 -0500
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Albert Cabellos <albert.cabellos@gmail.com>
References: <54B698A7.1080309@innovationslab.net> <6064CA71-36A7-421A-A2F3-FDCEAF25F3EB@gmail.com> <1C31C60B-19D7-4421-92C6-878976064E83@gmail.com> <54BD1B88.30900@innovationslab.net> <CAGE_Qeyxx1xeG+bUUABhLqs-gMpefSagfGZ1c=0-NY9bq=H0kg@mail.gmail.com>
In-Reply-To: <CAGE_Qeyxx1xeG+bUUABhLqs-gMpefSagfGZ1c=0-NY9bq=H0kg@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2L2cEVkt3W2N8NC9I4N9bAOLbRpmcOv61"
Archived-At: <http://mailarchive.ietf.org/arch/msg/lisp/fJtdV63WaJqMTC0bSYRM-AXb638>
Cc: "lisp-chairs@tools.ietf.org" <lisp-chairs@tools.ietf.org>, draft-ietf-lisp-introduction@tools.ietf.org, "lisp@ietf.org" <lisp@ietf.org>
Subject: Re: [lisp] AD Evaluation: draft-ietf-lisp-introduction
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Jan 2015 13:09:53 -0000

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