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

Dino Farinacci <farinacci@gmail.com> Mon, 19 January 2015 17:56 UTC

Return-Path: <farinacci@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 734CC1B2BDF for <lisp@ietfa.amsl.com>; Mon, 19 Jan 2015 09:56:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 pP4E-jF15b_E for <lisp@ietfa.amsl.com>; Mon, 19 Jan 2015 09:56:52 -0800 (PST)
Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 654ED1B2BD7 for <lisp@ietf.org>; Mon, 19 Jan 2015 09:56:52 -0800 (PST)
Received: by mail-pa0-f50.google.com with SMTP id bj1so40107936pad.9 for <lisp@ietf.org>; Mon, 19 Jan 2015 09:56:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U35Bi2lkz+U2q2yxIZiLKvngfQ8NXgC4SRjZ9D0XEuE=; b=DBlmkhpppJ6dCpue8zWUYJdvK8MuBnkguJvlB2rOBelvvg4vL1riDxagU8c1yXAKGl YB+GmhaK5uhkwSeK5mUdHkIeg5Igey/qKoDTPcZirk5vKdxOSld9q06F9JEdEaCmYP7Q RyUVBmSRASCUGuM4J7wEBhI0qDX/l6WyAWvCZ8kirYRNW9oRqiB7RC1RXlscPwzVpvfk iur5TMvIL6Ry3kN2atTzYN7B9n1STz3UUtbq40JSESJTTdd/pH2CQU5eWdBJ05rj2m2X S1CVCvrX6ooqZ1+U7b46SkmllnaN5fz3bNPmKYTCH3929mL0jkX1tVhkITQFjCGT2yPx ImKA==
X-Received: by 10.66.97.6 with SMTP id dw6mr20106410pab.114.1421690211654; Mon, 19 Jan 2015 09:56:51 -0800 (PST)
Received: from [10.169.113.83] (71-6-80-11.static-ip.telepacific.net. [71.6.80.11]) by mx.google.com with ESMTPSA id uk5sm732764pbc.17.2015.01.19.09.56.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Jan 2015 09:56:51 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <54BD186C.9020401@innovationslab.net>
Date: Mon, 19 Jan 2015 09:56:54 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <35BBD0D7-FBC9-4B39-9BEF-BBBC7AD61583@gmail.com>
References: <54B698A7.1080309@innovationslab.net> <6064CA71-36A7-421A-A2F3-FDCEAF25F3EB@gmail.com> <54BD186C.9020401@innovationslab.net>
To: Brian Haberman <brian@innovationslab.net>
X-Mailer: Apple Mail (2.1993)
Archived-At: <http://mailarchive.ietf.org/arch/msg/lisp/nvo2GZPp_uGGEu8GWgEem3bOh9I>
Cc: draft-ietf-lisp-introduction@tools.ietf.org, "lisp@ietf.org" <lisp@ietf.org>, "lisp-chairs@tools.ietf.org" <lisp-chairs@tools.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: Mon, 19 Jan 2015 17:56:54 -0000

Since you responded Brian to Albert's email and have commented and agreed to most of the changes, I don't need to respond to each point below. I think we are golden. Agree?

Dino

