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

Albert Cabellos <albert.cabellos@gmail.com> Tue, 20 January 2015 13:00 UTC

Return-Path: <albert.cabellos@gmail.com>
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 0A48E1B2A29 for <lisp@ietfa.amsl.com>; Tue, 20 Jan 2015 05:00:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 ZJajn5b26Sc4 for <lisp@ietfa.amsl.com>; Tue, 20 Jan 2015 05:00:31 -0800 (PST)
Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C138B1AD375 for <lisp@ietf.org>; Tue, 20 Jan 2015 05:00:30 -0800 (PST)
Received: by mail-qg0-f54.google.com with SMTP id q108so2604477qgd.13 for <lisp@ietf.org>; Tue, 20 Jan 2015 05:00:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=RBcsmBwuJGkIXEMIl/MNzEE8Vf5RulOjW/9aNS6+X1k=; b=xzpgU8Y7D6avaR2cBEEgAsjrdPwHl97SFdPFedadZECa8la+xU1G6OBmBrjN1LK0kO nx9BYxwmtm5yuNsLZx1fcSvZOGu/utSO61+7SvJeqyH6C2SocIYcFq50VaGivX1H9JSF wnDeL8fPPu4qFDXfREVzyeWrMA0MsQL+V7Ub6RKr4DKEDDlwDFAkaj5tTfvVW4A4axK+ xozvL+EQC6L19/GM09dBUS+FsXHE/vqXQbOe9ctP4nD8Ih86VwafjWGURxZzCM1ZK3Ru 7ksduNK2KfO5SEmPQwjlWY05wrZ4jhFLuhJ3DJbry6mxdK9zeqQ/MQpOL+Hjm/B7rekA Sttw==
MIME-Version: 1.0
X-Received: by 10.224.61.1 with SMTP id r1mr37270939qah.0.1421758829974; Tue, 20 Jan 2015 05:00:29 -0800 (PST)
Received: by 10.96.67.101 with HTTP; Tue, 20 Jan 2015 05:00:29 -0800 (PST)
In-Reply-To: <54BD1B88.30900@innovationslab.net>
References: <54B698A7.1080309@innovationslab.net> <6064CA71-36A7-421A-A2F3-FDCEAF25F3EB@gmail.com> <1C31C60B-19D7-4421-92C6-878976064E83@gmail.com> <54BD1B88.30900@innovationslab.net>
Date: Tue, 20 Jan 2015 14:00:29 +0100
Message-ID: <CAGE_Qeyxx1xeG+bUUABhLqs-gMpefSagfGZ1c=0-NY9bq=H0kg@mail.gmail.com>
From: Albert Cabellos <albert.cabellos@gmail.com>
To: Brian Haberman <brian@innovationslab.net>
Content-Type: multipart/alternative; boundary=001a11c3f4d4047001050d15068f
Archived-At: <http://mailarchive.ietf.org/arch/msg/lisp/b5xTeYGD5Z1MI7YBkcVkpBWUKLo>
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
Reply-To: acabello@ac.upc.edu
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:00:38 -0000

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