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 >
- [lisp] AD Evaluation: draft-ietf-lisp-introduction Brian Haberman
- Re: [lisp] AD Evaluation: draft-ietf-lisp-introdu… Dino Farinacci
- Re: [lisp] AD Evaluation: draft-ietf-lisp-introdu… Albert Cabellos
- Re: [lisp] AD Evaluation: draft-ietf-lisp-introdu… Dino Farinacci
- Re: [lisp] AD Evaluation: draft-ietf-lisp-introdu… Brian Haberman
- Re: [lisp] AD Evaluation: draft-ietf-lisp-introdu… Brian Haberman
- Re: [lisp] AD Evaluation: draft-ietf-lisp-introdu… Dino Farinacci
- Re: [lisp] AD Evaluation: draft-ietf-lisp-introdu… Albert Cabellos
- Re: [lisp] AD Evaluation: draft-ietf-lisp-introdu… Brian Haberman