> On Jan 19, 2015, at 6:45 AM, Brian Haberman <brian@innovationslab.net> wrote:
> 
> Hi Dino,
> 
> On 1/14/15 1:10 PM, Dino Farinacci wrote:
>> Here are some brief responses to your comments Brian. Thanks for
>> doing the throuogh review.
>> 
>>> On Jan 14, 2015, at 8:26 AM, Brian Haberman
>>> <brian@innovationslab.net> wrote:
>>> 
>>> All, I have completed by AD Evaluation of
>>> draft-ietf-lisp-introduction as a part of the IETF publication
>>> process.  I have some comments/questions that should be resolved
>>> prior to starting an IETF Last Call.  Please let me know if you
>>> have any questions on these...
>>> 
>>> 1. Section 1
>>> 
>>> * I am going to try and short-circuit the inevitable question that
>>> will arise about the reference [Chiappa].  Since it is a web page,
>>> the RFC Editor will be concerned by its long-term stability.  Is
>>> that the best reference for that text?  Anything similar that has
>>> been published in a conference/journal/RFC/etc.?
>> 
>> I will yield to the authors.
>> 
>>> * The text uses the terms underlay and overlay without any context
>>> (in the summary bullets).  This is easily fixed by augmenting the
>>> text in the 2nd paragraph to identify which networks form the
>>> underlay and the overlay.
>> 
>> Those terms aren't used very much in RFC 6830 because those terms
>> seem to become fashionable with the advent of nv03. If the authors
>> want to continue to use those terms, I have no problem with that, but
>> would suggest that the Definition of Terms section say that the
>> underlay is what is referred to in RFC 6830 as "the underlying core
>> routing system". And that an "overlay" is the encapsulation
>> relationship between ITRs, ETRs, PxTRs, and RTRs.
> 
> That is fine with me.
> 
>> 
>>> 2. Section 3 (and a few times in 3.5) :
>>> s/inetrworking/internetworking/
>>> 
>>> 3. Section 3.2
>>> 
>>> * Is it correct to say that EIDs are only routable at the edge?
>>> This seems to contradict the text in section 3.5 that says EIDs may
>>> be injected in the global routing system.
>> 
>> Well it depends on your reference point. If the overlay is the center
>> of perspective, then the global routing system is a non-LISP site
>> relative to the overlay. The whole point is that EIDs are routable
>> where LISP is not available. And that is true inside of a LISP site
>> where packets are at a point in the data-path pre-encapsulation or
>> post-decapsulation.
> 
> I agree with what you say above, but the document explicitly says EIDs
> are only routable at the edge and that is not the case in non-LISP parts
> of the Internet.  The document just needs to be more explicit on that point.
> 
>> 
>>> * I find the PI and PA analogies misleading.  EIDs are global, but
>>> they may change their point of attachment.  If that occurs, you are
>>> not guaranteed that your EID space does not change.
>> 
>> It is desirable that your EIDs do not change. But the scope of EID
>> mobility may be limited and if a legacy site wants to continue to use
>> DHCP and address addresses out of, say an enterprise address pool, it
>> should be able to do that while losing session survivability
>> features. That is a decision for the organization that is supporting
>> mobility into its own domain.
> 
> Given my concern and your comment above, how does the EID/PI analogy hold?
> 
>> 
>>> * In the example, bullet four mistakenly says that the destination 
>>> address of the outer header is set to RLOC_B2 (it should be
>>> RLOC_b1).
>>> 
>>> 4. Section 3.3.1 introduces the term RTR (Reencapsulating Tunnel 
>>> Routers) with no real description of how it functions or relates to
>>> ITRs and ETRs.
>> 
>> Well there are references to it in RFC 6830 and there are many
>> use-cases for them which we are not allowed to reference since the
>> drafts are not working group documents.
> 
> So, Section 3.3.1 should point the reader to 6830 when it mentions the RTR.
> 
>> 
>>> 5. Section 3.4.3 makes reference to the LISP WG.  Given that this 
>>> document will probably outlive the WG, I would suggest re-wording
>>> to remove a direct reference to the WG.
>>> 
>>> 6. Section 3.4 has no discussion of EIDs and NATs.  Given the
>>> global nature of the mapping system, it would seem that NATs don't
>>> play well with LISP.  There should be some discussion of that.
>> 
>> LISP plays very well with NATs and we have many use-cases which are
>> alive and being used. But again the draft on  NAT-traversal is not a
>> working group document so it is hard to reference it. EIDs are
>> translatable by NATs and so are RLOCs. It all depends where the xTR
>> resides (on the public versus private side of the NAT).
> 
> Even though the NAT-traversal draft is not a WG draft, this document can
> spend a few cycles talking about the general ability of LISP to operate
> in the face of NATs.
> 
>> 
>>> 7. Section 4.1
>>> 
>>> * s/requires of a /requires a/
>>> 
>>> * The discussion of SMR should contain a reference to 6830 or a
>>> brief discussion of how the SMR is used.
>>> 
>>> 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?
> 
> MIP and NEMO are the general modes of mobility that most closely
> approximate what is being discussed in Section 5.  My thought was to
> give the reader a basis for how mobility in LISP operates, including the
> drawbacks.
> 
>> 
>> Plus, it raises questions more than simplifies the understanding of
>> LISP. This is an intro document.
>> 
>>> * Should there be some discussion of the mapping system's TTL
>>> mechanism impact on mobility support?
>> 
>> The TTL is not used for mobility to work. It is the SMR and
>> Map-Notify mechanisms between xTRs and the mapping system and xTRs,
>> respectively.
> 
> Shouldn't that be mentioned somewhere in this draft?
> 
>> 
>>> 9. Section 9 talks about propagating multicast state as (S-EID,
>>> G). Does that mean that multicast in LISP is really only allowed to
>>> be SSM?
>> 
>> We are encouraging SSM but an (RP-EID, G) can be used as well. RFC
>> 6831 describes all PIM modes.
> 
> So, to avoid erroneous assumptions, perhaps the intro should mention that.
> 
> Regards,
> Brian
>