Re: [lisp] WG Last Call draft-ietf-lisp-impact-01
Ronald Bonica <rbonica@juniper.net> Mon, 06 April 2015 10:54 UTC
Return-Path: <rbonica@juniper.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 215571A8755 for <lisp@ietfa.amsl.com>; Mon, 6 Apr 2015 03:54:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.003
X-Spam-Level:
X-Spam-Status: No, score=-100.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 zaLCVDIaWmvT for <lisp@ietfa.amsl.com>; Mon, 6 Apr 2015 03:54:19 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0792.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:792]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B34551A874B for <lisp@ietf.org>; Mon, 6 Apr 2015 03:54:18 -0700 (PDT)
Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) with Microsoft SMTP Server (TLS) id 15.1.130.23; Mon, 6 Apr 2015 10:53:59 +0000
Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.220]) with mapi id 15.01.0130.020; Mon, 6 Apr 2015 10:53:59 +0000
From: Ronald Bonica <rbonica@juniper.net>
To: Luigi Iannone <ggx@gigix.net>
Thread-Topic: [lisp] WG Last Call draft-ietf-lisp-impact-01
Thread-Index: AQHQWnSPtp3FrZs9xUaprzBtSdSj9p00VbOAgAAJRQCAAAPNAIAAAXiAgADc9UCAAInEAIABMXWAgAFRZQCAB6rPwA==
Date: Mon, 06 Apr 2015 10:53:58 +0000
Message-ID: <CO1PR05MB44213E258489BCFADEDDAB3AEFE0@CO1PR05MB442.namprd05.prod.outlook.com>
References: <B339BFE7-7E19-4AAA-8B2C-276402024C74@gigix.net> <BY1PR0501MB14304477BFF1F86BAFC810B3A5F50@BY1PR0501MB1430.namprd05.prod.outlook.com> <5518A89C.3090108@joelhalpern.com> <BY1PR0501MB14306D728BC2F0CAE037DE58A5F50@BY1PR0501MB1430.namprd05.prod.outlook.com> <5518AD07.9090200@joelhalpern.com> <BLUPR05MB4335869FD919F59F5A53914AEF50@BLUPR05MB433.namprd05.prod.outlook.com> <580EAA3E-7B39-430B-A23B-001F0E8E597B@gmail.com> <BLUPR05MB4331702941021F9E1783224AEF40@BLUPR05MB433.namprd05.prod.outlook.com> <AB25B0B0-54B2-47E2-82E5-65B568472F39@gigix.net>
In-Reply-To: <AB25B0B0-54B2-47E2-82E5-65B568472F39@gigix.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.241.14]
authentication-results: gigix.net; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB442;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(479174004)(377454003)(51704005)(13464003)(53754006)(24454002)(19580395003)(92566002)(19580405001)(2950100001)(54356999)(76176999)(50986999)(86362001)(46102003)(77156002)(62966003)(230783001)(66066001)(2656002)(87936001)(110136001)(76576001)(33656002)(74316001)(15975445007)(102836002)(122556002)(106116001)(561944003)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB442; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
x-microsoft-antispam-prvs: <CO1PR05MB44251CD388BE67AD477E8D2AEFE0@CO1PR05MB442.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO1PR05MB442; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB442;
x-forefront-prvs: 0538A71254
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2015 10:53:58.2789 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB442
Archived-At: <http://mailarchive.ietf.org/arch/msg/lisp/TVoshFIwocvNcMw0ivpTMQtD2UI>
Cc: LISP mailing list list <lisp@ietf.org>
Subject: Re: [lisp] WG Last Call draft-ietf-lisp-impact-01
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, 06 Apr 2015 10:54:23 -0000
Hi Luigi, I am not suggesting that discussion of cache scaling and control overhead be dropped. This discussion is very helpful to the reader. I suggest only that we run with Joel's proposal to add a disclaimer. The disclaimer should say something like: >>>>>> we do not know what the > >>>> impact on cache size and control overhead will be, as the studies > >>>> that have been made have been disputed as to their relevance to the > >>>> core Internet case Furthermore, we should extend the disclaimer to say: "We do not know what the impact of cache size and control overhead will be upon {x, y, and z}". Ron > -----Original Message----- > From: Luigi Iannone [mailto:ggx@gigix.net] > Sent: Wednesday, April 01, 2015 9:40 AM > To: Ronald Bonica > Cc: Damien Saucez; LISP mailing list list; BRUNGARD, DEBORAH A (ATTLABS) > Subject: Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 > > Hi Ron, > > > On 31 Mar 2015, at 19:48, Ronald Bonica <rbonica@juniper.net> wrote: > > > > Damien, > > > > In his email below, Joel asks: > > > >>>> if we modified the section to say that we do not know what the > >>>> impact on cache size and control overhead will be, as the studies > >>>> that have been made have been disputed as to their relevance to the > >>>> core Internet case, would the document still meet the IESG > >>>> requirements for evaluating the impact > > > > I support Joel's request, so long as the disclaimer is complete. > > Agreed that we need to clarify (via a disclaimer) what are the assumptions of > the studies, and that outsides these assumptions we have no information. > > > > If cache size and control overhead have impact, they must have impact > upon something. Do we know what they will impact? If so, tell us. If not, tell > us that. > > > > Let me try to understand here. What you are suggesting is that any > discussion on the scalability of cache and control overhead should be > dropped (they are in the papers anyway), and only the aspects that have an > impact (and on what they have an impact) should be maintained. > > Is my reading correct? > > BTW, Deborah was also suggesting to simplify some sections which are > cluttered with to much numbers. This seems to me inline with your > suggestion (if I got it correctly). > > ciao > > Luigi > > > > > > Ron > > > >> -----Original Message----- > >> From: Damien Saucez [mailto:damien.saucez@gmail.com] > >> Sent: Monday, March 30, 2015 7:19 PM > >> To: Ronald Bonica > >> Cc: Joel Halpern; Brian Haberman; BRUNGARD, DEBORAH A (ATTLABS); > LISP > >> mailing list list > >> Subject: Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 > >> > >> Ron, > >> > >> As one of the authors I can say I am not frustrated :-) > >> > >> We are looking on how to address in the best way the comments of this > >> thread. > >> > >> Just that it is unrealistic to hope a new full study on the cache > >> size from research partners as such a study takes a lot of time and > >> resources (to produce the experimentation, then to get reviewed in a > >> conference or journal and finally get published) and would not change > >> any conclusion with regards to the analytical studies reference in > >> the draft already and that draw general conclusions. > >> > >> The best solution could be to ask your customers to provide me the > >> necessary information so that I could evaluate the impact of LISP for > >> their needs. Without that, I am afraid that the only thing that we > >> can reasonably provide is theoretical/analytical studies. > >> > >> The disclaimer you propose to add is just incorrect. It is not true > >> that we don't know the impact of cache size. Actually, in the draft, > >> we already reference the analytical study [CCD12] that demonstrates > >> analytically that it is possible to link cache size, traffic pattern, and miss > rate. > >> > >> Here is the paragraph present in the draft: > >> > >> [CCD12] generalizes the caching discussion and proposes an analytic > >> model for the EID-to-RLOC cache size when prefix-level traffic has a > >> stationary generating process. The model shows that miss rate can be > >> accurately predicted from the EID-to-RLOC cache size and a small set > >> of easily measurable traffic parameters, meaning that operators can > >> provision the EID-to-RLOC cache of their ITRs according to the miss > >> rate they want to achieve for their given traffic. > >> > >> That is clear enough for me and unless someone can prove the model > >> wrong I am perfectly fine with this observation that is supported by > empirical data. > >> > >> Cheers, > >> > >> Damien Saucez > >> > >> On 30 Mar 2015, at 17:17, Ronald Bonica <rbonica@juniper.net> wrote: > >> > >>> Brian, Deborah, > >>> > >>> I realize that the authors are frustrated. Maybe we can run with > >>> Joel's > >> proposal if we make the disclaimer complete. > >>> > >>> Shouldn't the disclaimer read something like, "We do not know the > >>> impact > >> of cache size and control overhead on {x, y, z}", where x, y and z might be: > >>> > >>> - LISP scaling > >>> - LISP security > >>> - LISP resiliency > >>> - other ??? > >>> > >>> Given that, might we draw some conclusions regarding LISP's > applicability? > >>> > >>> Ron > >>> > >>>> -----Original Message----- > >>>> From: lisp [mailto:lisp-bounces@ietf.org] On Behalf Of Joel M. > >>>> Halpern > >>>> Sent: Sunday, March 29, 2015 9:55 PM > >>>> To: Brian Haberman; BRUNGARD, DEBORAH A (ATTLABS) > >>>> Cc: LISP mailing list list > >>>> Subject: Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 > >>>> > >>>> Brian, Deborah, if we modified the section to say that we do not > >>>> know what the impact on cache size and control overhead will be, as > >>>> the studies that have been made have been disputed as to their > >>>> relevance to the core Internet case, would the document still meet > >>>> the IESG requirements for evaluating the impact. I don't want to > >>>> ask the authors if they can live with a certain change if that > >>>> change will cause other necessary reviewers to complain. > >>>> > >>>> I do not see it as sensible to hold up the publication of this and > >>>> the other LISP work while researchers go off to see if they can > >>>> calculate > >> better results. > >>>> Particularly not when publishing this document is required to do > >>>> other > >> work. > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> On 3/29/15 9:50 PM, Ross Callon wrote: > >>>>> I suppose that there are two options: > >>>>> > >>>>> 1. Admit that we have no clue what the cache size or control > >>>>> overhead will be. > >>>>> > >>>>> 2. Repeat the cited studies, but with a pessimistic (worse case) > >>>>> rather than optimistic (better than best case) assumption about > >>>>> cache granularity. > >>>>> > >>>>> The second option would allow us to actually have some idea what > >>>>> would happen if LISP were deployed on an Internet-wide scale, but > >>>>> would of course take more time and more work. > >>>>> > >>>>> Ross > >>>>> > >>>>> PS: I will be offline at meetings all of this week, so I might be > >>>>> a bit slower to respond for the next few days. > >>>>> > >>>>> -----Original Message----- From: Joel M. Halpern > >>>>> [mailto:jmh@joelhalpern.com] Sent: Sunday, March 29, 2015 9:36 PM > >> To: > >>>>> Ross Callon; Luigi Iannone; LISP mailing list list Cc: > >>>>> draft-ietf-lisp-impact@tools.ietf.org Subject: Re: [lisp] WG Last > >>>>> Call > >>>>> draft-ietf-lisp-impact-01 > >>>>> > >>>>> Putting aside the TBD (which of course needs to be fixed), I have > >>>>> trouble figuring out what you want us to say about the main issue > >>>>> in your review. On the one hand, this is the very issue that we > >>>>> have been asked to comment on, and on the other hand you say that > >>>>> we don't know. What do you think it is reasoanble to say? > >>>>> > >>>>> Yours, Joel > >>>>> > >>>>> On 3/29/15 9:03 PM, Ross Callon wrote: > >>>>>> Generally I think that this document needs more work before it > >>>>>> will be ready to submit for publication. Some comments on > >>>>>> draft-ietf-lisp-impact-01: > >>>>>> > >>>>>> First of all, I assume that the TBD at the end of section 3 will > >>>>>> be fixed. This reads: > >>>>>> > >>>>>> TBD: add a paragraph to explain the operational difference while > >>>>>> > >>>>>> dealing with a pull model instead of a push. > >>>>>> > >>>>>> Also in section 3, the third paragraph begins: > >>>>>> > >>>>>> In addition, Iannone and Bonaventure [IB07] show that the number > >>>>>> of > >>>>>> > >>>>>> mapping entries that must be handled by an ITR of a campus > >>>>>> network > >>>>>> > >>>>>> with 10,000 users is limited to few tens of thousands, and does > >>>>>> not > >>>>>> > >>>>>> represent more than 3 to 4 Megabytes of memory. > >>>>>> > >>>>>> Reference [IB07] is of course: > >>>>>> > >>>>>> Iannone, L. and O. Bonaventure, "On the cost of caching > >>>>>> locator/id mappings", In > >>>>>> > >>>>>> Proc. ACM CoNEXT 2007, December 2007. > >>>>>> > >>>>>> This paper states: > >>>>>> > >>>>>> In our analysis, we assume that the granularity of the > >>>>>> > >>>>>> EID-to-RLOC mapping is the prefix blocks assigned by > >>>>>> > >>>>>> RIRs. We call it /BGP granularity. In particular, we > >>>>>> > >>>>>> used the list of prefixes made available by the iPlane > >>>>>> > >>>>>> Project [15], containing around 240,000 entries. Using > >>>>>> > >>>>>> /BGP granularity means that each EID is first mapped > >>>>>> > >>>>>> on a /BGP prefix. The cache will thus contain /BGP > >>>>>> > >>>>>> to RLOC mappings.2 This is a natural choice, since > >>>>>> > >>>>>> routing locators are supposed to be border routers. > >>>>>> > >>>>>> The authors should be aware that there is some aggregation / > >>>>>> summarization being done in the operation of BGP routing, and > >>>>>> that the granularity of routes which appear in the default-free > >>>>>> BGP routing tables is fundamentally different from the > >>>>>> granularity of enterprise network / ISP boundaries across which > >>>>>> traffic is exchanged. > >>>>>> > >>>>>> The same paragraph cites Kim et al. [KIF11], which is Kim, J., > >>>>>> Iannone, L., and A. Feldmann, "Deep dive into the lisp cache and > >>>>>> what isps should know about it", In Proc. IFIP Networking 2011, > >>>>>> May > >> 2011. > >>>>>> From this document: > >>>>>> > >>>>>> In addition, we use a local BGP prefixes > >>>>>> > >>>>>> database, fed with the list of BGP prefixes published by the > >>>>>> iPlane Project [17]. > >>>>>> > >>>>>> The database is used to group EID-to-RLOCs mappings with the > >>>>>> granularity of > >>>>>> > >>>>>> existing BGP prefixes, because, as for today, there is no > >>>>>> sufficient information > >>>>>> > >>>>>> to predict what will be the granularity of mappings in a > >>>>>> LISP-enabled Internet. > >>>>>> > >>>>>> I agree that "there is not sufficient information to predict what > >>>>>> will be the granularity of mappings in a LISP-enabled Internet". > >>>>>> However, not knowing what the mapping granularity will be does > >>>>>> not justify using an extremely optimistic guess, and then acting > >>>>>> as if the results are meaningful. These assumptions are clearly > >>>>>> off by some number of orders of magnitude, but how many orders > of > >>>>>> magnitude is unknown. We will note that the current internet > >>>>>> default-free routing table includes a few hundred thousand > >>>>>> entries (roughly twice the > >>>>>> 240,000 entries that existed when this study was done). > >>>>>> > >>>>>> For example, we might assume that the intended global deployment > >>>>>> model involves xTRs at the boundary between enterprise networks > >> and > >>>>>> service providers, and might note that there are several million > >>>>>> companies in the USA alone (most of these are relatively small > >>>>>> companies, of course). Thus there may be very roughly on the > >>>>>> order of a hundred million or so companies worldwide. If each one > >>>>>> had a separate entry in the mapping table, then the number of > >>>>>> entries will be nearly 1,000 times larger than BGP-prefix granularity. > >>>>>> > >>>>>> Section 4 mentions as one possible use of LISP: "enable mobility > >>>>>> of subscriber end points". If individual end points are > >>>>>> advertised into LISP, then the granularity of the mapping table > >>>>>> may be on the order of individual systems. In this case the > >>>>>> number of mapping table entries that could exist globally might > >>>>>> be on the same order of magnitude as the number of people in the > >>>>>> world, or very roughly > >>>>>> 7 Billion entries. This would suggest that the mapping table > >>>>>> might be roughly 30,000 times finer grained than was assumed in > >>>>>> the referenced studies. > >>>>>> > >>>>>> I don't see how we can accurately predict the control plane load > >>>>>> of LISP without some sense for what the granularity of the > >>>>>> mapping table will be. It should however be possible to bound the > >>>>>> control plane load. The referenced studies give a lower bound on > >>>>>> possible control plane load (it won't be any less), but give > >>>>>> neither an accurate measurement nor an upper bound on the > >>>>>> potential control plane load. I don't think that the document can > >>>>>> claim to explain the impact of LISP without there being an > >>>>>> attempt to measure an upper bound on the control plane load. > >>>>>> > >>>>>> Finally, perhaps I missed it but I didn't see any discussion of > >>>>>> the volume of overhead related to OAM traffic used for liveness > >>>>>> detection (the need for ITR's to determine the reachability of ETR's). > >>>>>> > >>>>>> Thanks, Ross > >>>>>> > >>>>>> *From:*lisp [mailto:lisp-bounces@ietf.org] *On Behalf Of *Luigi > >>>>>> Iannone *Sent:* Monday, March 09, 2015 10:22 AM *To:* LISP > >>>>>> mailing list list *Cc:* draft-ietf-lisp-impact@tools.ietf.org > >>>>>> *Subject:* [lisp] WG Last Call draft-ietf-lisp-impact-01 > >>>>>> > >>>>>> Hi All, > >>>>>> > >>>>>> the authors of the LISP Impact document > >>>>>> [https://tools.ietf.org/html/draft-ietf-lisp-impact-01] requested > >>>>>> the Work Group Last Call. > >>>>>> > >>>>>> This email starts a WG Last Call, to end March 30th, 2015. > >>>>>> > >>>>>> Because usually the pre-meeting period is already overloaded, the > >>>>>> LC duration is set to three weeks. > >>>>>> > >>>>>> Please review this updated WG document and let the WG know if > you > >>>>>> agree that it is ready for handing to the AD. > >>>>>> > >>>>>> If you have objections, please state your reasons why, and > >>>>>> explain what it would take to address your concerns. > >>>>>> > >>>>>> Any raised issue will be discussed during the WG meeting in Dallas. > >>>>>> > >>>>>> Thanks > >>>>>> > >>>>>> > >>>>>> Luigi & Joel > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ lisp > >> mailing > >>>> list > >>>>>> lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp > >>>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> lisp mailing list > >>>> lisp@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/lisp > >>> > >>> _______________________________________________ > >>> lisp mailing list > >>> lisp@ietf.org > >>> https://www.ietf.org/mailman/listinfo/lisp > > > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Luigi Iannone
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Ross Callon
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Joel M. Halpern
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Ross Callon
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Joel M. Halpern
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Ronald Bonica
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Damien Saucez
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Luigi Iannone
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Ronald Bonica
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Luigi Iannone
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Damien Saucez
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Damien Saucez
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Ross Callon
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Damien Saucez
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Ronald Bonica
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Ross Callon
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Darrel Lewis (darlewis)
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Dino Farinacci
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Ross Callon
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Dino Farinacci
- [lisp] WG Last Call draft-ietf-lisp-impact-01 Luigi Iannone
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Ross Callon
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Florin Coras
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Dino Farinacci
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Ross Callon
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Dino Farinacci
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Ross Callon
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Florin Coras
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Ross Callon
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-01 Dino Farinacci
- [lisp] WG Last Call draft-ietf-lisp-impact-02 Luigi Iannone
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-02 Ross Callon
- Re: [lisp] WG Last Call draft-ietf-lisp-impact-02 Luigi Iannone