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

Dino Farinacci <> Mon, 19 January 2015 17:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 734CC1B2BDF for <>; Mon, 19 Jan 2015 09:56:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pP4E-jF15b_E for <>; Mon, 19 Jan 2015 09:56:52 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 654ED1B2BD7 for <>; Mon, 19 Jan 2015 09:56:52 -0800 (PST)
Received: by with SMTP id bj1so40107936pad.9 for <>; Mon, 19 Jan 2015 09:56:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id dw6mr20106410pab.114.1421690211654; Mon, 19 Jan 2015 09:56:51 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id uk5sm732764pbc.17.2015. (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 <>
In-Reply-To: <>
Date: Mon, 19 Jan 2015 09:56:54 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Brian Haberman <>
X-Mailer: Apple Mail (2.1993)
Archived-At: <>
Cc:, "" <>, "" <>
Subject: Re: [lisp] AD Evaluation: draft-ietf-lisp-introduction
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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?


> On Jan 19, 2015, at 6:45 AM, Brian Haberman <> 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
>>> <> 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