From nobody Fri Aug 1 08:07:20 2014 Return-Path: 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 2BFC91B2935; Thu, 31 Jul 2014 08:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 QJPO_BO05l2a; Thu, 31 Jul 2014 08:45:38 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84A8E1B286C; Thu, 31 Jul 2014 08:45:38 -0700 (PDT) Received: from BY2PR03MB128.namprd03.prod.outlook.com (10.242.36.28) by BY2PR03MB125.namprd03.prod.outlook.com (10.242.36.14) with Microsoft SMTP Server (TLS) id 15.0.995.14; Thu, 31 Jul 2014 15:45:29 +0000 Received: from BY2PR03MB128.namprd03.prod.outlook.com ([169.254.5.211]) by BY2PR03MB128.namprd03.prod.outlook.com ([169.254.5.211]) with mapi id 15.00.0995.014; Thu, 31 Jul 2014 15:45:29 +0000 From: Pankaj Garg To: "Larry Kreeger (kreeger)" , Tom Herbert Thread-Topic: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: AQHPqeDVMCB+3Ia6AEuZwp+KZdt7RJu0odGAgABtLwCAAIjUgIAAzUAAgAAT3oCAAAUFgIAABKAAgAKn94CAAAEQgIAABAWAgAAmDICAAA3jgIAA9NLw Date: Thu, 31 Jul 2014 15:45:28 +0000 Message-ID: References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> <20140728215213292302.e07f5538@sniff.de> <3A7F72AE-4746-41A6-A103-3424461D6D07@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [125.62.209.8] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0289B6431E x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(377454003)(24454002)(199002)(51704005)(164054003)(13464003)(479174003)(4396001)(64706001)(15202345003)(101416001)(95666004)(77096002)(76176999)(50986999)(74316001)(99286002)(87936001)(33646002)(77982001)(107046002)(54356999)(106356001)(85852003)(46102001)(92566001)(20776003)(15975445006)(99396002)(85306003)(81542001)(21056001)(93886003)(74662001)(76482001)(74502001)(81342001)(19580405001)(31966008)(86612001)(76576001)(86362001)(83072002)(80022001)(66066001)(79102001)(106116001)(105586002)(19580395003)(2656002)(83322001)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB125; H:BY2PR03MB128.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/dxk5dcTaUHpt5e3nvBbyPXTcbdw X-Mailman-Approved-At: Fri, 01 Aug 2014 08:07:17 -0700 Cc: David Melman , LISP mailing list list , "nvo3@ietf.org" Subject: Re: [lisp] [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 15:45:42 -0000 > -----Original Message----- > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Larry Kreeger > (kreeger) > Sent: Wednesday, July 30, 2014 6:07 PM > To: Tom Herbert > Cc: David Melman; Marc Binderberger; LISP mailing list list; Dino Farinac= ci; > nvo3@ietf.org > Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn- > vxlan-gpe-03 >=20 >=20 >=20 > On 7/30/14 5:16 PM, "Tom Herbert" wrote: >=20 > >On Wed, Jul 30, 2014 at 3:00 PM, Larry Kreeger (kreeger) > > wrote: > >> Hi Tom, > >> > >> First, the VXLAN-GPE Next Protocol field would indicate the value 0x4 > >>for NSH (as specified in draft-quinn-vxlan-gpe-03). Then, directly > >>following the VXLAN-GPE header would be an NSH header. One would > >>need to define a new MD Type (not the SFC value of 0x1, specified in > >>draft-quinn-nsh-03). > >> Then you need to make a decision as to whether you want to > >>possibility of your authentication value to be processed by hardware > >>or only software. > >> If you want hardware support, then I would recommend that it not be > >>encoded as a TLV. If you only care about software support, then you > >>could encode the authentication in a TLV using your own > >>organization's TLV Class, or perhaps an IETF TLV Class if you are > >>standardizing it. If you expect hardware to parse and validate the > >>VNI authentication, then I would encode it somewhere within the 20 > >>bytes following the base NSH header and not in a TLV. > >> > >Any optional data I define which proves useful in the datapath I may > >eventually want to implement in HW, and I really wouldn't want to have > >to make such a decision up front-- so I'll assume anything we'd want to > >define would need to go into NSH headers in order to keep HW support an > >option. So then in this model is it correct to say that the we could > >arbitrarily extend the protocol by using a chain of NSH headers each of > >which provides 20 bytes of data we can use for optional data and still > >be "HW friendly"? >=20 > No, I would not necessarily say that. I think an arbitrary number of NSH > headers makes the expected offset of the payload vary in a similar way th= at > TLVs would. [PG] The idea here is that TLV provides a way for the software to experimen= t and quickly light up new features without requiring changes to NIC offloa= ds. Once the hardware support is needed for those, those TLVs can be conver= ted to standard format metadata and put in the fixed header portion of the = NSH header. Using different MDType, one can have a 20-byte fixed header or = larger/smaller in future for different MDType. This provides a lot of exten= sibility in a way that is both hardware and software friendly. >=20 > > > >Thanks, > >Tom > > > >> - Larry > >> > >> On 7/30/14 2:46 PM, "Tom Herbert" wrote: > >> > >>>> I think the intent of NSH is to be generic enough to work at > >>>>different layers. The recent addition of the Metadata Type field > >>>>in the NSH header allows for it to be used for purposes beyond SFC. > >>>>It could theoretically be used to essentially extend the header of > >>>>the layer below it (e.g. > >>>> VXLAN/LISP). e.g. I think this could be used for Tom to carry his > >>>>64 bit VNI authentication. > >>>> > >>>I'd be interested to see exactly what the headers might look like in > >>>that case. I've tried to extrapolate from the SFC drafts how that > >>>might work but really don't see it... > >>> > >>>Thanks, > >>>Tom > >>> > >>>> - Larry > >>>> > >>>>>Just like any other UDP application. If that packet needs to be > >>>>>encapsulated that is a lower level function. Just like IP packets > >>>>>can go in an MPLS based LSP. > >>>>> > >>>>>> picture? They do mean something about how the packet is handled, > >>>>>>don't they? > >>>>> > >>>>>I won't answer that because those bit introductions into the design > >>>>>are indeed design bugs IMO. > >>>>> > >>>>>Dino > >>>>>_______________________________________________ > >>>>>nvo3 mailing list > >>>>>nvo3@ietf.org > >>>>>https://www.ietf.org/mailman/listinfo/nvo3 > >>>> > >> >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From nobody Fri Aug 1 08:07:21 2014 Return-Path: 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 306BA1A0173; Thu, 31 Jul 2014 14:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DKmzXjvCaDdP; Thu, 31 Jul 2014 14:09:20 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE3281A010A; Thu, 31 Jul 2014 14:09:19 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-0a-53da5aa66894 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 9B.6E.25146.6AA5AD35; Thu, 31 Jul 2014 17:03:02 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Thu, 31 Jul 2014 17:09:10 -0400 From: Eric Gray To: Dino Farinacci , Larry Kreeger Thread-Topic: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: AQHPqeDTgKnTo8JzqEinUCL6aopzsZu05OCAgABtLwCAAIjTgIAAzUAAgAAT3oCAAAUGgIAABJ8AgAKZtgCAAEbGgIAAAm4AgAEB1ZA= Date: Thu, 31 Jul 2014 21:09:09 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF632B222C2@eusaamb107.ericsson.se> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> <20140728215213292302.e07f5538@sniff.de> <3A7F72AE-4746-41A6-A103-3424461D6D07@gmail.com> <1B87D84A-C34F-46D5-BA50-262C095DF72E@gmail.com> In-Reply-To: <1B87D84A-C34F-46D5-BA50-262C095DF72E@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZXLrHT3dZ1K1gg0eTFSz+fVzMaNG++xqj xYI3i1ksppxVt5h95T+zxdP5khb7L5xmcWD3mPJ7I6vHzll32T0WbCr1WLLkJ5PH5IUXmT1a V3ezBLBFcdmkpOZklqUW6dslcGV8+7uZpeCaYMX73Q8ZGxin8nUxcnJICJhInFm+iBXCFpO4 cG89WxcjF4eQwFFGidkfp7FAOMsZJdZ+38kOUsUmoCFx7M5axi5GDg4RAW+J+xOYQGqYBXYy Siw4spgNpEZYIFSi7+M0ZhBbRCBM4uDH1awQdpnEog+9jCA2i4CqxJlVN8Bm8gr4Shw/3Ai1 bB6rxM8lk9hAFnAK2Er8eZsIUsMIdN33U2uYQGxmAXGJW0/mM0FcLSCxZM95ZghbVOLl439Q 3yhJTFp6jhWiXkdiwe5PbBC2tsSyha+ZIfYKSpyc+YRlAqPYLCRjZyFpmYWkZRaSlgWMLKsY OUqLU8ty040MNzECY++YBJvjDsYFnywPMQpwMCrx8C4QvhUsxJpYVlyZe4hRmoNFSZxXs3pe sJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGzuLLX74UG5tNb8sW/jRNLLMsrGk+w9V9rJd5 atgKr99jP7VzzyzJJctPJX/W6NPlS8nxlflU+PKLmarv7aMtW561+P3fumKj2vkti//u4xI8 dKClVu6gk5iL4t8owQnKflcrbK+YSE4uXOL6QP1DtbPPmUc/X/Ite5g+IS5x6YGAgnimyNgd SizFGYmGWsxFxYkAXNYFzJ4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/UQ8nqKFtO0z1b0ReAu-AuHDPAok X-Mailman-Approved-At: Fri, 01 Aug 2014 08:07:18 -0700 Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: Re: [lisp] [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 21:09:22 -0000 Dino, Would you re-phrase your response? I am having some trouble parsing it, so= =20 I must be missing something. First, I think (when you said "... sent from any pair of ports ...") you me= ant to say "... sent with any pair of ports ..." - but this is a guess. As for making OAM messages traverse the exact same path as data, this is=20 what OAM is expected to do. In essence, if data follows a path that involv= es a non-zero number of gates, while OAM does not, the successful delivery of OAM is only an approximate indication of the data-path integrity. Any H/W that data has to go through, and OAM does not go through, could fail and we would see an OAM indication of a valid path through which data either would not go, or would be diverted in some unexpected way. Ordinarily, this should not be a problem for the hardware, as (ordinarily) = the OAM is indistinguishable from data. The hardware works no harder to push OAM than it would to push an equivalent amount of data. So, what is the problem again? -- Eric -----Original Message----- From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Dino Farinacci Sent: Wednesday, July 30, 2014 9:13 PM To: Larry Kreeger Cc: Tom Herbert; David Melman; Marc Binderberger; LISP mailing list list; n= vo3@ietf.org Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxla= n-gpe-03 > I'm assuming that routers and switches will be multipathing based on=20 > the UDP port numbers, so I would expect different destination UDP=20 > ports to take different equal cost paths. Well if OAM is going to be effective, messages need to be sent from any pai= r of ports that yield 0 through N modulus so multiple paths can be determin= ed. So it doesn't matter with the port number values you use, those contro= l packets will be ECMPed as well. If you are also inferring that you want the OAM packets to go through the s= ame data-path of each device on the path, then you will have to put TLVs in= the data path, which is traditionally not prudent. See my Puneet reference= from previous email. Dino _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From nobody Fri Aug 1 09:24:50 2014 Return-Path: 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 444401B27FC; Fri, 1 Aug 2014 09:24:48 -0700 (PDT) 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 JEc0rBz9Dj2u; Fri, 1 Aug 2014 09:24:45 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FE641A0100; Fri, 1 Aug 2014 09:24:45 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kx10so6035074pab.6 for ; Fri, 01 Aug 2014 09:24:45 -0700 (PDT) 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=jd6tbIE1+CujcHokAa0LA9chBB1ZmsW5YbMt1njfEc4=; b=zIKdLLw7JJQTWV33YSOtq1INLVNinhCKnY6tBDA9SiKaVWturZkx0/++nIAvj0TqBA B8jVwGZHAjzVpgyxDG4cX/zpjUiyuuZfsrRx7Tyn3rLO9ALIqLmZVL8p3EEiBRoyVHYS 8drkJJPvC7L0k/zXju3OABnIfKeveAInj3CeKRCoq+DNkA+VJoFtwU1sptPYPbOxNrFt r6BYCz5q/HXnkm/7daE9Vzqcy8nm+m/A6nsjOBxJcOOAw934zm6zBIWBDxVSTQ2nHf7B l7jIEcPXVxGSG6A1SzkKZh4jNtU9AfuOe4V2doyA2BXEvyl/jp47SMHWm9Np2CDbU3UI eVUA== X-Received: by 10.70.53.232 with SMTP id e8mr7565207pdp.30.1406910285221; Fri, 01 Aug 2014 09:24:45 -0700 (PDT) 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 n2sm13752351pdo.32.2014.08.01.09.24.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Aug 2014 09:24:44 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dino Farinacci In-Reply-To: <20140731230828372641.3d067333@sniff.de> Date: Fri, 1 Aug 2014 09:24:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <84FAEDDF-DA80-4D0D-BB08-26987DFC0D58@gmail.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> <20140728215213292302.e07f5538@sniff.de> <3A7F72AE-4746-41A6-A103-3424461D6D07@gmail.com> <1B87D84A-C34F-46D5-BA50-262C095DF72E@gmail.com> <48E1A67CB9CA044EADFEAB87D814BFF632B222C2@eusaamb107.ericsson.se> <20140731230828372641.3d067333@sniff.de> To: Marc Binderberger X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/BvVjgSquXXnM-7msNSluPhWPQ7o Cc: LISP mailing list list , "nvo3@ietf.org" , David Melman , Eric Gray , Tom Herbert Subject: Re: [lisp] [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 16:24:48 -0000 > Hello Dino, >=20 > always interesting, different people interpret differently. >=20 > You seem to talk about controlling where the OAM data flows. I don't = think=20 > this is what Eric means. As long as a flow is defined in the = traditional 3-=20 > or 5-tuple way from the IP/UDP packet and as long as every router is = mapping=20 > the same flow onto the same ECMP egress interface we are fine. The = details -=20 > the exact algorithm, if the algorithm uses the router-id as an = additional=20 > hash or whatever else - don't matter. The OAM packet would use the = same=20 > IP/UDP header as the data packet it's supervising. And the receiver = processes=20 > OAM packets as "OAM" because of the flag set. For overlays, if you want to do RLOC selection at the encapsulator based = on the underlay's paths, you will need to know all paths so you can have = granular decision control. I didn't mean to emphasize the algorithm being used at each hop. There = is a combinatorial problem by looking at all paths. For example say one = hop has ECMP paths (A, B, C) and the next one has (A', B', C'). For = different 5-tuples you can have A -> A', A -> B', A -> C', B -> A', B = -> B', B -> C', and C -> A', C -> B', C-> C'. And if the same algorithms = are not used, you may have a 1-to-many relationship from hop 1 to hope = 2. If an OAM mechanism is going to measure attributes of a path, it will to = do so for all paths, And the number of combinations above was just in 2 = boxes with only 3 ECMPs each. This quickly raises my complexity flag. >> One needs to argue if you really need the granuarlity for the = complexity=20 >> that will needed to get this partially correct. >=20 >> Well I think LISP RLOC-probing is good enough, but I am biased. ;-) >=20 > you are "rich" by having an additional control plane UDP port ;-) > I don't see much complexity although I agree that just knowing if the = RLOC is=20 > alive and ping-able may be enough in many cases. If we can get more = like=20 > in-band OAM - why not? You can inband OAM for the control-port too. >> If an ITR sends a packet the ETR's address, the middle boxes do not = know if=20 >> it is a control-packet versus a data-packet. >=20 > true but e.g. for LISP, while the middle box may have no idea what = 4341 and=20 > 4342 as udp ports mean, it could still calculate a different hash = bucket for=20 > ECMP due to the different UDP port. The hash is modulo the number of ECMP paths. You build the control = packets with 5-tuples that generate hashs across all ECMP paths. > Hmm, my statement is so trivial - I assume you want to say something=20= > different with your reply? >=20 >=20 >> I am trying to avoid problems. Seems like things are being = over-engineered.=20 >> Again. >=20 > I would say the echo nonce in RFC6830 is not fundamentally different = from=20 > OAM. The N+E flags trigger some activity on the receiver, similar to = OAM. It is way different. All we are testing is the forward path from ITR to = ETR (and nothing else). OAM proposals also meausre other attributes of = the path. >=20 >> P.S. Sorry I keep being negative. And if one person says shut up, = I'll stop=20 >> posting. >=20 > well, everyone is entitled to his/her opinion and to voice it in = his/her=20 > personal style. You have a point as I was a bit upset myself about = this=20 > draft: there is likely more about it, otherwise why would we discuss=20= > yet-another-8-byte-header? Fabio offered the simplification the new = header=20 > offers but for a while we will have 2-3 slightly different headers = that need=20 > active support in the code or hardware. Actually in terms of code - be = it C=20 > or Verilog - I'm not sure there is any simplification ever over VxLAN = + LISP. Well if one wants the VXLAN and LISP header to be consistent, it was = already that way from the start. And if you wanted to run L3 with a = VXLAN header, you use the destination MAC as the xTR's address and you = got L3. There is no demux needed because the inner ethernet header has = an ethertype that can demux every protocol ever invented in the world. Do not create a new registry for types authors of GPE. PPP learned this = in 1989 and used ethertypes. Why is that different now? If there is an ethertype allocated for "ethernet" there can be one = allocated for NSH. And then if anyone ever wanted to run NSH directly = over ethernet, you have your ethertype. But I AM NOT RECOMMENDING THIS. I believe NSH should run on top of UDP = and get its own port number. NSH sends UDP packets, period. > But at least the situation of having both VxLAN and LISP can be = simplified by=20 > having a common umbrella and one common discussion. Agree.=20 > Personally I think VxLAN-gpe is how the VxLAN/LISP header could have = looked=20 > like from the start (hindsight is great, I know) and I don't have a = technical=20 > problem with the draft itself. What is missing is enough context to = discuss=20 > it. E.g. I'm still not sure why there is a P flag, if for a hard = technical=20 > reason or for the aesthetics that every field is controlled by a = turn-on flag=20 > ;-) There is a P-flag so you have demux ability in the VXLAN/LISP header. So = we will demux at the UDP port level, the P-bit level, and the ethertype = level. All these will be demux decisions a forwarder has to deal with. = This is quite ridiculous. > So I encourage and kindly ask the authors to provide more of this = context in=20 > the next draft version. >=20 > Regards, Marc Dino >=20 >=20 >=20 > On Thu, 31 Jul 2014 16:16:53 -0700, Dino Farinacci wrote: >>> Dino, >>>=20 >>> Would you re-phrase your response? I am having some trouble parsing = it,=20 >>> so=20 >>> I must be missing something. >>>=20 >>> First, I think (when you said "... sent from any pair of ports ...") = you=20 >>> meant to >>> say "... sent with any pair of ports ..." - but this is a guess. >>=20 >> Yes "with" is a better way of stating it. >>=20 >>> As for making OAM messages traverse the exact same path as data, = this is=20 >>> what OAM is expected to do. In essence, if data follows a path that=20= >>> involves >>=20 >> Good luck. I do not how you will be able to control each ECMP path at = each=20 >> path across different vendors as well as the same vendor with = different=20 >> hashing algorithms. >>=20 >> One needs to argue if you really need the granuarlity for the = complexity=20 >> that will needed to get this partially correct. >>=20 >>> a non-zero number of gates, while OAM does not, the successful = delivery of >>> OAM is only an approximate indication of the data-path integrity. = Any H/W >>> that data has to go through, and OAM does not go through, could fail = and we >>> would see an OAM indication of a valid path through which data = either would >>> not go, or would be diverted in some unexpected way. >>=20 >> Well I think LISP RLOC-probing is good enough, but I am biased. ;-) >>=20 >>> Ordinarily, this should not be a problem for the hardware, as = (ordinarily)=20 >>> the >>> OAM is indistinguishable from data. The hardware works no harder to = push >>> OAM than it would to push an equivalent amount of data. >>=20 >> If an ITR sends a packet the ETR's address, the middle boxes do not = know if=20 >> it is a control-packet versus a data-packet. >>=20 >>> So, what is the problem again? >>=20 >> I am trying to avoid problems. Seems like things are being = over-engineered.=20 >> Again. >>=20 >> Dino >>=20 >> P.S. Sorry I keep being negative. And if one person says shut up, = I'll stop=20 >> posting. >>=20 >>>=20 >>> -- >>> Eric >>>=20 >>> -----Original Message----- >>> From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Dino = Farinacci >>> Sent: Wednesday, July 30, 2014 9:13 PM >>> To: Larry Kreeger >>> Cc: Tom Herbert; David Melman; Marc Binderberger; LISP mailing list = list;=20 >>> nvo3@ietf.org >>> Subject: Re: [nvo3] Comments on=20 >>> http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 >>>=20 >>>> I'm assuming that routers and switches will be multipathing based = on=20 >>>> the UDP port numbers, so I would expect different destination UDP=20= >>>> ports to take different equal cost paths. >>>=20 >>> Well if OAM is going to be effective, messages need to be sent from = any=20 >>> pair of ports that yield 0 through N modulus so multiple paths can = be=20 >>> determined. So it doesn't matter with the port number values you = use,=20 >>> those control packets will be ECMPed as well. >>>=20 >>> If you are also inferring that you want the OAM packets to go = through the=20 >>> same data-path of each device on the path, then you will have to put = TLVs=20 >>> in the data path, which is traditionally not prudent. See my Puneet=20= >>> reference from previous email. >>>=20 >>> Dino >>>=20 >>> _______________________________________________ >>> nvo3 mailing list >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 >>=20 From nobody Fri Aug 1 10:11:54 2014 Return-Path: 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 249BE1B2859 for ; Fri, 1 Aug 2014 10:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 MMC8FFl9vMAf for ; Fri, 1 Aug 2014 10:11:45 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 602EF1B2840 for ; Fri, 1 Aug 2014 10:11:34 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id rl12so6314394iec.29 for ; Fri, 01 Aug 2014 10:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XI4pz7AeRs1sLulFzjwnAeNI6wqDPmsxX+6gYA4W1zU=; b=hHUmIBJ8tUzdId9dclPaGeBjpBrfnTvqX4xRPiWisSmKf2evrN+PYiPxDLYMrEQU9M nnijAwrlhVzdHY2bIogPQMGwGIoWONWmzCnxvrJLzxX8Ntx5eku+dtkaD+3c4EG+tNY5 vuLfIBCMk40YMItdl2ROPrf7jZ+KzJDVEmveUwHKqJdSAXs5jTI8PLSmZW27lWldAu6h dHjHQc8uDJ7pTghKfpAjMlldG3dD7qWgfwLbPAO2aLSh/b9IyHFKKICvhrd9oNUGyBUE FBzjnjK1i2Bj3ox0sqFozZOFDATYFB/g7eycorlvUZtTjU9U0JU9u7oryNyEGpO78nQc V+5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XI4pz7AeRs1sLulFzjwnAeNI6wqDPmsxX+6gYA4W1zU=; b=HjtW+0ls/2aRJY3wQvMg8NOskwv3lFu2fKAqib0Gbrb/OS/aIMtlkvezjDQ5g/mmjQ 7nQADAtBNbYJunJ/tqJ1jjwdStf2KASgBpQQhU4W5BeQ0dA2nFfKs6VAwHs3N76gdQbc rDNLN7Cm5o7mvIqxFKw6BUA7N4e6+ojDdSJ57eJvpeexFsnDM2kNkTIK+tnEVwL4jnes vAhO9Wwg1E6yvm23h13VK79NNjUXQpy9pExB7Ez/a4ads8woIjeowlTR0AjmIGH7EoF6 kIPr0bUqaQoceDeIxQcmzWwXkhnhEIFXHbozwjaKfZ1VtN7H8U19M7nm9d9T+EwCz6J/ +ukg== X-Gm-Message-State: ALoCoQnBFIc18+PXJAY+SgQ8cXQTuS/a4FGgaALYbHFLFGLIhbMcxJ31oRnuyV6YiFb7/dO+0QW2 MIME-Version: 1.0 X-Received: by 10.50.61.195 with SMTP id s3mr9543928igr.29.1406913093670; Fri, 01 Aug 2014 10:11:33 -0700 (PDT) Received: by 10.64.32.200 with HTTP; Fri, 1 Aug 2014 10:11:33 -0700 (PDT) In-Reply-To: <84FAEDDF-DA80-4D0D-BB08-26987DFC0D58@gmail.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> <20140728215213292302.e07f5538@sniff.de> <3A7F72AE-4746-41A6-A103-3424461D6D07@gmail.com> <1B87D84A-C34F-46D5-BA50-262C095DF72E@gmail.com> <48E1A67CB9CA044EADFEAB87D814BFF632B222C2@eusaamb107.ericsson.se> <20140731230828372641.3d067333@sniff.de> <84FAEDDF-DA80-4D0D-BB08-26987DFC0D58@gmail.com> Date: Fri, 1 Aug 2014 10:11:33 -0700 Message-ID: From: Tom Herbert To: Dino Farinacci Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/DgRUBgTG8TuHRGIssRSIkSbqEo4 Cc: LISP mailing list list , "nvo3@ietf.org" , David Melman , Eric Gray Subject: Re: [lisp] [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 17:11:53 -0000 On Fri, Aug 1, 2014 at 9:24 AM, Dino Farinacci wrote: >> Hello Dino, >> >> always interesting, different people interpret differently. >> >> You seem to talk about controlling where the OAM data flows. I don't thi= nk >> this is what Eric means. As long as a flow is defined in the traditional= 3- >> or 5-tuple way from the IP/UDP packet and as long as every router is map= ping >> the same flow onto the same ECMP egress interface we are fine. The detai= ls - >> the exact algorithm, if the algorithm uses the router-id as an additiona= l >> hash or whatever else - don't matter. The OAM packet would use the same >> IP/UDP header as the data packet it's supervising. And the receiver proc= esses >> OAM packets as "OAM" because of the flag set. > > For overlays, if you want to do RLOC selection at the encapsulator based = on the underlay's paths, you will need to know all paths so you can have gr= anular decision control. > > I didn't mean to emphasize the algorithm being used at each hop. There is= a combinatorial problem by looking at all paths. For example say one hop h= as ECMP paths (A, B, C) and the next one has (A', B', C'). For different 5-= tuples you can have A -> A', A -> B', A -> C', B -> A', B -> B', B -> C', = and C -> A', C -> B', C-> C'. And if the same algorithms are not used, you = may have a 1-to-many relationship from hop 1 to hope 2. > > If an OAM mechanism is going to measure attributes of a path, it will to = do so for all paths, And the number of combinations above was just in 2 box= es with only 3 ECMPs each. > > This quickly raises my complexity flag. > Definitely, the combinatorial problem has made concurrently probing all paths infeasible. The solution to detecting bad paths has been to get feedback to the application from the transport (e.g. TCP) for packet loss or excessive RTT for specific flows. The response to a bad path is simply reopen the connection and hope for a better path (by virtue of a different 5-tuple hash for the new connection). For encapsulation there is good news and bad news. When we're encapsulating over UDP we can affect the path simply by twiddling the source port a little, so having application reopen connection might not be necessary response to bad path. Bad news is that it may be infeasible to get the feedback from a third party guest about path quality. If the encapsulation layer wants to perform path selection somehow inband signaling and per flow might be needed at that layer. >>> One needs to argue if you really need the granuarlity for the complexit= y >>> that will needed to get this partially correct. >> >>> Well I think LISP RLOC-probing is good enough, but I am biased. ;-) >> >> you are "rich" by having an additional control plane UDP port ;-) >> I don't see much complexity although I agree that just knowing if the RL= OC is >> alive and ping-able may be enough in many cases. If we can get more like >> in-band OAM - why not? > > You can inband OAM for the control-port too. > >>> If an ITR sends a packet the ETR's address, the middle boxes do not kno= w if >>> it is a control-packet versus a data-packet. >> >> true but e.g. for LISP, while the middle box may have no idea what 4341 = and >> 4342 as udp ports mean, it could still calculate a different hash bucket= for >> ECMP due to the different UDP port. > > The hash is modulo the number of ECMP paths. You build the control packet= s with 5-tuples that generate hashs across all ECMP paths. > >> Hmm, my statement is so trivial - I assume you want to say something >> different with your reply? >> >> >>> I am trying to avoid problems. Seems like things are being over-enginee= red. >>> Again. >> >> I would say the echo nonce in RFC6830 is not fundamentally different fro= m >> OAM. The N+E flags trigger some activity on the receiver, similar to OAM= . > > It is way different. All we are testing is the forward path from ITR to E= TR (and nothing else). OAM proposals also meausre other attributes of the p= ath. > >> >>> P.S. Sorry I keep being negative. And if one person says shut up, I'll = stop >>> posting. >> >> well, everyone is entitled to his/her opinion and to voice it in his/her >> personal style. You have a point as I was a bit upset myself about this >> draft: there is likely more about it, otherwise why would we discuss >> yet-another-8-byte-header? Fabio offered the simplification the new head= er >> offers but for a while we will have 2-3 slightly different headers that = need >> active support in the code or hardware. Actually in terms of code - be i= t C >> or Verilog - I'm not sure there is any simplification ever over VxLAN + = LISP. > > Well if one wants the VXLAN and LISP header to be consistent, it was alre= ady that way from the start. And if you wanted to run L3 with a VXLAN heade= r, you use the destination MAC as the xTR's address and you got L3. There i= s no demux needed because the inner ethernet header has an ethertype that c= an demux every protocol ever invented in the world. > > Do not create a new registry for types authors of GPE. PPP learned this i= n 1989 and used ethertypes. Why is that different now? > > If there is an ethertype allocated for "ethernet" there can be one alloca= ted for NSH. And then if anyone ever wanted to run NSH directly over ethern= et, you have your ethertype. > > But I AM NOT RECOMMENDING THIS. I believe NSH should run on top of UDP an= d get its own port number. NSH sends UDP packets, period. > >> But at least the situation of having both VxLAN and LISP can be simplifi= ed by >> having a common umbrella and one common discussion. > > Agree. > >> Personally I think VxLAN-gpe is how the VxLAN/LISP header could have loo= ked >> like from the start (hindsight is great, I know) and I don't have a tech= nical >> problem with the draft itself. What is missing is enough context to disc= uss >> it. E.g. I'm still not sure why there is a P flag, if for a hard technic= al >> reason or for the aesthetics that every field is controlled by a turn-on= flag >> ;-) > > There is a P-flag so you have demux ability in the VXLAN/LISP header. So = we will demux at the UDP port level, the P-bit level, and the ethertype lev= el. All these will be demux decisions a forwarder has to deal with. This is= quite ridiculous. > >> So I encourage and kindly ask the authors to provide more of this contex= t in >> the next draft version. >> >> Regards, Marc > > Dino > >> >> >> >> On Thu, 31 Jul 2014 16:16:53 -0700, Dino Farinacci wrote: >>>> Dino, >>>> >>>> Would you re-phrase your response? I am having some trouble parsing i= t, >>>> so >>>> I must be missing something. >>>> >>>> First, I think (when you said "... sent from any pair of ports ...") y= ou >>>> meant to >>>> say "... sent with any pair of ports ..." - but this is a guess. >>> >>> Yes "with" is a better way of stating it. >>> >>>> As for making OAM messages traverse the exact same path as data, this = is >>>> what OAM is expected to do. In essence, if data follows a path that >>>> involves >>> >>> Good luck. I do not how you will be able to control each ECMP path at e= ach >>> path across different vendors as well as the same vendor with different >>> hashing algorithms. >>> >>> One needs to argue if you really need the granuarlity for the complexit= y >>> that will needed to get this partially correct. >>> >>>> a non-zero number of gates, while OAM does not, the successful deliver= y of >>>> OAM is only an approximate indication of the data-path integrity. Any= H/W >>>> that data has to go through, and OAM does not go through, could fail a= nd we >>>> would see an OAM indication of a valid path through which data either = would >>>> not go, or would be diverted in some unexpected way. >>> >>> Well I think LISP RLOC-probing is good enough, but I am biased. ;-) >>> >>>> Ordinarily, this should not be a problem for the hardware, as (ordinar= ily) >>>> the >>>> OAM is indistinguishable from data. The hardware works no harder to p= ush >>>> OAM than it would to push an equivalent amount of data. >>> >>> If an ITR sends a packet the ETR's address, the middle boxes do not kno= w if >>> it is a control-packet versus a data-packet. >>> >>>> So, what is the problem again? >>> >>> I am trying to avoid problems. Seems like things are being over-enginee= red. >>> Again. >>> >>> Dino >>> >>> P.S. Sorry I keep being negative. And if one person says shut up, I'll = stop >>> posting. >>> >>>> >>>> -- >>>> Eric >>>> >>>> -----Original Message----- >>>> From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Dino Farinacci >>>> Sent: Wednesday, July 30, 2014 9:13 PM >>>> To: Larry Kreeger >>>> Cc: Tom Herbert; David Melman; Marc Binderberger; LISP mailing list li= st; >>>> nvo3@ietf.org >>>> Subject: Re: [nvo3] Comments on >>>> http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 >>>> >>>>> I'm assuming that routers and switches will be multipathing based on >>>>> the UDP port numbers, so I would expect different destination UDP >>>>> ports to take different equal cost paths. >>>> >>>> Well if OAM is going to be effective, messages need to be sent from an= y >>>> pair of ports that yield 0 through N modulus so multiple paths can be >>>> determined. So it doesn't matter with the port number values you use, >>>> those control packets will be ECMPed as well. >>>> >>>> If you are also inferring that you want the OAM packets to go through = the >>>> same data-path of each device on the path, then you will have to put T= LVs >>>> in the data path, which is traditionally not prudent. See my Puneet >>>> reference from previous email. >>>> >>>> Dino >>>> >>>> _______________________________________________ >>>> nvo3 mailing list >>>> nvo3@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nvo3 >>> > From nobody Fri Aug 1 10:22:55 2014 Return-Path: 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 675761B2861; Fri, 1 Aug 2014 10:22:52 -0700 (PDT) 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 39YkqCe-BE4J; Fri, 1 Aug 2014 10:22:46 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91AFD1B2839; Fri, 1 Aug 2014 10:21:45 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id y13so5910812pdi.11 for ; Fri, 01 Aug 2014 10:21:45 -0700 (PDT) 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=Iw/2BhXjW4Vudc19lJtJcfpEcNcQTufnzTD38tPriZE=; b=oIv6OXB3uAczFEE7BVgYCRAKmnG3Uabhefrydb7kuCUzW9WXAuxEKWfSFxeOzmEpEx zytc//6yfDmZlfpECTG2Q/bfcWdXS1835wCLD78CdqGyBKZYATBWvo0rb+lFuwMo9cbD e0aEy90adgWck7gIzCtz4dmUIqM/UvMrDcGPelQPAiGmVrwQlmAEEUxvZE90aVy1wrPf Ki8pg56ZpfoRysb4wEXli0gYm4qDVA7AWKjm+QKrp5/OwA+0P6x27DaPSW47G3KPq+mS Q1e//uOIjYocTrMsKrVI+bBNB9a9OAcPVOcJtL6GrWfM/3WOt6Ak+EpMSmo4dFB3o0YQ Ik5A== X-Received: by 10.66.123.36 with SMTP id lx4mr7809307pab.21.1406913705255; Fri, 01 Aug 2014 10:21:45 -0700 (PDT) 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 nk1sm13952058pdb.0.2014.08.01.10.21.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Aug 2014 10:21:43 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dino Farinacci In-Reply-To: Date: Fri, 1 Aug 2014 10:21:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <466CF624-53B9-4EFC-9494-7292C689E71A@gmail.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> <20140728215213292302.e07f5538@sniff.de> <3A7F72AE-4746-41A6-A103-3424461D6D07@gmail.com> <1B87D84A-C34F-46D5-BA50-262C095DF72E@gmail.com> <48E1A67CB9CA044EADFEAB87D814BFF632B222C2@eusaamb107.ericsson.se> <20140731230828372641.3d067333@sniff.de> <84FAEDDF-DA80-4D0D-BB08-26987DFC0D58@gmail.com> To: Tom Herbert X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/0GIFI6P54vuRRGzNsMSFdYI42aA Cc: LISP mailing list list , "nvo3@ietf.org" , David Melman , Eric Gray Subject: Re: [lisp] [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 17:22:52 -0000 > For encapsulation there is good news and bad news. When we're > encapsulating over UDP we can affect the path simply by twiddling the > source port a little, so having application reopen connection might > not be necessary response to bad path. Bad news is that it may be > infeasible to get the feedback from a third party guest about path > quality. If the encapsulation layer wants to perform path selection > somehow inband signaling and per flow might be needed at that layer. This is why in LISP the ITR simply RLOC-probes each RLOC in the = locator-set and not concerned with the multiple paths to each RLOC. So = if RLOC-probing or echo-noncing determines an RLOC is unreachable, we = just switch to another RLOC. I am not sure if the LISP overlay had Segment Routing underneath it, = that it could really stay with an RLOC that has just gone down if it = could select another SR path to that RLOC. Maybe we are just splitting = hairs too thinly here. Dino From nobody Fri Aug 1 10:50:00 2014 Return-Path: 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 959121B288C; Fri, 1 Aug 2014 10:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RH-r6KaGfmdZ; Fri, 1 Aug 2014 10:49:50 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BF2D1A02DB; Fri, 1 Aug 2014 10:49:48 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-2a-53db7d578685 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 81.E1.25146.75D7BD35; Fri, 1 Aug 2014 13:43:20 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Fri, 1 Aug 2014 13:49:35 -0400 From: Eric Gray To: Marc Binderberger , Dino Farinacci Thread-Topic: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: AQHPqeDTgKnTo8JzqEinUCL6aopzsZu05OCAgABtLwCAAIjTgIAAzUAAgAAT3oCAAAUGgIAABJ8AgAKZtgCAAEbGgIAAAm4AgAEB1ZCAAG/vgIAAcv8AgACAirA= Date: Fri, 1 Aug 2014 17:49:33 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF632B2306C@eusaamb107.ericsson.se> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> <20140728215213292302.e07f5538@sniff.de> <3A7F72AE-4746-41A6-A103-3424461D6D07@gmail.com> <1B87D84A-C34F-46D5-BA50-262C095DF72E@gmail.com> <48E1A67CB9CA044EADFEAB87D814BFF632B222C2@eusaamb107.ericsson.se> <20140731230828372641.3d067333@sniff.de> In-Reply-To: <20140731230828372641.3d067333@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZXLonXDei9nawwZLVfBb/Pi5mtGjffY3R YsGbxSwWU86qW8y+8p/Z4ul8SYv9F06zOLB7TPm9kdVj56y77B4LNpV6LFnyk8lj8sKLzB6t q7tZAtiiuGxSUnMyy1KL9O0SuDLmPZrPXPDHrGLJi9+MDYyHtLsYOTkkBEwk7v6+xwphi0lc uLeerYuRi0NI4CijRP+keUwQzjJGiY33NjCCVLEJaEgcu7MWzBYR8JaYs+wiI0gRs8BORonl fy4xgySEBUIl+j5OY4YoCpM4+HE1K0iRiEAXo8SBvlVsIAkWARWJs8sWg03iFfCVWHJqNzuI LSRwgE2i5Us8iM0pYCpxdOMBsHpGoPu+n1rDBGIzC4hL3HoynwnibgGJJXvOM0PYohIvH/+D +kdJYtLSc6wQ9ToSC3Z/YoOwtSWWLXzNDLFXUOLkzCcsExjFZiEZOwtJyywkLbOQtCxgZFnF yFFanFqWm25kuIkRGH/HJNgcdzAu+GR5iFGAg1GJh1ch9XawEGtiWXFl7iFGaQ4WJXFezep5 wUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY9/NnSrrvWCumFGztt2pn5a40lcnc8/pOv1Jg vajzx6yxUmn3RpPWie0C96LS1y+IPbzsQfKHG4/7xdk5J2U+l167quGy3aPJi1iPzGATYMjp frQtYWVkiZ+jb+Lfd2rzTlZ90lq4cUmrkZS6THt4xHkH5+++655I7+8N1zX875bpZ1i8Zq2i EktxRqKhFnNRcSIAi7nABaACAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/C6POKFzyISCAjtuUbj3Aj1AGrhI Cc: David Melman , "nvo3@ietf.org" , LISP mailing list list , Tom Herbert Subject: Re: [lisp] [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 17:49:59 -0000 Marc/Dino, Marc has essentially caught the interpretation I meant. Sorry if I was no= t clear. -- Eric -----Original Message----- From: Marc Binderberger [mailto:marc@sniff.de]=20 Sent: Friday, August 01, 2014 2:08 AM To: Dino Farinacci; Eric Gray Cc: Larry Kreeger; Tom Herbert; David Melman; LISP mailing list list; nvo3@= ietf.org Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxla= n-gpe-03 Importance: High Hello Dino, always interesting, different people interpret differently. You seem to talk about controlling where the OAM data flows. I don't think = this is what Eric means. As long as a flow is defined in the traditional 3-= or 5-tuple way from the IP/UDP packet and as long as every router is mappi= ng the same flow onto the same ECMP egress interface we are fine. The detai= ls - the exact algorithm, if the algorithm uses the router-id as an additio= nal hash or whatever else - don't matter. The OAM packet would use the same= IP/UDP header as the data packet it's supervising. And the receiver proces= ses OAM packets as "OAM" because of the flag set. > One needs to argue if you really need the granuarlity for the=20 > complexity that will needed to get this partially correct. > Well I think LISP RLOC-probing is good enough, but I am biased. ;-) you are "rich" by having an additional control plane UDP port ;-) I don't s= ee much complexity although I agree that just knowing if the RLOC is alive = and ping-able may be enough in many cases. If we can get more like in-band = OAM - why not? > If an ITR sends a packet the ETR's address, the middle boxes do not=20 > know if it is a control-packet versus a data-packet. true but e.g. for LISP, while the middle box may have no idea what 4341 and 4342 as udp ports mean, it could still calculate a different hash bucket fo= r ECMP due to the different UDP port. Hmm, my statement is so trivial - I assume you want to say something differ= ent with your reply? > I am trying to avoid problems. Seems like things are being over-engineere= d.=20 > Again. I would say the echo nonce in RFC6830 is not fundamentally different from O= AM. The N+E flags trigger some activity on the receiver, similar to OAM. > P.S. Sorry I keep being negative. And if one person says shut up, I'll st= op=20 > posting. well, everyone is entitled to his/her opinion and to voice it in his/her=20 personal style. You have a point as I was a bit upset myself about this=20 draft: there is likely more about it, otherwise why would we discuss=20 yet-another-8-byte-header? Fabio offered the simplification the new header= =20 offers but for a while we will have 2-3 slightly different headers that nee= d=20 active support in the code or hardware. Actually in terms of code - be it C= =20 or Verilog - I'm not sure there is any simplification ever over VxLAN + LIS= P. But at least the situation of having both VxLAN and LISP can be simplified = by=20 having a common umbrella and one common discussion. Personally I think VxLAN-gpe is how the VxLAN/LISP header could have looked= =20 like from the start (hindsight is great, I know) and I don't have a technic= al=20 problem with the draft itself. What is missing is enough context to discuss= =20 it. E.g. I'm still not sure why there is a P flag, if for a hard technical= =20 reason or for the aesthetics that every field is controlled by a turn-on fl= ag=20 ;-) So I encourage and kindly ask the authors to provide more of this context i= n=20 the next draft version. Regards, Marc On Thu, 31 Jul 2014 16:16:53 -0700, Dino Farinacci wrote: >> Dino, >>=20 >> Would you re-phrase your response? I am having some trouble parsing it,= =20 >> so=20 >> I must be missing something. >>=20 >> First, I think (when you said "... sent from any pair of ports ...") you= =20 >> meant to >> say "... sent with any pair of ports ..." - but this is a guess. >=20 > Yes "with" is a better way of stating it. >=20 >> As for making OAM messages traverse the exact same path as data, this is= =20 >> what OAM is expected to do. In essence, if data follows a path that=20 >> involves >=20 > Good luck. I do not how you will be able to control each ECMP path at eac= h=20 > path across different vendors as well as the same vendor with different=20 > hashing algorithms. >=20 > One needs to argue if you really need the granuarlity for the complexity= =20 > that will needed to get this partially correct. >=20 >> a non-zero number of gates, while OAM does not, the successful delivery = of >> OAM is only an approximate indication of the data-path integrity. Any H= /W >> that data has to go through, and OAM does not go through, could fail and= we >> would see an OAM indication of a valid path through which data either wo= uld >> not go, or would be diverted in some unexpected way. >=20 > Well I think LISP RLOC-probing is good enough, but I am biased. ;-) >=20 >> Ordinarily, this should not be a problem for the hardware, as (ordinaril= y)=20 >> the >> OAM is indistinguishable from data. The hardware works no harder to pus= h >> OAM than it would to push an equivalent amount of data. >=20 > If an ITR sends a packet the ETR's address, the middle boxes do not know = if=20 > it is a control-packet versus a data-packet. >=20 >> So, what is the problem again? >=20 > I am trying to avoid problems. Seems like things are being over-engineere= d.=20 > Again. >=20 > Dino >=20 > P.S. Sorry I keep being negative. And if one person says shut up, I'll st= op=20 > posting. >=20 >>=20 >> -- >> Eric >>=20 >> -----Original Message----- >> From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Dino Farinacci >> Sent: Wednesday, July 30, 2014 9:13 PM >> To: Larry Kreeger >> Cc: Tom Herbert; David Melman; Marc Binderberger; LISP mailing list list= ;=20 >> nvo3@ietf.org >> Subject: Re: [nvo3] Comments on=20 >> http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 >>=20 >>> I'm assuming that routers and switches will be multipathing based on=20 >>> the UDP port numbers, so I would expect different destination UDP=20 >>> ports to take different equal cost paths. >>=20 >> Well if OAM is going to be effective, messages need to be sent from any= =20 >> pair of ports that yield 0 through N modulus so multiple paths can be=20 >> determined. So it doesn't matter with the port number values you use,=20 >> those control packets will be ECMPed as well. >>=20 >> If you are also inferring that you want the OAM packets to go through th= e=20 >> same data-path of each device on the path, then you will have to put TLV= s=20 >> in the data path, which is traditionally not prudent. See my Puneet=20 >> reference from previous email. >>=20 >> Dino >>=20 >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >=20 From nobody Fri Aug 1 11:14:25 2014 Return-Path: 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 526531B2796; Fri, 1 Aug 2014 11:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 EGfSjB3nVUIu; Fri, 1 Aug 2014 11:14:15 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E76D1A031A; Fri, 1 Aug 2014 11:14:15 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-f9-53db85851aa3 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id FB.F4.05330.5858BD35; Fri, 1 Aug 2014 14:18:14 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0174.001; Fri, 1 Aug 2014 14:14:13 -0400 From: Eric Gray To: Dino Farinacci Thread-Topic: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: AQHPqeDTgKnTo8JzqEinUCL6aopzsZu05OCAgABtLwCAAIjTgIAAzUAAgAAT3oCAAAUGgIAABJ8AgAKZtgCAAEbGgIAAAm4AgAEB1ZCAAG/vgIAA6f5Q Date: Fri, 1 Aug 2014 18:14:13 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF632B230F8@eusaamb107.ericsson.se> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> <20140728215213292302.e07f5538@sniff.de> <3A7F72AE-4746-41A6-A103-3424461D6D07@gmail.com> <1B87D84A-C34F-46D5-BA50-262C095DF72E@gmail.com> <48E1A67CB9CA044EADFEAB87D814BFF632B222C2@eusaamb107.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyuXRPlG5b6+1ggyfzBS3ad19jtJhyVt3i 6XxJB2aPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSvjyJM7TAXPzSu+rFjB1sA4V6eLkZND QsBEYs28AywQtpjEhXvr2boYuTiEBI4ySux9+5UZwlnGKPH/zF5GkCo2AQ2JY3fWgtkiQPbd 97vZQWxmgXiJiR2TWEFsYYFQib6P05ghasIkDn5czQoySESgiVFiSedxNpAEi4CKxMXtE8BW 8wr4SjT9OccEsW0qm0TfxHtMIAlOAVuJeZ/fgW1jBLrv+6k1TBDbxCVuPZnPBHG3gMSSPeeZ IWxRiZeP/7FC2EoSk5aeY4Wo15FYsPsTG4StLbFs4WtmiMWCEidnPmGZwCg2C8nYWUhaZiFp mYWkZQEjyypGjtLi1LLcdCODTYzAiDkmwaa7g3HPS8tDjAIcjEo8vAuEbwULsSaWFVfmHmKU 5mBREuedVTsvWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjUFzQw+lCUYX6ArWGuq7/EpXu R+48d+Z4z3HND1EmVxYa7zVaYt7/feM8ufV3Lly4URnw99Uql1aDv7fiPevrenKk49V3lK/+ Z18h3q4tFzDtu2DOv7k3n99iPZ3zUdiZrzAo3FAtykk++/ECmcPNc5Sebzol9cam4WHbWWGO gvuOaWzvC58qsRRnJBpqMRcVJwIAqv2bKXkCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/YEUY5X-vOFIGKka0rTZEjRh_6Fc Cc: "nvo3@ietf.org" , "LISP mailing list list \(lisp@ietf.org\)" Subject: Re: [lisp] [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 18:14:20 -0000 Dino, Thanks for the reply. I think we are on the same page, but possibly not. I don't argue that we should be able to steer an OAM message to follow a particular path among the multiple equal-cost paths, as long as OAM messa= ges contain enough entropy to ensure that sending some number of them will resu= lt=20 in having OAM messages traverse each of the multiple equal-cost paths. Ide= ally,=20 the mechanisms used - both in OAM and in path selection at each hop - will = tend=20 to distribute OAM messages and data on a proportional basis (e.g. - it's ba= d if 20%=20 of the OAM messages go along a path that carries ~50% of the data). Indeed, it is not clear what "following the same path" would mean on the basis of any individual data PDU. In order to do this literally you would = first have to=20 determine which path the data took and then determine what to put in the OA= M message to make it follow the same path. Alternatively, you could clone the parts of a particular data PDU that are= =20 used by distribution algorithms in each hop, in an OAM PDU that you want to= use the same path. Either of these approaches would be very hard, for all of the reasons you= =20 mentioned, and maybe a few you did not, and it is unclear to me why you wou= ld=20 need to do this most of the time. Certainly it will be pointless in proact= ive OAM. If the forwarders on a path are not able to distinguish data from OAM, it can be relatively easy to ensure that approximately the same distribution o= f OAM and data is the case. One issue that may come up is if the OAM messages have to be sent like other data packets, with Source and Destination IP address and transport-la= yer=20 port information of the source and sink of the OAM itself, and these fields= are all=20 that are included in any mechanism used to distribute traffic across multip= le paths,=20 then the OAM will all traverse the same path. One approach to dealing with this is to add one or more fields used to=20 provide the entropy that would otherwise be missing, and require every hop = to=20 include this field (or these fields) in path selection. Where this can cause trouble is if the field(s) are included in path selec= tion only if the PDU is an OAM message. In this case, while the entropy is ther= e to allow OAM message to provide full coverage, there is extra logic required in trav= ersing a series of hops (where each may have multiple path choices for forwarding) t= hat is=20 used to determine if the message is an OAM message. In this case, by definition, the forwarding devices will be distinguishing= OAM from data (using the extra logic) and this results in a "different path" (a= t the micro level, because of the extra logic - that may itself be subject to failure). The issue is less about the fact that the OAM PDU follows a different path= =20 in the network from that a corresponding data PDU would follow (though it m= ay);=20 it is that every OAM PDU will "follow" a different logical path within the = node itself. Alternatively, the field(s) can be examined in every PDU. This eliminates= =20 the risk of "path differentiation" (at the micro-level) because of the use = of extra=20 logic steps, but introduces a requirement that any PDU source MUST be caref= ul=20 about value(s) it puts in these fields (or risk having its flows distribute= d across=20 multiple paths). This can complicate domain ingress devices (for example, = a=20 tunnel entry point), and reduce overall entropy for distribution of data PD= Us. -- Eric -----Original Message----- From: Dino Farinacci [mailto:farinacci@gmail.com]=20 Sent: Thursday, July 31, 2014 7:17 PM To: Eric Gray Cc: Larry Kreeger; Tom Herbert; David Melman; Marc Binderberger; LISP maili= ng list list; nvo3@ietf.org Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxla= n-gpe-03 Importance: High > Dino, >=20 > Would you re-phrase your response? I am having some trouble parsing=20 > it, so I must be missing something. >=20 > First, I think (when you said "... sent from any pair of ports ...")=20 > you meant to say "... sent with any pair of ports ..." - but this is a g= uess. Yes "with" is a better way of stating it. > As for making OAM messages traverse the exact same path as data, this=20 > is what OAM is expected to do. In essence, if data follows a path=20 > that involves Good luck. I do not how you will be able to control each ECMP path at each = path across different vendors as well as the same vendor with different has= hing algorithms. One needs to argue if you really need the granuarlity for the complexity th= at will needed to get this partially correct. > a non-zero number of gates, while OAM does not, the successful=20 > delivery of OAM is only an approximate indication of the data-path=20 > integrity. Any H/W that data has to go through, and OAM does not go=20 > through, could fail and we would see an OAM indication of a valid path=20 > through which data either would not go, or would be diverted in some unex= pected way. Well I think LISP RLOC-probing is good enough, but I am biased. ;-) > Ordinarily, this should not be a problem for the hardware, as=20 > (ordinarily) the OAM is indistinguishable from data. The hardware=20 > works no harder to push OAM than it would to push an equivalent amount of= data. If an ITR sends a packet the ETR's address, the middle boxes do not know if= it is a control-packet versus a data-packet. > So, what is the problem again? I am trying to avoid problems. Seems like things are being over-engineered.= Again. Dino P.S. Sorry I keep being negative. And if one person says shut up, I'll stop= posting. >=20 > -- > Eric >=20 > -----Original Message----- > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Dino Farinacci > Sent: Wednesday, July 30, 2014 9:13 PM > To: Larry Kreeger > Cc: Tom Herbert; David Melman; Marc Binderberger; LISP mailing list=20 > list; nvo3@ietf.org > Subject: Re: [nvo3] Comments on=20 > http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 >=20 >> I'm assuming that routers and switches will be multipathing based on=20 >> the UDP port numbers, so I would expect different destination UDP=20 >> ports to take different equal cost paths. >=20 > Well if OAM is going to be effective, messages need to be sent from any p= air of ports that yield 0 through N modulus so multiple paths can be determ= ined. So it doesn't matter with the port number values you use, those cont= rol packets will be ECMPed as well. >=20 > If you are also inferring that you want the OAM packets to go through the= same data-path of each device on the path, then you will have to put TLVs = in the data path, which is traditionally not prudent. See my Puneet referen= ce from previous email. >=20 > Dino >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From nobody Fri Aug 1 11:26:25 2014 Return-Path: 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 E4FC61A031A; Fri, 1 Aug 2014 11:26:19 -0700 (PDT) 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 J01zWQ7laH19; Fri, 1 Aug 2014 11:26:12 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9C041A026F; Fri, 1 Aug 2014 11:26:12 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id fp1so5990310pdb.33 for ; Fri, 01 Aug 2014 11:26:12 -0700 (PDT) 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=rDqVaSnI8GY+fTe2ahVzzMBtQvRWX8nqi6iHWcMipiM=; b=h1CzFV6VwO4W+KvKaPAXGefJWpwBD/Coyri6J76gROkXJoFARFUhuWS6GHrSLEdLLz chdHsATX9X0P/+nMBYqM0IfCIpMGUzPctMXfABSFDC8UtpKSmjuvmHW4qQcee36/lLQS SMtqAUcul1ru3d6aQbVDoztVp7fDB/+XVVz7pgZuRQ5hRQUqfbjJFoJaar8zJYZB4dcx 5lC3xN9k67g0rm1p9aDpoJqOi1jn9qUKWbZTF3U5cfgBB8YfWv2fI8Dyv4swbjAv7Dzs EVfmhbRUEKfo8idxxgmN1fG1Gy7C2fvvQkSguIDKhuA5fr8K5kJn26e/HsgktnJv+y89 QpuA== X-Received: by 10.68.143.100 with SMTP id sd4mr8220041pbb.76.1406917572424; Fri, 01 Aug 2014 11:26:12 -0700 (PDT) Received: from [10.169.113.83] (69-170-63-51.static-ip.telepacific.net. [69.170.63.51]) by mx.google.com with ESMTPSA id da14sm32799612pac.24.2014.08.01.11.26.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Aug 2014 11:26:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dino Farinacci In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF632B230F8@eusaamb107.ericsson.se> Date: Fri, 1 Aug 2014 11:26:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <12909468-2D5A-41C9-B6FB-00DC496FC228@gmail.com> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> <20140728215213292302.e07f5538@sniff.de> <3A7F72AE-4746-41A6-A103-3424461D6D07@gmail.com> <1B87D84A-C34F-46D5-BA50-262C095DF72E@gmail.com> <48E1A67CB9CA044EADFEAB87D814BFF632B222C2@eusaamb107.ericsson.se> <48E1A67CB9CA044EADFEAB87D814BFF632B230F8@eusaamb107.ericsson.se> To: Eric Gray X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/R1PYp83esTb7D_Mu4_bNzv8bGBo Cc: "nvo3@ietf.org" , "LISP mailing list list \(lisp@ietf.org\)" Subject: Re: [lisp] [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 18:26:20 -0000 Yes Eric, you make a lot of good points. Therefore the promise of OAM is = very limited and can mislead at best. ;-) Dino On Aug 1, 2014, at 11:14 AM, Eric Gray wrote: > Dino, >=20 > Thanks for the reply. >=20 > I think we are on the same page, but possibly not. >=20 > I don't argue that we should be able to steer an OAM message to = follow > a particular path among the multiple equal-cost paths, as long as OAM = messages > contain enough entropy to ensure that sending some number of them will = result=20 > in having OAM messages traverse each of the multiple equal-cost paths. = Ideally,=20 > the mechanisms used - both in OAM and in path selection at each hop - = will tend=20 > to distribute OAM messages and data on a proportional basis (e.g. - = it's bad if 20%=20 > of the OAM messages go along a path that carries ~50% of the data). >=20 > Indeed, it is not clear what "following the same path" would = mean on the > basis of any individual data PDU. In order to do this literally you = would first have to=20 > determine which path the data took and then determine what to put in = the OAM > message to make it follow the same path. >=20 > Alternatively, you could clone the parts of a particular data = PDU that are=20 > used by distribution algorithms in each hop, in an OAM PDU that you = want to use > the same path. >=20 > Either of these approaches would be very hard, for all of the = reasons you=20 > mentioned, and maybe a few you did not, and it is unclear to me why = you would=20 > need to do this most of the time. Certainly it will be pointless in = proactive OAM. >=20 > If the forwarders on a path are not able to distinguish data = from OAM, it > can be relatively easy to ensure that approximately the same = distribution of OAM > and data is the case. >=20 > One issue that may come up is if the OAM messages have to be = sent like > other data packets, with Source and Destination IP address and = transport-layer=20 > port information of the source and sink of the OAM itself, and these = fields are all=20 > that are included in any mechanism used to distribute traffic across = multiple paths,=20 > then the OAM will all traverse the same path. >=20 > One approach to dealing with this is to add one or more fields = used to=20 > provide the entropy that would otherwise be missing, and require every = hop to=20 > include this field (or these fields) in path selection. >=20 > Where this can cause trouble is if the field(s) are included in = path selection > only if the PDU is an OAM message. In this case, while the entropy is = there to allow > OAM message to provide full coverage, there is extra logic required in = traversing a > series of hops (where each may have multiple path choices for = forwarding) that is=20 > used to determine if the message is an OAM message. >=20 > In this case, by definition, the forwarding devices will be = distinguishing OAM > from data (using the extra logic) and this results in a "different = path" (at the micro > level, because of the extra logic - that may itself be subject to = failure). >=20 > The issue is less about the fact that the OAM PDU follows a = different path=20 > in the network from that a corresponding data PDU would follow (though = it may);=20 > it is that every OAM PDU will "follow" a different logical path within = the node itself. >=20 > Alternatively, the field(s) can be examined in every PDU. This = eliminates=20 > the risk of "path differentiation" (at the micro-level) because of the = use of extra=20 > logic steps, but introduces a requirement that any PDU source MUST be = careful=20 > about value(s) it puts in these fields (or risk having its flows = distributed across=20 > multiple paths). This can complicate domain ingress devices (for = example, a=20 > tunnel entry point), and reduce overall entropy for distribution of = data PDUs. >=20 > -- > Eric >=20 > -----Original Message----- > From: Dino Farinacci [mailto:farinacci@gmail.com]=20 > Sent: Thursday, July 31, 2014 7:17 PM > To: Eric Gray > Cc: Larry Kreeger; Tom Herbert; David Melman; Marc Binderberger; LISP = mailing list list; nvo3@ietf.org > Subject: Re: [nvo3] Comments on = http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 > Importance: High >=20 >> Dino, >>=20 >> Would you re-phrase your response? I am having some trouble parsing=20= >> it, so I must be missing something. >>=20 >> First, I think (when you said "... sent from any pair of ports ...")=20= >> you meant to say "... sent with any pair of ports ..." - but this is = a guess. >=20 > Yes "with" is a better way of stating it. >=20 >> As for making OAM messages traverse the exact same path as data, this=20= >> is what OAM is expected to do. In essence, if data follows a path=20 >> that involves >=20 > Good luck. I do not how you will be able to control each ECMP path at = each path across different vendors as well as the same vendor with = different hashing algorithms. >=20 > One needs to argue if you really need the granuarlity for the = complexity that will needed to get this partially correct. >=20 >> a non-zero number of gates, while OAM does not, the successful=20 >> delivery of OAM is only an approximate indication of the data-path=20 >> integrity. Any H/W that data has to go through, and OAM does not go=20= >> through, could fail and we would see an OAM indication of a valid = path=20 >> through which data either would not go, or would be diverted in some = unexpected way. >=20 > Well I think LISP RLOC-probing is good enough, but I am biased. ;-) >=20 >> Ordinarily, this should not be a problem for the hardware, as=20 >> (ordinarily) the OAM is indistinguishable from data. The hardware=20 >> works no harder to push OAM than it would to push an equivalent = amount of data. >=20 > If an ITR sends a packet the ETR's address, the middle boxes do not = know if it is a control-packet versus a data-packet. >=20 >> So, what is the problem again? >=20 > I am trying to avoid problems. Seems like things are being = over-engineered. Again. >=20 > Dino >=20 > P.S. Sorry I keep being negative. And if one person says shut up, I'll = stop posting. >=20 >>=20 >> -- >> Eric >>=20 >> -----Original Message----- >> From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Dino Farinacci >> Sent: Wednesday, July 30, 2014 9:13 PM >> To: Larry Kreeger >> Cc: Tom Herbert; David Melman; Marc Binderberger; LISP mailing list=20= >> list; nvo3@ietf.org >> Subject: Re: [nvo3] Comments on=20 >> http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 >>=20 >>> I'm assuming that routers and switches will be multipathing based on=20= >>> the UDP port numbers, so I would expect different destination UDP=20 >>> ports to take different equal cost paths. >>=20 >> Well if OAM is going to be effective, messages need to be sent from = any pair of ports that yield 0 through N modulus so multiple paths can = be determined. So it doesn't matter with the port number values you = use, those control packets will be ECMPed as well. >>=20 >> If you are also inferring that you want the OAM packets to go through = the same data-path of each device on the path, then you will have to put = TLVs in the data path, which is traditionally not prudent. See my Puneet = reference from previous email. >>=20 >> Dino >>=20 >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >=20 From nobody Fri Aug 1 13:18:51 2014 Return-Path: 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 58E971B28B6; Fri, 1 Aug 2014 13:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 UsKBFvpblwYz; Fri, 1 Aug 2014 13:18:46 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D89E81B28B3; Fri, 1 Aug 2014 13:18:43 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-9c-53dba0408e67 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 85.AA.25146.040ABD35; Fri, 1 Aug 2014 16:12:17 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Fri, 1 Aug 2014 16:18:37 -0400 From: Eric Gray To: Dino Farinacci Thread-Topic: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 Thread-Index: AQHPqeDTgKnTo8JzqEinUCL6aopzsZu05OCAgABtLwCAAIjTgIAAzUAAgAAT3oCAAAUGgIAABJ8AgAKZtgCAAEbGgIAAAm4AgAEB1ZCAAG/vgIAA6f5QgABXGoD//9mvUA== Date: Fri, 1 Aug 2014 20:18:37 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF632B232AD@eusaamb107.ericsson.se> References: <032948928353486bb22eee58baad15c9@IL-EXCH01.marvell.com> <6D3E76C0-1A3C-4527-B286-54D58202A5E6@gmail.com> <20140727235848276183.21b2fe35@sniff.de> <20140728202308389912.8bba09a4@sniff.de> <075103F4-1163-4CDD-8ED7-4BB84AC59AB3@gmail.com> <20140728215213292302.e07f5538@sniff.de> <3A7F72AE-4746-41A6-A103-3424461D6D07@gmail.com> <1B87D84A-C34F-46D5-BA50-262C095DF72E@gmail.com> <48E1A67CB9CA044EADFEAB87D814BFF632B222C2@eusaamb107.ericsson.se> <48E1A67CB9CA044EADFEAB87D814BFF632B230F8@eusaamb107.ericsson.se> <12909468-2D5A-41C9-B6FB-00DC496FC228@gmail.com> In-Reply-To: <12909468-2D5A-41C9-B6FB-00DC496FC228@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyuXSPn67jgtvBBrs+8lu0777GaDHlrLrF 0/mSDsweO2fdZfdYsuQnUwBTFJdNSmpOZllqkb5dAlfG0q8d7AUNHBUT581gamDcyNbFyMkh IWAisfzNM2YIW0ziwr31QHEuDiGBo4wSLy++YoVwljFKzD/8jxWkik1AQ+LYnbWMILYIkH33 /W52EJtZIF5iYscksBphgVCJvo/TmCFqwiQOflzNCmFPYpS4dU2gi5GDg0VAReLJcVEQk1fA V+Li+XSQCiGBHnaJG2/1QWxOAVuJ48c+g01hBLrt+6k1TBCbxCVuPZnPBHGzgMSSPeeh7heV ePkY4koJASWJSUvPsULU60gs2P2JDcLWlli28DVYPa+AoMTJmU9YJjCKzUIydhaSlllIWmYh aVnAyLKKkaO0OLUsN93IcBMjMFKOSbA57mBc8MnyEKMAB6MSD69C6u1gIdbEsuLK3EOM0hws SuK8mtXzgoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwqhV9C0vYHaZV9+SJ9Yt1yjt6lEwk 7/sE912Xf8r+7C/P8QC9gP/PxE2Vd//OfZ93RNDRdNKrRbFTLh9YHH830VX4lY/xZcbYl4ur OHrEt967fIDrDUdOnfa+XEvr+yGNDy7tylXUyZwqdvfj6/nbo9T27UrM95q3fH/6IZN3kgXn vt2xcpc4rMRSnJFoqMVcVJwIAKgVUgl1AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/5AoRFEUrfNDHG2gWQHiKZp9FQdk Cc: "nvo3@ietf.org" , "LISP mailing list list \(lisp@ietf.org\)" Subject: Re: [lisp] [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 20:18:48 -0000 :-) Well, possibly somewhat limited under unusual circumstances and might misle= ad at=20 worst. The small possibility of being struck by lightning doesn't really justify s= tanding outside in a storm for no good reason. We could argue whether or not there is a good reason, but you might be surp= rised at my lack of fervor. I suspect that where you really stand in the argument depends on whether yo= u=20 build forwarding equipment, or use forwarding equipment built by someone el= se. I am just passing on arguments I have heard. -- Eric -----Original Message----- From: Dino Farinacci [mailto:farinacci@gmail.com]=20 Sent: Friday, August 01, 2014 2:26 PM To: Eric Gray Cc: LISP mailing list list (lisp@ietf.org); nvo3@ietf.org Subject: Re: [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxla= n-gpe-03 Importance: High Yes Eric, you make a lot of good points. Therefore the promise of OAM is ve= ry limited and can mislead at best. ;-) Dino --- [SNIP] --- From nobody Fri Aug 1 14:31:12 2014 Return-Path: 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 880771A008B for ; Fri, 1 Aug 2014 14:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.791 X-Spam-Level: X-Spam-Status: No, score=-11.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 wozUaGpyvkwf for ; Fri, 1 Aug 2014 14:30:55 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E7481A0084 for ; Fri, 1 Aug 2014 14:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=191977; q=dns/txt; s=iport; t=1406928655; x=1408138255; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Sm5MlB3IgFaZXKIYAgxoBv9dTe4uc0lAXSP9ggKcCdI=; b=dUKLC/K0oT8uDRf9NS4ZrYjO5NEB12gJowWBKLY6xWiVIs4bViXro9Xh SDMzISgCx7f5a/MaiGhybp0R1cA+j3qeAx7S5/CZgPsVu1FKuxvXNHiHA /qD2uIXVVpwFIV5Z1nt+h/iE/PxTZcbMR13y0cQO8vwoMSqPUYOXC9thq 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoHAGcG3FOtJA2D/2dsb2JhbABRAQkOgn9SVwSxdJg7gVgBCYdMAYELFneEBAEBBAEBAQsMAQw+AgYBBgUQAgEIDgQmAQYHIQYLFAMOAgQBDQUUB4gTAxENwUENhwkXiX+DIIFRAQMBCQxCBwmDJoEcBY5uiGGCJIIHgVSMYIYmgUaBQUJsgQMBAR4GHA X-IronPort-AV: E=Sophos;i="5.01,782,1400025600"; d="scan'208,217";a="344490946" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-7.cisco.com with ESMTP; 01 Aug 2014 21:30:50 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s71LUn0M023493 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Aug 2014 21:30:49 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.252]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Fri, 1 Aug 2014 16:30:48 -0500 From: "Victor Moreno (vimoreno)" To: Albert Cabellos , Damien Saucez Thread-Topic: [lisp] I-D ACTION:draft-ietf-lisp-introduction-04.txt Thread-Index: AQHPoTAXJ1qF/XE86kWhlodsRWy+ppukPp+AgAB2lICAAE77AIAMmTuAgAS5HICABlqjgA== Date: Fri, 1 Aug 2014 21:30:48 +0000 Message-ID: References: <20140716164043.11214.75343.idtracker@ietfa.amsl.com> <53C6ACAC.7090407@joelhalpern.com> <53EE128C-1552-4F00-AECF-6EE8511A4D18@gigix.net> <53D2BC3B.1090308@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.27.62.34] Content-Type: multipart/alternative; boundary="_000_BB4FB88584FC4F91A3CDBE41A81F39E8ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/Q4r1uzW2dyCD-098ccYEWuv0vHA Cc: "lisp@ietf.org" Subject: Re: [lisp] I-D ACTION:draft-ietf-lisp-introduction-04.txt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 21:31:10 -0000 --_000_BB4FB88584FC4F91A3CDBE41A81F39E8ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Alberto, Damien, A few suggestions for the intro doc: Overview/Basic Approach (currently 6 and 6.1): - Not in the current text: Spell out very clearly and upfront the concept o= f *separation* of location and identity. - With the concept of location/identity separation clear, then proceed to i= ntroduce RLOCs and EIDs as manifestations of such concepts. - Highlight that these are not mandatorily IP addresses (could be almost an= ything). - Build upon this to introduce the notion of RLOCs and EIDs as forming two = distinct address spaces - Finally introduce LISP as the mechanisms to handle the mappings that corr= elate the two address spaces. May be a good segway into the Basic functiona= lity section that follows. Basic Functionality (6.2): - I think it is worth adding to this section the notion of the destination = based policies manifested as priorities and weights. Since this is an archi= tectural doc, we may want to abstract this policy notion enough to accommod= ate other/future policy options that may arise. - The pull nature of the mechanism is introduced in 6.3 currently. I think = this is an important attribute and may be worth considering bringing it for= ward to 6.2. Initial Applications (7): - Fully agree that the section needs to be moved back if we keep it. - Most use cases will probably fall out of charter at this point, making th= is section very short until a future re-charter allows more use cases. IMO = we need text to allow for those future use cases that are currently out of = charter without having to re-open this architecture document. One option is= to keep the text on the use cases that is currently in the document. Anoth= er option is to include general text to allow future use cases. The latter = may be required regardless. - IMO, just keep the use cases in any order. 8.2. Regarding EID-block vs. prefix. I kind of like EID-block in support of= the AF agnostic characteristics of LISP. Prefixes (I think) are tightly co= upled with IP, once we have MAC addresses or other addresses prefix may not= be the best choice. 10. Part II {{comment from editors: is that the role of an introductory document to enter in such level of details and discuss (mostly) all fields of the protocol? }} IMO not in detail and we should probably be a bit more selective in terms o= f which fields we do discuss in this doc vs. which we do not. Thus outlinin= g the moving parts, at a high level, and providing references to the docum= entation with the relevant details may be helpful to those starting with LI= SP. In general, this second part should be much more succinct in my opinion= . Regarding any other =93Suggestions by editors", I agree with all the editor= suggestions in version 04 with any comments/exceptions noted above. Thanks for moving this forward. Regards, -v On Jul 28, 2014, at 1:28 PM, Albert Cabellos > wrote: Fabio, Please see below: On Fri, Jul 25, 2014 at 10:21 PM, Fabio Maino > wrote: Albert, Damien, please find my comments below. Network Working Group A. Cabellos-Aparicio (Ed.) Internet-Draft Technical University of Catalonia Intended status: Informational D. Saucez (Ed.) Expires: January 17, 2015 INRIA July 16, 2014 An Architectural Introduction to the LISP Location-Identity Separation System draft-ietf-lisp-introduction-04.txt Abstract This document is an introductory overview of the Locator/ID Separation Protocol, it describes the major concepts and functional sub-systems of LISP and the interactions between them. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is athttp://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 17, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 1] Internet-Draft LISP Introduction July 2014 Table of Contents 1. Prefatory Note . . . . . . . . . . . . . . . . . . . . . . . 4 2. Part I . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Initial Glossary . . . . . . . . . . . . . . . . . . . . . . 5 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Deployment Philosophy . . . . . . . . . . . . . . . . . . . . 7 5.1. Economics . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Maximize Re-use of Existing Mechanism . . . . . . . . . . 8 6. LISP Overview . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Basic Approach . . . . . . . . . . . . . . . . . . . . . 9 6.2. Basic Functionality . . . . . . . . . . . . . . . . . . . 9 6.3. Mapping from EIDs to RLOCs . . . . . . . . . . . . . . . 11 6.4. Interworking With Non-LISP-Capable Endpoints . . . . . . 11 6.5. Security in LISP . . . . . . . . . . . . . . . . . . . . 12 7. Initial Applications . . . . . . . . . . . . . . . . . . . . 13 7.1. Provider Independence . . . . . . . . . . . . . . . . . . 13 7.2. Multi-Homing . . . . . . . . . . . . . . . . . . . . . . 13 7.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 14 7.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . 15 7.6. Traversal Across Alternate IP Versions . . . . . . . . . 15 7.7. Virtual Private Networks . . . . . . . . . . . . . . . . 16 7.8. Local Uses . . . . . . . . . . . . . . . . . . . . . . . 16 8. Major Functional Subsystems . . . . . . . . . . . . . . . . . 17 8.1. Data Plane - xTRs Overview . . . . . . . . . . . . . . . 17 8.1.1. Mapping Cache Performance . . . . . . . . . . . . . . 18 8.2. Control Plane - Mapping System Overview . . . . . . . . . 18 8.2.1. Mapping System Organization . . . . . . . . . . . . . 19 8.2.2. Interface to the Mapping System . . . . . . . . . . . 20 8.2.3. Indexing Sub-system . . . . . . . . . . . . . . . . . 20 9. Examples of operation . . . . . . . . . . . . . . . . . . . . 22 9.1. An Ordinary Packet's Processing . . . . . . . . . . . . . 22 9.2. A Mapping Cache Miss . . . . . . . . . . . . . . . . . . 23 10. Part II . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. Design Approach . . . . . . . . . . . . . . . . . . . . . . . 24 12. xTRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 12.1. When to Encapsulate . . . . . . . . . . . . . . . . . . 25 12.2. UDP Encapsulation Details . . . . . . . . . . . . . . . 26 12.3. Header Control Channel . . . . . . . . . . . . . . . . . 26 12.3.1. Mapping Versioning . . . . . . . . . . . . . . . . . 26 12.3.2. Echo Nonces . . . . . . . . . . . . . . . . . . . . 27 12.3.3. Instances . . . . . . . . . . . . . . . . . . . . . 27 12.4. Probing . . . . . . . . . . . . . . . . . . . . . . . . 28 12.5. Mapping Lifetimes and Timeouts . . . . . . . . . . . . . 28 12.6. Mapping Gleaning in ETRs . . . . . . . . . . . . . . . . 29 12.7. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . 29 12.8. Security of Mapping Lookups . . . . . . . . . . . . . . 29 Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 2] Internet-Draft LISP Introduction July 2014 12.9. ITR Mapping Cache Performance . . . . . . . . . . . . . 30 13. The Mapping System . . . . . . . . . . . . . . . . . . . . . 31 13.1. The Mapping System Interface . . . . . . . . . . . . . . 32 13.1.1. Map-Request Messages . . . . . . . . . . . . . . . . 32 13.1.2. Map-Reply Messages . . . . . . . . . . . . . . . . . 32 13.1.3. Map-Register and Map-Notify Messages . . . . . . . . 33 13.2. The DDT Indexing Sub-system . . . . . . . . . . . . . . 34 13.3. Reliability via Replication . . . . . . . . . . . . . . 35 13.4. Security of the DDT Indexing Sub-system . . . . . . . . 35 13.5. Extended Capabilities . . . . . . . . . . . . . . . . . 36 13.6. Performance of the Mapping System . . . . . . . . . . . 36 14. Multicast Support in LISP . . . . . . . . . . . . . . . . . . 37 14.1. Basic Concepts of Multicast Support in LISP . . . . . . 37 14.2. Initial Multicast Support in LISP . . . . . . . . . . . 38 15. Deployment Issues and Mechanisms . . . . . . . . . . . . . . 39 15.1. LISP Deployment Needs . . . . . . . . . . . . . . . . . 39 15.2. Interworking Mechanisms . . . . . . . . . . . . . . . . 40 15.2.1. Proxy LISP Routers . . . . . . . . . . . . . . . . . 40 15.2.2. LISP-NAT . . . . . . . . . . . . . . . . . . . . . . 42 15.3. Use Through NAT Devices . . . . . . . . . . . . . . . . 42 15.4. LISP and Core Internet Routing . . . . . . . . . . . . . 43 16. Fault Discovery/Handling . . . . . . . . . . . . . . . . . . 43 16.1. Handling Missing Mappings . . . . . . . . . . . . . . . 44 16.2. Outdated Mappings . . . . . . . . . . . . . . . . . . . 44 16.2.1. Outdated Mappings - Updated Mapping . . . . . . . . 44 16.2.2. Outdated Mappings - Wrong ETR . . . . . . . . . . . 44 16.2.3. Outdated Mappings - No Longer an ETR . . . . . . . . 45 16.3. Erroneous Mappings . . . . . . . . . . . . . . . . . . . 45 16.4. Verifying ETR Liveness . . . . . . . . . . . . . . . . . 45 16.5. Verifying ETR Reachability . . . . . . . . . . . . . . . 46 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 19. Security Considerations . . . . . . . . . . . . . . . . . . . 47 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 20.1. Normative References . . . . . . . . . . . . . . . . . . 47 20.2. Informative References . . . . . . . . . . . . . . . . . 49 Appendix A. Glossary/Definition of Terms . . . . . . . . . . . . 52 Appendix B. Other Appendices . . . . . . . . . . . . . . . . . . 55 B.1. A Brief History of Location/Identity Separation . . . . 55 B.2. A Brief History of the LISP Project . . . . . . . . . . . 56 B.3. Old LISP 'Models' . . . . . . . . . . . . . . . . . . . . 56 B.4. The ALT Mapping Indexing Sub-system . . . . . . . . . . . 57 B.5. Early NAT Support . . . . . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 3] Internet-Draft LISP Introduction July 2014 1. Prefatory Note {{Suggestion by editors: Remove all the sections before "LISP Overview" and write a straight-to-the-point introduction}} {{Suggestion by editors: The draft should focus on describing the LISP architecture and avoid comparing loc/id split architectures with other approaches}} Agree: my suggestion is to view this as a doc for a reader new to LISP that= needs to be introduced to the architecture. At the end of the doc the read= er will be familiar with the basic aspects of LISP, and able to navigate th= rough the RFCs. The document should be kept as short and as "dry" as possib= le. If the reader wants to know more, after reading this doc, he will know = where to go for the details. This document is the first of a pair which, together, form what one would think of as the 'architecture document' for LISP (the 'Location-Identity Separation Protocol'). Much of what would normally be in an architecture document (e.g. the architectural design principles used in LISP, and the design considerations behind various components and aspects of the LISP system) is in the second document, the 'Architectural Perspective on LISP' document. [I-D.ietf-lisp-perspective] This 'Architectural Introduction' document is primarily intended for those who are unfamiliar with LISP, and want to start learning about it. It is intended primarily for those working on LISP, but those working with LISP, and more generally anyone who wants to know more about LISP, may also find this document useful. This document is intended to both be easy to follow and it is structured as a series of phases, each covering the entire system, but with ever-increasing detail. Reading only the first part of the document will give a good high-level view of the system; reading the complete document should provide a fairly detailed understanding of the entire system. People who just want to get an idea of how LISP works might only read the first part; they can stop reading either just before, or just after Section 9. People who are going to go on and read the protocol specifications (perhaps to implement LISP) should read the entire document. This document is a descriptive document, not a protocol specification. Should it differ in any detail from any of the LISP protocol specification documents, they take precedence for the actual operation of the protocol. 2. Part I Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 4] Internet-Draft LISP Introduction July 2014 3. Initial Glossary let's stick to the RFCs glossary. Since this is a first-to-read doc there s= hould be a minimal definition section, but definitions should mostly be cut= and paste from the RFCs. Agree, this will make easier to read the rest of the RFCs. This initial glossary defines a few general terms which will be useful to have in hand when commencing reading this document. A complete glossary is available in Appendix A. A note about style: initial usage of a term defined in the glossary is denoted with double quotation marks ("). Other uses of quotations (e.g. for quotations, euphemisms, etc) use single quotation marks ('). o Name: a name refers to an identifier for an object or entity. Names have both semantics (meaning) and syntax (form) [RFC1498]. o Namespace: A group of names with matching semantics and syntax; they usually, but not always, refer to members of a class of identical objects. o Mapping: a binding between two names, one in each of two namespaces. o Delegation Hierarchy: an abstract rooted tree (in the graph theory sense of the term) which is a virtual representation of the delegation of a namespace into smaller and smaller blocks, in a recursive process. o Node: The general term used to describe any sort of communicating entity; it might be a physical or a virtual host, or a mobile device of some sort. It includes both entities which forward packets, and entities which create or consume packets. o Switch, Packet Switch: A packet switch, in the general meaning of that term. A device which takes in packets from its interfaces and forwards them on, either to a next-hop switch, or to the final destination. They may operate at either the network layer (e.g. ARPANET), or internetwork layer. [Baran][Heart][RFC1812] o Endpoint, end-end communication entity: The fate-sharing region at one end of an end-end communication; the collection of state related to both the reliable end-end communication channel, and the applications running there. [Chiappa] o Address: In this document, in current IP (IPv4 or IPv6) and similar networking suites, a "name" which has mixed semantics, in that it includes both identity ('who') and location ('where') semantics. [Atkinson] Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 5] Internet-Draft LISP Introduction July 2014 o Address Block, Block: A contiguous section of a namespace (e.g., IP addresses that belong to the same prefix). o Identifier: a name which has identity semantics. o Locator: name with only location semantics and not necessarily carried in every packet [RFC1992]. o Site: A collection of hosts, routers, and networks under a single administrative control. o LISP site: a site separated from the rest of the network by LISP routers. o LISP node: A network element implementing LISP functionality; this means it can process some subset of LISP control and planes traffic. o LISP router: A network element implementing LISP data-plane functionality, i.e., a LISP node which can forward user traffic. o LISP host: A host which is behind (from the point of view of the rest of the network) a LISP router. 4. Background It has gradually been realized in the networking community that networks, especially large networks, should deal quite separately with the identity and location of an endpoint - basically, who an endpoint is, and where it is ([RFC1498] [RFC4984]). At the moment of this writing, in both IPv4 and IPv6, IP addresses indicate both where the named node is, as well as identify it for purposes of end-end communication; i.e. it has both location and identity properties. However, the separation of those two properties is a step which has been identified by the IRTF as a necessary evolutionary architectural step for the Internet [RFC6115] and the on-going LISP project is an attempt to provide a viable path towards this separation. As an add-on to a large existing system, it has had to make certain compromises. (For a good example, see [I-D.ietf-lisp-perspective], Section "Residual Location Functionality in EIDs". However, if it reaches near-ubiquitous deployment, it will have two important consequences. First, in effectively providing separation of location and identity, along with providing a distributed directory of the mappings between Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 6] Internet-Draft LISP Introduction July 2014 them, 'Wheeler's Law' ('All problems in computer science can be solved by another level of indirection') will come into play, and the Internet technical community will have a new, immensely powerful, tool at its disposal. The fact that the namespaces on both sides of the mapping are global ones maximizes the power of that tool. (See [I-D.ietf-lisp-perspective], Section "Need for a Mapping System", for more on this.) Second, because of a combination of the flexible capability built into LISP, and the breaking of the unification of location and identity names, further architectural evolution of the Internet becomes easily available; for example, new namespaces for location or identity could be designed and deployed. In other words, LISP is not a point solution to meet a particular need, but hopefully an 'escape hatch' which will allow further significant enhancement to the Internet's overall architecture. (See [Future] for more on this.) 5. Deployment Philosophy {{Suggestion by editors: Remove the entire section, it can be summarized by the last paragraph. Furthermore the arguments used in this sections are hard to follow since LISP has not been described yet.}} The deployment philosophy was a major driver for the design of LISP (architecture and engineering). Experience over the last several decades has shown that having a viable deployment model for a new design is a key to the adoption of the solution. In general, it is comparatively easy to conceive of new network designs, but much harder to devise approaches which will actually get deployed throughout the global network. A new design may be fantastic but if it can not be successfully deployed (for whatever factors), it is useless. LISP aims to achieve the near-ubiquitous deployment necessary for maximum exploitation of an architectural upgrade by i) minimizing the amount of change needed (most existing hosts and routers can operate unmodified); and ii) by providing significant benefits to early adopters. 5.1. Economics {{Suggestion by editors: Remove this section, this has not been discussed by the WG}} A key factor in successful adoption is economics: does the new design have benefits which outweigh its costs? Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 7] Internet-Draft LISP Introduction July 2014 More importantly, this balance needs to hold for early adopters - because if they do not receive benefits to their adoption, the sphere of earliest adopters will not expand, and it will never get to widespread deployment. This is particularly true of architectural enhancements, which are far less likely to be an addition which one can bolt onto the side of existing mechanisms, and often offer their greatest benefits only when widely (or ubiquitously) deployed. Maximizing the cost-benefit ratio obviously has two aspects. First, on the cost side, by making the design as inexpensive as possible, which means in part making the deployment as easy as possible. Second, on the benefit side, by providing many new capabilities, which is best done not by loading the design up with lots of features or options (which adds complexity), but by making the addition powerful through deeper flexibility. The LISP community believes LISP has met both of these goals. 5.2. Maximize Re-use of Existing Mechanism {{Suggestion by editors: Remove/Summarize the entire section, the arguments used in this section are hard to follow since LISP has not been described yet.}} Remove. This doc is not a guide to good protocol design. The concept that L= ISP is deployable incrementally should be mentioned in the document though,= possibly with a reference to the deployment RFC. Agreed, we=B4ll include an (ultra-short) section describing the design prin= ciples of LISP, incremental deployment is of course one of them. One key part of reducing the cost of a new design is to minimize the amount of change required to existing, deployed, devices: the fewer devices need to be changed, and the smaller the change to those that do, the greater the likelihood of deployment. Designs which absolutely require forklift upgrades to large amounts of existing gear are far less likely to succeed - because they have to have extremely large benefits to make their very substantial costs worthwhile. It is for this reason that LISP, in most cases, initially requires no changes to almost all existing devices in the Internet (both hosts and routers); LISP functionality needs to be added in only a few places ( Section 15.1) 6. LISP Overview LISP is an incrementally deployable architectural upgrade to the existing Internet infrastructure, one which provides separation of location and identity. It thus starts to separate the names used for identity and location of nodes, which are currently unified in IP addresses. Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 8] Internet-Draft LISP Introduction July 2014 6.1. Basic Approach {{Suggestion by editors: Merge this section with the previous one (LISP Overview)}} Agree: across the document, as done in the RFCs, I'd suggest to focus on de= scribing the protocol architecture and how it works rather than on more gen= eric considerations about the LISP philosophy. In LISP, the first key concept is that nodes have both an identifier called an Endpoint IDentifier (EID) and an associated Routing Locator (RLOC). A node may be associated with more than one RLOC, or the RLOC may change over time (e.g., if the node is mobile), but it would normally always have the same EID. The second key concept is that if one wants to be as forward-looking as possible, conceptually one should think of the two kinds of names (EIDs and RLOCs) as naming different classes of entities. On the one hand, EIDs are used to name nodes - or rather, their end- end communication entities. RLOC(s), on the other hand, name interfaces, i.e. places to which the system of routers sends packets. This distinction, the formal recognition of different kinds of entities ("endpoints" and interfaces), and their association with the two different classes of names, is also important. Clearly recognizing interfaces and endpoints as distinctly separate classes of objects is another improvement to the existing Internet architecture. An important insight in LISP is that it initially uses existing IP addresses for both of these kinds of names, as opposed to some similar earlier deployment proposals for separation of location and identity (e.g. [RFC1992]), which proposed using a new namespace for locators. This choice minimizes LISP's deployment cost, as well as providing the ability to easily interact with un-modified hosts and routers. The capability to use namespaces other than IP addresses for both kinds of names is already built in LISP, which is expected to greatly increase the long-term benefits, flexibility, and power of LISP ([AFI], [I-D.ietf-lisp-lcaf]). 6.2. Basic Functionality {{Suggestion by editors: Rewrite this section: It is using non- standard terminology to refer to standard LISP concepts ('enhance' instead of encapsulate) It is using subjective terms (e.g., 'near' the source) It is missing key LISP aspects such as that RLOC packets are forwarded in the RLOC space }} Make sure a figure with the basic elements of the protocol architecture (po= ssibly similar to figure 1) is introduced as early as possible. Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 9] Internet-Draft LISP Introduction July 2014 The basic operation of LISP, as it currently stands, is quite simple. LISP augmented packet switches, "LISP routers", near the source and destination of packets intercept traffic, and 'enhance' the packets for the trip between the LISP switches. The LISP router near the original source (the Ingress Tunnel Router, or ITR ) looks up additional information about the destination of the packet, and then wraps the packet in an outer header, one which contains additional information related to LISP operation. The LISP router near the destination, the (the Egress Tunnel Router, or ETR) removes that header, leaving the original, un-modified, packet to be sent on to the original destination node. The overall processing is shown below, in Figure 1: /-----------------\ --- | Mapping | | . System | | Control -| |`, | Plane ,' \-----------------/ . | / \ --- ,.., - _,..--..,, `, ,.., | / ` ,' ,-` `', . / ` | / \ +-----+ ,' `, +--'--+ / \ | | EID |-| xTR |---/ RLOC ,---| xTR |-| EID | | Dat= a | Space |-| |---| Space |---| |-| Space | | Pla= ne \ / +-----+ . / +-----+ \ / | `. .' `. ,' `. .' | `'-` `., ,.' `'-` --- ``''--''`` LISP Site (Edge) Core LISP Site (Edge) Figure.- An schema of the LISP Architecture Figure 1: Basic LISP Packet Flow To retrieve that additional information, the ITR uses the information in the original packet about the identity of its ultimate destination, i.e. the destination EID address. It uses the destination EID to look up the current location (the RLOC) of that EID. The lookup is performed through a mapping system, which is the heart of LISP: it is a distributed directory of mappings from EIDs to Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 10] Internet-Draft LISP Introduction July 2014 RLOCs. The destination RLOC(s) is (are) normally the address(es) of the ETR(s) near the ultimate destination. The ITR then generates a new outer header for the original packet, with that header containing the ETR's RLOC as the wrapped packet's destination, and the ITR's own address (i.e. the RLOC usually associated with the original source) as the wrapped packet's source, and sends it off. When the packet arrives at the ETR, that outer header is stripped off, and the original packet is forwarded to the original ultimate destination for normal processing. Return traffic is handled similarly, often (depending on the network's configuration) with the original ITR and ETR switching roles. The ETR and ITR functionality is usually co-located in a single LISP router; these are normally denominated as xTRs. 6.3. Mapping from EIDs to RLOCs The mappings from EIDs to RLOCs are provided by a distributed, and potentially replicated, database, the "mapping database", which is the heart of LISP. Here, and in other places in LISP, the replication is not a deep architectural concept, simply an engineering device to obtain reliability via potential redundancy. Entities which need EID-to-RLOC mappings get them from the mapping system, which is a collection of sub-systems through which clients can find and obtain mappings as discussed in more details in Section 8.2 and Section 13. Mappings are normally distributed via a pull mechanism (i.e., not pre-loaded, but requested on demand). Once obtained by an ITR, they are cached for performance reasons. 6.4. Interworking With Non-LISP-Capable Endpoints It is clearly crucial to provide the capability for easy interoperation between "LISP hosts" - i.e. they are behind xTRs, and their EIDs are in the mapping database - and existing non-LISP-using hosts (often called 'legacy' hosts) or legacy "sites". To allow interoperation between devices hosted in a LISP site and devices not belonging to a LISP site (non-LISP site), an interworking mechanism based on proxies has been designed. Proxy ITRs (PITR) encapsulate packets sent from non-LISP sites to LISP sites while Proxy ETRs (PETR) decapsulate packets sent from LISP sites to non- LISP sites. More details are given in Section 15.2.1. Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 11] Internet-Draft LISP Introduction July 2014 6.5. Security in LISP {{Suggestion by editors: Rewrite this section: (first 3 paragraphs) It contains a general discussion as well as strong statements that are not supported by any WG document. (last 3 paragraphs) It enumerates the security mechanisms specified in LISP but does not describe them.}} Agree. I think that the security considerations section of RFC6830 may prov= ide a guide to the items you may want to touch in this document. Point the = reader to the RFCs when possible. Move broader security considerations to t= he Security Section referencing lisp-threats where needed. Agreed. To provide a brief overview of security in LISP, it is definitely understood that LISP needs to be highly _securable_, especially in the long term; over time, the attacks mounted by 'bad guys' are becoming more and more sophisticated. So LISP, like DNS, needs to be _capable_ of providing 'the very best' security there is. At the same time, there is a conflicting goal: it must be deployable at a a viable cost. That means two things: First, as an experiment, we cannot expect to create the complete security apparatus which we might see in the finished product, including both design and implementation. Second, security needs to be flexible, so that we don't overload the users with more security than they need at any point. To accomplish these divergent goals, the approach taken is to first analyze what LISP needs for security. [I-D.ietf-lisp-threats]. Then, steps can be taken to ensure that the appropriate 'hooks' (such as packet fields) are included at an early stage, when doing so is still easy. Over time, additional mechanisms will be fully specified, implemented, and deployed. LISP does already include a number of security mechanisms; in particular, requesting mappings can be secured (see Section 12.8, "Security of Mapping Lookups"), as can registering of xTRs (see Section 13.1.3, "Map-Register and Map-Notify Messages"); the key database of the mapping system is also secured (see Section 13.4, "Security of the DDT Indexing Sub-system"). The existing security mechanisms, and their configuration (which is mostly manual at this point) currently in LISP are felt to be adequate for the needs of the on-going early stages of deployment; experience will indicate when improvements are required (within the constraints of the conflicting goal given above). For more on LISP's security philosophy; see [I-D.ietf-lisp-perspective], Section 7 "Security", where it is laid out in some detail. Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 12] Internet-Draft LISP Introduction July 2014 7. Initial Applications {{Suggested by editors: Move this section after section 8, the applications should not be described before LISP has been fully described. {{Suggested by Noel: Reorder the whole section in popularity order?}} As previously mentioned, it is felt that LISP will provide even the earliest adopters with some useful capabilities, and that these capabilities will drive early LISP deployment. It is very imporant to note that even when used only for interoperation with existing un-modified hosts, use of LISP can still provide benefits to the site which has deployed it - and, perhaps even more importantly, can do so to both sides. This characteristic acts to further enhance the utility for early adopters of LISP. Note also that this section only lists some early applications and benefits. See [I-D.ietf-lisp-perspective], in the Section "Goals of LISP", for a more extensive discussion of some of what LISP might ultimately provide. 7.1. Provider Independence Provider independence (i.e. the ability to easily change one's Internet Service Provider) is a good example of the utility of separating location and identity. To limit global routing table size addresses need to be aggregated. To that aim networks can use provider aggregatable addresses ([RFC4116]) which means that the IP prefixes of networks are sub- prefixes of their provider. This solutions allows to reduce scalability issues of the global routing table but it means that when a network switches providers it has to re-number all its devices which is known to be complex in current networks [RFC5887]. Having separate namespaces for location and identity greatly reduces the problems involved with re-numbering; an organization which moves retains its EIDs (which are how most other parties refer to its nodes), but is allocated new RLOCs, and the mapping system can quickly provide the updated mapping from the EIDs to the new RLOCs. 7.2. Multi-Homing {{Suggested by editors: This section should be extended, it is unclear the benefits that LISP brings to multihoming (.e.g, traffic engineering, decoupled multihoming from the data-plane). Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 13] Internet-Draft LISP Introduction July 2014 Multi-homing is another place where the value of separation of location and identity became apparent. There are several different sub-flavours of the multi-homing problem - e.g. depending on whether one wants open TCP connections to keep working, etc - and other axes as well (e.g. site multi-homing versus host multi-homing). In particular, for the 'keep open connections up' case, without separation of location and identity, with most currently deployed implementations, the only currently feasible approach is to use provider-independent addressses - which moves the problem into the global routing system, with attendant costs. This approach is also not really feasible for host multi-homing. 7.3. Traffic Engineering {{Suggestion by editors: Merge this section with the previous one, TE is not practical without multihoming}} {{Needs a fix - not sure what.}} Traffic engineering (TE) [RFC3272], desirable though this capability is in a global network, is currently somewhat problematic to provide in the Internet. The problem, fundamentally, is that this capability was not forseen when the Internet was designed, so the support for it via hacks is neither clean, nor flexible. TE is, fundamentally, a routing issue. However, the current Internet routing architecture, which is basically the Baran design of fifty years ago [Baran] (a single large, distributed computation), is ill- suited to provide TE. The Internet seems a long way from adopting a more-advanced routing architecture, although the basic concepts for such have been known for some time. [RFC1992] Although the identity-location mapping layer is thus a poor place, architecturally, to provide TE capabilities, it is still an improvement over the current routing tools available for this purpose (e.g. injection of more-specific routes into the global routing table). In addition, instead of the entire network incurring the costs (through the routing system overhead), when using a mapping layer to provide TE, the overhead is limited to those who are actually communicating with that particular destination. LISP includes a number of features in the mapping system to support TE. (described in Section 8.2, "Control Plane - Mapping System Overview", below); more details about using LISP for TE can be found in [I-D.farinacci-lisp-te]. Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 14] Internet-Draft LISP Introduction July 2014 Also, a number of academic papers have explored how LISP can be used to do TE, and how effective it can be. See the online LISP Bibliography ([Bibliography]) for information about them. 7.4. Routing {{Suggestion by editors: Remove this section, LISP is not a routing protocol.}} Multi-homing and Traffic Engineering are both, in some sense, uses of LISP for routing, but there are many other routing-related uses for LISP. One of the major original motivations for the separation of location and identity in general, and thus LISP, was to reduce the growth of the routing tables in the "Internet core", the part where routes to _all_ ultimate destinations must be available. LISP is expected to help with this; for more detail, see Section 15.4, "LISP and Core Internet Routing", below. LISP may also have more local applications in which it can help with routing; see, for instance, [CorasBGP]. 7.5. Mobility {{Suggestion by editors: Remove this section, mobility is not in charter.}} Mobility is yet another place where separation of location and identity is a key part of a clean, efficient and high-functionality solution. Considerable experimentation has been completed on doing mobility with LISP. The mobility provided by LISP allows active sessions to survive moves (provided of course that there is not a period of inaccessibility which exceeds a timeout). LISP mobility also will typically have better packet stretch (i.e. increase in path length) compared to traditional mobility schemes, which use a home agent. 7.6. Traversal Across Alternate IP Versions Note that LISP inherently supports intermixing of various IP versions for packet carriage; IPv4 packets might well be carried in IPv6, or vice versa, depending on the network's configuration. This capability allows an island of operation of one type to be automatically tunneled over a stretch of infrastucture which only supports the other type. Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 15] Internet-Draft LISP Introduction July 2014 7.7. Virtual Private Networks {{Suggestion by editors: Remove this section, not covered by any WG document}} L2 and L3 {{Need to add text here - This used to be part of 'Local' below, but we decided this was so important it deserved its own section. Maybe move this up further, as it seems to be the most important 'early adopter' application?}} The mapping-and-encapsulation nature of LISP makes it a perfect candidate for VPN solutions. In this case, private parts of the VPN form LISP sites and the IP addresses of devices in the private parts are composing EID spaces. The interconnection between the LISP sites is the public network and IP addresses in the interconnection compose the RLOC space. A major advantage of using LISP to construct VPN resides in the simplicity of the configurations: each xTR (i.e., VPN end) is configured to query the mapping system to retrieve mappings making the glue between the public (RLOC space) and the private (EID space) of the VPN. This includes support of multi-tenancy where several private networks can be carried over the same underlayer network. Thanks to the instance-id field, multi-tenant network can even use the exact same addresses as the xTR distinguishes the tenant based on the value of the instance-id. The multiple address family support in LISP mappings also allows to build private networks using a different addressing family than the carrier (e.g., IPv6 over IPv4). 7.8. Local Uses {{Suggestion by editors: Remove this section. The section contains a general discussion about the applicability of LISP in intra-domain scenarios, however it does not describe any specific application.}} LISP has a number of use cases which are within purely organizationally-local contexts, i.e. not in the larger Internet. These fall into two categories: uses seen on the Internet (above), but here on a private (and usually small scale) setting; and applications which do not have a direct analog in the larger Internet, and which apply only to local deployments. Among the former are multi-homing and IP version traversal. {{This was marked to be deleted - why? The next part doesn't make sense without this first?}} Among the latter class, non-Internet applications which have no analog on the Internet, are the following example applications: Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 16] Internet-Draft LISP Introduction July 2014 virtual machine mobility in data centers; non-IP EID types such as L2 MAC addresses, or application specific data. Several of the applications listed in this section are the ones which have been most popular for LISP in practise; these include virtual networks, and virtual machine mobility. These often show a synergistic tendency, in that a site which installs LISP to do one, often finds that then becomes a small matter to use it for the second. Given all the things which LISP can do, it is hoped that this synergistic effect will continue to expand LISP's uses. {{Preceeding paragraphs should probably get moved up into VPN section?}} 8. Major Functional Subsystems {{Suggestion by editors: This section should appear before since it describes key aspects of LISP (e.g., LISP decoupled control and data- plane).}} Yes, possibly where the first figure is. LISP has two major functional sub-systems: the xTRs which form the data-plane of LISP; and the mapping system which forms the control plane that maintains and distributes the mapping database. The purpose and operation of each is described at a high level below, and then, later on, in a fair amount of detail, in separate sections on each (Section 12 and Section 13). 8.1. Data Plane - xTRs Overview {{Suggestion by editors: Extend this section, it misses key LISP data-plane aspects, such as the map-cache.}} xTRs are routers that have been augmented with extra functionality in both the data and control planes. The data plane functions in ITRs include deciding which packets need to be given LISP processing (since packets to non-LISP hosts may be sent as they are); i.e. looking up the mapping; encapsulating (wrapping) the packet; and sending it to the ETR. This encapsulation is done using UDP [RFC0768], along with an additional outer IP header (to hold the source and destination RLOCs). To the extent that traffic engineering features are in use for a particular EID, the ITRs implement them as well. Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 17] Internet-Draft LISP Introduction July 2014 In the ETR, the data plane simply decapsulates (unwraps) the packets, and forwards the it to the destination. Control plane functions in ITRs include: asking for EID-to-RLOC mappings via Map-Request packets; handling the returning reply control messages (i.e., Map-Reply packets), which contain the EID-to- RLOC mapping; managing the local mapping cache and checking for the reachability of destination ETR's RLOCs. In the ETR, control plane functions include participating in the reachability tests (see Section 16.4); interacting with the mapping sub-system to let it know what mapping this ETR can provide (see Section 8.2.2); and answering Map-Request packets from ITRs for those mappings. 8.1.1. Mapping Cache Performance {{Suggestion by editors: Push this section further in the document, the cache performance is not a "Major LISP subsystem"}} As mentioned, studies have been performed to verify that caching mappings in ITRs is viable, in practical engineering terms. These studies not only verified that such caching is feasible, but also provided some insight for designing ITR "mapping caches". Briefly, they took lengthy traces of all packets leaving a large site, over a period of a week or so, and used those to drive simulations which showed how many mappings would be required. It also allowed analysis of how much control traffic (for loading needed mappings) would result, using various cache sizes and replacement algorithms. These studies provide an insight into how well LISP can be expected to perform, and scale, over time. A more extended look at the results us given below, in Section 12.9, "xTR Mapping Cache Performance". 8.2. Control Plane - Mapping System Overview {{Suggestion by editors: Rewrite: Replace EID block terminology (along with its description) with the very common term "prefix". Describe Map-Request/Map-Reply LISP signaling messages.}} The mapping system's entire purpose is to give ITRs on-demand access to the mapping database, which is a distributed, and potentially replicated, database which holds mappings between EIDs (identity) and RLOCs (location), along with needed ancillary data (e.g. lifetimes). Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 18] Internet-Draft LISP Introduction July 2014 To be exact, it contains mappings between EID blocks and RLOCs (the block size is given explicitly, as part of the syntax). Support for blocks is both for minimizing the administrative configuration overhead, as well as for operational efficiency; e.g. when a group of EIDs are behind a single xTR. In IP blocks are delimited by their IP prefix. However, the block may be, and sometimes is, as small as a single EID. However, since mappings are only loaded upon demand, if smaller blocks become predominant, then the increased size of the overall database is far less problematic than if the Internet's routing tables came to be dominated by such small entries. A particular EID (or EID block) may be associated to than one RLOC, and may change the association with time. Also, in general, throughout LISP, the address family of EIDs and RLOCs is explicitly mentioned in control packet. Finally, the mapping from an EID (or EID block) contains not just the RLOC(s), but also (for each RLOC for any given EID entry) priority and weight fields (to allow allocation of load between several RLOCs at a given priority); this allows a certain amount of traffic engineering to be accomplished with LISP. 8.2.1. Mapping System Organization {{Suggestion by editors: Rewrite: Describe key Mapping System components: Map-Server/Map-Resolver}} The mapping system is split into three functional sub-systems. The first is the actual mappings themselves, collectively the mapping database; they are held by the ETRs, and an ITR which needs a mapping gets it (effectively) directly from the ETR. This co-location of the authoritative version of the mappings, and the forwarding functionality which it describes, is an instance of fate-sharing. [Clark] To find the appropriate ETR(s) to query for the mapping, the second two sub-systems form an indexing system, itself also based on a distributed, potentially replicated database. It provides information on which ETR(s) are authoritative sources for the various EID-to-RLOC mappings which are available. The two sub-systems which form it are the client interface sub-system, and indexing sub-system (which holds and provides the actual information). Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 19] Internet-Draft LISP Introduction July 2014 8.2.2. Interface to the Mapping System {{Suggestion by editors: has been rewritten: This section should appear earlier since it describes key LISP components (Map-Request/ Map-Reply/Map-Server/Map-Resolver}} The client interface to the indexing system from an ITR's point of view is not with the indexing sub-system directly; rather, it is through the Map-Resolvers (MRs) and Map-Servers (MSs). To obtain the mapping for an EID, the ITRs sends Map-Request packet to an MR. The MR then uses the indexing sub-system to allow it to forward the Map-Request to an appropriate Map-Server (MS), which in turn sends the Map-Request on to the appropriate ETR. The latter is authoritative for the actual mappings for the EID. The ETR then sends the mappings for that EID in the form of aMap- Reply packets, which is sent directly to the ITR, without passing through the indexing sub-system and MR. The details of the indexing sub-system are thus hidden from the ITRs. Note that in proxy mode, the MS replies on behalf of the ETR. When this the case, the map-replies is tagged to indicate that the answer is not delivered from the authoritative ETR but from the MS instead. The interface to the indexing system from an ETR's point of view is made through MSes. ETRs send Map-Register packets to their designated MSes. The effect of a Map-Register is to inform the MS about the mappings maintained by ETRs such that the MS can transmit the Map-Requests is receives to the appropriate ETRs. The MS optionally replies Map-Register packets with a Map-Notify packet to confirm the registration. The details of the indexing sub- system are thus likewise hidden from ETRs. The fact that the details of the indexing sub-system are entirely hidden from xTRs gives considerably flexibility to this aspect of LISP. As long as any potential indexing sub-system can track where mappings are, it could potentially be used; this would allow the actual indexing sub-system to be replaced without needing to modify the xTRs. 8.2.3. Indexing Sub-system {{suggestion by editor: rename the section to "DDT"}} I think this section should briefly describe both ALT (mostly by reference = to RFC 6836) and DDT (by reference to LISP-DDT, with way fewer details on = DDT than in the current document). "Indexing System" (as a component of the= mapping system, together with the mapping database) may be a good name for= this section. "Index subsystem" is not a term used in ALT or DDT. What about "Mapping Dat= abase"? The current indexing sub-system is the Delegated Database Tree (DDT), which is conceptually similar to DNS ([I-D.ietf-lisp-ddt], Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 20] Internet-Draft LISP Introduction July 2014 [RFC1034]). DDT replaces the earlier LISP+ALT indexing sub-system ([RFC6836]). The seamless migration to DDT while LISP+ALT was previously used validated the concept of having a client-interface sub-system between the indexing sub-system, and the clients. 8.2.3.1. DDT Overview Conceptually, DDT is similar to the DNS, in DDT the delegation of the EID namespace is instantiated as a delegation hierarchy, a tree of DDT nodes, starting with the root DDT node. Each vertex is responsible for a block of the EID namespace. The root node is responsible for the entire EID space; any DDT node can delegate part(s) of its EID block to child DDT node(s). The child node(s) can in turn further delegate (necessarily smaller) blocks of namespace to their children, through as many levels as are needed (for operational, administrative, etc, needs). Just as with DNS, any particular vertex in the DDT delegation tree may be instantiated in one or more DDT servers. Multiple (redundant) servers for a given node would be used for reasons of performance, reliability, and robustness. Obviously, all the servers which instantiate a particular nodes in the tree have to have identical data about that node. 8.2.3.2. Use of DDT by MRs An MR which wants to find a mapping for a particular EID first interacts with the DDT servers which instantiate the nodes of the LISP delegation hierarchy tree, discovering (by querying the servers for information about DDT nodes) the chain of delegations which cover that EID. Eventually it is directed to an MS, which is servicing an ETR which is authoritative for that EID. Also, again like DNS, MRs may cache information they receive about the delegations in the delegation tree. This means that once an MR has been in operation for a while, it will usually have much of the delegation information cached locally (especially the top levels of the delegation tree). This allows them, when passed a request for a mapping by an ITR, to usually forward the mapping request to the appropriate MS without having to interact with all the DDT servers on the path down the delegation tree, in order to find any particular mapping. Thus, a typical resolution cycle would usually involve looking at some locally cached delegation information, perhaps loading some missing delegation entries into their delegation cache, and finally sending the Map-Request to the appropriate MS. Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 21] Internet-Draft LISP Introduction July 2014 It should also be noted that the delegation tree is fairly static, since it reflects EID block allocations, which are themselves fairly static. This stability has several important consequences. First, it increases the performance of the mapping system, since the sub- system almost never needs to be re-queried for information about intermediate vertices. {{comment from editor: does not understand the next sentence...}}Second, it is not necessary to include a mechanism to find out-dated delegations. [LISP-TREE] This contrasts with the mappings, which may change at a high rate - changes which have no impact on the indexing sub-system. The potentially high dynamics of mappings explains why mappings are delivered directly from ETRs (or MSes in proxy mode) to ITRs and hence not cached at the MR level. LISP is designed to make sure that changes in the mappings are detected and acted upon fairly quickly; this allows LISP to provide a number of capabilities, such as mobility. 9. Examples of operation To aid in comprehension, a few examples are given of user packets traversing the LISP system. The first shows the processing of a typical user packet which is LISP forwarded, i.e. what the vast majority of user packets will see. The second shows what happens when the first packet to a previously-unseen ultimate destination (at a particular ITR) is to be processed by LISP. 9.1. An Ordinary Packet's Processing {{Suggestion by editors: This section should be earlier in the document structure, examples are important -particularly for engineers- to explain how systems work}} This case follows the processing of a typical , {{comment from editors: text missing}} when the packet has made its way through the local site to an ITR, which in this case is a border router for the site, the border router looks up the destination address - an EID - in its local mapping cache. For EIDs which are IP addresses, this lookup uses the IP longest prefix matching algorithm. It finds a mapping, which instructs it to wrap the packet in an outer header - an IP packet, containing a UDP packet which contains a LISP header - and then the user's original packet (see Section 12.2 for the reasons for this particular choice). The destination address in the outer header is set by the ITR to the RLOC of the destination ETR. Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 22] Internet-Draft LISP Introduction July 2014 The encapsulated packet is then sent off through the RLOC space (e.g., Internet), using normal Internet routing. On arrival at the destination ETR, the ETR will notice that it is listed as the destination in the outer header. It will examine the packet, detect that it is a LISP packet, and unwrap it. It will then examine the header of the user's original packet, and forward it internally, through the local site, to the ultimate destination. At the ultimate destination, the packet will be processed, and may produce a return packet, which follows the exact same process in reverse - with the exception that the roles of the ITR and ETR are swapped. 9.2. A Mapping Cache Miss {{Suggestion by editors: (same as previous section)}} If a host sends a packet, and it gets to the ITR, and the ITR determines that it does not yet have a mapping cache entry which covers that destination EID, then additional processing ensues; it has to look up the mapping in the mapping system (as previously described in Section 6.2). The overall processing is shown below, in Figure 2: ----- ----- | | 3 | | Map Resolver | | -------> | | Map Server | | | | ----- ----- ^ | Key: | | | | -- =3D Control | | =3D=3D =3D Data | | 2 | 5 | 4 | --- | Host A | / \ | Host B | |_ \ V ----- ----- \ ----- ----- | | 1 | | 6 | | 7 | | | | =3D=3D=3D=3D=3D> | ITR | =3D=3D=3D=3D=3D=3D=3D> | ETR | =3D=3D= =3D=3D=3D> | | | | | | | | | | ----- ----- ----- ----- Figure 2: Packet flow with missing mapping Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 23] Internet-Draft LISP Introduction July 2014 1. Source-EID sends packet (to Dest-EID) to ITR 2. ITR sends Map-Request to Map-Resolver 3. Map-Resolver delivers Map-Request to Map-Server 4. Map-Server delivers Map-Request to ETR 5. ETR returns Map-Reply to ITR; ITR caches EID-to-RLOC(s) mapping 6. ITR uses mapping to encapsulate to ETR; sends user packet to ETR 7. ETR decapsulates packet, delivers to Dest-EID The ITR first sends a Map-Request packet, giving the destination EID it needs a mapping for, to its MR. The MR will look in its cache of delegation information to find the vertex which is the most specific in the delegation tree for that destination EID . If it does not have the address of an appropriate MS, it will query the DDT system, recursively if need be, in order to eventually find the address of such an MS. When it has the MS's address, it will send the Map-Request on to the MS, which then usually sends it on to an appropriate ETR. The ETR sends a Map-Reply to the ITR which needs the mapping; from then on, processing of user packets through that ITR to that ultimate destination proceeds as above. To the best of our knowledge, in all LISP implementations, the original user packet will have been discarded, and not queued waiting for the mapping to be returned. When the host retransmits such a packet, the mapping will be there, and the packet will be forwarded. Alternatively, it might have been forwarded using a PITR to avoid being dropped (Section 6.4). 10. Part II {{comment from editors: is that the role of an introductory document to enter in such level of details and discuss (mostly) all fields of the protocol? }} No. It should just describe the architecture of the entire LISP system, making = it easier to read the rest of the LISP specifications and providing a *basi= s* for discussion about the details of the LISP protocols. 11. Design Approach {{Suggestion by editors: Remove this section, it does not describe/ discuss anything relevant, it is only providing a reference to another non-WG document.}} Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 24] Internet-Draft LISP Introduction July 2014 Before describing LISP's components in more detail below, it it worth pointing out that what may seem, in some cases, like odd (or poor) design approaches do in fact result from the application of a thought-through, and consistent, design philosophy used in creating them. {{Subjective: maybe JMH, Dino can help with better words?}} This design philosophy is covered in detail in [I-D.ietf-lisp-perspective], Section "Design"), and readers who are interested in the 'why' of various mechanisms should consult that; reading it may make clearer the reasons for some engineering choices in the mechanisms given here. 12. xTRs As mentioned above (in Section 8.1), xTRs are the essential LISP data plane elements. This section explores some advanced topics related to xTRs. {{Suggestion by editors: remove next paragraph, brings nothing)}} Careful rules have been specified for both TTL and ECN [RFC3168] to ensure that passage through xTRs does not interfere with the operation of these mechanisms. In addition, care has been taken to ensure that traceroute works when xTRs are involved. 12.1. When to Encapsulate An ITR knows that an ultimate destination is running LISP (remember that the actual destination machine itself probably knows nothing about LISP), and thus that it should perform LISP processing on a packet (including potential encapsulation) if it has an entry in its local mapping cache that covers the destination address (it is then called an EID). Conversely, if the cache contains a negative entry (indicating that the ITR has previously attempted to find a mapping that covers this EID, and it has been informed by the mapping system that no such mapping exists), it knows the ultimate destination is not running LISP, and the packet can be forwarded natively (i.e. not LISP- encapsulated). Note that the ITR cannot simply depend on the appearance, or non- appearance, of the destination in the routing tables in the Internet core, as a way to tell if a destination is a LISP node or not. That is because mechanisms to allow interoperation of LISP sites and legacy sites necessarily involve advertising LISP sites' EIDs into the Internet core; in other words, LISP sites which need to Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 25] Internet-Draft LISP Introduction July 2014 interoperate with legacy nodes will appear in the Internet core routing tables, along with non-LISP sites. 12.2. UDP Encapsulation Details Use of UDP (instead of, say, a LISP-specific protocol number) was driven by the fact that many routers and middle boxes filter out unknown protocols, so adopting a non-UDP encapsulation would have compromised the initial deployment of LISP. The UDP source port used for encapsulating packet is computed with a 5-way hash of the original source and destination in the inner header, along with the ports, and the protocol. This is because many ISPs use multiple parallel paths (so-called Equal Cost Multi-Path), and load-share across them. Using such a hash in the source-port in the outer header both allows LISP traffic to be load-shared, and also ensures that packets from individual connections are delivered in order (since most ISPs try to ensure that packets for a particular flow follow a single path, and hence do not become disordered). The UDP checksum is zero because the inner packet usually already has a end-end checksum, and the outer checksum adds no value ([Saltzer]). {{Suggestion by editors: not sure that next statement is correct}} In most exising hardware, computing such a checksum (and checking it at the other end) would also present a major load, for no benefit. 12.3. Header Control Channel {{Suggestion by editors: Rewrite this section to improve readability, use standard terminology (e.g., Cache Coherence/Reachability instead of "Header Control Channel"). Split the mechanisms depending on its goal (cache coherence/reachability) and describe them under the same context.}} LISP provides a multiplexed channel in the encapsulation header. It is mostly (but not entirely) used for control purposes. The general concept is that the header starts with a flags field, and it also includes two data fields, the contents and meaning of which vary, depending on which flags are set. This allows these fields to be multiplexed among a number of different low-duty-cycle functions, while minimizing the space overhead of the LISP. 12.3.1. Mapping Versioning One important use of the multiplexed control channel is mapping versioning; i.e. the discovery of when the mapping cached in an ITR is outdated. To allow an ITR to discover this, identifying sequence numbers are applied to different versions of a mappping [RFC6834]. Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 26] Internet-Draft LISP Introduction July 2014 This allows an ITR to easily discover when a cached mapping has been updated by a more recent variant. Version numbers are available in control messages (Map-Replies), but the initial concept is that to limit control message overhead, the versioning mechanism should primarily use the multiplexed user data header control channel. Versioning can operate in both directions: an ITR can advise an ETR what version of a mapping it is currently using (so the ETR can notify it if there is a more recent version), and ETRs can let ITRs know what the current mapping version is (so the ITRs can request an update, if their copy is outdated). 12.3.2. Echo Nonces Another important use of the header control channel is for a mechanism known as the Nonce Echo, which is used as an efficient method for ITRs to check the reachability of neighbour ETRs. Basically, an ITR which has to determine that an ETR is up, and reachable, sends a nonce to that ETR, carried in the encapsulation header; when that ETR (also acting as an ITR) sends some other user data packet back to the ITR (acting in turn as an ETR), that nonce is carried in the header of that packet, allowing the original ITR to confirm that its packets are reaching that ETR. Note that a lack of a response is not necessarily proof that something has gone wrong - but it strongly suggests that something has, so other actions (e.g. a switch to an alternative ETR, if one is listed; a direct probe; etc) are advised. (See Section 16.5 for more about Echo Nonces.) 12.3.3. Instances {{Suggestion by editors: Move and extend this section: - Instance ID is not a cache-coherence/reachability algorithm. Describe where and what is the Instance ID field Explain its applications}} The LISP data-plane header is also used to support VPN and multi- tenant networks. Since there is only one destination UDP port used for carriage of user data packets, and the source port is used for multiplexing, there is no other way to differentiate among different destination EID spaces (which are often overlapped in VPNs and multi- tenant networks). Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 27] Internet-Draft LISP Introduction July 2014 12.4. Probing RLOC-Probing is a mechanism method that an ITR can use to determine with that an ETR is up and reachable from the ITR. As a side- benefit, it gives RTT estimates. To probe the reachability of an RLOC, an ITR sends a specially marked Map-Request directly to the ETR it wishes information about; that ETR sends back a specially marked Map-Reply. A Map-Request message and a Map-Reply message are used, rather than a special probing control- message pair, because as a side-benefit the ITR can discover if the mapping has been updated since it cached it. {{Suggestion from editors: remove the following sentence as it is not motivated by strong arguments}} The probing mechanism is rather heavy-weight and expensive (compared to mechanisms like the Echo- Nonce), since it costs a control message from each side, so it should only be used sparingly. If the number of active neighbour ETRs of the ITR is large, use of RLOC-Probing to check on their reachability will result in considerable control traffic; such control traffic has to be spread out to prevent a load peak. Obviously, if RLOC-Probing is the only mechanism being used to detect unreachable neighbour ETRs, the rate at which RLOC-Probing is done will control the timeliness of the detection of loss of reachability. There is thus a tradeoff between overhead and responsiveness, particular when an ITR has a large fanout of neighbour ETRs. 12.5. Mapping Lifetimes and Timeouts {{Suggestion by editors: Remove this section, TTL is a simple well- known concept, we suggest to include a sentence (and hence remove this section) in the control-plane section stating that mappings include a TTL. Mappings come with a Time-To-Live, which indicate how long the creator of the mapping expects them to be useful for. Mappings might also be discarded before the TTL expires, depending on what strategies the ITR is using to maintain its cache; if the maximum cache size is fixed, or the ITR needs to reclaim memory, mappings which have not been used recently may be discarded. (After all, there is no harm in so doing; a future reference will merely cause that mapping to be reloaded.) {{Contents may change before TTL expires?}} Cabellos-Aparicio (Ed.) Expires January 17, 2015 [Page 28] Internet-Draft LISP Introduction July 2014 12.6. Mapping Gleaning in ETRs {{Suggestion by editors: Remove this section, gleaning is discouraged since it rises many security concerns.}} As an optimization to the mapping acquisition process, ETRs are allowed to glean mappings from incoming user data packets, and also from incoming Map-Request control messages. This is not secure, and so any such mapping must be verified by sending a Map-Request to get an authoritative mapping. The value of gleaning is that most communications are two-way, and so if host A is sending packets to host B (therefore needing B's EID->RLOC mapping), very likely B will soon be sending packets back to A (and thus needing A's EID->RLOC mapping). Without gleaning, this would sometimes result in a delay, and the dropping of the first return packet; this is felt to be very undesirable. 12.7. MTU Issues Several mechanisms have been proposed for dealing with packets which are too large to transit the path from a particular ITR to a given ETR. In one, called the stateful approach, the ITR keeps a per-ETR record of the maximum size allowed, and sends an ICMP Too Big message to the _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --_000_BB4FB88584FC4F91A3CDBE41A81F39E8ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <70A68C2EE36E5F478CA3F0062D0EB289@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Hi Alberto, Damien,

A few suggestions for the intro doc:

Overview/Basic Approach (currently 6 and 6.1):
- Not in the current text: Spell out very clearly and upfront the conc= ept of *separation* of location and identity. 
- With the concept of location/identity separation clear, then proceed= to introduce RLOCs and EIDs as manifestations of such concepts. 
- Highlight that these are not mandatorily IP addresses (could be almo= st anything).
- Build upon this to introduce the notion of RLOCs and EIDs as forming= two distinct address spaces
- Finally introduce LISP as the mechanisms to handle the mappings that= correlate the two address spaces. May be a good segway into the Basic func= tionality section that follows.

Basic Functionality (6.2):
- I think it is worth adding to this section the notion of the destina= tion based policies manifested as priorities and weights. Since this is an = architectural doc, we may want to abstract this policy notion enough to acc= ommodate other/future policy options that may arise.
- The pull nature of the mechanism is introduced in 6.3 currently. I t= hink this is an important attribute and may be worth considering bringing i= t forward to 6.2.

Initial Applications (7):
- Fully agree that the section needs to be moved back if we keep it.
- Most use cases will probably fall out of charter at this point, maki= ng this section very short until a future re-charter allows more use cases.= IMO we need text to allow for those future use cases that are currently ou= t of charter without having to re-open this architecture document. One option is to keep the text on the use case= s that is currently in the document. Another option is to include general t= ext to allow future use cases. The latter may be required regardless.
- IMO, just keep the use cases in any order.

8.2. Regarding EID-block vs. prefix. I kind of like EID-block in suppo= rt of the AF agnostic characteristics of LISP. Prefixes (I think) are tight= ly coupled with IP, once we have MAC addresses or other addresses prefix ma= y not be the best choice.

10.  Part II

   {{comment from editors: is that the role of an introductory document
   to enter in such level of details and discuss (mostly) all fields of
   the protocol? }}
IMO not in detail and we should probably be a bit more selective in te= rms of which fields we do discuss in this doc vs. which we do not. Thus out= lining the moving parts, at a high level,  and providing referenc= es to the documentation with the relevant details may be helpful to those starting with LISP. In general, this secon= d part should be much more succinct in my opinion.

Regarding any other =93Suggestions by editors", I agree with all = the editor suggestions in version 04 with any comments/exceptions noted abo= ve.

Thanks for moving this forward. 

Regards,

-v


On Jul 28, 2014, at 1:28 PM, Albert Cabellos <albert.cabellos@gmail.com> wrote:

Fabio,

Please see below:


On Fri, Jul 25, 2014 at 10:21 PM, Fabio Maino <fmaino@cisco.com<= /a>> wrote:
Albert, Damien,
please find my comments below.


Network Working Group               &nbs= p;         A. Cabellos-Aparicio (Ed.)
Internet-Draft                 &nbs= p;       Technical University of Catalonia
Intended status: Informational             &n= bsp;             D. Saucez (Ed.)
Expires: January 17, 2015               =                      = ;      INRIA
                     = ;                     &nb= sp;                 July 16, 2014

       An Architectural Introduction to the LISP Locati= on-Identity
                     = ;       Separation System
                   draft-= ietf-lisp-introduction-04.txt

Abstract

    This document is an introductory overview of the Locator/ID     Separation Protocol, it describes the major concepts and func= tional
    sub-systems of LISP and the interactions between them.

Status of This Memo

    This Internet-Draft is submitted in full conformance with the=
    provisions of BCP 78 and BCP 79.

    Internet-Drafts are working documents of the Internet Enginee= ring
    Task Force (IETF).  Note that other groups may also dist= ribute
    working documents as Internet-Drafts.  The list of curre= nt Internet-
    Drafts is athttp://datatracker.ietf.org/drafts/current/= .

    Internet-Drafts are draft documents valid for a maximum of si= x months
    and may be updated, replaced, or obsoleted by other documents= at any
    time.  It is inappropriate to use Internet-Drafts as ref= erence
    material or to cite them other than as "work in progress= ."

    This Internet-Draft will expire on January 17, 2015.

Copyright Notice

    Copyright (c) 2014 IETF Trust and the persons identified as t= he
    document authors.  All rights reserved.

    This document is subject to BCP 78 and the IETF Trust's Legal=
    Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info) in effect on the da= te of
    publication of this document.  Please review these docum= ents
    carefully, as they describe your rights and restrictions with= respect
    to this document.  Code Components extracted from this d= ocument must
    include Simplified BSD License text as described in Section 4= .e of
    the Trust Legal Provisions and are provided without warranty = as
    described in the Simplified BSD License.



Cabellos-Aparicio (Ed.) Expires January 17, 2015        = ;        [Page 1]

Internet-Draft              LISP Introdu= ction                  July 20= 14


Table of Contents

    1.  Prefatory Note  . . . . . . . . . . . . . . . .= . . . . . . .   4
    2.  Part I  . . . . . . . . . . . . . . . . . . . .= . . . . . . .   4
    3.  Initial Glossary  . . . . . . . . . . . . . . .= . . . . . . .   5
    4.  Background  . . . . . . . . . . . . . . . . . .= . . . . . . .   6
    5.  Deployment Philosophy . . . . . . . . . . . . . . . = . . . . .   7
      5.1.  Economics . . . . . . . . . . . . . . . . .= . . . . . . .   7
      5.2.  Maximize Re-use of Existing Mechanism . . .= . . . . . . .   8
    6.  LISP Overview . . . . . . . . . . . . . . . . . . . = . . . . .   8
      6.1.  Basic Approach  . . . . . . . . . . . = . . . . . . . . . .   9
      6.2.  Basic Functionality . . . . . . . . . . . .= . . . . . . .   9
      6.3.  Mapping from EIDs to RLOCs  . . . . . = . . . . . . . . . .  11
      6.4.  Interworking With Non-LISP-Capable Endpoint= s  . . . . . .  11
      6.5.  Security in LISP  . . . . . . . . . . = . . . . . . . . . .  12
    7.  Initial Applications  . . . . . . . . . . . . .= . . . . . . .  13
      7.1.  Provider Independence . . . . . . . . . . .= . . . . . . .  13
      7.2.  Multi-Homing  . . . . . . . . . . . . = . . . . . . . . . .  13
      7.3.  Traffic Engineering . . . . . . . . . . . .= . . . . . . .  14
      7.4.  Routing . . . . . . . . . . . . . . . . . .= . . . . . . .  15
      7.5.  Mobility  . . . . . . . . . . . . . . = . . . . . . . . . .  15
      7.6.  Traversal Across Alternate IP Versions &nbs= p;. . . . . . . . .  15
      7.7.  Virtual Private Networks  . . . . . . = . . . . . . . . . .  16
      7.8.  Local Uses  . . . . . . . . . . . . . = . . . . . . . . . .  16
    8.  Major Functional Subsystems . . . . . . . . . . . . = . . . . .  17
      8.1.  Data Plane - xTRs Overview  . . . . . = . . . . . . . . . .  17
        8.1.1.  Mapping Cache Performance . . . . = . . . . . . . . . .  18
      8.2.  Control Plane - Mapping System Overview . .= . . . . . . .  18
        8.2.1.  Mapping System Organization . . . = . . . . . . . . . .  19
        8.2.2.  Interface to the Mapping System . = . . . . . . . . . .  20
        8.2.3.  Indexing Sub-system . . . . . . . = . . . . . . . . . .  20
    9.  Examples of operation . . . . . . . . . . . . . . . = . . . . .  22
      9.1.  An Ordinary Packet's Processing . . . . . .= . . . . . . .  22
      9.2.  A Mapping Cache Miss  . . . . . . . . = . . . . . . . . . .  23
    10. Part II . . . . . . . . . . . . . . . . . . . . . . . . .= . .  24
    11. Design Approach . . . . . . . . . . . . . . . . . . . . .= . .  24
    12. xTRs  . . . . . . . . . . . . . . . . . . . . . . . = . . . . .  25
      12.1.  When to Encapsulate  . . . . . . . . = . . . . . . . . . .  25
      12.2.  UDP Encapsulation Details  . . . . . = . . . . . . . . . .  26
      12.3.  Header Control Channel . . . . . . . . . .= . . . . . . .  26
        12.3.1.  Mapping Versioning . . . . . . . = . . . . . . . . . .  26
        12.3.2.  Echo Nonces  . . . . . . . .= . . . . . . . . . . . .  27
        12.3.3.  Instances  . . . . . . . . .= . . . . . . . . . . . .  27
      12.4.  Probing  . . . . . . . . . . . . . . = . . . . . . . . . .  28
      12.5.  Mapping Lifetimes and Timeouts . . . . . .= . . . . . . .  28
      12.6.  Mapping Gleaning in ETRs . . . . . . . . .= . . . . . . .  29
      12.7.  MTU Issues . . . . . . . . . . . . . . . .= . . . . . . .  29
      12.8.  Security of Mapping Lookups  . . . . = . . . . . . . . . .  29



Cabellos-Aparicio (Ed.) Expires January 17, 2015        = ;        [Page 2]

Internet-Draft              LISP Introdu= ction                  July 20= 14


      12.9.  ITR Mapping Cache Performance  . . . = . . . . . . . . . .  30
    13. The Mapping System  . . . . . . . . . . . . . . . . = . . . . .  31
      13.1.  The Mapping System Interface . . . . . . .= . . . . . . .  32
        13.1.1.  Map-Request Messages . . . . . . = . . . . . . . . . .  32
        13.1.2.  Map-Reply Messages . . . . . . . = . . . . . . . . . .  32
        13.1.3.  Map-Register and Map-Notify Messa= ges . . . . . . . .  33
      13.2.  The DDT Indexing Sub-system  . . . . = . . . . . . . . . .  34
      13.3.  Reliability via Replication  . . . . = . . . . . . . . . .  35
      13.4.  Security of the DDT Indexing Sub-system &n= bsp;. . . . . . . .  35
      13.5.  Extended Capabilities  . . . . . . . = . . . . . . . . . .  36
      13.6.  Performance of the Mapping System  . = . . . . . . . . . .  36
    14. Multicast Support in LISP . . . . . . . . . . . . . . . .= . .  37
      14.1.  Basic Concepts of Multicast Support in LIS= P  . . . . . .  37
      14.2.  Initial Multicast Support in LISP  . = . . . . . . . . . .  38
    15. Deployment Issues and Mechanisms  . . . . . . . . . = . . . . .  39
      15.1.  LISP Deployment Needs  . . . . . . . = . . . . . . . . . .  39
      15.2.  Interworking Mechanisms  . . . . . . = . . . . . . . . . .  40
        15.2.1.  Proxy LISP Routers . . . . . . . = . . . . . . . . . .  40
        15.2.2.  LISP-NAT . . . . . . . . . . . . = . . . . . . . . . .  42
      15.3.  Use Through NAT Devices  . . . . . . = . . . . . . . . . .  42
      15.4.  LISP and Core Internet Routing . . . . . .= . . . . . . .  43
    16. Fault Discovery/Handling  . . . . . . . . . . . . . = . . . . .  43
      16.1.  Handling Missing Mappings  . . . . . = . . . . . . . . . .  44
      16.2.  Outdated Mappings  . . . . . . . . . = . . . . . . . . . .  44
        16.2.1.  Outdated Mappings - Updated Mappi= ng  . . . . . . . .  44
        16.2.2.  Outdated Mappings - Wrong ETR &nb= sp;. . . . . . . . . . .  44
        16.2.3.  Outdated Mappings - No Longer an = ETR . . . . . . . .  45
      16.3.  Erroneous Mappings . . . . . . . . . . . .= . . . . . . .  45
      16.4.  Verifying ETR Liveness . . . . . . . . . .= . . . . . . .  45
      16.5.  Verifying ETR Reachability . . . . . . . .= . . . . . . .  46
    17. Acknowledgments . . . . . . . . . . . . . . . . . . . . .= . .  46
    18. IANA Considerations . . . . . . . . . . . . . . . . . . .= . .  47
    19. Security Considerations . . . . . . . . . . . . . . . . .= . .  47
    20. References  . . . . . . . . . . . . . . . . . . . . = . . . . .  47
      20.1.  Normative References . . . . . . . . . . .= . . . . . . .  47
      20.2.  Informative References . . . . . . . . . .= . . . . . . .  49
    Appendix A.  Glossary/Definition of Terms . . . . . . . = . . . . .  52
    Appendix B.  Other Appendices . . . . . . . . . . . . . = . . . . .  55
      B.1.   A Brief History of Location/Identity Separ= ation  . . . .  55
      B.2.  A Brief History of the LISP Project . . . .= . . . . . . .  56
      B.3.  Old LISP 'Models' . . . . . . . . . . . . .= . . . . . . .  56
      B.4.  The ALT Mapping Indexing Sub-system . . . .= . . . . . . .  57
      B.5.  Early NAT Support . . . . . . . . . . . . .= . . . . . . .  58
    Authors' Addresses  . . . . . . . . . . . . . . . . . . = . . . . .  59







Cabellos-Aparicio (Ed.) Expires January 17, 2015        = ;        [Page 3]

Internet-Draft              LISP Introdu= ction                  July 20= 14


1.  Prefatory Note

    {{Suggestion by editors: Remove all the sections before "= ;LISP
    Overview" and write a straight-to-the-point introduction= }}

    {{Suggestion by editors: The draft should focus on describing= the
    LISP architecture and avoid comparing loc/id split architectu= res with
    other approaches}}

Agree: my suggestion is to view this as a doc for a reader new to LISP that= needs to be introduced to the architecture. At the end of the doc the read= er will be familiar with the basic aspects of LISP, and able to navigate th= rough the RFCs. The document should be kept as short and as "dry" as possible. If the reader wants t= o know more, after reading this doc, he will know where to go for the detai= ls.




    This document is the first of a pair which, together, form wh= at one
    would think of as the 'architecture document' for LISP (the     'Location-Identity Separation Protocol').  Much of what = would
    normally be in an architecture document (e.g. the architectur= al
    design principles used in LISP, and the design considerations= behind
    various components and aspects of the LISP system) is in the = second
    document, the 'Architectural Perspective on LISP' document.     [I-D.ietf-lisp-perspective]

    This 'Architectural Introduction' document is primarily inten= ded for
    those who are unfamiliar with LISP, and want to start learnin= g about
    it.  It is intended primarily for those working on LISP,= but those
    working with LISP, and more generally anyone who wants to kno= w more
    about LISP, may also find this document useful.

    This document is intended to both be easy to follow and it is=
    structured as a series of phases, each covering the entire sy= stem,
    but with ever-increasing detail.  Reading only the first= part of the
    document will give a good high-level view of the system; read= ing the
    complete document should provide a fairly detailed understand= ing of
    the entire system.

    People who just want to get an idea of how LISP works might o= nly read
    the first part; they can stop reading either just before, or = just
    after Section 9.  People who are going to go on and read= the protocol
    specifications (perhaps to implement LISP) should read the en= tire
    document.

    This document is a descriptive document, not a protocol
    specification.  Should it differ in any detail from any = of the LISP
    protocol specification documents, they take precedence for th= e actual
    operation of the protocol.

2.  Part I








Cabellos-Aparicio (Ed.) Expires January 17, 2015        = ;        [Page 4]

Internet-Draft              LISP Introdu= ction                  July 20= 14


3.  Initial Glossary

let's stick to the RFCs glossary. Since this is a first-to-read doc there s= hould be a minimal definition section, but definitions should mostly be cut= and paste from the RFCs.

Agree, this will make easier to read the rest of the RFCs.
 


    This initial glossary defines a few general terms which will = be
    useful to have in hand when commencing reading this document.=  A
    complete glossary is available in Appendix A.

    A note about style: initial usage of a term defined in the gl= ossary
    is denoted with double quotation marks (").  Other = uses of quotations
    (e.g. for quotations, euphemisms, etc) use single quotation m= arks
    (').

    o  Name: a name refers to an identifier for an object or= entity.
       Names have both semantics (meaning) and syntax (= form) [RFC1498].

    o  Namespace: A group of names with matching semantics a= nd syntax;
       they usually, but not always, refer to members o= f a class of
       identical objects.

    o  Mapping: a binding between two names, one in each of = two
       namespaces.

    o  Delegation Hierarchy: an abstract rooted tree (in the= graph theory
       sense of the term) which is a virtual representa= tion of the
       delegation of a namespace into smaller and small= er blocks, in a
       recursive process.

    o  Node: The general term used to describe any sort of c= ommunicating
       entity; it might be a physical or a virtual host= , or a mobile
       device of some sort.  It includes both enti= ties which forward
       packets, and entities which create or consume pa= ckets.

    o  Switch, Packet Switch: A packet switch, in the genera= l meaning of
       that term.  A device which takes in packets= from its interfaces
       and forwards them on, either to a next-hop switc= h, or to the final
       destination.  They may operate at either th= e network layer (e.g.
       ARPANET), or internetwork layer.  [Baran][H= eart][RFC1812]

    o  Endpoint, end-end communication entity: The fate-shar= ing region at
       one end of an end-end communication; the collect= ion of state
       related to both the reliable end-end communicati= on channel, and
       the applications running there.  [Chiappa]<= br>
    o  Address: In this document, in current IP (IPv4 or IPv= 6) and
       similar networking suites, a "name" wh= ich has mixed semantics, in
       that it includes both identity ('who') and locat= ion ('where')
       semantics.  [Atkinson]





Cabellos-Aparicio (Ed.) Expires January 17, 2015        = ;        [Page 5]

Internet-Draft              LISP Introdu= ction                  July 20= 14


    o  Address Block, Block: A contiguous section of a names= pace (e.g.,
       IP addresses that belong to the same prefix).
    o  Identifier: a name which has identity semantics.

    o  Locator: name with only location semantics and not ne= cessarily
       carried in every packet [RFC1992].

    o  Site: A collection of hosts, routers, and networks un= der a single
       administrative control.

    o  LISP site: a site separated from the rest of the netw= ork by LISP
       routers.

    o  LISP node: A network element implementing LISP functi= onality; this
       means it can process some subset of LISP control= and planes
       traffic.

    o  LISP router: A network element implementing LISP data= -plane
       functionality, i.e., a LISP node which can forwa= rd user traffic.

    o  LISP host: A host which is behind (from the point of = view of the
       rest of the network) a LISP router.

4.  Background

    It has gradually been realized in the networking community th= at
    networks, especially large networks, should deal quite separa= tely
    with the identity and location of an endpoint - basically, wh= o an
    endpoint is, and where it is ([RFC1498] [RFC4984]).

    At the moment of this writing, in both IPv4 and IPv6, IP addr= esses
    indicate both where the named node is, as well as identify it= for
    purposes of end-end communication; i.e. it has both location = and
    identity properties.  However, the separation of those t= wo properties
    is a step which has been identified by the IRTF as a necessar= y
    evolutionary architectural step for the Internet [RFC6115] an= d the
    on-going LISP project is an attempt to provide a viable path = towards
    this separation.

    As an add-on to a large existing system, it has had to make c= ertain
    compromises.  (For a good example, see [I-D.ietf-lisp-pe= rspective],
    Section "Residual Location Functionality in EIDs". =  However, if it
    reaches near-ubiquitous deployment, it will have two importan= t
    consequences.

    First, in effectively providing separation of location and id= entity,
    along with providing a distributed directory of the mappings = between



Cabellos-Aparicio (Ed.) Expires January 17, 2015        = ;        [Page 6]

Internet-Draft              LISP Introdu= ction                  July 20= 14


    them, 'Wheeler's Law' ('All problems in computer science can = be
    solved by another level of indirection') will come into play,= and the
    Internet technical community will have a new, immensely power= ful,
    tool at its disposal.  The fact that the namespaces on b= oth sides of
    the mapping are global ones maximizes the power of that tool.=  (See
    [I-D.ietf-lisp-perspective], Section "Need for a Mapping= System", for
    more on this.)

    Second, because of a combination of the flexible capability b= uilt
    into LISP, and the breaking of the unification of location an= d
    identity names, further architectural evolution of the Intern= et
    becomes easily available; for example, new namespaces for loc= ation or
    identity could be designed and deployed.  In other words= , LISP is not
    a point solution to meet a particular need, but hopefully an = 'escape
    hatch' which will allow further significant enhancement to th= e
    Internet's overall architecture.  (See [Future] for more= on this.)

5.  Deployment Philosophy

    {{Suggestion by editors: Remove the entire section, it can be=
    summarized by the last paragraph.  Furthermore the argum= ents used in
    this sections are hard to follow since LISP has not been desc= ribed
    yet.}}

    The deployment philosophy was a major driver for the design o= f LISP
    (architecture and engineering).

    Experience over the last several decades has shown that havin= g a
    viable deployment model for a new design is a key to the adop= tion of
    the solution.  In general, it is comparatively easy to c= onceive of
    new network designs, but much harder to devise approaches whi= ch will
    actually get deployed throughout the global network.  A = new design
    may be fantastic but if it can not be successfully deployed (= for
    whatever factors), it is useless.

    LISP aims to achieve the near-ubiquitous deployment necessary= for
    maximum exploitation of an architectural upgrade by i) minimi= zing the
    amount of change needed (most existing hosts and routers can = operate
    unmodified); and ii) by providing significant benefits to ear= ly
    adopters.

5.1.  Economics

    {{Suggestion by editors: Remove this section, this has not be= en
    discussed by the WG}}

    A key factor in successful adoption is economics: does the ne= w design
    have benefits which outweigh its costs?



Cabellos-Aparicio (Ed.) Expires January 17, 2015        = ;        [Page 7]

Internet-Draft              LISP Introdu= ction                  July 20= 14


    More importantly, this balance needs to hold for early adopte= rs -
    because if they do not receive benefits to their adoption, th= e sphere
    of earliest adopters will not expand, and it will never get t= o
    widespread deployment.

    This is particularly true of architectural enhancements, whic= h are
    far less likely to be an addition which one can bolt onto the= side of
    existing mechanisms, and often offer their greatest benefits = only
    when widely (or ubiquitously) deployed.

    Maximizing the cost-benefit ratio obviously has two aspects. =  First,
    on the cost side, by making the design as inexpensive as poss= ible,
    which means in part making the deployment as easy as possible= .
    Second, on the benefit side, by providing many new capabiliti= es,
    which is best done not by loading the design up with lots of = features
    or options (which adds complexity), but by making the additio= n
    powerful through deeper flexibility.  The LISP community= believes
    LISP has met both of these goals.

5.2.  Maximize Re-use of Existing Mechanism

    {{Suggestion by editors: Remove/Summarize the entire section,= the
    arguments used in this section are hard to follow since LISP = has not
    been described yet.}}

Remove. This doc is not a guide to good protocol design. The concept that L= ISP is deployable incrementally should be mentioned in the document though,= possibly with a reference to the deployment RFC.

Agreed, we=B4ll include an (ultra-short) section describing the design= principles of LISP, incremental deployment is of course one of them.

    One key part of reducing the cost of a new design is to minim= ize the
    amount of change required to existing, deployed, devices: the= fewer
    devices need to be changed, and the smaller the change to tho= se that
    do, the greater the likelihood of deployment.

    Designs which absolutely require forklift upgrades to large a= mounts
    of existing gear are far less likely to succeed - because the= y have
    to have extremely large benefits to make their very substanti= al costs
    worthwhile.

    It is for this reason that LISP, in most cases, initially req= uires no
    changes to almost all existing devices in the Internet (both = hosts
    and routers); LISP functionality needs to be added in only a = few
    places ( Section 15.1)

6.  LISP Overview

    LISP is an incrementally deployable architectural upgrade to = the
    existing Internet infrastructure, one which provides separati= on of
    location and identity.  It thus starts to separate the n= ames used for
    identity and location of nodes, which are currently unified i= n IP
    addresses.




Cabellos-Aparicio (Ed.) Expires January 17, 2015        = ;        [Page 8]

Internet-Draft              LISP Introdu= ction                  July 20= 14


6.1.  Basic Approach

    {{Suggestion by editors: Merge this section with the previous= one
    (LISP Overview)}}

Agree: across the document, as done in the RFCs, I'd suggest to focus on de= scribing the protocol architecture and how it works rather than on more gen= eric considerations about the LISP philosophy.

    In LISP, the first key concept is that nodes have both an ide= ntifier
    called an Endpoint IDentifier (EID) and an associated Routing= Locator
    (RLOC).  A node may be associated with more than one RLO= C, or the
    RLOC may change over time (e.g., if the node is mobile), but = it would
    normally always have the same EID.

    The second key concept is that if one wants to be as forward-= looking
    as possible, conceptually one should think of the two kinds o= f names
    (EIDs and RLOCs) as naming different classes of entities.

    On the one hand, EIDs are used to name nodes - or rather, the= ir end-
    end communication entities.  RLOC(s), on the other hand,= name
    interfaces, i.e. places to which the system of routers sends = packets.

    This distinction, the formal recognition of different kinds o= f
    entities ("endpoints" and interfaces), and their as= sociation with the
    two different classes of names, is also important.  Clea= rly
    recognizing interfaces and endpoints as distinctly separate c= lasses
    of objects is another improvement to the existing Internet     architecture.

    An important insight in LISP is that it initially uses existi= ng IP
    addresses for both of these kinds of names, as opposed to som= e
    similar earlier deployment proposals for separation of locati= on and
    identity (e.g.  [RFC1992]), which proposed using a new n= amespace for
    locators.  This choice minimizes LISP's deployment cost,= as well as
    providing the ability to easily interact with un-modified hos= ts and
    routers.

    The capability to use namespaces other than IP addresses for = both
    kinds of names is already built in LISP, which is expected to= greatly
    increase the long-term benefits, flexibility, and power of LI= SP
    ([AFI], [I-D.ietf-lisp-lcaf]).

6.2.  Basic Functionality

    {{Suggestion by editors: Rewrite this section: It is using no= n-
    standard terminology to refer to standard LISP concepts ('enh= ance'
    instead of encapsulate) It is using subjective terms (e.g., '= near'
    the source) It is missing key LISP aspects such as that RLOC = packets
    are forwarded in the RLOC space }}


Make sure a figure with the basic elements of the protocol architecture (po= ssibly similar to figure 1) is introduced as early as possible. 





Cabellos-Aparicio (Ed.) Expires January 17, 2015        = ;        [Page 9]

Internet-Draft              LISP Introdu= ction                  July 20= 14


    The basic operation of LISP, as it currently stands, is quite= simple.
    LISP augmented packet switches, "LISP routers", nea= r the source and
    destination of packets intercept traffic, and 'enhance' the p= ackets
    for the trip between the LISP switches.

    The LISP router near the original source (the Ingress Tunnel = Router,
    or ITR ) looks up additional information about the destinatio= n of the
    packet, and then wraps the packet in an outer header, one whi= ch
    contains additional information related to LISP operation.
    The LISP router near the destination, the (the Egress Tunnel = Router,
    or ETR) removes that header, leaving the original, un-modifie= d,
    packet to be sent on to the original destination node.

    The overall processing is shown below, in Figure 1:


     /-----------------\           =             ---
     |     Mapping     |     &= nbsp;                  |
     .     System      |   &nb= sp;                    | =  Control
    -|                 |`= ,                     &nb= sp;|  Plane
  ,' \-----------------/  .           &n= bsp;         |
                     = ; /                     &= nbsp;   \                 &nbs= p; ---
     ,..,           -    =    _,..--..,,         `,      = ;   ,..,      |
   /     `        ,'     =  ,-`          `',        = .      /     `     |
  /        \ +-----+    ,'  = ;              `,    +--'-= -+ /        \   |
  |  EID   |-| xTR |---/        RLOC &nb= sp;      ,---| xTR |-|  EID   |   |  Dat= a
  | Space  |-|     |---|       Space &nb= sp;      |---|     |-| Space  |   | &nbs= p;Plane
  \        / +-----+   .    = ;               /    +----= -+ \        /   |
   `.    .'             `= .                ,'     &= nbsp;       `.    .'    |
     `'-`               &= nbsp; `.,          ,.'        =         `'-`     ---
                     = ;        ``''--''``
   LISP Site (Edge)            Core=              LISP Site (Edge)

                   Figure= .- An schema of the LISP Architecture



                     = ; Figure 1: Basic LISP Packet Flow

    To retrieve that additional information, the ITR uses the inf= ormation
    in the original packet about the identity of its ultimate
    destination, i.e. the destination EID address.  It uses = the
    destination EID to look up the current location (the RLOC) of= that
    EID.

    The lookup is performed through a mapping system, which is th= e heart
    of LISP: it is a distributed directory of mappings from EIDs = to



Cabellos-Aparicio (Ed.) Expires January 17, 2015        = ;       [Page 10]

Internet-Draft              LISP Introdu= ction                  July 20= 14


    RLOCs.  The destination RLOC(s) is (are) normally the ad= dress(es) of
    the ETR(s) near the ultimate destination.

    The ITR then generates a new outer header for the original pa= cket,
    with that header containing the ETR's RLOC as the wrapped pac= ket's
    destination, and the ITR's own address (i.e. the RLOC usually=
    associated with the original source) as the wrapped packet's = source,
    and sends it off.

    When the packet arrives at the ETR, that outer header is stri= pped
    off, and the original packet is forwarded to the original ult= imate
    destination for normal processing.

    Return traffic is handled similarly, often (depending on the<= br>     network's configuration) with the original ITR and ETR switch= ing
    roles.  The ETR and ITR functionality is usually co-loca= ted in a
    single LISP router; these are normally denominated as xTRs.
6.3.  Mapping from EIDs to RLOCs

    The mappings from EIDs to RLOCs are provided by a distributed= , and
    potentially replicated, database, the "mapping database&= quot;, which is
    the heart of LISP.  Here, and in other places in LISP, t= he
    replication is not a deep architectural concept, simply an     engineering device to obtain reliability via potential redund= ancy.

    Entities which need EID-to-RLOC mappings get them from the ma= pping
    system, which is a collection of sub-systems through which cl= ients
    can find and obtain mappings as discussed in more details in<= br>     Section 8.2 and Section 13.

    Mappings are normally distributed via a pull mechanism (i.e.,= not
    pre-loaded, but requested on demand).  Once obtained by = an ITR, they
    are cached for performance reasons.

6.4.  Interworking With Non-LISP-Capable Endpoints

    It is clearly crucial to provide the capability for easy
    interoperation between "LISP hosts" - i.e. they are= behind xTRs, and
    their EIDs are in the mapping database - and existing non-LIS= P-using
    hosts (often called 'legacy' hosts) or legacy "sites&quo= t;.

    To allow interoperation between devices hosted in a LISP site= and
    devices not belonging to a LISP site (non-LISP site), an inte= rworking
    mechanism based on proxies has been designed.  Proxy ITR= s (PITR)
    encapsulate packets sent from non-LISP sites to LISP sites wh= ile
    Proxy ETRs (PETR) decapsulate packets sent from LISP sites to= non-
    LISP sites.  More details are given in Section 15.2.1.


Cabellos-Aparicio (Ed.) Expires January 17, 2015        = ;       [Page 11]

Internet-Draft              LISP Introdu= ction                  July 20= 14


6.5.  Security in LISP

    {{Suggestion by editors: Rewrite this section: (first 3 parag= raphs)
    It contains a general discussion as well as strong statements= that
    are not supported by any WG document.  (last 3 paragraph= s) It
    enumerates the security mechanisms specified in LISP but does= not
    describe them.}}

Agree. I think that the security considerations section of RFC6830 may prov= ide a guide to the items you may want to touch in this document. Point the = reader to the RFCs when possible. Move broader security considerations to t= he Security Section referencing lisp-threats where needed.

Agreed. 

    To provide a brief overview of security in LISP, it is defini= tely
    understood that LISP needs to be highly _securable_, especial= ly in
    the long term; over time, the attacks mounted by 'bad guys' a= re
    becoming more and more sophisticated.  So LISP, like DNS= , needs to be
    _capable_ of providing 'the very best' security there is.

    At the same time, there is a conflicting goal: it must be dep= loyable
    at a a viable cost.  That means two things: First, as an= experiment,
    we cannot expect to create the complete security apparatus wh= ich we
    might see in the finished product, including both design and<= br>     implementation.  Second, security needs to be flexible, = so that we
    don't overload the users with more security than they need at= any
    point.

    To accomplish these divergent goals, the approach taken is to= first
    analyze what LISP needs for security.  [I-D.ietf-lisp-th= reats].
    Then, steps can be taken to ensure that the appropriate 'hook= s' (such
    as packet fields) are included at an early stage, when doing = so is
    still easy.  Over time, additional mechanisms will be fu= lly
    specified, implemented, and deployed.

    LISP does already include a number of security mechanisms; in=
    particular, requesting mappings can be secured (see Section 1= 2.8,
    "Security of Mapping Lookups"), as can registering = of xTRs (see
    Section 13.1.3, "Map-Register and Map-Notify Messages&qu= ot;); the key
    database of the mapping system is also secured (see Section 1= 3.4,
    "Security of the DDT Indexing Sub-system").

    The existing security mechanisms, and their configuration (wh= ich is
    mostly manual at this point) currently in LISP are felt to be=
    adequate for the needs of the on-going early stages of deploy= ment;
    experience will indicate when improvements are required (with= in the
    constraints of the conflicting goal given above).

    For more on LISP's security philosophy; see
    [I-D.ietf-lisp-perspective], Section 7 "Security", = where it is laid
    out in some detail.






Cabellos-Aparicio (Ed.) Expires January 17, 2015        = ;       [Page 12]

Internet-Draft              LISP Introdu= ction                  July 20= 14


7.  Initial Applications

    {{Suggested by editors: Move this section after section 8, th= e
    applications should not be described before LISP has been ful= ly
    described.

    {{Suggested by Noel: Reorder the whole section in popularity = order?}}

    As previously mentioned, it is felt that LISP will provide ev= en the
    earliest adopters with some useful capabilities, and that the= se
    capabilities will drive early LISP deployment.

    It is very imporant to note that even when used only for
    interoperation with existing un-modified hosts, use of LISP c= an still
    provide benefits to the site which has deployed it - and, per= haps
    even more importantly, can do so to both sides.  This ch= aracteristic
    acts to further enhance the utility for early adopters of LIS= P.

    Note also that this section only lists some early application= s and
    benefits.  See [I-D.ietf-lisp-perspective], in the Secti= on "Goals of
    LISP", for a more extensive discussion of some of what L= ISP might
    ultimately provide.

7.1.  Provider Independence

    Provider independence (i.e. the ability to easily change one'= s
    Internet Service Provider) is a good example of the utility o= f
    separating location and identity.

    To limit global routing table size addresses need to be aggre= gated.
    To that aim networks can use provider aggregatable addresses<= br>     ([RFC4116]) which means that the IP prefixes of networks are = sub-
    prefixes of their provider.  This solutions allows to re= duce
    scalability issues of the global routing table but it means t= hat when
    a network switches providers it has to re-number all its devi= ces
    which is known to be complex in current networks [RFC5887].
    Having separate namespaces for location and identity greatly = reduces
    the problems involved with re-numbering; an organization whic= h moves
    retains its EIDs (which are how most other parties refer to i= ts
    nodes), but is allocated new RLOCs, and the mapping system ca= n
    quickly provide the updated mapping from the EIDs to the new = RLOCs.

7.2.  Multi-Homing

    {{Suggested by editors: This section should be extended, it i= s
    unclear the benefits that LISP brings to multihoming (.e.g, t= raffic
    engineering, decoupled multihoming from the data-plane).



Cabellos-Aparicio (Ed.) Expires January 17, 2015        = ;       [Page 13]

Internet-Draft              LISP Introdu= ction                  July 20= 14


    Multi-homing is another place where the value of separation o= f
    location and identity became apparent.  There are severa= l different
    sub-flavours of the multi-homing problem - e.g. depending on = whether
    one wants open TCP connections to keep working, etc - and oth= er axes
    as well (e.g. site multi-homing versus host multi-homing).
    In particular, for the 'keep open connections up' case, witho= ut
    separation of location and identity, with most currently depl= oyed
    implementations, the only currently feasible approach is to u= se
    provider-independent addressses - which moves the problem int= o the
    global routing system, with attendant costs.  This appro= ach is also
    not really feasible for host multi-homing.

7.3.  Traffic Engineering

    {{Suggestion by editors: Merge this section with the previous= one, TE
    is not practical without multihoming}}

    {{Needs a fix - not sure what.}}

    Traffic engineering (TE) [RFC3272], desirable though this cap= ability
    is in a global network, is currently somewhat problematic to = provide
    in the Internet.  The problem, fundamentally, is that th= is capability
    was not forseen when the Internet was designed, so the suppor= t for it
    via hacks is neither clean, nor flexible.

    TE is, fundamentally, a routing issue.  However, the cur= rent Internet
    routing architecture, which is basically the Baran design of = fifty
    years ago [Baran] (a single large, distributed computation), = is ill-
    suited to provide TE.  The Internet seems a long way fro= m adopting a
    more-advanced routing architecture, although the basic concep= ts for
    such have been known for some time.  [RFC1992]

    Although the identity-location mapping layer is thus a poor p= lace,
    architecturally, to provide TE capabilities, it is still an     improvement over the current routing tools available for this= purpose
    (e.g. injection of more-specific routes into the global routi= ng
    table).

    In addition, instead of the entire network incurring the cost= s
    (through the routing system overhead), when using a mapping l= ayer to
    provide TE, the overhead is limited to those who are actually=
    communicating with that particular destination.

    LISP includes a number of features in the mapping system to s= upport
    TE. (described in Section 8.2, "Control Plane - Mapping = System
    Overview", below); more details about using LISP for TE = can be found
    in [I-D.farinacci-lisp-te].



Cabellos-Aparicio (Ed.) Expires January 17, 2015        = ;       [Page 14]

Internet-Draft              LISP Introdu= ction                  July 20= 14


    Also, a number of academic papers have explored how LISP can = be used
    to do TE, and how effective it can be.  See the online L= ISP
    Bibliography ([Bibliography]) for information about them.

7.4.  Routing

    {{Suggestion by editors: Remove this section, LISP is not a r= outing
    protocol.}}

    Multi-homing and Traffic Engineering are both, in some sense,= uses of
    LISP for routing, but there are many other routing-related us= es for
    LISP.

    One of the major original motivations for the separation of l= ocation
    and identity in general, and thus LISP, was to reduce the gro= wth of
    the routing tables in the "Internet core", the part= where routes to
    _all_ ultimate destinations must be available.  LISP is = expected to
    help with this; for more detail, see Section 15.4, "LISP= and Core
    Internet Routing", below.

    LISP may also have more local applications in which it can he= lp with
    routing; see, for instance, [CorasBGP].

7.5.  Mobility

    {{Suggestion by editors: Remove this section, mobility is not= in
    charter.}}

    Mobility is yet another place where separation of location an= d
    identity is a key part of a clean, efficient and high-functio= nality
    solution.  Considerable experimentation has been complet= ed on doing
    mobility with LISP.

    The mobility provided by LISP allows active sessions to survi= ve moves
    (provided of course that there is not a period of inaccessibi= lity
    which exceeds a timeout).  LISP mobility also will typic= ally have
    better packet stretch (i.e. increase in path length) compared= to
    traditional mobility schemes, which use a home agent.

7.6.  Traversal Across Alternate IP Versions

    Note that LISP inherently supports intermixing of various IP = versions
    for packet carriage; IPv4 packets might well be carried in IP= v6, or
    vice versa, depending on the network's configuration.

    This capability allows an island of operation of one type to = be
    automatically tunneled over a stretch of infrastucture which = only
    supports the other type.



Cabellos-Aparicio (Ed.) Expires January 17, 2015        = ;       [Page 15]

Internet-Draft              LISP Introdu= ction                  July 20= 14


7.7.  Virtual Private Networks

    {{Suggestion by editors: Remove this section, not covered by = any WG
    document}}

    L2 and L3 {{Need to add text here - This used to be part of '= Local'
    below, but we decided this was so important it deserved its o= wn
    section.  Maybe move this up further, as it seems to be = the most
    important 'early adopter' application?}}

    The mapping-and-encapsulation nature of LISP makes it a perfe= ct
    candidate for VPN solutions.  In this case, private part= s of the VPN
    form LISP sites and the IP addresses of devices in the privat= e parts
    are composing EID spaces.  The interconnection between t= he LISP sites
    is the public network and IP addresses in the interconnection= compose
    the RLOC space.  A major advantage of using LISP to cons= truct VPN
    resides in the simplicity of the configurations: each xTR (i.= e., VPN
    end) is configured to query the mapping system to retrieve ma= ppings
    making the glue between the public (RLOC space) and the priva= te (EID
    space) of the VPN.

    This includes support of multi-tenancy where several private = networks
    can be carried over the same underlayer network.  Thanks= to the
    instance-id field, multi-tenant network can even use the exac= t same
    addresses as the xTR distinguishes the tenant based on the va= lue of
    the instance-id.  The multiple address family support in= LISP
    mappings also allows to build private networks using a differ= ent
    addressing family than the carrier (e.g., IPv6 over IPv4).
7.8.  Local Uses

    {{Suggestion by editors: Remove this section.  The secti= on contains a
    general discussion about the applicability of LISP in intra-d= omain
    scenarios, however it does not describe any specific applicat= ion.}}

    LISP has a number of use cases which are within purely
    organizationally-local contexts, i.e. not in the larger Inter= net.
    These fall into two categories: uses seen on the Internet (ab= ove),
    but here on a private (and usually small scale) setting; and<= br>     applications which do not have a direct analog in the larger<= br>     Internet, and which apply only to local deployments.

    Among the former are multi-homing and IP version traversal. {= {This
    was marked to be deleted - why?  The next part doesn't m= ake sense
    without this first?}}

    Among the latter class, non-Internet applications which have = no
    analog on the Internet, are the following example application= s:



Cabellos-Aparicio (Ed.) Expires January 17, 2015        = ;       [Page 16]

Internet-Draft              LISP Introdu= ction                  July 20= 14


    virtual machine mobility in data centers; non-IP EID types su= ch as L2
    MAC addresses, or application specific data.

    Several of the applications listed in this section are the on= es which
    have been most popular for LISP in practise; these include vi= rtual
    networks, and virtual machine mobility.

    These often show a synergistic tendency, in that a site which=
    installs LISP to do one, often finds that then becomes a smal= l matter
    to use it for the second.  Given all the things which LI= SP can do, it
    is hoped that this synergistic effect will continue to expand= LISP's
    uses.

    {{Preceeding paragraphs should probably get moved up into VPN=
    section?}}

8.  Major Functional Subsystems

    {{Suggestion by editors: This section should appear before si= nce it
    describes key aspects of LISP (e.g., LISP decoupled control a= nd data-
    plane).}}

Yes, possibly where the first figure is.

    LISP has two major functional sub-systems: the xTRs which for= m the
    data-plane of LISP; and the mapping system which forms the co= ntrol
    plane that maintains and distributes the mapping database.
    The purpose and operation of each is described at a high leve= l below,
    and then, later on, in a fair amount of detail, in separate s= ections
    on each (Section 12 and Section 13).

8.1.  Data Plane - xTRs Overview

    {{Suggestion by editors: Extend this section, it misses key L= ISP
    data-plane aspects, such as the map-cache.}}

    xTRs are routers that have been augmented with extra function= ality in
    both the data and control planes.  The data plane functi= ons in ITRs
    include deciding which packets need to be given LISP processi= ng
    (since packets to non-LISP hosts may be sent as they are); i.= e.
    looking up the mapping; encapsulating (wrapping) the packet; = and
    sending it to the ETR.

    This encapsulation is done using UDP [RFC0768], along with an=
    additional outer IP header (to hold the source and destinatio= n
    RLOCs).  To the extent that traffic engineering features= are in use
    for a particular EID, the ITRs implement them as well.





Cabellos-Aparicio (Ed.) Expires January 17, 2015        = ;       [Page 17]

Internet-Draft              LISP Introdu= ction                  July 20= 14


    In the ETR, the data plane simply decapsulates (unwraps) the = packets,
    and forwards the it to the destination.

    Control plane functions in ITRs include: asking for EID-to-RL= OC
    mappings via Map-Request packets; handling the returning repl= y
    control messages (i.e., Map-Reply packets), which contain the= EID-to-
    RLOC mapping; managing the local mapping cache and checking f= or the
    reachability of destination ETR's RLOCs.

    In the ETR, control plane functions include participating in = the
    reachability tests (see Section 16.4); interacting with the m= apping
    sub-system to let it know what mapping this ETR can provide (= see
    Section 8.2.2); and answering Map-Request packets from ITRs f= or those
    mappings.

8.1.1.  Mapping Cache Performance

    {{Suggestion by editors: Push this section further in the doc= ument,
    the cache performance is not a "Major LISP subsystem&quo= t;}}

    As mentioned, studies have been performed to verify that cach= ing
    mappings in ITRs is viable, in practical engineering terms. &= nbsp;These
    studies not only verified that such caching is feasible, but = also
    provided some insight for designing ITR "mapping caches&= quot;.

    Briefly, they took lengthy traces of all packets leaving a la= rge
    site, over a period of a week or so, and used those to drive<= br>     simulations which showed how many mappings would be required.=  It
    also allowed analysis of how much control traffic (for loadin= g needed
    mappings) would result, using various cache sizes and replace= ment
    algorithms.  These studies provide an insight into how w= ell LISP can
    be expected to perform, and scale, over time.

    A more extended look at the results us given below, in Sectio= n 12.9,
    "xTR Mapping Cache Performance".

8.2.  Control Plane - Mapping System Overview

    {{Suggestion by editors: Rewrite: Replace EID block terminolo= gy
    (along with its description) with the very common term "= prefix".
    Describe Map-Request/Map-Reply LISP signaling messages.}}

    The mapping system's entire purpose is to give ITRs on-demand= access
    to the mapping database, which is a distributed, and potentia= lly
    replicated, database which holds mappings between EIDs (ident= ity) and
    RLOCs (location), along with needed ancillary data (e.g. life= times).





Cabellos-Aparicio (Ed.) Expires January 17, 2015        = ;       [Page 18]

Internet-Draft              LISP Introdu= ction                  July 20= 14


    To be exact, it contains mappings between EID blocks and RLOC= s (the
    block size is given explicitly, as part of the syntax).  = ;Support for
    blocks is both for minimizing the administrative configuratio= n
    overhead, as well as for operational efficiency; e.g. when a = group of
    EIDs are behind a single xTR.  In IP blocks are delimite= d by their IP
    prefix.

    However, the block may be, and sometimes is, as small as a si= ngle
    EID.  However, since mappings are only loaded upon deman= d, if smaller
    blocks become predominant, then the increased size of the ove= rall
    database is far less problematic than if the Internet's routi= ng
    tables came to be dominated by such small entries.

    A particular EID (or EID block) may be associated to than one= RLOC,
    and may change the association with time.

    Also, in general, throughout LISP, the address family of EIDs= and
    RLOCs is explicitly mentioned in control packet.

    Finally, the mapping from an EID (or EID block) contains not = just the
    RLOC(s), but also (for each RLOC for any given EID entry) pri= ority
    and weight fields (to allow allocation of load between severa= l RLOCs
    at a given priority); this allows a certain amount of traffic=
    engineering to be accomplished with LISP.

8.2.1.  Mapping System Organization

    {{Suggestion by editors: Rewrite: Describe key Mapping System=
    components: Map-Server/Map-Resolver}}

    The mapping system is split into three functional sub-systems= .

    The first is the actual mappings themselves, collectively the= mapping
    database; they are held by the ETRs, and an ITR which needs a= mapping
    gets it (effectively) directly from the ETR.  This co-lo= cation of the
    authoritative version of the mappings, and the forwarding
    functionality which it describes, is an instance of fate-shar= ing.
    [Clark]

    To find the appropriate ETR(s) to query for the mapping, the = second
    two sub-systems form an indexing system, itself also based on= a
    distributed, potentially replicated database.  It provid= es
    information on which ETR(s) are authoritative sources for the= various
    EID-to-RLOC mappings which are available.  The two sub-s= ystems which
    form it are the client interface sub-system, and indexing sub= -system
    (which holds and provides the actual information).





Cabellos-Aparicio (Ed.) Expires January 17, 2015        = ;       [Page 19]

Internet-Draft              LISP Introdu= ction                  July 20= 14


8.2.2.  Interface to the Mapping System

    {{Suggestion by editors: has been rewritten: This section sho= uld
    appear earlier since it describes key LISP components (Map-Re= quest/
    Map-Reply/Map-Server/Map-Resolver}}

    The client interface to the indexing system from an ITR's poi= nt of
    view is not with the indexing sub-system directly; rather, it= is
    through the Map-Resolvers (MRs) and Map-Servers (MSs).

    To obtain the mapping for an EID, the ITRs sends Map-Request = packet
    to an MR.  The MR then uses the indexing sub-system to a= llow it to
    forward the Map-Request to an appropriate Map-Server (MS), wh= ich in
    turn sends the Map-Request on to the appropriate ETR.  T= he latter is
    authoritative for the actual mappings for the EID.

    The ETR then sends the mappings for that EID in the form of a= Map-
    Reply packets, which is sent directly to the ITR, without pas= sing
    through the indexing sub-system and MR.  The details of = the indexing
    sub-system are thus hidden from the ITRs.

    Note that in proxy mode, the MS replies on behalf of the ETR.=  When
    this the case, the map-replies is tagged to indicate that the= answer
    is not delivered from the authoritative ETR but from the MS i= nstead.

    The interface to the indexing system from an ETR's point of v= iew is
    made through MSes.  ETRs send Map-Register packets to th= eir
    designated MSes.  The effect of a Map-Register is to inf= orm the MS
    about the mappings maintained by ETRs such that the MS can tr= ansmit
    the Map-Requests is receives to the appropriate ETRs.

    The MS optionally replies Map-Register packets with a Map-Not= ify
    packet to confirm the registration.  The details of the = indexing sub-
    system are thus likewise hidden from ETRs.

    The fact that the details of the indexing sub-system are enti= rely
    hidden from xTRs gives considerably flexibility to this aspec= t of
    LISP.  As long as any potential indexing sub-system can = track where
    mappings are, it could potentially be used; this would allow = the
    actual indexing sub-system to be replaced without needing to = modify
    the xTRs.

8.2.3.  Indexing Sub-system

    {{suggestion by editor: rename the section to "DDT"= }}



I think this section should briefly describe both ALT (mostly by reference = to RFC 6836) and  DDT (by reference to LISP-DDT, with way fewer detail= s on DDT than in the current document). "Indexing System" (as a c= omponent of the mapping system, together with the mapping database) may be a good name for this section.

"Index subsystem" is not a term used in ALT or DDT. What abo= ut "Mapping Database"?

    The current indexing sub-system is the Delegated Database Tre= e (DDT),
    which is conceptually similar to DNS ([I-D.ietf-lisp-ddt],


Cabellos-Aparicio (Ed.) Expires January 17, 2015        = ;       [Page 20]

Internet-Draft              LISP Introdu= ction                  July 20= 14


    [RFC1034]).  DDT replaces the earlier LISP+ALT index= ing sub-system
    ([RFC6836]).  The seamless migration to DDT while LISP&#= 43;ALT was
    previously used validated the concept of having a client-inte= rface
    sub-system between the indexing sub-system, and the clients.<= br>
8.2.3.1.  DDT Overview

    Conceptually, DDT is similar to the DNS, in DDT the delegatio= n of the
    EID namespace is instantiated as a delegation hierarchy, a tr= ee of
    DDT nodes, starting with the root DDT node.  Each vertex= is
    responsible for a block of the EID namespace.

    The root node is responsible for the entire EID space; any DD= T node
    can delegate part(s) of its EID block to child DDT node(s). &= nbsp;The
    child node(s) can in turn further delegate (necessarily small= er)
    blocks of namespace to their children, through as many levels= as are
    needed (for operational, administrative, etc, needs).

    Just as with DNS, any particular vertex in the DDT delegation= tree
    may be instantiated in one or more DDT servers.  Multipl= e (redundant)
    servers for a given node would be used for reasons of perform= ance,
    reliability, and robustness.  Obviously, all the servers= which
    instantiate a particular nodes in the tree have to have ident= ical
    data about that node.

8.2.3.2.  Use of DDT by MRs

    An MR which wants to find a mapping for a particular EID firs= t
    interacts with the DDT servers which instantiate the nodes of= the
    LISP delegation hierarchy tree, discovering (by querying the = servers
    for information about DDT nodes) the chain of delegations whi= ch cover
    that EID.  Eventually it is directed to an MS, which is = servicing an
    ETR which is authoritative for that EID.

    Also, again like DNS, MRs may cache information they receive = about
    the delegations in the delegation tree.  This means that= once an MR
    has been in operation for a while, it will usually have much = of the
    delegation information cached locally (especially the top lev= els of
    the delegation tree).  This allows them, when passed a r= equest for a
    mapping by an ITR, to usually forward the mapping request to = the
    appropriate MS without having to interact with all the DDT se= rvers on
    the path down the delegation tree, in order to find any parti= cular
    mapping.

    Thus, a typical resolution cycle would usually involve lookin= g at
    some locally cached delegation information, perhaps loading s= ome
    missing delegation entries into their delegation cache, and f= inally
    sending the Map-Request to the appropriate MS.



Cabellos-Aparicio (Ed.) Expires January 17, 2015        = ;       [Page 21]

Internet-Draft              LISP Introdu= ction                  July 20= 14


    It should also be noted that the delegation tree is fairly st= atic,
    since it reflects EID block allocations, which are themselves= fairly
    static.  This stability has several important consequenc= es.  First,
    it increases the performance of the mapping system, since the= sub-
    system almost never needs to be re-queried for information ab= out
    intermediate vertices.  {{comment from editor: does not = understand
    the next sentence...}}Second, it is not necessary to include = a
    mechanism to find out-dated delegations.  [LISP-TREE]
    This contrasts with the mappings, which may change at a high = rate -
    changes which have no impact on the indexing sub-system. &nbs= p;The
    potentially high dynamics of mappings explains why mappings a= re
    delivered directly from ETRs (or MSes in proxy mode) to ITRs = and
    hence not cached at the MR level.  LISP is designed to m= ake sure that
    changes in the mappings are detected and acted upon fairly qu= ickly;
    this allows LISP to provide a number of capabilities, such as=
    mobility.

9.  Examples of operation

    To aid in comprehension, a few examples are given of user pac= kets
    traversing the LISP system.  The first shows the process= ing of a
    typical user packet which is LISP forwarded, i.e. what the va= st
    majority of user packets will see.  The second shows wha= t happens
    when the first packet to a previously-unseen ultimate destina= tion (at
    a particular ITR) is to be processed by LISP.

9.1.  An Ordinary Packet's Processing

    {{Suggestion by editors: This section should be earlier in th= e
    document structure, examples are important -particularly for<= br>     engineers- to explain how systems work}}

    This case follows the processing of a typical , {{comment fro= m
    editors: text missing}} when the packet has made its way thro= ugh the
    local site to an ITR, which in this case is a border router f= or the
    site, the border router looks up the destination address - an= EID -
    in its local mapping cache.  For EIDs which are IP addre= sses, this
    lookup uses the IP longest prefix matching algorithm.

    It finds a mapping, which instructs it to wrap the packet in = an outer
    header - an IP packet, containing a UDP packet which contains= a LISP
    header - and then the user's original packet (see Section 12.= 2 for
    the reasons for this particular choice).  The destinatio= n address in
    the outer header is set by the ITR to the RLOC of the destina= tion
    ETR.





Cabellos-Aparicio (Ed.) Expires January 17, 2015        = ;       [Page 22]

Internet-Draft              LISP Introdu= ction                  July 20= 14


    The encapsulated packet is then sent off through the RLOC spa= ce
    (e.g., Internet), using normal Internet routing.

    On arrival at the destination ETR, the ETR will notice that i= t is
    listed as the destination in the outer header.  It will = examine the
    packet, detect that it is a LISP packet, and unwrap it.  = ;It will then
    examine the header of the user's original packet, and forward= it
    internally, through the local site, to the ultimate destinati= on.

    At the ultimate destination, the packet will be processed, an= d may
    produce a return packet, which follows the exact same process= in
    reverse - with the exception that the roles of the ITR and ET= R are
    swapped.

9.2.  A Mapping Cache Miss

    {{Suggestion by editors: (same as previous section)}}

    If a host sends a packet, and it gets to the ITR, and the ITR=
    determines that it does not yet have a mapping cache entry wh= ich
    covers that destination EID, then additional processing ensue= s; it
    has to look up the mapping in the mapping system (as previous= ly
    described in Section 6.2).

    The overall processing is shown below, in Figure 2:

                   ----- =            -----
                  |   &nb= sp; |    3     |     |
    Map Resolver  |     | -------> |   &nb= sp; |  Map Server
                  |   &nb= sp; |          |     |
                   ----- =            -----
                     = ;^                |
    Key:             |    = ;            |
                     = ;|                |
    -- =3D Control     |         &n= bsp;      |
    =3D=3D =3D Data        |     &n= bsp;          |
                  2  | &n= bsp;     5        |  4
                     = ;|      ---       |
    Host A           |    / &n= bsp;   \     |            Host= B
                     = ;|  |_       \    V
     -----          -----   &n= bsp;      \ -----          -----     |     |   1    |     | &nb= sp;  6     |     |   7    |   =   |
    |     | =3D=3D=3D=3D=3D> | ITR | =3D=3D=3D=3D=3D= =3D=3D> | ETR | =3D=3D=3D=3D=3D> |     |
    |     |        |     = |          |     |       =  |     |
     -----          -----   &n= bsp;        -----          ---= --

                 Figure 2: Pac= ket flow with missing mapping




Cabellos-Aparicio (Ed.) Expires January 17, 2015        = ;       [Page 23]

Internet-Draft              LISP Introdu= ction                  July 20= 14


    1.  Source-EID sends packet (to Dest-EID) to ITR

    2.  ITR sends Map-Request to Map-Resolver

    3.  Map-Resolver delivers Map-Request to Map-Server

    4.  Map-Server delivers Map-Request to ETR

    5.  ETR returns Map-Reply to ITR; ITR caches EID-to-RLOC= (s) mapping

    6.  ITR uses mapping to encapsulate to ETR; sends user p= acket to ETR

    7.  ETR decapsulates packet, delivers to Dest-EID

    The ITR first sends a Map-Request packet, giving the destinat= ion EID
    it needs a mapping for, to its MR.  The MR will look in = its cache of
    delegation information to find the vertex which is the most s= pecific
    in the delegation tree for that destination EID .  If it= does not
    have the address of an appropriate MS, it will query the DDT = system,
    recursively if need be, in order to eventually find the addre= ss of
    such an MS.

    When it has the MS's address, it will send the Map-Request on= to the
    MS, which then usually sends it on to an appropriate ETR. &nb= sp;The ETR
    sends a Map-Reply to the ITR which needs the mapping; from th= en on,
    processing of user packets through that ITR to that ultimate<= br>     destination proceeds as above.

    To the best of our knowledge, in all LISP implementations, th= e
    original user packet will have been discarded, and not queued= waiting
    for the mapping to be returned.  When the host retransmi= ts such a
    packet, the mapping will be there, and the packet will be for= warded.
    Alternatively, it might have been forwarded using a PITR to a= void
    being dropped (Section 6.4).

10.  Part II

    {{comment from editors: is that the role of an introductory d= ocument
    to enter in such level of details and discuss (mostly) all fi= elds of
    the protocol? }}

No.
It should just describe the architecture of the entire LISP system, making = it easier to read the rest of the LISP specifications and providing a *basi= s* for discussion about the details of the LISP protocols.


11.  Design Approach

    {{Suggestion by editors: Remove this section, it does not des= cribe/
    discuss anything relevant, it is only providing a reference t= o
    another non-WG document.}}



Cabellos-Aparicio (Ed.) Expires January 17, 2015        = ;       [Page 24]

Internet-Draft              LISP Introdu= ction                  July 20= 14


    Before describing LISP's components in more detail below, it = it worth
    pointing out that what may seem, in some cases, like odd (or = poor)
    design approaches do in fact result from the application of a=
    thought-through, and consistent, design philosophy used in cr= eating
    them. {{Subjective: maybe JMH, Dino can help with better word= s?}}

    This design philosophy is covered in detail in
    [I-D.ietf-lisp-perspective], Section "Design"), and= readers who are
    interested in the 'why' of various mechanisms should consult = that;
    reading it may make clearer the reasons for some engineering = choices
    in the mechanisms given here.

12.  xTRs

    As mentioned above (in Section 8.1), xTRs are the essential L= ISP data
    plane elements.  This section explores some advanced top= ics related
    to xTRs.

    {{Suggestion by editors: remove next paragraph, brings nothin= g)}}

    Careful rules have been specified for both TTL and ECN [RFC31= 68] to
    ensure that passage through xTRs does not interfere with the<= br>     operation of these mechanisms.  In addition, care has be= en taken to
    ensure that traceroute works when xTRs are involved.

12.1.  When to Encapsulate

    An ITR knows that an ultimate destination is running LISP (re= member
    that the actual destination machine itself probably knows not= hing
    about LISP), and thus that it should perform LISP processing = on a
    packet (including potential encapsulation) if it has an entry= in its
    local mapping cache that covers the destination address (it i= s then
    called an EID).

    Conversely, if the cache contains a negative entry (indicatin= g that
    the ITR has previously attempted to find a mapping that cover= s this
    EID, and it has been informed by the mapping system that no s= uch
    mapping exists), it knows the ultimate destination is not run= ning
    LISP, and the packet can be forwarded natively (i.e. not LISP= -
    encapsulated).

    Note that the ITR cannot simply depend on the appearance, or = non-
    appearance, of the destination in the routing tables in the I= nternet
    core, as a way to tell if a destination is a LISP node or not= .  That
    is because mechanisms to allow interoperation of LISP sites a= nd
    legacy sites necessarily involve advertising LISP sites' EIDs= into
    the Internet core; in other words, LISP sites which need to



Cabellos-Aparicio (Ed.) Expires January 17, 2015        = ;       [Page 25]

Internet-Draft              LISP Introdu= ction                  July 20= 14


    interoperate with legacy nodes will appear in the Internet co= re
    routing tables, along with non-LISP sites.

12.2.  UDP Encapsulation Details

    Use of UDP (instead of, say, a LISP-specific protocol number)= was
    driven by the fact that many routers and middle boxes filter = out
    unknown protocols, so adopting a non-UDP encapsulation would = have
    compromised the initial deployment of LISP.

    The UDP source port used for encapsulating packet is computed= with a
    5-way hash of the original source and destination in the inne= r
    header, along with the ports, and the protocol.  This is= because many
    ISPs use multiple parallel paths (so-called Equal Cost Multi-= Path),
    and load-share across them.  Using such a hash in the so= urce-port in
    the outer header both allows LISP traffic to be load-shared, = and also
    ensures that packets from individual connections are delivere= d in
    order (since most ISPs try to ensure that packets for a parti= cular
    flow follow a single path, and hence do not become disordered= ).

    The UDP checksum is zero because the inner packet usually alr= eady has
    a end-end checksum, and the outer checksum adds no value ([Sa= ltzer]).
    {{Suggestion by editors: not sure that next statement is corr= ect}} In
    most exising hardware, computing such a checksum (and checkin= g it at
    the other end) would also present a major load, for no benefi= t.

12.3.  Header Control Channel

    {{Suggestion by editors: Rewrite this section to improve read= ability,
    use standard terminology (e.g., Cache Coherence/Reachability = instead
    of "Header Control Channel").  Split the mecha= nisms depending on its
    goal (cache coherence/reachability) and describe them under t= he same
    context.}}

    LISP provides a multiplexed channel in the encapsulation head= er.  It
    is mostly (but not entirely) used for control purposes.  = ;The general
    concept is that the header starts with a flags field, and it = also
    includes two data fields, the contents and meaning of which v= ary,
    depending on which flags are set.  This allows these fie= lds to be
    multiplexed among a number of different low-duty-cycle functi= ons,
    while minimizing the space overhead of the LISP.

12.3.1.  Mapping Versioning

    One important use of the multiplexed control channel is mappi= ng
    versioning; i.e. the discovery of when the mapping cached in = an ITR
    is outdated.  To allow an ITR to discover this, identify= ing sequence
    numbers are applied to different versions of a mappping [RFC6= 834].



Cabellos-Aparicio (Ed.) Expires January 17, 2015        = ;       [Page 26]

Internet-Draft              LISP Introdu= ction                  July 20= 14


    This allows an ITR to easily discover when a cached mapping h= as been
    updated by a more recent variant.

    Version numbers are available in control messages (Map-Replie= s), but
    the initial concept is that to limit control message overhead= , the
    versioning mechanism should primarily use the multiplexed use= r data
    header control channel.

    Versioning can operate in both directions: an ITR can advise = an ETR
    what version of a mapping it is currently using (so the ETR c= an
    notify it if there is a more recent version), and ETRs can le= t ITRs
    know what the current mapping version is (so the ITRs can req= uest an
    update, if their copy is outdated).

12.3.2.  Echo Nonces

    Another important use of the header control channel is for a<= br>     mechanism known as the Nonce Echo, which is used as an effici= ent
    method for ITRs to check the reachability of neighbour ETRs.<= br>
    Basically, an ITR which has to determine that an ETR is up, a= nd
    reachable, sends a nonce to that ETR, carried in the encapsul= ation
    header; when that ETR (also acting as an ITR) sends some othe= r user
    data packet back to the ITR (acting in turn as an ETR), that = nonce is
    carried in the header of that packet, allowing the original I= TR to
    confirm that its packets are reaching that ETR.

    Note that a lack of a response is not necessarily proof that<= br>     something has gone wrong - but it strongly suggests that some= thing
    has, so other actions (e.g. a switch to an alternative ETR, i= f one is
    listed; a direct probe; etc) are advised.  (See Section = 16.5 for more
    about Echo Nonces.)

12.3.3.  Instances

    {{Suggestion by editors: Move and extend this section: - Inst= ance ID
    is not a cache-coherence/reachability algorithm.  Descri= be where and
    what is the Instance ID field Explain its applications}}

    The LISP data-plane header is also used to support VPN and mu= lti-
    tenant networks.  Since there is only one destination UD= P port used
    for carriage of user data packets, and the source port is use= d for
    multiplexing, there is no other way to differentiate among di= fferent
    destination EID spaces (which are often overlapped in VPNs an= d multi-
    tenant networks).






Cabellos-Aparicio (Ed.) Expires January 17, 2015        = ;       [Page 27]

Internet-Draft              LISP Introdu= ction                  July 20= 14


12.4.  Probing

    RLOC-Probing is a mechanism method that an ITR can use to det= ermine
    with that an ETR is up and reachable from the ITR.  As a= side-
    benefit, it gives RTT estimates.

    To probe the reachability of an RLOC, an ITR sends a speciall= y marked
    Map-Request directly to the ETR it wishes information about; = that ETR
    sends back a specially marked Map-Reply.  A Map-Request = message and a
    Map-Reply message are used, rather than a special probing con= trol-
    message pair, because as a side-benefit the ITR can discover = if the
    mapping has been updated since it cached it.

    {{Suggestion from editors: remove the following sentence as i= t is not
    motivated by strong arguments}} The probing mechanism is rath= er
    heavy-weight and expensive (compared to mechanisms like the E= cho-
    Nonce), since it costs a control message from each side, so i= t should
    only be used sparingly.

    If the number of active neighbour ETRs of the ITR is large, u= se of
    RLOC-Probing to check on their reachability will result in     considerable control traffic; such control traffic has to be = spread
    out to prevent a load peak.

    Obviously, if RLOC-Probing is the only mechanism being used t= o detect
    unreachable neighbour ETRs, the rate at which RLOC-Probing is= done
    will control the timeliness of the detection of loss of reach= ability.
    There is thus a tradeoff between overhead and responsiveness,=
    particular when an ITR has a large fanout of neighbour ETRs.<= br>
12.5.  Mapping Lifetimes and Timeouts

    {{Suggestion by editors: Remove this section, TTL is a simple= well-
    known concept, we suggest to include a sentence (and hence re= move
    this section) in the control-plane section stating that mappi= ngs
    include a TTL.

    Mappings come with a Time-To-Live, which indicate how long th= e
    creator of the mapping expects them to be useful for.

    Mappings might also be discarded before the TTL expires, depe= nding on
    what strategies the ITR is using to maintain its cache; if th= e
    maximum cache size is fixed, or the ITR needs to reclaim memo= ry,
    mappings which have not been used recently may be discarded. =  (After
    all, there is no harm in so doing; a future reference will me= rely
    cause that mapping to be reloaded.)

    {{Contents may change before TTL expires?}}



Cabellos-Aparicio (Ed.) Expires January 17, 2015        = ;       [Page 28]

Internet-Draft              LISP Introdu= ction                  July 20= 14


12.6.  Mapping Gleaning in ETRs

    {{Suggestion by editors: Remove this section, gleaning is dis= couraged
    since it rises many security concerns.}}

    As an optimization to the mapping acquisition process, ETRs a= re
    allowed to glean mappings from incoming user data packets, an= d also
    from incoming Map-Request control messages.  This is not= secure, and
    so any such mapping must be verified by sending a Map-Request= to get
    an authoritative mapping.

    The value of gleaning is that most communications are two-way= , and so
    if host A is sending packets to host B (therefore needing B's=
    EID->RLOC mapping), very likely B will soon be sending pac= kets back
    to A (and thus needing A's EID->RLOC mapping).  Witho= ut gleaning,
    this would sometimes result in a delay, and the dropping of t= he first
    return packet; this is felt to be very undesirable.

12.7.  MTU Issues

    Several mechanisms have been proposed for dealing with packet= s which
    are too large to transit the path from a particular ITR to a = given
    ETR.

    In one, called the stateful approach, the ITR keeps a per-ETR= record
    of the maximum size allowed, and sends an ICMP Too Big messag= e to the

_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

--_000_BB4FB88584FC4F91A3CDBE41A81F39E8ciscocom_-- From nobody Mon Aug 4 01:22:41 2014 Return-Path: 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 B14161B28B2 for ; Mon, 4 Aug 2014 01:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.808 X-Spam-Level: X-Spam-Status: No, score=0.808 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 ZkuswqF4xhla for ; Mon, 4 Aug 2014 01:22:13 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8BB1B28AE for ; Mon, 4 Aug 2014 01:22:11 -0700 (PDT) Received: from gw-3.ac.upc.es (gw-3.ac.upc.es [147.83.30.9]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id s748MAto001730 for ; Mon, 4 Aug 2014 10:22:10 +0200 Received: from [10.21.144.41] (128-107-239-233.cisco.com [128.107.239.233]) by gw-3.ac.upc.es (Postfix) with ESMTPSA id A641E7AA for ; Mon, 4 Aug 2014 10:22:04 +0200 (CEST) Message-ID: <53DF42A5.9050707@ac.upc.edu> Date: Mon, 04 Aug 2014 01:21:57 -0700 From: Florin Coras User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: lisp@ietf.org References: <20140716164043.11214.75343.idtracker@ietfa.amsl.com> <53C6ACAC.7090407@joelhalpern.com> <53EE128C-1552-4F00-AECF-6EE8511A4D18@gigix.net> <53D2BC3B.1090308@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010307020201040600000808" Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/_5Uuvr3RyPgewFezqCi6GncJm-E Subject: Re: [lisp] I-D ACTION:draft-ietf-lisp-introduction-04.txt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 08:22:36 -0000 This is a multi-part message in MIME format. --------------010307020201040600000808 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Albert, Damien, There's not much to add to what previous reviewers have already mentioned. Overall, I agree with the editorial recommendations, especially those in favor of simplifying the discourse. I'm also of opinion that the document should be a concise description of LISP and only offer a high-level description of problems that it solves or it may solve. In this sense, I agree with Victor's point that more general text that allows for future use cases might be needed. Thanks for moving this forward. I'm looking forward to reviewing the next revision. Florin On 8/1/14 2:30 PM, Victor Moreno (vimoreno) wrote: > Hi Alberto, Damien, > > A few suggestions for the intro doc: > > Overview/Basic Approach (currently 6 and 6.1): > - Not in the current text: Spell out very clearly and upfront the > concept of *separation* of location and identity. > - With the concept of location/identity separation clear, then proceed > to introduce RLOCs and EIDs as manifestations of such concepts. > - Highlight that these are not mandatorily IP addresses (could be > almost anything). > - Build upon this to introduce the notion of RLOCs and EIDs as forming > two distinct address spaces > - Finally introduce LISP as the mechanisms to handle the mappings that > correlate the two address spaces. May be a good segway into the Basic > functionality section that follows. > > Basic Functionality (6.2): > - I think it is worth adding to this section the notion of the > destination based policies manifested as priorities and weights. Since > this is an architectural doc, we may want to abstract this policy > notion enough to accommodate other/future policy options that may arise. > - The pull nature of the mechanism is introduced in 6.3 currently. I > think this is an important attribute and may be worth considering > bringing it forward to 6.2. > > Initial Applications (7): > - Fully agree that the section needs to be moved back if we keep it. > - Most use cases will probably fall out of charter at this point, > making this section very short until a future re-charter allows more > use cases. IMO we need text to allow for those future use cases that > are currently out of charter without having to re-open this > architecture document. One option is to keep the text on the use cases > that is currently in the document. Another option is to include > general text to allow future use cases. The latter may be required > regardless. > - IMO, just keep the use cases in any order. > > 8.2. Regarding EID-block vs. prefix. I kind of like EID-block in > support of the AF agnostic characteristics of LISP. Prefixes (I think) > are tightly coupled with IP, once we have MAC addresses or other > addresses prefix may not be the best choice. > > 10. Part II > > {{comment from editors: is that the role of an introductory document > to enter in such level of details and discuss (mostly) all fields of > the protocol? }} > IMO not in detail and we should probably be a bit more selective in > terms of which fields we do discuss in this doc vs. which we do not. > Thus outlining the moving parts, at a high level, and providing > references to the documentation with the relevant details may be > helpful to those starting with LISP. In general, this second part > should be much more succinct in my opinion. > > Regarding any other “Suggestions by editors", I agree with all the > editor suggestions in version 04 with any comments/exceptions noted above. > > Thanks for moving this forward. > > Regards, > > -v > > > On Jul 28, 2014, at 1:28 PM, Albert Cabellos > > wrote: > >> Fabio, >> >> Please see below: >> >> >> On Fri, Jul 25, 2014 at 10:21 PM, Fabio Maino > > wrote: >> >> Albert, Damien, >> please find my comments below. >> >> >> Network Working Group A. >> Cabellos-Aparicio (Ed.) >> Internet-Draft Technical University >> of Catalonia >> Intended status: Informational D. Saucez (Ed.) >> Expires: January 17, 2015 INRIA >> July 16, 2014 >> >> >> An Architectural Introduction to the LISP >> Location-Identity >> Separation System >> draft-ietf-lisp-introduction-04.txt >> >> Abstract >> >> This document is an introductory overview of the Locator/ID >> Separation Protocol, it describes the major concepts and >> functional >> sub-systems of LISP and the interactions between them. >> >> Status of This Memo >> >> This Internet-Draft is submitted in full conformance with the >> provisions of BCP 78 and BCP 79. >> >> Internet-Drafts are working documents of the Internet >> Engineering >> Task Force (IETF). Note that other groups may also >> distribute >> working documents as Internet-Drafts. The list of >> current Internet- >> Drafts is athttp://datatracker.ietf.org/drafts/current/ >> . >> >> Internet-Drafts are draft documents valid for a maximum >> of six months >> and may be updated, replaced, or obsoleted by other >> documents at any >> time. It is inappropriate to use Internet-Drafts as >> reference >> material or to cite them other than as "work in progress." >> >> This Internet-Draft will expire on January 17, 2015. >> >> Copyright Notice >> >> Copyright (c) 2014 IETF Trust and the persons identified >> as the >> document authors. All rights reserved. >> >> This document is subject to BCP 78 and the IETF Trust's Legal >> Provisions Relating to IETF Documents >> (http://trustee.ietf.org/license-info) in effect on the >> date of >> publication of this document. Please review these documents >> carefully, as they describe your rights and restrictions >> with respect >> to this document. Code Components extracted from this >> document must >> include Simplified BSD License text as described in >> Section 4.e of >> the Trust Legal Provisions and are provided without >> warranty as >> described in the Simplified BSD License. >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 >> [Page 1] >> >> Internet-Draft LISP Introduction >> July 2014 >> >> >> Table of Contents >> >> 1. Prefatory Note . . . . . . . . . . . . . . . . . . . >> . . . . 4 >> 2. Part I . . . . . . . . . . . . . . . . . . . . . . . >> . . . . 4 >> 3. Initial Glossary . . . . . . . . . . . . . . . . . . >> . . . . 5 >> 4. Background . . . . . . . . . . . . . . . . . . . . . >> . . . . 6 >> 5. Deployment Philosophy . . . . . . . . . . . . . . . . >> . . . . 7 >> 5.1. Economics . . . . . . . . . . . . . . . . . . . . >> . . . . 7 >> 5.2. Maximize Re-use of Existing Mechanism . . . . . . >> . . . . 8 >> 6. LISP Overview . . . . . . . . . . . . . . . . . . . . >> . . . . 8 >> 6.1. Basic Approach . . . . . . . . . . . . . . . . . >> . . . . 9 >> 6.2. Basic Functionality . . . . . . . . . . . . . . . >> . . . . 9 >> 6.3. Mapping from EIDs to RLOCs . . . . . . . . . . . >> . . . . 11 >> 6.4. Interworking With Non-LISP-Capable Endpoints . . >> . . . . 11 >> 6.5. Security in LISP . . . . . . . . . . . . . . . . >> . . . . 12 >> 7. Initial Applications . . . . . . . . . . . . . . . . >> . . . . 13 >> 7.1. Provider Independence . . . . . . . . . . . . . . >> . . . . 13 >> 7.2. Multi-Homing . . . . . . . . . . . . . . . . . . >> . . . . 13 >> 7.3. Traffic Engineering . . . . . . . . . . . . . . . >> . . . . 14 >> 7.4. Routing . . . . . . . . . . . . . . . . . . . . . >> . . . . 15 >> 7.5. Mobility . . . . . . . . . . . . . . . . . . . . >> . . . . 15 >> 7.6. Traversal Across Alternate IP Versions . . . . . >> . . . . 15 >> 7.7. Virtual Private Networks . . . . . . . . . . . . >> . . . . 16 >> 7.8. Local Uses . . . . . . . . . . . . . . . . . . . >> . . . . 16 >> 8. Major Functional Subsystems . . . . . . . . . . . . . >> . . . . 17 >> 8.1. Data Plane - xTRs Overview . . . . . . . . . . . >> . . . . 17 >> 8.1.1. Mapping Cache Performance . . . . . . . . . . >> . . . . 18 >> 8.2. Control Plane - Mapping System Overview . . . . . >> . . . . 18 >> 8.2.1. Mapping System Organization . . . . . . . . . >> . . . . 19 >> 8.2.2. Interface to the Mapping System . . . . . . . >> . . . . 20 >> 8.2.3. Indexing Sub-system . . . . . . . . . . . . . >> . . . . 20 >> 9. Examples of operation . . . . . . . . . . . . . . . . >> . . . . 22 >> 9.1. An Ordinary Packet's Processing . . . . . . . . . >> . . . . 22 >> 9.2. A Mapping Cache Miss . . . . . . . . . . . . . . >> . . . . 23 >> 10. Part II . . . . . . . . . . . . . . . . . . . . . . . >> . . . . 24 >> 11. Design Approach . . . . . . . . . . . . . . . . . . . >> . . . . 24 >> 12. xTRs . . . . . . . . . . . . . . . . . . . . . . . . >> . . . . 25 >> 12.1. When to Encapsulate . . . . . . . . . . . . . . >> . . . . 25 >> 12.2. UDP Encapsulation Details . . . . . . . . . . . >> . . . . 26 >> 12.3. Header Control Channel . . . . . . . . . . . . . >> . . . . 26 >> 12.3.1. Mapping Versioning . . . . . . . . . . . . . >> . . . . 26 >> 12.3.2. Echo Nonces . . . . . . . . . . . . . . . . >> . . . . 27 >> 12.3.3. Instances . . . . . . . . . . . . . . . . . >> . . . . 27 >> 12.4. Probing . . . . . . . . . . . . . . . . . . . . >> . . . . 28 >> 12.5. Mapping Lifetimes and Timeouts . . . . . . . . . >> . . . . 28 >> 12.6. Mapping Gleaning in ETRs . . . . . . . . . . . . >> . . . . 29 >> 12.7. MTU Issues . . . . . . . . . . . . . . . . . . . >> . . . . 29 >> 12.8. Security of Mapping Lookups . . . . . . . . . . >> . . . . 29 >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 >> [Page 2] >> >> Internet-Draft LISP Introduction >> July 2014 >> >> >> 12.9. ITR Mapping Cache Performance . . . . . . . . . >> . . . . 30 >> 13. The Mapping System . . . . . . . . . . . . . . . . . >> . . . . 31 >> 13.1. The Mapping System Interface . . . . . . . . . . >> . . . . 32 >> 13.1.1. Map-Request Messages . . . . . . . . . . . . >> . . . . 32 >> 13.1.2. Map-Reply Messages . . . . . . . . . . . . . >> . . . . 32 >> 13.1.3. Map-Register and Map-Notify Messages . . . . >> . . . . 33 >> 13.2. The DDT Indexing Sub-system . . . . . . . . . . >> . . . . 34 >> 13.3. Reliability via Replication . . . . . . . . . . >> . . . . 35 >> 13.4. Security of the DDT Indexing Sub-system . . . . >> . . . . 35 >> 13.5. Extended Capabilities . . . . . . . . . . . . . >> . . . . 36 >> 13.6. Performance of the Mapping System . . . . . . . >> . . . . 36 >> 14. Multicast Support in LISP . . . . . . . . . . . . . . >> . . . . 37 >> 14.1. Basic Concepts of Multicast Support in LISP . . >> . . . . 37 >> 14.2. Initial Multicast Support in LISP . . . . . . . >> . . . . 38 >> 15. Deployment Issues and Mechanisms . . . . . . . . . . >> . . . . 39 >> 15.1. LISP Deployment Needs . . . . . . . . . . . . . >> . . . . 39 >> 15.2. Interworking Mechanisms . . . . . . . . . . . . >> . . . . 40 >> 15.2.1. Proxy LISP Routers . . . . . . . . . . . . . >> . . . . 40 >> 15.2.2. LISP-NAT . . . . . . . . . . . . . . . . . . >> . . . . 42 >> 15.3. Use Through NAT Devices . . . . . . . . . . . . >> . . . . 42 >> 15.4. LISP and Core Internet Routing . . . . . . . . . >> . . . . 43 >> 16. Fault Discovery/Handling . . . . . . . . . . . . . . >> . . . . 43 >> 16.1. Handling Missing Mappings . . . . . . . . . . . >> . . . . 44 >> 16.2. Outdated Mappings . . . . . . . . . . . . . . . >> . . . . 44 >> 16.2.1. Outdated Mappings - Updated Mapping . . . . >> . . . . 44 >> 16.2.2. Outdated Mappings - Wrong ETR . . . . . . . >> . . . . 44 >> 16.2.3. Outdated Mappings - No Longer an ETR . . . . >> . . . . 45 >> 16.3. Erroneous Mappings . . . . . . . . . . . . . . . >> . . . . 45 >> 16.4. Verifying ETR Liveness . . . . . . . . . . . . . >> . . . . 45 >> 16.5. Verifying ETR Reachability . . . . . . . . . . . >> . . . . 46 >> 17. Acknowledgments . . . . . . . . . . . . . . . . . . . >> . . . . 46 >> 18. IANA Considerations . . . . . . . . . . . . . . . . . >> . . . . 47 >> 19. Security Considerations . . . . . . . . . . . . . . . >> . . . . 47 >> 20. References . . . . . . . . . . . . . . . . . . . . . >> . . . . 47 >> 20.1. Normative References . . . . . . . . . . . . . . >> . . . . 47 >> 20.2. Informative References . . . . . . . . . . . . . >> . . . . 49 >> Appendix A. Glossary/Definition of Terms . . . . . . . . >> . . . . 52 >> Appendix B. Other Appendices . . . . . . . . . . . . . . >> . . . . 55 >> B.1. A Brief History of Location/Identity Separation >> . . . . 55 >> B.2. A Brief History of the LISP Project . . . . . . . >> . . . . 56 >> B.3. Old LISP 'Models' . . . . . . . . . . . . . . . . >> . . . . 56 >> B.4. The ALT Mapping Indexing Sub-system . . . . . . . >> . . . . 57 >> B.5. Early NAT Support . . . . . . . . . . . . . . . . >> . . . . 58 >> Authors' Addresses . . . . . . . . . . . . . . . . . . . >> . . . . 59 >> >> >> >> >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 >> [Page 3] >> >> Internet-Draft LISP Introduction >> July 2014 >> >> >> 1. Prefatory Note >> >> {{Suggestion by editors: Remove all the sections before "LISP >> Overview" and write a straight-to-the-point introduction}} >> >> {{Suggestion by editors: The draft should focus on >> describing the >> LISP architecture and avoid comparing loc/id split >> architectures with >> other approaches}} >> >> >> Agree: my suggestion is to view this as a doc for a reader new to >> LISP that needs to be introduced to the architecture. At the end >> of the doc the reader will be familiar with the basic aspects of >> LISP, and able to navigate through the RFCs. The document should >> be kept as short and as "dry" as possible. If the reader wants to >> know more, after reading this doc, he will know where to go for >> the details. >> >> >> >> >> This document is the first of a pair which, together, >> form what one >> would think of as the 'architecture document' for LISP (the >> 'Location-Identity Separation Protocol'). Much of what would >> normally be in an architecture document (e.g. the >> architectural >> design principles used in LISP, and the design >> considerations behind >> various components and aspects of the LISP system) is in >> the second >> document, the 'Architectural Perspective on LISP' document. >> [I-D.ietf-lisp-perspective] >> >> This 'Architectural Introduction' document is primarily >> intended for >> those who are unfamiliar with LISP, and want to start >> learning about >> it. It is intended primarily for those working on LISP, >> but those >> working with LISP, and more generally anyone who wants to >> know more >> about LISP, may also find this document useful. >> >> This document is intended to both be easy to follow and it is >> structured as a series of phases, each covering the >> entire system, >> but with ever-increasing detail. Reading only the first >> part of the >> document will give a good high-level view of the system; >> reading the >> complete document should provide a fairly detailed >> understanding of >> the entire system. >> >> People who just want to get an idea of how LISP works >> might only read >> the first part; they can stop reading either just before, >> or just >> after Section 9. People who are going to go on and read >> the protocol >> specifications (perhaps to implement LISP) should read >> the entire >> document. >> >> This document is a descriptive document, not a protocol >> specification. Should it differ in any detail from any >> of the LISP >> protocol specification documents, they take precedence >> for the actual >> operation of the protocol. >> >> 2. Part I >> >> >> >> >> >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 >> [Page 4] >> >> Internet-Draft LISP Introduction >> July 2014 >> >> >> 3. Initial Glossary >> >> >> let's stick to the RFCs glossary. Since this is a first-to-read >> doc there should be a minimal definition section, but definitions >> should mostly be cut and paste from the RFCs. >> >> >> Agree, this will make easier to read the rest of the RFCs. >> >> >> >> This initial glossary defines a few general terms which >> will be >> useful to have in hand when commencing reading this >> document. A >> complete glossary is available in Appendix A. >> >> A note about style: initial usage of a term defined in >> the glossary >> is denoted with double quotation marks ("). Other uses >> of quotations >> (e.g. for quotations, euphemisms, etc) use single >> quotation marks >> ('). >> >> o Name: a name refers to an identifier for an object or >> entity. >> Names have both semantics (meaning) and syntax (form) >> [RFC1498]. >> >> o Namespace: A group of names with matching semantics >> and syntax; >> they usually, but not always, refer to members of a >> class of >> identical objects. >> >> o Mapping: a binding between two names, one in each of two >> namespaces. >> >> o Delegation Hierarchy: an abstract rooted tree (in the >> graph theory >> sense of the term) which is a virtual representation >> of the >> delegation of a namespace into smaller and smaller >> blocks, in a >> recursive process. >> >> o Node: The general term used to describe any sort of >> communicating >> entity; it might be a physical or a virtual host, or a >> mobile >> device of some sort. It includes both entities which >> forward >> packets, and entities which create or consume packets. >> >> o Switch, Packet Switch: A packet switch, in the general >> meaning of >> that term. A device which takes in packets from its >> interfaces >> and forwards them on, either to a next-hop switch, or >> to the final >> destination. They may operate at either the network >> layer (e.g. >> ARPANET), or internetwork layer. [Baran][Heart][RFC1812] >> >> o Endpoint, end-end communication entity: The >> fate-sharing region at >> one end of an end-end communication; the collection of >> state >> related to both the reliable end-end communication >> channel, and >> the applications running there. [Chiappa] >> >> o Address: In this document, in current IP (IPv4 or >> IPv6) and >> similar networking suites, a "name" which has mixed >> semantics, in >> that it includes both identity ('who') and location >> ('where') >> semantics. [Atkinson] >> >> >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 >> [Page 5] >> >> Internet-Draft LISP Introduction >> July 2014 >> >> >> o Address Block, Block: A contiguous section of a >> namespace (e.g., >> IP addresses that belong to the same prefix). >> >> o Identifier: a name which has identity semantics. >> >> o Locator: name with only location semantics and not >> necessarily >> carried in every packet [RFC1992]. >> >> o Site: A collection of hosts, routers, and networks >> under a single >> administrative control. >> >> o LISP site: a site separated from the rest of the >> network by LISP >> routers. >> >> o LISP node: A network element implementing LISP >> functionality; this >> means it can process some subset of LISP control and >> planes >> traffic. >> >> o LISP router: A network element implementing LISP >> data-plane >> functionality, i.e., a LISP node which can forward >> user traffic. >> >> o LISP host: A host which is behind (from the point of >> view of the >> rest of the network) a LISP router. >> >> 4. Background >> >> It has gradually been realized in the networking >> community that >> networks, especially large networks, should deal quite >> separately >> with the identity and location of an endpoint - >> basically, who an >> endpoint is, and where it is ([RFC1498] [RFC4984]). >> >> At the moment of this writing, in both IPv4 and IPv6, IP >> addresses >> indicate both where the named node is, as well as >> identify it for >> purposes of end-end communication; i.e. it has both >> location and >> identity properties. However, the separation of those >> two properties >> is a step which has been identified by the IRTF as a >> necessary >> evolutionary architectural step for the Internet >> [RFC6115] and the >> on-going LISP project is an attempt to provide a viable >> path towards >> this separation. >> >> As an add-on to a large existing system, it has had to >> make certain >> compromises. (For a good example, see >> [I-D.ietf-lisp-perspective], >> Section "Residual Location Functionality in EIDs". >> However, if it >> reaches near-ubiquitous deployment, it will have two >> important >> consequences. >> >> First, in effectively providing separation of location >> and identity, >> along with providing a distributed directory of the >> mappings between >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 >> [Page 6] >> >> Internet-Draft LISP Introduction >> July 2014 >> >> >> them, 'Wheeler's Law' ('All problems in computer science >> can be >> solved by another level of indirection') will come into >> play, and the >> Internet technical community will have a new, immensely >> powerful, >> tool at its disposal. The fact that the namespaces on >> both sides of >> the mapping are global ones maximizes the power of that >> tool. (See >> [I-D.ietf-lisp-perspective], Section "Need for a Mapping >> System", for >> more on this.) >> >> Second, because of a combination of the flexible >> capability built >> into LISP, and the breaking of the unification of >> location and >> identity names, further architectural evolution of the >> Internet >> becomes easily available; for example, new namespaces for >> location or >> identity could be designed and deployed. In other words, >> LISP is not >> a point solution to meet a particular need, but hopefully >> an 'escape >> hatch' which will allow further significant enhancement >> to the >> Internet's overall architecture. (See [Future] for more >> on this.) >> >> 5. Deployment Philosophy >> >> {{Suggestion by editors: Remove the entire section, it can be >> summarized by the last paragraph. Furthermore the >> arguments used in >> this sections are hard to follow since LISP has not been >> described >> yet.}} >> >> The deployment philosophy was a major driver for the >> design of LISP >> (architecture and engineering). >> >> Experience over the last several decades has shown that >> having a >> viable deployment model for a new design is a key to the >> adoption of >> the solution. In general, it is comparatively easy to >> conceive of >> new network designs, but much harder to devise approaches >> which will >> actually get deployed throughout the global network. A >> new design >> may be fantastic but if it can not be successfully >> deployed (for >> whatever factors), it is useless. >> >> LISP aims to achieve the near-ubiquitous deployment >> necessary for >> maximum exploitation of an architectural upgrade by i) >> minimizing the >> amount of change needed (most existing hosts and routers >> can operate >> unmodified); and ii) by providing significant benefits to >> early >> adopters. >> >> 5.1. Economics >> >> {{Suggestion by editors: Remove this section, this has >> not been >> discussed by the WG}} >> >> A key factor in successful adoption is economics: does >> the new design >> have benefits which outweigh its costs? >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 >> [Page 7] >> >> Internet-Draft LISP Introduction >> July 2014 >> >> >> More importantly, this balance needs to hold for early >> adopters - >> because if they do not receive benefits to their >> adoption, the sphere >> of earliest adopters will not expand, and it will never >> get to >> widespread deployment. >> >> This is particularly true of architectural enhancements, >> which are >> far less likely to be an addition which one can bolt onto >> the side of >> existing mechanisms, and often offer their greatest >> benefits only >> when widely (or ubiquitously) deployed. >> >> Maximizing the cost-benefit ratio obviously has two >> aspects. First, >> on the cost side, by making the design as inexpensive as >> possible, >> which means in part making the deployment as easy as >> possible. >> Second, on the benefit side, by providing many new >> capabilities, >> which is best done not by loading the design up with lots >> of features >> or options (which adds complexity), but by making the >> addition >> powerful through deeper flexibility. The LISP community >> believes >> LISP has met both of these goals. >> >> 5.2. Maximize Re-use of Existing Mechanism >> >> {{Suggestion by editors: Remove/Summarize the entire >> section, the >> arguments used in this section are hard to follow since >> LISP has not >> been described yet.}} >> >> >> Remove. This doc is not a guide to good protocol design. The >> concept that LISP is deployable incrementally should be mentioned >> in the document though, possibly with a reference to the >> deployment RFC. >> >> >> Agreed, we´ll include an (ultra-short) section describing the design >> principles of LISP, incremental deployment is of course one of them. >> >> >> One key part of reducing the cost of a new design is to >> minimize the >> amount of change required to existing, deployed, devices: >> the fewer >> devices need to be changed, and the smaller the change to >> those that >> do, the greater the likelihood of deployment. >> >> Designs which absolutely require forklift upgrades to >> large amounts >> of existing gear are far less likely to succeed - because >> they have >> to have extremely large benefits to make their very >> substantial costs >> worthwhile. >> >> It is for this reason that LISP, in most cases, initially >> requires no >> changes to almost all existing devices in the Internet >> (both hosts >> and routers); LISP functionality needs to be added in >> only a few >> places ( Section 15.1) >> >> 6. LISP Overview >> >> LISP is an incrementally deployable architectural upgrade >> to the >> existing Internet infrastructure, one which provides >> separation of >> location and identity. It thus starts to separate the >> names used for >> identity and location of nodes, which are currently >> unified in IP >> addresses. >> >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 >> [Page 8] >> >> Internet-Draft LISP Introduction >> July 2014 >> >> >> 6.1. Basic Approach >> >> {{Suggestion by editors: Merge this section with the >> previous one >> (LISP Overview)}} >> >> >> Agree: across the document, as done in the RFCs, I'd suggest to >> focus on describing the protocol architecture and how it works >> rather than on more generic considerations about the LISP philosophy. >> >> In LISP, the first key concept is that nodes have both an >> identifier >> called an Endpoint IDentifier (EID) and an associated >> Routing Locator >> (RLOC). A node may be associated with more than one >> RLOC, or the >> RLOC may change over time (e.g., if the node is mobile), >> but it would >> normally always have the same EID. >> >> The second key concept is that if one wants to be as >> forward-looking >> as possible, conceptually one should think of the two >> kinds of names >> (EIDs and RLOCs) as naming different classes of entities. >> >> On the one hand, EIDs are used to name nodes - or rather, >> their end- >> end communication entities. RLOC(s), on the other hand, name >> interfaces, i.e. places to which the system of routers >> sends packets. >> >> This distinction, the formal recognition of different >> kinds of >> entities ("endpoints" and interfaces), and their >> association with the >> two different classes of names, is also important. Clearly >> recognizing interfaces and endpoints as distinctly >> separate classes >> of objects is another improvement to the existing Internet >> architecture. >> >> An important insight in LISP is that it initially uses >> existing IP >> addresses for both of these kinds of names, as opposed to >> some >> similar earlier deployment proposals for separation of >> location and >> identity (e.g. [RFC1992]), which proposed using a new >> namespace for >> locators. This choice minimizes LISP's deployment cost, >> as well as >> providing the ability to easily interact with un-modified >> hosts and >> routers. >> >> The capability to use namespaces other than IP addresses >> for both >> kinds of names is already built in LISP, which is >> expected to greatly >> increase the long-term benefits, flexibility, and power >> of LISP >> ([AFI], [I-D.ietf-lisp-lcaf]). >> >> 6.2. Basic Functionality >> >> {{Suggestion by editors: Rewrite this section: It is >> using non- >> standard terminology to refer to standard LISP concepts >> ('enhance' >> instead of encapsulate) It is using subjective terms >> (e.g., 'near' >> the source) It is missing key LISP aspects such as that >> RLOC packets >> are forwarded in the RLOC space }} >> >> >> >> Make sure a figure with the basic elements of the protocol >> architecture (possibly similar to figure 1) is introduced as >> early as possible. >> >> >> >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 >> [Page 9] >> >> Internet-Draft LISP Introduction >> July 2014 >> >> >> The basic operation of LISP, as it currently stands, is >> quite simple. >> LISP augmented packet switches, "LISP routers", near the >> source and >> destination of packets intercept traffic, and 'enhance' >> the packets >> for the trip between the LISP switches. >> >> The LISP router near the original source (the Ingress >> Tunnel Router, >> or ITR ) looks up additional information about the >> destination of the >> packet, and then wraps the packet in an outer header, one >> which >> contains additional information related to LISP operation. >> >> The LISP router near the destination, the (the Egress >> Tunnel Router, >> or ETR) removes that header, leaving the original, >> un-modified, >> packet to be sent on to the original destination node. >> >> The overall processing is shown below, in Figure 1: >> >> >> /-----------------\ --- >> | Mapping | | >> . System | | Control >> -| |`, | Plane >> ,' \-----------------/ . | >> / \ --- >> ,.., - _,..--..,, `, ,.., | >> / ` ,' ,-` `', . / ` | >> / \ +-----+ ,' `, +--'--+ / >> \ | >> | EID |-| xTR |---/ RLOC ,---| xTR |-| EID | >> | Data >> | Space |-| |---| Space |---| |-| Space | >> | Plane >> \ / +-----+ . / +-----+ \ >> / | >> `. .' `. ,' `. .' >> | >> `'-` `., ,.' `'-` --- >> ``''--''`` >> LISP Site (Edge) Core LISP Site (Edge) >> >> Figure.- An schema of the LISP Architecture >> >> >> >> Figure 1: Basic LISP Packet Flow >> >> To retrieve that additional information, the ITR uses the >> information >> in the original packet about the identity of its ultimate >> destination, i.e. the destination EID address. It uses the >> destination EID to look up the current location (the >> RLOC) of that >> EID. >> >> The lookup is performed through a mapping system, which >> is the heart >> of LISP: it is a distributed directory of mappings from >> EIDs to >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 >> [Page 10] >> >> Internet-Draft LISP Introduction >> July 2014 >> >> >> RLOCs. The destination RLOC(s) is (are) normally the >> address(es) of >> the ETR(s) near the ultimate destination. >> >> The ITR then generates a new outer header for the >> original packet, >> with that header containing the ETR's RLOC as the wrapped >> packet's >> destination, and the ITR's own address (i.e. the RLOC usually >> associated with the original source) as the wrapped >> packet's source, >> and sends it off. >> >> When the packet arrives at the ETR, that outer header is >> stripped >> off, and the original packet is forwarded to the original >> ultimate >> destination for normal processing. >> >> Return traffic is handled similarly, often (depending on the >> network's configuration) with the original ITR and ETR >> switching >> roles. The ETR and ITR functionality is usually >> co-located in a >> single LISP router; these are normally denominated as xTRs. >> >> 6.3. Mapping from EIDs to RLOCs >> >> The mappings from EIDs to RLOCs are provided by a >> distributed, and >> potentially replicated, database, the "mapping database", >> which is >> the heart of LISP. Here, and in other places in LISP, the >> replication is not a deep architectural concept, simply an >> engineering device to obtain reliability via potential >> redundancy. >> >> Entities which need EID-to-RLOC mappings get them from >> the mapping >> system, which is a collection of sub-systems through >> which clients >> can find and obtain mappings as discussed in more details in >> Section 8.2 and Section 13. >> >> Mappings are normally distributed via a pull mechanism >> (i.e., not >> pre-loaded, but requested on demand). Once obtained by >> an ITR, they >> are cached for performance reasons. >> >> 6.4. Interworking With Non-LISP-Capable Endpoints >> >> It is clearly crucial to provide the capability for easy >> interoperation between "LISP hosts" - i.e. they are >> behind xTRs, and >> their EIDs are in the mapping database - and existing >> non-LISP-using >> hosts (often called 'legacy' hosts) or legacy "sites". >> >> To allow interoperation between devices hosted in a LISP >> site and >> devices not belonging to a LISP site (non-LISP site), an >> interworking >> mechanism based on proxies has been designed. Proxy ITRs >> (PITR) >> encapsulate packets sent from non-LISP sites to LISP >> sites while >> Proxy ETRs (PETR) decapsulate packets sent from LISP >> sites to non- >> LISP sites. More details are given in Section 15.2.1. >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 >> [Page 11] >> >> Internet-Draft LISP Introduction >> July 2014 >> >> >> 6.5. Security in LISP >> >> {{Suggestion by editors: Rewrite this section: (first 3 >> paragraphs) >> It contains a general discussion as well as strong >> statements that >> are not supported by any WG document. (last 3 paragraphs) It >> enumerates the security mechanisms specified in LISP but >> does not >> describe them.}} >> >> >> Agree. I think that the security considerations section of >> RFC6830 may provide a guide to the items you may want to touch in >> this document. Point the reader to the RFCs when possible. Move >> broader security considerations to the Security Section >> referencing lisp-threats where needed. >> >> >> Agreed. >> >> >> To provide a brief overview of security in LISP, it is >> definitely >> understood that LISP needs to be highly _securable_, >> especially in >> the long term; over time, the attacks mounted by 'bad >> guys' are >> becoming more and more sophisticated. So LISP, like DNS, >> needs to be >> _capable_ of providing 'the very best' security there is. >> >> At the same time, there is a conflicting goal: it must be >> deployable >> at a a viable cost. That means two things: First, as an >> experiment, >> we cannot expect to create the complete security >> apparatus which we >> might see in the finished product, including both design and >> implementation. Second, security needs to be flexible, >> so that we >> don't overload the users with more security than they >> need at any >> point. >> >> To accomplish these divergent goals, the approach taken >> is to first >> analyze what LISP needs for security. >> [I-D.ietf-lisp-threats]. >> Then, steps can be taken to ensure that the appropriate >> 'hooks' (such >> as packet fields) are included at an early stage, when >> doing so is >> still easy. Over time, additional mechanisms will be fully >> specified, implemented, and deployed. >> >> LISP does already include a number of security mechanisms; in >> particular, requesting mappings can be secured (see >> Section 12.8, >> "Security of Mapping Lookups"), as can registering of >> xTRs (see >> Section 13.1.3, "Map-Register and Map-Notify Messages"); >> the key >> database of the mapping system is also secured (see >> Section 13.4, >> "Security of the DDT Indexing Sub-system"). >> >> The existing security mechanisms, and their configuration >> (which is >> mostly manual at this point) currently in LISP are felt to be >> adequate for the needs of the on-going early stages of >> deployment; >> experience will indicate when improvements are required >> (within the >> constraints of the conflicting goal given above). >> >> For more on LISP's security philosophy; see >> [I-D.ietf-lisp-perspective], Section 7 "Security", where >> it is laid >> out in some detail. >> >> >> >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 >> [Page 12] >> >> Internet-Draft LISP Introduction >> July 2014 >> >> >> 7. Initial Applications >> >> {{Suggested by editors: Move this section after section >> 8, the >> applications should not be described before LISP has been >> fully >> described. >> >> {{Suggested by Noel: Reorder the whole section in >> popularity order?}} >> >> As previously mentioned, it is felt that LISP will >> provide even the >> earliest adopters with some useful capabilities, and that >> these >> capabilities will drive early LISP deployment. >> >> It is very imporant to note that even when used only for >> interoperation with existing un-modified hosts, use of >> LISP can still >> provide benefits to the site which has deployed it - and, >> perhaps >> even more importantly, can do so to both sides. This >> characteristic >> acts to further enhance the utility for early adopters of >> LISP. >> >> Note also that this section only lists some early >> applications and >> benefits. See [I-D.ietf-lisp-perspective], in the >> Section "Goals of >> LISP", for a more extensive discussion of some of what >> LISP might >> ultimately provide. >> >> 7.1. Provider Independence >> >> Provider independence (i.e. the ability to easily change >> one's >> Internet Service Provider) is a good example of the >> utility of >> separating location and identity. >> >> To limit global routing table size addresses need to be >> aggregated. >> To that aim networks can use provider aggregatable addresses >> ([RFC4116]) which means that the IP prefixes of networks >> are sub- >> prefixes of their provider. This solutions allows to reduce >> scalability issues of the global routing table but it >> means that when >> a network switches providers it has to re-number all its >> devices >> which is known to be complex in current networks [RFC5887]. >> >> Having separate namespaces for location and identity >> greatly reduces >> the problems involved with re-numbering; an organization >> which moves >> retains its EIDs (which are how most other parties refer >> to its >> nodes), but is allocated new RLOCs, and the mapping >> system can >> quickly provide the updated mapping from the EIDs to the >> new RLOCs. >> >> 7.2. Multi-Homing >> >> {{Suggested by editors: This section should be extended, >> it is >> unclear the benefits that LISP brings to multihoming >> (.e.g, traffic >> engineering, decoupled multihoming from the data-plane). >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 >> [Page 13] >> >> Internet-Draft LISP Introduction >> July 2014 >> >> >> Multi-homing is another place where the value of >> separation of >> location and identity became apparent. There are several >> different >> sub-flavours of the multi-homing problem - e.g. depending >> on whether >> one wants open TCP connections to keep working, etc - and >> other axes >> as well (e.g. site multi-homing versus host multi-homing). >> >> In particular, for the 'keep open connections up' case, >> without >> separation of location and identity, with most currently >> deployed >> implementations, the only currently feasible approach is >> to use >> provider-independent addressses - which moves the problem >> into the >> global routing system, with attendant costs. This >> approach is also >> not really feasible for host multi-homing. >> >> 7.3. Traffic Engineering >> >> {{Suggestion by editors: Merge this section with the >> previous one, TE >> is not practical without multihoming}} >> >> {{Needs a fix - not sure what.}} >> >> Traffic engineering (TE) [RFC3272], desirable though this >> capability >> is in a global network, is currently somewhat problematic >> to provide >> in the Internet. The problem, fundamentally, is that >> this capability >> was not forseen when the Internet was designed, so the >> support for it >> via hacks is neither clean, nor flexible. >> >> TE is, fundamentally, a routing issue. However, the >> current Internet >> routing architecture, which is basically the Baran design >> of fifty >> years ago [Baran] (a single large, distributed >> computation), is ill- >> suited to provide TE. The Internet seems a long way from >> adopting a >> more-advanced routing architecture, although the basic >> concepts for >> such have been known for some time. [RFC1992] >> >> Although the identity-location mapping layer is thus a >> poor place, >> architecturally, to provide TE capabilities, it is still an >> improvement over the current routing tools available for >> this purpose >> (e.g. injection of more-specific routes into the global >> routing >> table). >> >> In addition, instead of the entire network incurring the >> costs >> (through the routing system overhead), when using a >> mapping layer to >> provide TE, the overhead is limited to those who are actually >> communicating with that particular destination. >> >> LISP includes a number of features in the mapping system >> to support >> TE. (described in Section 8.2, "Control Plane - Mapping >> System >> Overview", below); more details about using LISP for TE >> can be found >> in [I-D.farinacci-lisp-te]. >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 >> [Page 14] >> >> Internet-Draft LISP Introduction >> July 2014 >> >> >> Also, a number of academic papers have explored how LISP >> can be used >> to do TE, and how effective it can be. See the online LISP >> Bibliography ([Bibliography]) for information about them. >> >> 7.4. Routing >> >> {{Suggestion by editors: Remove this section, LISP is not >> a routing >> protocol.}} >> >> Multi-homing and Traffic Engineering are both, in some >> sense, uses of >> LISP for routing, but there are many other >> routing-related uses for >> LISP. >> >> One of the major original motivations for the separation >> of location >> and identity in general, and thus LISP, was to reduce the >> growth of >> the routing tables in the "Internet core", the part where >> routes to >> _all_ ultimate destinations must be available. LISP is >> expected to >> help with this; for more detail, see Section 15.4, "LISP >> and Core >> Internet Routing", below. >> >> LISP may also have more local applications in which it >> can help with >> routing; see, for instance, [CorasBGP]. >> >> 7.5. Mobility >> >> {{Suggestion by editors: Remove this section, mobility is >> not in >> charter.}} >> >> Mobility is yet another place where separation of >> location and >> identity is a key part of a clean, efficient and >> high-functionality >> solution. Considerable experimentation has been >> completed on doing >> mobility with LISP. >> >> The mobility provided by LISP allows active sessions to >> survive moves >> (provided of course that there is not a period of >> inaccessibility >> which exceeds a timeout). LISP mobility also will >> typically have >> better packet stretch (i.e. increase in path length) >> compared to >> traditional mobility schemes, which use a home agent. >> >> 7.6. Traversal Across Alternate IP Versions >> >> Note that LISP inherently supports intermixing of various >> IP versions >> for packet carriage; IPv4 packets might well be carried >> in IPv6, or >> vice versa, depending on the network's configuration. >> >> This capability allows an island of operation of one type >> to be >> automatically tunneled over a stretch of infrastucture >> which only >> supports the other type. >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 >> [Page 15] >> >> Internet-Draft LISP Introduction >> July 2014 >> >> >> 7.7. Virtual Private Networks >> >> {{Suggestion by editors: Remove this section, not covered >> by any WG >> document}} >> >> L2 and L3 {{Need to add text here - This used to be part >> of 'Local' >> below, but we decided this was so important it deserved >> its own >> section. Maybe move this up further, as it seems to be >> the most >> important 'early adopter' application?}} >> >> The mapping-and-encapsulation nature of LISP makes it a >> perfect >> candidate for VPN solutions. In this case, private parts >> of the VPN >> form LISP sites and the IP addresses of devices in the >> private parts >> are composing EID spaces. The interconnection between >> the LISP sites >> is the public network and IP addresses in the >> interconnection compose >> the RLOC space. A major advantage of using LISP to >> construct VPN >> resides in the simplicity of the configurations: each xTR >> (i.e., VPN >> end) is configured to query the mapping system to >> retrieve mappings >> making the glue between the public (RLOC space) and the >> private (EID >> space) of the VPN. >> >> This includes support of multi-tenancy where several >> private networks >> can be carried over the same underlayer network. Thanks >> to the >> instance-id field, multi-tenant network can even use the >> exact same >> addresses as the xTR distinguishes the tenant based on >> the value of >> the instance-id. The multiple address family support in LISP >> mappings also allows to build private networks using a >> different >> addressing family than the carrier (e.g., IPv6 over IPv4). >> >> 7.8. Local Uses >> >> {{Suggestion by editors: Remove this section. The >> section contains a >> general discussion about the applicability of LISP in >> intra-domain >> scenarios, however it does not describe any specific >> application.}} >> >> LISP has a number of use cases which are within purely >> organizationally-local contexts, i.e. not in the larger >> Internet. >> These fall into two categories: uses seen on the Internet >> (above), >> but here on a private (and usually small scale) setting; and >> applications which do not have a direct analog in the larger >> Internet, and which apply only to local deployments. >> >> Among the former are multi-homing and IP version >> traversal. {{This >> was marked to be deleted - why? The next part doesn't >> make sense >> without this first?}} >> >> Among the latter class, non-Internet applications which >> have no >> analog on the Internet, are the following example >> applications: >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 >> [Page 16] >> >> Internet-Draft LISP Introduction >> July 2014 >> >> >> virtual machine mobility in data centers; non-IP EID >> types such as L2 >> MAC addresses, or application specific data. >> >> Several of the applications listed in this section are >> the ones which >> have been most popular for LISP in practise; these >> include virtual >> networks, and virtual machine mobility. >> >> These often show a synergistic tendency, in that a site which >> installs LISP to do one, often finds that then becomes a >> small matter >> to use it for the second. Given all the things which >> LISP can do, it >> is hoped that this synergistic effect will continue to >> expand LISP's >> uses. >> >> {{Preceeding paragraphs should probably get moved up into VPN >> section?}} >> >> 8. Major Functional Subsystems >> >> {{Suggestion by editors: This section should appear >> before since it >> describes key aspects of LISP (e.g., LISP decoupled >> control and data- >> plane).}} >> >> >> Yes, possibly where the first figure is. >> >> LISP has two major functional sub-systems: the xTRs which >> form the >> data-plane of LISP; and the mapping system which forms >> the control >> plane that maintains and distributes the mapping database. >> >> The purpose and operation of each is described at a high >> level below, >> and then, later on, in a fair amount of detail, in >> separate sections >> on each (Section 12 and Section 13). >> >> 8.1. Data Plane - xTRs Overview >> >> {{Suggestion by editors: Extend this section, it misses >> key LISP >> data-plane aspects, such as the map-cache.}} >> >> xTRs are routers that have been augmented with extra >> functionality in >> both the data and control planes. The data plane >> functions in ITRs >> include deciding which packets need to be given LISP >> processing >> (since packets to non-LISP hosts may be sent as they >> are); i.e. >> looking up the mapping; encapsulating (wrapping) the >> packet; and >> sending it to the ETR. >> >> This encapsulation is done using UDP [RFC0768], along with an >> additional outer IP header (to hold the source and >> destination >> RLOCs). To the extent that traffic engineering features >> are in use >> for a particular EID, the ITRs implement them as well. >> >> >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 >> [Page 17] >> >> Internet-Draft LISP Introduction >> July 2014 >> >> >> In the ETR, the data plane simply decapsulates (unwraps) >> the packets, >> and forwards the it to the destination. >> >> Control plane functions in ITRs include: asking for >> EID-to-RLOC >> mappings via Map-Request packets; handling the returning >> reply >> control messages (i.e., Map-Reply packets), which contain >> the EID-to- >> RLOC mapping; managing the local mapping cache and >> checking for the >> reachability of destination ETR's RLOCs. >> >> In the ETR, control plane functions include participating >> in the >> reachability tests (see Section 16.4); interacting with >> the mapping >> sub-system to let it know what mapping this ETR can >> provide (see >> Section 8.2.2); and answering Map-Request packets from >> ITRs for those >> mappings. >> >> 8.1.1. Mapping Cache Performance >> >> {{Suggestion by editors: Push this section further in the >> document, >> the cache performance is not a "Major LISP subsystem"}} >> >> As mentioned, studies have been performed to verify that >> caching >> mappings in ITRs is viable, in practical engineering >> terms. These >> studies not only verified that such caching is feasible, >> but also >> provided some insight for designing ITR "mapping caches". >> >> Briefly, they took lengthy traces of all packets leaving >> a large >> site, over a period of a week or so, and used those to drive >> simulations which showed how many mappings would be >> required. It >> also allowed analysis of how much control traffic (for >> loading needed >> mappings) would result, using various cache sizes and >> replacement >> algorithms. These studies provide an insight into how >> well LISP can >> be expected to perform, and scale, over time. >> >> A more extended look at the results us given below, in >> Section 12.9, >> "xTR Mapping Cache Performance". >> >> 8.2. Control Plane - Mapping System Overview >> >> {{Suggestion by editors: Rewrite: Replace EID block >> terminology >> (along with its description) with the very common term >> "prefix". >> Describe Map-Request/Map-Reply LISP signaling messages.}} >> >> The mapping system's entire purpose is to give ITRs >> on-demand access >> to the mapping database, which is a distributed, and >> potentially >> replicated, database which holds mappings between EIDs >> (identity) and >> RLOCs (location), along with needed ancillary data (e.g. >> lifetimes). >> >> >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 >> [Page 18] >> >> Internet-Draft LISP Introduction >> July 2014 >> >> >> To be exact, it contains mappings between EID blocks and >> RLOCs (the >> block size is given explicitly, as part of the syntax). >> Support for >> blocks is both for minimizing the administrative >> configuration >> overhead, as well as for operational efficiency; e.g. >> when a group of >> EIDs are behind a single xTR. In IP blocks are delimited >> by their IP >> prefix. >> >> However, the block may be, and sometimes is, as small as >> a single >> EID. However, since mappings are only loaded upon >> demand, if smaller >> blocks become predominant, then the increased size of the >> overall >> database is far less problematic than if the Internet's >> routing >> tables came to be dominated by such small entries. >> >> A particular EID (or EID block) may be associated to than >> one RLOC, >> and may change the association with time. >> >> Also, in general, throughout LISP, the address family of >> EIDs and >> RLOCs is explicitly mentioned in control packet. >> >> Finally, the mapping from an EID (or EID block) contains >> not just the >> RLOC(s), but also (for each RLOC for any given EID entry) >> priority >> and weight fields (to allow allocation of load between >> several RLOCs >> at a given priority); this allows a certain amount of traffic >> engineering to be accomplished with LISP. >> >> 8.2.1. Mapping System Organization >> >> {{Suggestion by editors: Rewrite: Describe key Mapping System >> components: Map-Server/Map-Resolver}} >> >> The mapping system is split into three functional >> sub-systems. >> >> The first is the actual mappings themselves, collectively >> the mapping >> database; they are held by the ETRs, and an ITR which >> needs a mapping >> gets it (effectively) directly from the ETR. This >> co-location of the >> authoritative version of the mappings, and the forwarding >> functionality which it describes, is an instance of >> fate-sharing. >> [Clark] >> >> To find the appropriate ETR(s) to query for the mapping, >> the second >> two sub-systems form an indexing system, itself also >> based on a >> distributed, potentially replicated database. It provides >> information on which ETR(s) are authoritative sources for >> the various >> EID-to-RLOC mappings which are available. The two >> sub-systems which >> form it are the client interface sub-system, and indexing >> sub-system >> (which holds and provides the actual information). >> >> >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 >> [Page 19] >> >> Internet-Draft LISP Introduction >> July 2014 >> >> >> 8.2.2. Interface to the Mapping System >> >> {{Suggestion by editors: has been rewritten: This section >> should >> appear earlier since it describes key LISP components >> (Map-Request/ >> Map-Reply/Map-Server/Map-Resolver}} >> >> The client interface to the indexing system from an ITR's >> point of >> view is not with the indexing sub-system directly; >> rather, it is >> through the Map-Resolvers (MRs) and Map-Servers (MSs). >> >> To obtain the mapping for an EID, the ITRs sends >> Map-Request packet >> to an MR. The MR then uses the indexing sub-system to >> allow it to >> forward the Map-Request to an appropriate Map-Server >> (MS), which in >> turn sends the Map-Request on to the appropriate ETR. >> The latter is >> authoritative for the actual mappings for the EID. >> >> The ETR then sends the mappings for that EID in the form >> of aMap- >> Reply packets, which is sent directly to the ITR, without >> passing >> through the indexing sub-system and MR. The details of >> the indexing >> sub-system are thus hidden from the ITRs. >> >> Note that in proxy mode, the MS replies on behalf of the >> ETR. When >> this the case, the map-replies is tagged to indicate that >> the answer >> is not delivered from the authoritative ETR but from the >> MS instead. >> >> The interface to the indexing system from an ETR's point >> of view is >> made through MSes. ETRs send Map-Register packets to their >> designated MSes. The effect of a Map-Register is to >> inform the MS >> about the mappings maintained by ETRs such that the MS >> can transmit >> the Map-Requests is receives to the appropriate ETRs. >> >> The MS optionally replies Map-Register packets with a >> Map-Notify >> packet to confirm the registration. The details of the >> indexing sub- >> system are thus likewise hidden from ETRs. >> >> The fact that the details of the indexing sub-system are >> entirely >> hidden from xTRs gives considerably flexibility to this >> aspect of >> LISP. As long as any potential indexing sub-system can >> track where >> mappings are, it could potentially be used; this would >> allow the >> actual indexing sub-system to be replaced without needing >> to modify >> the xTRs. >> >> 8.2.3. Indexing Sub-system >> >> {{suggestion by editor: rename the section to "DDT"}} >> >> >> >> >> I think this section should briefly describe both ALT (mostly by >> reference to RFC 6836) and DDT (by reference to LISP-DDT, with >> way fewer details on DDT than in the current document). "Indexing >> System" (as a component of the mapping system, together with the >> mapping database) may be a good name for this section. >> >> >> "Index subsystem" is not a term used in ALT or DDT. What about >> "Mapping Database"? >> >> >> The current indexing sub-system is the Delegated Database >> Tree (DDT), >> which is conceptually similar to DNS ([I-D.ietf-lisp-ddt], >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 >> [Page 20] >> >> Internet-Draft LISP Introduction >> July 2014 >> >> >> [RFC1034]). DDT replaces the earlier LISP+ALT indexing >> sub-system >> ([RFC6836]). The seamless migration to DDT while >> LISP+ALT was >> previously used validated the concept of having a >> client-interface >> sub-system between the indexing sub-system, and the clients. >> >> 8.2.3.1. DDT Overview >> >> Conceptually, DDT is similar to the DNS, in DDT the >> delegation of the >> EID namespace is instantiated as a delegation hierarchy, >> a tree of >> DDT nodes, starting with the root DDT node. Each vertex is >> responsible for a block of the EID namespace. >> >> The root node is responsible for the entire EID space; >> any DDT node >> can delegate part(s) of its EID block to child DDT >> node(s). The >> child node(s) can in turn further delegate (necessarily >> smaller) >> blocks of namespace to their children, through as many >> levels as are >> needed (for operational, administrative, etc, needs). >> >> Just as with DNS, any particular vertex in the DDT >> delegation tree >> may be instantiated in one or more DDT servers. Multiple >> (redundant) >> servers for a given node would be used for reasons of >> performance, >> reliability, and robustness. Obviously, all the servers >> which >> instantiate a particular nodes in the tree have to have >> identical >> data about that node. >> >> 8.2.3.2. Use of DDT by MRs >> >> An MR which wants to find a mapping for a particular EID >> first >> interacts with the DDT servers which instantiate the >> nodes of the >> LISP delegation hierarchy tree, discovering (by querying >> the servers >> for information about DDT nodes) the chain of delegations >> which cover >> that EID. Eventually it is directed to an MS, which is >> servicing an >> ETR which is authoritative for that EID. >> >> Also, again like DNS, MRs may cache information they >> receive about >> the delegations in the delegation tree. This means that >> once an MR >> has been in operation for a while, it will usually have >> much of the >> delegation information cached locally (especially the top >> levels of >> the delegation tree). This allows them, when passed a >> request for a >> mapping by an ITR, to usually forward the mapping request >> to the >> appropriate MS without having to interact with all the >> DDT servers on >> the path down the delegation tree, in order to find any >> particular >> mapping. >> >> Thus, a typical resolution cycle would usually involve >> looking at >> some locally cached delegation information, perhaps >> loading some >> missing delegation entries into their delegation cache, >> and finally >> sending the Map-Request to the appropriate MS. >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 >> [Page 21] >> >> Internet-Draft LISP Introduction >> July 2014 >> >> >> It should also be noted that the delegation tree is >> fairly static, >> since it reflects EID block allocations, which are >> themselves fairly >> static. This stability has several important >> consequences. First, >> it increases the performance of the mapping system, since >> the sub- >> system almost never needs to be re-queried for >> information about >> intermediate vertices. {{comment from editor: does not >> understand >> the next sentence...}}Second, it is not necessary to >> include a >> mechanism to find out-dated delegations. [LISP-TREE] >> >> This contrasts with the mappings, which may change at a >> high rate - >> changes which have no impact on the indexing sub-system. The >> potentially high dynamics of mappings explains why >> mappings are >> delivered directly from ETRs (or MSes in proxy mode) to >> ITRs and >> hence not cached at the MR level. LISP is designed to >> make sure that >> changes in the mappings are detected and acted upon >> fairly quickly; >> this allows LISP to provide a number of capabilities, such as >> mobility. >> >> 9. Examples of operation >> >> To aid in comprehension, a few examples are given of user >> packets >> traversing the LISP system. The first shows the >> processing of a >> typical user packet which is LISP forwarded, i.e. what >> the vast >> majority of user packets will see. The second shows what >> happens >> when the first packet to a previously-unseen ultimate >> destination (at >> a particular ITR) is to be processed by LISP. >> >> 9.1. An Ordinary Packet's Processing >> >> {{Suggestion by editors: This section should be earlier >> in the >> document structure, examples are important -particularly for >> engineers- to explain how systems work}} >> >> This case follows the processing of a typical , {{comment >> from >> editors: text missing}} when the packet has made its way >> through the >> local site to an ITR, which in this case is a border >> router for the >> site, the border router looks up the destination address >> - an EID - >> in its local mapping cache. For EIDs which are IP >> addresses, this >> lookup uses the IP longest prefix matching algorithm. >> >> It finds a mapping, which instructs it to wrap the packet >> in an outer >> header - an IP packet, containing a UDP packet which >> contains a LISP >> header - and then the user's original packet (see Section >> 12.2 for >> the reasons for this particular choice). The destination >> address in >> the outer header is set by the ITR to the RLOC of the >> destination >> ETR. >> >> >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 >> [Page 22] >> >> Internet-Draft LISP Introduction >> July 2014 >> >> >> The encapsulated packet is then sent off through the RLOC >> space >> (e.g., Internet), using normal Internet routing. >> >> On arrival at the destination ETR, the ETR will notice >> that it is >> listed as the destination in the outer header. It will >> examine the >> packet, detect that it is a LISP packet, and unwrap it. >> It will then >> examine the header of the user's original packet, and >> forward it >> internally, through the local site, to the ultimate >> destination. >> >> At the ultimate destination, the packet will be >> processed, and may >> produce a return packet, which follows the exact same >> process in >> reverse - with the exception that the roles of the ITR >> and ETR are >> swapped. >> >> 9.2. A Mapping Cache Miss >> >> {{Suggestion by editors: (same as previous section)}} >> >> If a host sends a packet, and it gets to the ITR, and the ITR >> determines that it does not yet have a mapping cache >> entry which >> covers that destination EID, then additional processing >> ensues; it >> has to look up the mapping in the mapping system (as >> previously >> described in Section 6.2). >> >> The overall processing is shown below, in Figure 2: >> >> ----- ----- >> | | 3 | | >> Map Resolver | | -------> | | Map Server >> | | | | >> ----- ----- >> ^ | >> Key: | | >> | | >> -- = Control | | >> == = Data | | >> 2 | 5 | 4 >> | --- | >> Host A | / \ | Host B >> | |_ \ V >> ----- ----- \ ----- ----- >> | | 1 | | 6 | | 7 | | >> | | =====> | ITR | =======> | ETR | =====> | | >> | | | | | | | | >> ----- ----- ----- ----- >> >> Figure 2: Packet flow with missing mapping >> >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 >> [Page 23] >> >> Internet-Draft LISP Introduction >> July 2014 >> >> >> 1. Source-EID sends packet (to Dest-EID) to ITR >> >> 2. ITR sends Map-Request to Map-Resolver >> >> 3. Map-Resolver delivers Map-Request to Map-Server >> >> 4. Map-Server delivers Map-Request to ETR >> >> 5. ETR returns Map-Reply to ITR; ITR caches >> EID-to-RLOC(s) mapping >> >> 6. ITR uses mapping to encapsulate to ETR; sends user >> packet to ETR >> >> 7. ETR decapsulates packet, delivers to Dest-EID >> >> The ITR first sends a Map-Request packet, giving the >> destination EID >> it needs a mapping for, to its MR. The MR will look in >> its cache of >> delegation information to find the vertex which is the >> most specific >> in the delegation tree for that destination EID . If it >> does not >> have the address of an appropriate MS, it will query the >> DDT system, >> recursively if need be, in order to eventually find the >> address of >> such an MS. >> >> When it has the MS's address, it will send the >> Map-Request on to the >> MS, which then usually sends it on to an appropriate ETR. >> The ETR >> sends a Map-Reply to the ITR which needs the mapping; >> from then on, >> processing of user packets through that ITR to that ultimate >> destination proceeds as above. >> >> To the best of our knowledge, in all LISP >> implementations, the >> original user packet will have been discarded, and not >> queued waiting >> for the mapping to be returned. When the host >> retransmits such a >> packet, the mapping will be there, and the packet will be >> forwarded. >> Alternatively, it might have been forwarded using a PITR >> to avoid >> being dropped (Section 6.4). >> >> 10. Part II >> >> {{comment from editors: is that the role of an >> introductory document >> to enter in such level of details and discuss (mostly) >> all fields of >> the protocol? }} >> >> >> No. >> It should just describe the architecture of the entire LISP >> system, making it easier to read the rest of the LISP >> specifications and providing a *basis* for discussion about the >> details of the LISP protocols. >> >> >> 11. Design Approach >> >> {{Suggestion by editors: Remove this section, it does not >> describe/ >> discuss anything relevant, it is only providing a >> reference to >> another non-WG document.}} >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 >> [Page 24] >> >> Internet-Draft LISP Introduction >> July 2014 >> >> >> Before describing LISP's components in more detail below, >> it it worth >> pointing out that what may seem, in some cases, like odd >> (or poor) >> design approaches do in fact result from the application of a >> thought-through, and consistent, design philosophy used >> in creating >> them. {{Subjective: maybe JMH, Dino can help with better >> words?}} >> >> This design philosophy is covered in detail in >> [I-D.ietf-lisp-perspective], Section "Design"), and >> readers who are >> interested in the 'why' of various mechanisms should >> consult that; >> reading it may make clearer the reasons for some >> engineering choices >> in the mechanisms given here. >> >> 12. xTRs >> >> As mentioned above (in Section 8.1), xTRs are the >> essential LISP data >> plane elements. This section explores some advanced >> topics related >> to xTRs. >> >> {{Suggestion by editors: remove next paragraph, brings >> nothing)}} >> >> Careful rules have been specified for both TTL and ECN >> [RFC3168] to >> ensure that passage through xTRs does not interfere with the >> operation of these mechanisms. In addition, care has >> been taken to >> ensure that traceroute works when xTRs are involved. >> >> 12.1. When to Encapsulate >> >> An ITR knows that an ultimate destination is running LISP >> (remember >> that the actual destination machine itself probably knows >> nothing >> about LISP), and thus that it should perform LISP >> processing on a >> packet (including potential encapsulation) if it has an >> entry in its >> local mapping cache that covers the destination address >> (it is then >> called an EID). >> >> Conversely, if the cache contains a negative entry >> (indicating that >> the ITR has previously attempted to find a mapping that >> covers this >> EID, and it has been informed by the mapping system that >> no such >> mapping exists), it knows the ultimate destination is not >> running >> LISP, and the packet can be forwarded natively (i.e. not >> LISP- >> encapsulated). >> >> Note that the ITR cannot simply depend on the appearance, >> or non- >> appearance, of the destination in the routing tables in >> the Internet >> core, as a way to tell if a destination is a LISP node or >> not. That >> is because mechanisms to allow interoperation of LISP >> sites and >> legacy sites necessarily involve advertising LISP sites' >> EIDs into >> the Internet core; in other words, LISP sites which need to >> >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 >> [Page 25] >> >> Internet-Draft LISP Introduction >> July 2014 >> >> >> interoperate with legacy nodes will appear in the >> Internet core >> routing tables, along with non-LISP sites. >> >> 12.2. UDP Encapsulation Details >> >> Use of UDP (instead of, say, a LISP-specific protocol >> number) was >> driven by the fact that many routers and middle boxes >> filter out >> unknown protocols, so adopting a non-UDP encapsulation >> would have >> compromised the initial deployment of LISP. >> >> The UDP source port used for encapsulating packet is >> computed with a >> 5-way hash of the original source and destination in the >> inner >> header, along with the ports, and the protocol. This is >> because many >> ISPs use multiple parallel paths (so-called Equal Cost >> Multi-Path), >> and load-share across them. Using such a hash in the >> source-port in >> the outer header both allows LISP traffic to be >> load-shared, and also >> ensures that packets from individual connections are >> delivered in >> order (since most ISPs try to ensure that packets for a >> particular >> flow follow a single path, and hence do not become >> disordered). >> >> The UDP checksum is zero because the inner packet usually >> already has >> a end-end checksum, and the outer checksum adds no value >> ([Saltzer]). >> {{Suggestion by editors: not sure that next statement is >> correct}} In >> most exising hardware, computing such a checksum (and >> checking it at >> the other end) would also present a major load, for no >> benefit. >> >> 12.3. Header Control Channel >> >> {{Suggestion by editors: Rewrite this section to improve >> readability, >> use standard terminology (e.g., Cache >> Coherence/Reachability instead >> of "Header Control Channel"). Split the mechanisms >> depending on its >> goal (cache coherence/reachability) and describe them >> under the same >> context.}} >> >> LISP provides a multiplexed channel in the encapsulation >> header. It >> is mostly (but not entirely) used for control purposes. >> The general >> concept is that the header starts with a flags field, and >> it also >> includes two data fields, the contents and meaning of >> which vary, >> depending on which flags are set. This allows these >> fields to be >> multiplexed among a number of different low-duty-cycle >> functions, >> while minimizing the space overhead of the LISP. >> >> 12.3.1. Mapping Versioning >> >> One important use of the multiplexed control channel is >> mapping >> versioning; i.e. the discovery of when the mapping cached >> in an ITR >> is outdated. To allow an ITR to discover this, >> identifying sequence >> numbers are applied to different versions of a mappping >> [RFC6834]. >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 >> [Page 26] >> >> Internet-Draft LISP Introduction >> July 2014 >> >> >> This allows an ITR to easily discover when a cached >> mapping has been >> updated by a more recent variant. >> >> Version numbers are available in control messages >> (Map-Replies), but >> the initial concept is that to limit control message >> overhead, the >> versioning mechanism should primarily use the multiplexed >> user data >> header control channel. >> >> Versioning can operate in both directions: an ITR can >> advise an ETR >> what version of a mapping it is currently using (so the >> ETR can >> notify it if there is a more recent version), and ETRs >> can let ITRs >> know what the current mapping version is (so the ITRs can >> request an >> update, if their copy is outdated). >> >> 12.3.2. Echo Nonces >> >> Another important use of the header control channel is for a >> mechanism known as the Nonce Echo, which is used as an >> efficient >> method for ITRs to check the reachability of neighbour ETRs. >> >> Basically, an ITR which has to determine that an ETR is >> up, and >> reachable, sends a nonce to that ETR, carried in the >> encapsulation >> header; when that ETR (also acting as an ITR) sends some >> other user >> data packet back to the ITR (acting in turn as an ETR), >> that nonce is >> carried in the header of that packet, allowing the >> original ITR to >> confirm that its packets are reaching that ETR. >> >> Note that a lack of a response is not necessarily proof that >> something has gone wrong - but it strongly suggests that >> something >> has, so other actions (e.g. a switch to an alternative >> ETR, if one is >> listed; a direct probe; etc) are advised. (See Section >> 16.5 for more >> about Echo Nonces.) >> >> 12.3.3. Instances >> >> {{Suggestion by editors: Move and extend this section: - >> Instance ID >> is not a cache-coherence/reachability algorithm. >> Describe where and >> what is the Instance ID field Explain its applications}} >> >> The LISP data-plane header is also used to support VPN >> and multi- >> tenant networks. Since there is only one destination UDP >> port used >> for carriage of user data packets, and the source port is >> used for >> multiplexing, there is no other way to differentiate >> among different >> destination EID spaces (which are often overlapped in >> VPNs and multi- >> tenant networks). >> >> >> >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 >> [Page 27] >> >> Internet-Draft LISP Introduction >> July 2014 >> >> >> 12.4. Probing >> >> RLOC-Probing is a mechanism method that an ITR can use to >> determine >> with that an ETR is up and reachable from the ITR. As a >> side- >> benefit, it gives RTT estimates. >> >> To probe the reachability of an RLOC, an ITR sends a >> specially marked >> Map-Request directly to the ETR it wishes information >> about; that ETR >> sends back a specially marked Map-Reply. A Map-Request >> message and a >> Map-Reply message are used, rather than a special probing >> control- >> message pair, because as a side-benefit the ITR can >> discover if the >> mapping has been updated since it cached it. >> >> {{Suggestion from editors: remove the following sentence >> as it is not >> motivated by strong arguments}} The probing mechanism is >> rather >> heavy-weight and expensive (compared to mechanisms like >> the Echo- >> Nonce), since it costs a control message from each side, >> so it should >> only be used sparingly. >> >> If the number of active neighbour ETRs of the ITR is >> large, use of >> RLOC-Probing to check on their reachability will result in >> considerable control traffic; such control traffic has to >> be spread >> out to prevent a load peak. >> >> Obviously, if RLOC-Probing is the only mechanism being >> used to detect >> unreachable neighbour ETRs, the rate at which >> RLOC-Probing is done >> will control the timeliness of the detection of loss of >> reachability. >> There is thus a tradeoff between overhead and responsiveness, >> particular when an ITR has a large fanout of neighbour ETRs. >> >> 12.5. Mapping Lifetimes and Timeouts >> >> {{Suggestion by editors: Remove this section, TTL is a >> simple well- >> known concept, we suggest to include a sentence (and >> hence remove >> this section) in the control-plane section stating that >> mappings >> include a TTL. >> >> Mappings come with a Time-To-Live, which indicate how >> long the >> creator of the mapping expects them to be useful for. >> >> Mappings might also be discarded before the TTL expires, >> depending on >> what strategies the ITR is using to maintain its cache; >> if the >> maximum cache size is fixed, or the ITR needs to reclaim >> memory, >> mappings which have not been used recently may be >> discarded. (After >> all, there is no harm in so doing; a future reference >> will merely >> cause that mapping to be reloaded.) >> >> {{Contents may change before TTL expires?}} >> >> >> >> Cabellos-Aparicio (Ed.) Expires January 17, 2015 >> [Page 28] >> >> Internet-Draft LISP Introduction >> July 2014 >> >> >> 12.6. Mapping Gleaning in ETRs >> >> {{Suggestion by editors: Remove this section, gleaning is >> discouraged >> since it rises many security concerns.}} >> >> As an optimization to the mapping acquisition process, >> ETRs are >> allowed to glean mappings from incoming user data >> packets, and also >> from incoming Map-Request control messages. This is not >> secure, and >> so any such mapping must be verified by sending a >> Map-Request to get >> an authoritative mapping. >> >> The value of gleaning is that most communications are >> two-way, and so >> if host A is sending packets to host B (therefore needing B's >> EID->RLOC mapping), very likely B will soon be sending >> packets back >> to A (and thus needing A's EID->RLOC mapping). Without >> gleaning, >> this would sometimes result in a delay, and the dropping >> of the first >> return packet; this is felt to be very undesirable. >> >> 12.7. MTU Issues >> >> Several mechanisms have been proposed for dealing with >> packets which >> are too large to transit the path from a particular ITR >> to a given >> ETR. >> >> In one, called the stateful approach, the ITR keeps a >> per-ETR record >> of the maximum size allowed, and sends an ICMP Too Big >> message to the >> >> >> _______________________________________________ >> 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 --------------010307020201040600000808 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Albert, Damien,

There's not much to add to what previous reviewers have already mentioned. Overall, I agree with the editorial recommendations, especially those in favor of simplifying the discourse. I'm also of opinion that the document should be a concise description of LISP and only offer a high-level description of problems that it solves or it may solve. In this sense, I agree with Victor's point that more general text that allows for future use cases might be needed.

Thanks for moving this forward. I'm looking forward to reviewing the next revision.

Florin

On 8/1/14 2:30 PM, Victor Moreno (vimoreno) wrote:
Hi Alberto, Damien,

A few suggestions for the intro doc:

Overview/Basic Approach (currently 6 and 6.1):
- Not in the current text: Spell out very clearly and upfront the concept of *separation* of location and identity. 
- With the concept of location/identity separation clear, then proceed to introduce RLOCs and EIDs as manifestations of such concepts. 
- Highlight that these are not mandatorily IP addresses (could be almost anything).
- Build upon this to introduce the notion of RLOCs and EIDs as forming two distinct address spaces
- Finally introduce LISP as the mechanisms to handle the mappings that correlate the two address spaces. May be a good segway into the Basic functionality section that follows.

Basic Functionality (6.2):
- I think it is worth adding to this section the notion of the destination based policies manifested as priorities and weights. Since this is an architectural doc, we may want to abstract this policy notion enough to accommodate other/future policy options that may arise.
- The pull nature of the mechanism is introduced in 6.3 currently. I think this is an important attribute and may be worth considering bringing it forward to 6.2.

Initial Applications (7):
- Fully agree that the section needs to be moved back if we keep it.
- Most use cases will probably fall out of charter at this point, making this section very short until a future re-charter allows more use cases. IMO we need text to allow for those future use cases that are currently out of charter without having to re-open this architecture document. One option is to keep the text on the use cases that is currently in the document. Another option is to include general text to allow future use cases. The latter may be required regardless.
- IMO, just keep the use cases in any order.

8.2. Regarding EID-block vs. prefix. I kind of like EID-block in support of the AF agnostic characteristics of LISP. Prefixes (I think) are tightly coupled with IP, once we have MAC addresses or other addresses prefix may not be the best choice.

10.  Part II

   {{comment from editors: is that the role of an introductory document
   to enter in such level of details and discuss (mostly) all fields of
   the protocol? }}
IMO not in detail and we should probably be a bit more selective in terms of which fields we do discuss in this doc vs. which we do not. Thus outlining the moving parts, at a high level,  and providing references to the documentation with the relevant details may be helpful to those starting with LISP. In general, this second part should be much more succinct in my opinion.

Regarding any other “Suggestions by editors", I agree with all the editor suggestions in version 04 with any comments/exceptions noted above.

Thanks for moving this forward. 

Regards,

-v


On Jul 28, 2014, at 1:28 PM, Albert Cabellos <albert.cabellos@gmail.com> wrote:

Fabio,

Please see below:


On Fri, Jul 25, 2014 at 10:21 PM, Fabio Maino <fmaino@cisco.com> wrote:
Albert, Damien,
please find my comments below.


Network Working Group                         A. Cabellos-Aparicio (Ed.)
Internet-Draft                         Technical University of Catalonia
Intended status: Informational                           D. Saucez (Ed.)
Expires: January 17, 2015                                          INRIA
                                                            July 16, 2014


       An Architectural Introduction to the LISP Location-Identity
                            Separation System
                   draft-ietf-lisp-introduction-04.txt

Abstract

    This document is an introductory overview of the Locator/ID
    Separation Protocol, it describes the major concepts and functional
    sub-systems of LISP and the interactions between them.

Status of This Memo

    This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is athttp://datatracker.ietf.org/drafts/current/.

    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."

    This Internet-Draft will expire on January 17, 2015.

Copyright Notice

    Copyright (c) 2014 IETF Trust and the persons identified as the
    document authors.  All rights reserved.

    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
    carefully, as they describe your rights and restrictions with respect
    to this document.  Code Components extracted from this document must
    include Simplified BSD License text as described in Section 4.e of
    the Trust Legal Provisions and are provided without warranty as
    described in the Simplified BSD License.



Cabellos-Aparicio (Ed.) Expires January 17, 2015                [Page 1]

Internet-Draft              LISP Introduction                  July 2014


Table of Contents

    1.  Prefatory Note  . . . . . . . . . . . . . . . . . . . . . . .   4
    2.  Part I  . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
    3.  Initial Glossary  . . . . . . . . . . . . . . . . . . . . . .   5
    4.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   6
    5.  Deployment Philosophy . . . . . . . . . . . . . . . . . . . .   7
      5.1.  Economics . . . . . . . . . . . . . . . . . . . . . . . .   7
      5.2.  Maximize Re-use of Existing Mechanism . . . . . . . . . .   8
    6.  LISP Overview . . . . . . . . . . . . . . . . . . . . . . . .   8
      6.1.  Basic Approach  . . . . . . . . . . . . . . . . . . . . .   9
      6.2.  Basic Functionality . . . . . . . . . . . . . . . . . . .   9
      6.3.  Mapping from EIDs to RLOCs  . . . . . . . . . . . . . . .  11
      6.4.  Interworking With Non-LISP-Capable Endpoints  . . . . . .  11
      6.5.  Security in LISP  . . . . . . . . . . . . . . . . . . . .  12
    7.  Initial Applications  . . . . . . . . . . . . . . . . . . . .  13
      7.1.  Provider Independence . . . . . . . . . . . . . . . . . .  13
      7.2.  Multi-Homing  . . . . . . . . . . . . . . . . . . . . . .  13
      7.3.  Traffic Engineering . . . . . . . . . . . . . . . . . . .  14
      7.4.  Routing . . . . . . . . . . . . . . . . . . . . . . . . .  15
      7.5.  Mobility  . . . . . . . . . . . . . . . . . . . . . . . .  15
      7.6.  Traversal Across Alternate IP Versions  . . . . . . . . .  15
      7.7.  Virtual Private Networks  . . . . . . . . . . . . . . . .  16
      7.8.  Local Uses  . . . . . . . . . . . . . . . . . . . . . . .  16
    8.  Major Functional Subsystems . . . . . . . . . . . . . . . . .  17
      8.1.  Data Plane - xTRs Overview  . . . . . . . . . . . . . . .  17
        8.1.1.  Mapping Cache Performance . . . . . . . . . . . . . .  18
      8.2.  Control Plane - Mapping System Overview . . . . . . . . .  18
        8.2.1.  Mapping System Organization . . . . . . . . . . . . .  19
        8.2.2.  Interface to the Mapping System . . . . . . . . . . .  20
        8.2.3.  Indexing Sub-system . . . . . . . . . . . . . . . . .  20
    9.  Examples of operation . . . . . . . . . . . . . . . . . . . .  22
      9.1.  An Ordinary Packet's Processing . . . . . . . . . . . . .  22
      9.2.  A Mapping Cache Miss  . . . . . . . . . . . . . . . . . .  23
    10. Part II . . . . . . . . . . . . . . . . . . . . . . . . . . .  24
    11. Design Approach . . . . . . . . . . . . . . . . . . . . . . .  24
    12. xTRs  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  25
      12.1.  When to Encapsulate  . . . . . . . . . . . . . . . . . .  25
      12.2.  UDP Encapsulation Details  . . . . . . . . . . . . . . .  26
      12.3.  Header Control Channel . . . . . . . . . . . . . . . . .  26
        12.3.1.  Mapping Versioning . . . . . . . . . . . . . . . . .  26
        12.3.2.  Echo Nonces  . . . . . . . . . . . . . . . . . . . .  27
        12.3.3.  Instances  . . . . . . . . . . . . . . . . . . . . .  27
      12.4.  Probing  . . . . . . . . . . . . . . . . . . . . . . . .  28
      12.5.  Mapping Lifetimes and Timeouts . . . . . . . . . . . . .  28
      12.6.  Mapping Gleaning in ETRs . . . . . . . . . . . . . . . .  29
      12.7.  MTU Issues . . . . . . . . . . . . . . . . . . . . . . .  29
      12.8.  Security of Mapping Lookups  . . . . . . . . . . . . . .  29



Cabellos-Aparicio (Ed.) Expires January 17, 2015                [Page 2]

Internet-Draft              LISP Introduction                  July 2014


      12.9.  ITR Mapping Cache Performance  . . . . . . . . . . . . .  30
    13. The Mapping System  . . . . . . . . . . . . . . . . . . . . .  31
      13.1.  The Mapping System Interface . . . . . . . . . . . . . .  32
        13.1.1.  Map-Request Messages . . . . . . . . . . . . . . . .  32
        13.1.2.  Map-Reply Messages . . . . . . . . . . . . . . . . .  32
        13.1.3.  Map-Register and Map-Notify Messages . . . . . . . .  33
      13.2.  The DDT Indexing Sub-system  . . . . . . . . . . . . . .  34
      13.3.  Reliability via Replication  . . . . . . . . . . . . . .  35
      13.4.  Security of the DDT Indexing Sub-system  . . . . . . . .  35
      13.5.  Extended Capabilities  . . . . . . . . . . . . . . . . .  36
      13.6.  Performance of the Mapping System  . . . . . . . . . . .  36
    14. Multicast Support in LISP . . . . . . . . . . . . . . . . . .  37
      14.1.  Basic Concepts of Multicast Support in LISP  . . . . . .  37
      14.2.  Initial Multicast Support in LISP  . . . . . . . . . . .  38
    15. Deployment Issues and Mechanisms  . . . . . . . . . . . . . .  39
      15.1.  LISP Deployment Needs  . . . . . . . . . . . . . . . . .  39
      15.2.  Interworking Mechanisms  . . . . . . . . . . . . . . . .  40
        15.2.1.  Proxy LISP Routers . . . . . . . . . . . . . . . . .  40
        15.2.2.  LISP-NAT . . . . . . . . . . . . . . . . . . . . . .  42
      15.3.  Use Through NAT Devices  . . . . . . . . . . . . . . . .  42
      15.4.  LISP and Core Internet Routing . . . . . . . . . . . . .  43
    16. Fault Discovery/Handling  . . . . . . . . . . . . . . . . . .  43
      16.1.  Handling Missing Mappings  . . . . . . . . . . . . . . .  44
      16.2.  Outdated Mappings  . . . . . . . . . . . . . . . . . . .  44
        16.2.1.  Outdated Mappings - Updated Mapping  . . . . . . . .  44
        16.2.2.  Outdated Mappings - Wrong ETR  . . . . . . . . . . .  44
        16.2.3.  Outdated Mappings - No Longer an ETR . . . . . . . .  45
      16.3.  Erroneous Mappings . . . . . . . . . . . . . . . . . . .  45
      16.4.  Verifying ETR Liveness . . . . . . . . . . . . . . . . .  45
      16.5.  Verifying ETR Reachability . . . . . . . . . . . . . . .  46
    17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  46
    18. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  47
    19. Security Considerations . . . . . . . . . . . . . . . . . . .  47
    20. References  . . . . . . . . . . . . . . . . . . . . . . . . .  47
      20.1.  Normative References . . . . . . . . . . . . . . . . . .  47
      20.2.  Informative References . . . . . . . . . . . . . . . . .  49
    Appendix A.  Glossary/Definition of Terms . . . . . . . . . . . .  52
    Appendix B.  Other Appendices . . . . . . . . . . . . . . . . . .  55
      B.1.   A Brief History of Location/Identity Separation  . . . .  55
      B.2.  A Brief History of the LISP Project . . . . . . . . . . .  56
      B.3.  Old LISP 'Models' . . . . . . . . . . . . . . . . . . . .  56
      B.4.  The ALT Mapping Indexing Sub-system . . . . . . . . . . .  57
      B.5.  Early NAT Support . . . . . . . . . . . . . . . . . . . .  58
    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  59







Cabellos-Aparicio (Ed.) Expires January 17, 2015                [Page 3]

Internet-Draft              LISP Introduction                  July 2014


1.  Prefatory Note

    {{Suggestion by editors: Remove all the sections before "LISP
    Overview" and write a straight-to-the-point introduction}}

    {{Suggestion by editors: The draft should focus on describing the
    LISP architecture and avoid comparing loc/id split architectures with
    other approaches}}

Agree: my suggestion is to view this as a doc for a reader new to LISP that needs to be introduced to the architecture. At the end of the doc the reader will be familiar with the basic aspects of LISP, and able to navigate through the RFCs. The document should be kept as short and as "dry" as possible. If the reader wants to know more, after reading this doc, he will know where to go for the details.




    This document is the first of a pair which, together, form what one
    would think of as the 'architecture document' for LISP (the
    'Location-Identity Separation Protocol').  Much of what would
    normally be in an architecture document (e.g. the architectural
    design principles used in LISP, and the design considerations behind
    various components and aspects of the LISP system) is in the second
    document, the 'Architectural Perspective on LISP' document.
    [I-D.ietf-lisp-perspective]

    This 'Architectural Introduction' document is primarily intended for
    those who are unfamiliar with LISP, and want to start learning about
    it.  It is intended primarily for those working on LISP, but those
    working with LISP, and more generally anyone who wants to know more
    about LISP, may also find this document useful.

    This document is intended to both be easy to follow and it is
    structured as a series of phases, each covering the entire system,
    but with ever-increasing detail.  Reading only the first part of the
    document will give a good high-level view of the system; reading the
    complete document should provide a fairly detailed understanding of
    the entire system.

    People who just want to get an idea of how LISP works might only read
    the first part; they can stop reading either just before, or just
    after Section 9.  People who are going to go on and read the protocol
    specifications (perhaps to implement LISP) should read the entire
    document.

    This document is a descriptive document, not a protocol
    specification.  Should it differ in any detail from any of the LISP
    protocol specification documents, they take precedence for the actual
    operation of the protocol.

2.  Part I








Cabellos-Aparicio (Ed.) Expires January 17, 2015                [Page 4]

Internet-Draft              LISP Introduction                  July 2014


3.  Initial Glossary

let's stick to the RFCs glossary. Since this is a first-to-read doc there should be a minimal definition section, but definitions should mostly be cut and paste from the RFCs.

Agree, this will make easier to read the rest of the RFCs.
 


    This initial glossary defines a few general terms which will be
    useful to have in hand when commencing reading this document.  A
    complete glossary is available in Appendix A.

    A note about style: initial usage of a term defined in the glossary
    is denoted with double quotation marks (").  Other uses of quotations
    (e.g. for quotations, euphemisms, etc) use single quotation marks
    (').

    o  Name: a name refers to an identifier for an object or entity.
       Names have both semantics (meaning) and syntax (form) [RFC1498].

    o  Namespace: A group of names with matching semantics and syntax;
       they usually, but not always, refer to members of a class of
       identical objects.

    o  Mapping: a binding between two names, one in each of two
       namespaces.

    o  Delegation Hierarchy: an abstract rooted tree (in the graph theory
       sense of the term) which is a virtual representation of the
       delegation of a namespace into smaller and smaller blocks, in a
       recursive process.

    o  Node: The general term used to describe any sort of communicating
       entity; it might be a physical or a virtual host, or a mobile
       device of some sort.  It includes both entities which forward
       packets, and entities which create or consume packets.

    o  Switch, Packet Switch: A packet switch, in the general meaning of
       that term.  A device which takes in packets from its interfaces
       and forwards them on, either to a next-hop switch, or to the final
       destination.  They may operate at either the network layer (e.g.
       ARPANET), or internetwork layer.  [Baran][Heart][RFC1812]

    o  Endpoint, end-end communication entity: The fate-sharing region at
       one end of an end-end communication; the collection of state
       related to both the reliable end-end communication channel, and
       the applications running there.  [Chiappa]

    o  Address: In this document, in current IP (IPv4 or IPv6) and
       similar networking suites, a "name" which has mixed semantics, in
       that it includes both identity ('who') and location ('where')
       semantics.  [Atkinson]





Cabellos-Aparicio (Ed.) Expires January 17, 2015                [Page 5]

Internet-Draft              LISP Introduction                  July 2014


    o  Address Block, Block: A contiguous section of a namespace (e.g.,
       IP addresses that belong to the same prefix).

    o  Identifier: a name which has identity semantics.

    o  Locator: name with only location semantics and not necessarily
       carried in every packet [RFC1992].

    o  Site: A collection of hosts, routers, and networks under a single
       administrative control.

    o  LISP site: a site separated from the rest of the network by LISP
       routers.

    o  LISP node: A network element implementing LISP functionality; this
       means it can process some subset of LISP control and planes
       traffic.

    o  LISP router: A network element implementing LISP data-plane
       functionality, i.e., a LISP node which can forward user traffic.

    o  LISP host: A host which is behind (from the point of view of the
       rest of the network) a LISP router.

4.  Background

    It has gradually been realized in the networking community that
    networks, especially large networks, should deal quite separately
    with the identity and location of an endpoint - basically, who an
    endpoint is, and where it is ([RFC1498] [RFC4984]).

    At the moment of this writing, in both IPv4 and IPv6, IP addresses
    indicate both where the named node is, as well as identify it for
    purposes of end-end communication; i.e. it has both location and
    identity properties.  However, the separation of those two properties
    is a step which has been identified by the IRTF as a necessary
    evolutionary architectural step for the Internet [RFC6115] and the
    on-going LISP project is an attempt to provide a viable path towards
    this separation.

    As an add-on to a large existing system, it has had to make certain
    compromises.  (For a good example, see [I-D.ietf-lisp-perspective],
    Section "Residual Location Functionality in EIDs".  However, if it
    reaches near-ubiquitous deployment, it will have two important
    consequences.

    First, in effectively providing separation of location and identity,
    along with providing a distributed directory of the mappings between



Cabellos-Aparicio (Ed.) Expires January 17, 2015                [Page 6]

Internet-Draft              LISP Introduction                  July 2014


    them, 'Wheeler's Law' ('All problems in computer science can be
    solved by another level of indirection') will come into play, and the
    Internet technical community will have a new, immensely powerful,
    tool at its disposal.  The fact that the namespaces on both sides of
    the mapping are global ones maximizes the power of that tool.  (See
    [I-D.ietf-lisp-perspective], Section "Need for a Mapping System", for
    more on this.)

    Second, because of a combination of the flexible capability built
    into LISP, and the breaking of the unification of location and
    identity names, further architectural evolution of the Internet
    becomes easily available; for example, new namespaces for location or
    identity could be designed and deployed.  In other words, LISP is not
    a point solution to meet a particular need, but hopefully an 'escape
    hatch' which will allow further significant enhancement to the
    Internet's overall architecture.  (See [Future] for more on this.)

5.  Deployment Philosophy

    {{Suggestion by editors: Remove the entire section, it can be
    summarized by the last paragraph.  Furthermore the arguments used in
    this sections are hard to follow since LISP has not been described
    yet.}}

    The deployment philosophy was a major driver for the design of LISP
    (architecture and engineering).

    Experience over the last several decades has shown that having a
    viable deployment model for a new design is a key to the adoption of
    the solution.  In general, it is comparatively easy to conceive of
    new network designs, but much harder to devise approaches which will
    actually get deployed throughout the global network.  A new design
    may be fantastic but if it can not be successfully deployed (for
    whatever factors), it is useless.

    LISP aims to achieve the near-ubiquitous deployment necessary for
    maximum exploitation of an architectural upgrade by i) minimizing the
    amount of change needed (most existing hosts and routers can operate
    unmodified); and ii) by providing significant benefits to early
    adopters.

5.1.  Economics

    {{Suggestion by editors: Remove this section, this has not been
    discussed by the WG}}

    A key factor in successful adoption is economics: does the new design
    have benefits which outweigh its costs?



Cabellos-Aparicio (Ed.) Expires January 17, 2015                [Page 7]

Internet-Draft              LISP Introduction                  July 2014


    More importantly, this balance needs to hold for early adopters -
    because if they do not receive benefits to their adoption, the sphere
    of earliest adopters will not expand, and it will never get to
    widespread deployment.

    This is particularly true of architectural enhancements, which are
    far less likely to be an addition which one can bolt onto the side of
    existing mechanisms, and often offer their greatest benefits only
    when widely (or ubiquitously) deployed.

    Maximizing the cost-benefit ratio obviously has two aspects.  First,
    on the cost side, by making the design as inexpensive as possible,
    which means in part making the deployment as easy as possible.
    Second, on the benefit side, by providing many new capabilities,
    which is best done not by loading the design up with lots of features
    or options (which adds complexity), but by making the addition
    powerful through deeper flexibility.  The LISP community believes
    LISP has met both of these goals.

5.2.  Maximize Re-use of Existing Mechanism

    {{Suggestion by editors: Remove/Summarize the entire section, the
    arguments used in this section are hard to follow since LISP has not
    been described yet.}}

Remove. This doc is not a guide to good protocol design. The concept that LISP is deployable incrementally should be mentioned in the document though, possibly with a reference to the deployment RFC.

Agreed, we´ll include an (ultra-short) section describing the design principles of LISP, incremental deployment is of course one of them.

    One key part of reducing the cost of a new design is to minimize the
    amount of change required to existing, deployed, devices: the fewer
    devices need to be changed, and the smaller the change to those that
    do, the greater the likelihood of deployment.

    Designs which absolutely require forklift upgrades to large amounts
    of existing gear are far less likely to succeed - because they have
    to have extremely large benefits to make their very substantial costs
    worthwhile.

    It is for this reason that LISP, in most cases, initially requires no
    changes to almost all existing devices in the Internet (both hosts
    and routers); LISP functionality needs to be added in only a few
    places ( Section 15.1)

6.  LISP Overview

    LISP is an incrementally deployable architectural upgrade to the
    existing Internet infrastructure, one which provides separation of
    location and identity.  It thus starts to separate the names used for
    identity and location of nodes, which are currently unified in IP
    addresses.




Cabellos-Aparicio (Ed.) Expires January 17, 2015                [Page 8]

Internet-Draft              LISP Introduction                  July 2014


6.1.  Basic Approach

    {{Suggestion by editors: Merge this section with the previous one
    (LISP Overview)}}

Agree: across the document, as done in the RFCs, I'd suggest to focus on describing the protocol architecture and how it works rather than on more generic considerations about the LISP philosophy.

    In LISP, the first key concept is that nodes have both an identifier
    called an Endpoint IDentifier (EID) and an associated Routing Locator
    (RLOC).  A node may be associated with more than one RLOC, or the
    RLOC may change over time (e.g., if the node is mobile), but it would
    normally always have the same EID.

    The second key concept is that if one wants to be as forward-looking
    as possible, conceptually one should think of the two kinds of names
    (EIDs and RLOCs) as naming different classes of entities.

    On the one hand, EIDs are used to name nodes - or rather, their end-
    end communication entities.  RLOC(s), on the other hand, name
    interfaces, i.e. places to which the system of routers sends packets.

    This distinction, the formal recognition of different kinds of
    entities ("endpoints" and interfaces), and their association with the
    two different classes of names, is also important.  Clearly
    recognizing interfaces and endpoints as distinctly separate classes
    of objects is another improvement to the existing Internet
    architecture.

    An important insight in LISP is that it initially uses existing IP
    addresses for both of these kinds of names, as opposed to some
    similar earlier deployment proposals for separation of location and
    identity (e.g.  [RFC1992]), which proposed using a new namespace for
    locators.  This choice minimizes LISP's deployment cost, as well as
    providing the ability to easily interact with un-modified hosts and
    routers.

    The capability to use namespaces other than IP addresses for both
    kinds of names is already built in LISP, which is expected to greatly
    increase the long-term benefits, flexibility, and power of LISP
    ([AFI], [I-D.ietf-lisp-lcaf]).

6.2.  Basic Functionality

    {{Suggestion by editors: Rewrite this section: It is using non-
    standard terminology to refer to standard LISP concepts ('enhance'
    instead of encapsulate) It is using subjective terms (e.g., 'near'
    the source) It is missing key LISP aspects such as that RLOC packets
    are forwarded in the RLOC space }}


Make sure a figure with the basic elements of the protocol architecture (possibly similar to figure 1) is introduced as early as possible. 





Cabellos-Aparicio (Ed.) Expires January 17, 2015                [Page 9]

Internet-Draft              LISP Introduction                  July 2014


    The basic operation of LISP, as it currently stands, is quite simple.
    LISP augmented packet switches, "LISP routers", near the source and
    destination of packets intercept traffic, and 'enhance' the packets
    for the trip between the LISP switches.

    The LISP router near the original source (the Ingress Tunnel Router,
    or ITR ) looks up additional information about the destination of the
    packet, and then wraps the packet in an outer header, one which
    contains additional information related to LISP operation.

    The LISP router near the destination, the (the Egress Tunnel Router,
    or ETR) removes that header, leaving the original, un-modified,
    packet to be sent on to the original destination node.

    The overall processing is shown below, in Figure 1:


     /-----------------\                       ---
     |     Mapping     |                        |
     .     System      |                        |  Control
    -|                 |`,                      |  Plane
  ,' \-----------------/  .                     |
                      /                         \                   ---
     ,..,           -        _,..--..,,         `,         ,..,      |
   /     `        ,'      ,-`          `',        .      /     `     |
  /        \ +-----+    ,'                `,    +--'--+ /        \   |
  |  EID   |-| xTR |---/        RLOC        ,---| xTR |-|  EID   |   |  Data
  | Space  |-|     |---|       Space        |---|     |-| Space  |   |  Plane
  \        / +-----+   .                   /    +-----+ \        /   |
   `.    .'             `.                ,'             `.    .'    |
     `'-`                 `.,          ,.'                 `'-`     ---
                             ``''--''``
   LISP Site (Edge)            Core              LISP Site (Edge)

                   Figure.- An schema of the LISP Architecture



                      Figure 1: Basic LISP Packet Flow

    To retrieve that additional information, the ITR uses the information
    in the original packet about the identity of its ultimate
    destination, i.e. the destination EID address.  It uses the
    destination EID to look up the current location (the RLOC) of that
    EID.

    The lookup is performed through a mapping system, which is the heart
    of LISP: it is a distributed directory of mappings from EIDs to



Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 10]

Internet-Draft              LISP Introduction                  July 2014


    RLOCs.  The destination RLOC(s) is (are) normally the address(es) of
    the ETR(s) near the ultimate destination.

    The ITR then generates a new outer header for the original packet,
    with that header containing the ETR's RLOC as the wrapped packet's
    destination, and the ITR's own address (i.e. the RLOC usually
    associated with the original source) as the wrapped packet's source,
    and sends it off.

    When the packet arrives at the ETR, that outer header is stripped
    off, and the original packet is forwarded to the original ultimate
    destination for normal processing.

    Return traffic is handled similarly, often (depending on the
    network's configuration) with the original ITR and ETR switching
    roles.  The ETR and ITR functionality is usually co-located in a
    single LISP router; these are normally denominated as xTRs.

6.3.  Mapping from EIDs to RLOCs

    The mappings from EIDs to RLOCs are provided by a distributed, and
    potentially replicated, database, the "mapping database", which is
    the heart of LISP.  Here, and in other places in LISP, the
    replication is not a deep architectural concept, simply an
    engineering device to obtain reliability via potential redundancy.

    Entities which need EID-to-RLOC mappings get them from the mapping
    system, which is a collection of sub-systems through which clients
    can find and obtain mappings as discussed in more details in
    Section 8.2 and Section 13.

    Mappings are normally distributed via a pull mechanism (i.e., not
    pre-loaded, but requested on demand).  Once obtained by an ITR, they
    are cached for performance reasons.

6.4.  Interworking With Non-LISP-Capable Endpoints

    It is clearly crucial to provide the capability for easy
    interoperation between "LISP hosts" - i.e. they are behind xTRs, and
    their EIDs are in the mapping database - and existing non-LISP-using
    hosts (often called 'legacy' hosts) or legacy "sites".

    To allow interoperation between devices hosted in a LISP site and
    devices not belonging to a LISP site (non-LISP site), an interworking
    mechanism based on proxies has been designed.  Proxy ITRs (PITR)
    encapsulate packets sent from non-LISP sites to LISP sites while
    Proxy ETRs (PETR) decapsulate packets sent from LISP sites to non-
    LISP sites.  More details are given in Section 15.2.1.



Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 11]

Internet-Draft              LISP Introduction                  July 2014


6.5.  Security in LISP

    {{Suggestion by editors: Rewrite this section: (first 3 paragraphs)
    It contains a general discussion as well as strong statements that
    are not supported by any WG document.  (last 3 paragraphs) It
    enumerates the security mechanisms specified in LISP but does not
    describe them.}}

Agree. I think that the security considerations section of RFC6830 may provide a guide to the items you may want to touch in this document. Point the reader to the RFCs when possible. Move broader security considerations to the Security Section referencing lisp-threats where needed.

Agreed. 

    To provide a brief overview of security in LISP, it is definitely
    understood that LISP needs to be highly _securable_, especially in
    the long term; over time, the attacks mounted by 'bad guys' are
    becoming more and more sophisticated.  So LISP, like DNS, needs to be
    _capable_ of providing 'the very best' security there is.

    At the same time, there is a conflicting goal: it must be deployable
    at a a viable cost.  That means two things: First, as an experiment,
    we cannot expect to create the complete security apparatus which we
    might see in the finished product, including both design and
    implementation.  Second, security needs to be flexible, so that we
    don't overload the users with more security than they need at any
    point.

    To accomplish these divergent goals, the approach taken is to first
    analyze what LISP needs for security.  [I-D.ietf-lisp-threats].
    Then, steps can be taken to ensure that the appropriate 'hooks' (such
    as packet fields) are included at an early stage, when doing so is
    still easy.  Over time, additional mechanisms will be fully
    specified, implemented, and deployed.

    LISP does already include a number of security mechanisms; in
    particular, requesting mappings can be secured (see Section 12.8,
    "Security of Mapping Lookups"), as can registering of xTRs (see
    Section 13.1.3, "Map-Register and Map-Notify Messages"); the key
    database of the mapping system is also secured (see Section 13.4,
    "Security of the DDT Indexing Sub-system").

    The existing security mechanisms, and their configuration (which is
    mostly manual at this point) currently in LISP are felt to be
    adequate for the needs of the on-going early stages of deployment;
    experience will indicate when improvements are required (within the
    constraints of the conflicting goal given above).

    For more on LISP's security philosophy; see
    [I-D.ietf-lisp-perspective], Section 7 "Security", where it is laid
    out in some detail.






Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 12]

Internet-Draft              LISP Introduction                  July 2014


7.  Initial Applications

    {{Suggested by editors: Move this section after section 8, the
    applications should not be described before LISP has been fully
    described.

    {{Suggested by Noel: Reorder the whole section in popularity order?}}

    As previously mentioned, it is felt that LISP will provide even the
    earliest adopters with some useful capabilities, and that these
    capabilities will drive early LISP deployment.

    It is very imporant to note that even when used only for
    interoperation with existing un-modified hosts, use of LISP can still
    provide benefits to the site which has deployed it - and, perhaps
    even more importantly, can do so to both sides.  This characteristic
    acts to further enhance the utility for early adopters of LISP.

    Note also that this section only lists some early applications and
    benefits.  See [I-D.ietf-lisp-perspective], in the Section "Goals of
    LISP", for a more extensive discussion of some of what LISP might
    ultimately provide.

7.1.  Provider Independence

    Provider independence (i.e. the ability to easily change one's
    Internet Service Provider) is a good example of the utility of
    separating location and identity.

    To limit global routing table size addresses need to be aggregated.
    To that aim networks can use provider aggregatable addresses
    ([RFC4116]) which means that the IP prefixes of networks are sub-
    prefixes of their provider.  This solutions allows to reduce
    scalability issues of the global routing table but it means that when
    a network switches providers it has to re-number all its devices
    which is known to be complex in current networks [RFC5887].

    Having separate namespaces for location and identity greatly reduces
    the problems involved with re-numbering; an organization which moves
    retains its EIDs (which are how most other parties refer to its
    nodes), but is allocated new RLOCs, and the mapping system can
    quickly provide the updated mapping from the EIDs to the new RLOCs.

7.2.  Multi-Homing

    {{Suggested by editors: This section should be extended, it is
    unclear the benefits that LISP brings to multihoming (.e.g, traffic
    engineering, decoupled multihoming from the data-plane).



Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 13]

Internet-Draft              LISP Introduction                  July 2014


    Multi-homing is another place where the value of separation of
    location and identity became apparent.  There are several different
    sub-flavours of the multi-homing problem - e.g. depending on whether
    one wants open TCP connections to keep working, etc - and other axes
    as well (e.g. site multi-homing versus host multi-homing).

    In particular, for the 'keep open connections up' case, without
    separation of location and identity, with most currently deployed
    implementations, the only currently feasible approach is to use
    provider-independent addressses - which moves the problem into the
    global routing system, with attendant costs.  This approach is also
    not really feasible for host multi-homing.

7.3.  Traffic Engineering

    {{Suggestion by editors: Merge this section with the previous one, TE
    is not practical without multihoming}}

    {{Needs a fix - not sure what.}}

    Traffic engineering (TE) [RFC3272], desirable though this capability
    is in a global network, is currently somewhat problematic to provide
    in the Internet.  The problem, fundamentally, is that this capability
    was not forseen when the Internet was designed, so the support for it
    via hacks is neither clean, nor flexible.

    TE is, fundamentally, a routing issue.  However, the current Internet
    routing architecture, which is basically the Baran design of fifty
    years ago [Baran] (a single large, distributed computation), is ill-
    suited to provide TE.  The Internet seems a long way from adopting a
    more-advanced routing architecture, although the basic concepts for
    such have been known for some time.  [RFC1992]

    Although the identity-location mapping layer is thus a poor place,
    architecturally, to provide TE capabilities, it is still an
    improvement over the current routing tools available for this purpose
    (e.g. injection of more-specific routes into the global routing
    table).

    In addition, instead of the entire network incurring the costs
    (through the routing system overhead), when using a mapping layer to
    provide TE, the overhead is limited to those who are actually
    communicating with that particular destination.

    LISP includes a number of features in the mapping system to support
    TE. (described in Section 8.2, "Control Plane - Mapping System
    Overview", below); more details about using LISP for TE can be found
    in [I-D.farinacci-lisp-te].



Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 14]

Internet-Draft              LISP Introduction                  July 2014


    Also, a number of academic papers have explored how LISP can be used
    to do TE, and how effective it can be.  See the online LISP
    Bibliography ([Bibliography]) for information about them.

7.4.  Routing

    {{Suggestion by editors: Remove this section, LISP is not a routing
    protocol.}}

    Multi-homing and Traffic Engineering are both, in some sense, uses of
    LISP for routing, but there are many other routing-related uses for
    LISP.

    One of the major original motivations for the separation of location
    and identity in general, and thus LISP, was to reduce the growth of
    the routing tables in the "Internet core", the part where routes to
    _all_ ultimate destinations must be available.  LISP is expected to
    help with this; for more detail, see Section 15.4, "LISP and Core
    Internet Routing", below.

    LISP may also have more local applications in which it can help with
    routing; see, for instance, [CorasBGP].

7.5.  Mobility

    {{Suggestion by editors: Remove this section, mobility is not in
    charter.}}

    Mobility is yet another place where separation of location and
    identity is a key part of a clean, efficient and high-functionality
    solution.  Considerable experimentation has been completed on doing
    mobility with LISP.

    The mobility provided by LISP allows active sessions to survive moves
    (provided of course that there is not a period of inaccessibility
    which exceeds a timeout).  LISP mobility also will typically have
    better packet stretch (i.e. increase in path length) compared to
    traditional mobility schemes, which use a home agent.

7.6.  Traversal Across Alternate IP Versions

    Note that LISP inherently supports intermixing of various IP versions
    for packet carriage; IPv4 packets might well be carried in IPv6, or
    vice versa, depending on the network's configuration.

    This capability allows an island of operation of one type to be
    automatically tunneled over a stretch of infrastucture which only
    supports the other type.



Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 15]

Internet-Draft              LISP Introduction                  July 2014


7.7.  Virtual Private Networks

    {{Suggestion by editors: Remove this section, not covered by any WG
    document}}

    L2 and L3 {{Need to add text here - This used to be part of 'Local'
    below, but we decided this was so important it deserved its own
    section.  Maybe move this up further, as it seems to be the most
    important 'early adopter' application?}}

    The mapping-and-encapsulation nature of LISP makes it a perfect
    candidate for VPN solutions.  In this case, private parts of the VPN
    form LISP sites and the IP addresses of devices in the private parts
    are composing EID spaces.  The interconnection between the LISP sites
    is the public network and IP addresses in the interconnection compose
    the RLOC space.  A major advantage of using LISP to construct VPN
    resides in the simplicity of the configurations: each xTR (i.e., VPN
    end) is configured to query the mapping system to retrieve mappings
    making the glue between the public (RLOC space) and the private (EID
    space) of the VPN.

    This includes support of multi-tenancy where several private networks
    can be carried over the same underlayer network.  Thanks to the
    instance-id field, multi-tenant network can even use the exact same
    addresses as the xTR distinguishes the tenant based on the value of
    the instance-id.  The multiple address family support in LISP
    mappings also allows to build private networks using a different
    addressing family than the carrier (e.g., IPv6 over IPv4).

7.8.  Local Uses

    {{Suggestion by editors: Remove this section.  The section contains a
    general discussion about the applicability of LISP in intra-domain
    scenarios, however it does not describe any specific application.}}

    LISP has a number of use cases which are within purely
    organizationally-local contexts, i.e. not in the larger Internet.
    These fall into two categories: uses seen on the Internet (above),
    but here on a private (and usually small scale) setting; and
    applications which do not have a direct analog in the larger
    Internet, and which apply only to local deployments.

    Among the former are multi-homing and IP version traversal. {{This
    was marked to be deleted - why?  The next part doesn't make sense
    without this first?}}

    Among the latter class, non-Internet applications which have no
    analog on the Internet, are the following example applications:



Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 16]

Internet-Draft              LISP Introduction                  July 2014


    virtual machine mobility in data centers; non-IP EID types such as L2
    MAC addresses, or application specific data.

    Several of the applications listed in this section are the ones which
    have been most popular for LISP in practise; these include virtual
    networks, and virtual machine mobility.

    These often show a synergistic tendency, in that a site which
    installs LISP to do one, often finds that then becomes a small matter
    to use it for the second.  Given all the things which LISP can do, it
    is hoped that this synergistic effect will continue to expand LISP's
    uses.

    {{Preceeding paragraphs should probably get moved up into VPN
    section?}}

8.  Major Functional Subsystems

    {{Suggestion by editors: This section should appear before since it
    describes key aspects of LISP (e.g., LISP decoupled control and data-
    plane).}}

Yes, possibly where the first figure is.

    LISP has two major functional sub-systems: the xTRs which form the
    data-plane of LISP; and the mapping system which forms the control
    plane that maintains and distributes the mapping database.

    The purpose and operation of each is described at a high level below,
    and then, later on, in a fair amount of detail, in separate sections
    on each (Section 12 and Section 13).

8.1.  Data Plane - xTRs Overview

    {{Suggestion by editors: Extend this section, it misses key LISP
    data-plane aspects, such as the map-cache.}}

    xTRs are routers that have been augmented with extra functionality in
    both the data and control planes.  The data plane functions in ITRs
    include deciding which packets need to be given LISP processing
    (since packets to non-LISP hosts may be sent as they are); i.e.
    looking up the mapping; encapsulating (wrapping) the packet; and
    sending it to the ETR.

    This encapsulation is done using UDP [RFC0768], along with an
    additional outer IP header (to hold the source and destination
    RLOCs).  To the extent that traffic engineering features are in use
    for a particular EID, the ITRs implement them as well.





Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 17]

Internet-Draft              LISP Introduction                  July 2014


    In the ETR, the data plane simply decapsulates (unwraps) the packets,
    and forwards the it to the destination.

    Control plane functions in ITRs include: asking for EID-to-RLOC
    mappings via Map-Request packets; handling the returning reply
    control messages (i.e., Map-Reply packets), which contain the EID-to-
    RLOC mapping; managing the local mapping cache and checking for the
    reachability of destination ETR's RLOCs.

    In the ETR, control plane functions include participating in the
    reachability tests (see Section 16.4); interacting with the mapping
    sub-system to let it know what mapping this ETR can provide (see
    Section 8.2.2); and answering Map-Request packets from ITRs for those
    mappings.

8.1.1.  Mapping Cache Performance

    {{Suggestion by editors: Push this section further in the document,
    the cache performance is not a "Major LISP subsystem"}}

    As mentioned, studies have been performed to verify that caching
    mappings in ITRs is viable, in practical engineering terms.  These
    studies not only verified that such caching is feasible, but also
    provided some insight for designing ITR "mapping caches".

    Briefly, they took lengthy traces of all packets leaving a large
    site, over a period of a week or so, and used those to drive
    simulations which showed how many mappings would be required.  It
    also allowed analysis of how much control traffic (for loading needed
    mappings) would result, using various cache sizes and replacement
    algorithms.  These studies provide an insight into how well LISP can
    be expected to perform, and scale, over time.

    A more extended look at the results us given below, in Section 12.9,
    "xTR Mapping Cache Performance".

8.2.  Control Plane - Mapping System Overview

    {{Suggestion by editors: Rewrite: Replace EID block terminology
    (along with its description) with the very common term "prefix".
    Describe Map-Request/Map-Reply LISP signaling messages.}}

    The mapping system's entire purpose is to give ITRs on-demand access
    to the mapping database, which is a distributed, and potentially
    replicated, database which holds mappings between EIDs (identity) and
    RLOCs (location), along with needed ancillary data (e.g. lifetimes).





Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 18]

Internet-Draft              LISP Introduction                  July 2014


    To be exact, it contains mappings between EID blocks and RLOCs (the
    block size is given explicitly, as part of the syntax).  Support for
    blocks is both for minimizing the administrative configuration
    overhead, as well as for operational efficiency; e.g. when a group of
    EIDs are behind a single xTR.  In IP blocks are delimited by their IP
    prefix.

    However, the block may be, and sometimes is, as small as a single
    EID.  However, since mappings are only loaded upon demand, if smaller
    blocks become predominant, then the increased size of the overall
    database is far less problematic than if the Internet's routing
    tables came to be dominated by such small entries.

    A particular EID (or EID block) may be associated to than one RLOC,
    and may change the association with time.

    Also, in general, throughout LISP, the address family of EIDs and
    RLOCs is explicitly mentioned in control packet.

    Finally, the mapping from an EID (or EID block) contains not just the
    RLOC(s), but also (for each RLOC for any given EID entry) priority
    and weight fields (to allow allocation of load between several RLOCs
    at a given priority); this allows a certain amount of traffic
    engineering to be accomplished with LISP.

8.2.1.  Mapping System Organization

    {{Suggestion by editors: Rewrite: Describe key Mapping System
    components: Map-Server/Map-Resolver}}

    The mapping system is split into three functional sub-systems.

    The first is the actual mappings themselves, collectively the mapping
    database; they are held by the ETRs, and an ITR which needs a mapping
    gets it (effectively) directly from the ETR.  This co-location of the
    authoritative version of the mappings, and the forwarding
    functionality which it describes, is an instance of fate-sharing.
    [Clark]

    To find the appropriate ETR(s) to query for the mapping, the second
    two sub-systems form an indexing system, itself also based on a
    distributed, potentially replicated database.  It provides
    information on which ETR(s) are authoritative sources for the various
    EID-to-RLOC mappings which are available.  The two sub-systems which
    form it are the client interface sub-system, and indexing sub-system
    (which holds and provides the actual information).





Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 19]

Internet-Draft              LISP Introduction                  July 2014


8.2.2.  Interface to the Mapping System

    {{Suggestion by editors: has been rewritten: This section should
    appear earlier since it describes key LISP components (Map-Request/
    Map-Reply/Map-Server/Map-Resolver}}

    The client interface to the indexing system from an ITR's point of
    view is not with the indexing sub-system directly; rather, it is
    through the Map-Resolvers (MRs) and Map-Servers (MSs).

    To obtain the mapping for an EID, the ITRs sends Map-Request packet
    to an MR.  The MR then uses the indexing sub-system to allow it to
    forward the Map-Request to an appropriate Map-Server (MS), which in
    turn sends the Map-Request on to the appropriate ETR.  The latter is
    authoritative for the actual mappings for the EID.

    The ETR then sends the mappings for that EID in the form of aMap-
    Reply packets, which is sent directly to the ITR, without passing
    through the indexing sub-system and MR.  The details of the indexing
    sub-system are thus hidden from the ITRs.

    Note that in proxy mode, the MS replies on behalf of the ETR.  When
    this the case, the map-replies is tagged to indicate that the answer
    is not delivered from the authoritative ETR but from the MS instead.

    The interface to the indexing system from an ETR's point of view is
    made through MSes.  ETRs send Map-Register packets to their
    designated MSes.  The effect of a Map-Register is to inform the MS
    about the mappings maintained by ETRs such that the MS can transmit
    the Map-Requests is receives to the appropriate ETRs.

    The MS optionally replies Map-Register packets with a Map-Notify
    packet to confirm the registration.  The details of the indexing sub-
    system are thus likewise hidden from ETRs.

    The fact that the details of the indexing sub-system are entirely
    hidden from xTRs gives considerably flexibility to this aspect of
    LISP.  As long as any potential indexing sub-system can track where
    mappings are, it could potentially be used; this would allow the
    actual indexing sub-system to be replaced without needing to modify
    the xTRs.

8.2.3.  Indexing Sub-system

    {{suggestion by editor: rename the section to "DDT"}}



I think this section should briefly describe both ALT (mostly by reference to RFC 6836) and  DDT (by reference to LISP-DDT, with way fewer details on DDT than in the current document). "Indexing System" (as a component of the mapping system, together with the mapping database) may be a good name for this section.

"Index subsystem" is not a term used in ALT or DDT. What about "Mapping Database"?

    The current indexing sub-system is the Delegated Database Tree (DDT),
    which is conceptually similar to DNS ([I-D.ietf-lisp-ddt],



Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 20]

Internet-Draft              LISP Introduction                  July 2014


    [RFC1034]).  DDT replaces the earlier LISP+ALT indexing sub-system
    ([RFC6836]).  The seamless migration to DDT while LISP+ALT was
    previously used validated the concept of having a client-interface
    sub-system between the indexing sub-system, and the clients.

8.2.3.1.  DDT Overview

    Conceptually, DDT is similar to the DNS, in DDT the delegation of the
    EID namespace is instantiated as a delegation hierarchy, a tree of
    DDT nodes, starting with the root DDT node.  Each vertex is
    responsible for a block of the EID namespace.

    The root node is responsible for the entire EID space; any DDT node
    can delegate part(s) of its EID block to child DDT node(s).  The
    child node(s) can in turn further delegate (necessarily smaller)
    blocks of namespace to their children, through as many levels as are
    needed (for operational, administrative, etc, needs).

    Just as with DNS, any particular vertex in the DDT delegation tree
    may be instantiated in one or more DDT servers.  Multiple (redundant)
    servers for a given node would be used for reasons of performance,
    reliability, and robustness.  Obviously, all the servers which
    instantiate a particular nodes in the tree have to have identical
    data about that node.

8.2.3.2.  Use of DDT by MRs

    An MR which wants to find a mapping for a particular EID first
    interacts with the DDT servers which instantiate the nodes of the
    LISP delegation hierarchy tree, discovering (by querying the servers
    for information about DDT nodes) the chain of delegations which cover
    that EID.  Eventually it is directed to an MS, which is servicing an
    ETR which is authoritative for that EID.

    Also, again like DNS, MRs may cache information they receive about
    the delegations in the delegation tree.  This means that once an MR
    has been in operation for a while, it will usually have much of the
    delegation information cached locally (especially the top levels of
    the delegation tree).  This allows them, when passed a request for a
    mapping by an ITR, to usually forward the mapping request to the
    appropriate MS without having to interact with all the DDT servers on
    the path down the delegation tree, in order to find any particular
    mapping.

    Thus, a typical resolution cycle would usually involve looking at
    some locally cached delegation information, perhaps loading some
    missing delegation entries into their delegation cache, and finally
    sending the Map-Request to the appropriate MS.



Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 21]

Internet-Draft              LISP Introduction                  July 2014


    It should also be noted that the delegation tree is fairly static,
    since it reflects EID block allocations, which are themselves fairly
    static.  This stability has several important consequences.  First,
    it increases the performance of the mapping system, since the sub-
    system almost never needs to be re-queried for information about
    intermediate vertices.  {{comment from editor: does not understand
    the next sentence...}}Second, it is not necessary to include a
    mechanism to find out-dated delegations.  [LISP-TREE]

    This contrasts with the mappings, which may change at a high rate -
    changes which have no impact on the indexing sub-system.  The
    potentially high dynamics of mappings explains why mappings are
    delivered directly from ETRs (or MSes in proxy mode) to ITRs and
    hence not cached at the MR level.  LISP is designed to make sure that
    changes in the mappings are detected and acted upon fairly quickly;
    this allows LISP to provide a number of capabilities, such as
    mobility.

9.  Examples of operation

    To aid in comprehension, a few examples are given of user packets
    traversing the LISP system.  The first shows the processing of a
    typical user packet which is LISP forwarded, i.e. what the vast
    majority of user packets will see.  The second shows what happens
    when the first packet to a previously-unseen ultimate destination (at
    a particular ITR) is to be processed by LISP.

9.1.  An Ordinary Packet's Processing

    {{Suggestion by editors: This section should be earlier in the
    document structure, examples are important -particularly for
    engineers- to explain how systems work}}

    This case follows the processing of a typical , {{comment from
    editors: text missing}} when the packet has made its way through the
    local site to an ITR, which in this case is a border router for the
    site, the border router looks up the destination address - an EID -
    in its local mapping cache.  For EIDs which are IP addresses, this
    lookup uses the IP longest prefix matching algorithm.

    It finds a mapping, which instructs it to wrap the packet in an outer
    header - an IP packet, containing a UDP packet which contains a LISP
    header - and then the user's original packet (see Section 12.2 for
    the reasons for this particular choice).  The destination address in
    the outer header is set by the ITR to the RLOC of the destination
    ETR.





Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 22]

Internet-Draft              LISP Introduction                  July 2014


    The encapsulated packet is then sent off through the RLOC space
    (e.g., Internet), using normal Internet routing.

    On arrival at the destination ETR, the ETR will notice that it is
    listed as the destination in the outer header.  It will examine the
    packet, detect that it is a LISP packet, and unwrap it.  It will then
    examine the header of the user's original packet, and forward it
    internally, through the local site, to the ultimate destination.

    At the ultimate destination, the packet will be processed, and may
    produce a return packet, which follows the exact same process in
    reverse - with the exception that the roles of the ITR and ETR are
    swapped.

9.2.  A Mapping Cache Miss

    {{Suggestion by editors: (same as previous section)}}

    If a host sends a packet, and it gets to the ITR, and the ITR
    determines that it does not yet have a mapping cache entry which
    covers that destination EID, then additional processing ensues; it
    has to look up the mapping in the mapping system (as previously
    described in Section 6.2).

    The overall processing is shown below, in Figure 2:

                   -----            -----
                  |     |    3     |     |
    Map Resolver  |     | -------> |     |  Map Server
                  |     |          |     |
                   -----            -----
                     ^                |
    Key:             |                |
                     |                |
    -- = Control     |                |
    == = Data        |                |
                  2  |       5        |  4
                     |      ---       |
    Host A           |    /     \     |            Host B
                     |  |_       \    V
     -----          -----          \ -----          -----
    |     |   1    |     |    6     |     |   7    |     |
    |     | =====> | ITR | =======> | ETR | =====> |     |
    |     |        |     |          |     |        |     |
     -----          -----            -----          -----

                 Figure 2: Packet flow with missing mapping




Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 23]

Internet-Draft              LISP Introduction                  July 2014


    1.  Source-EID sends packet (to Dest-EID) to ITR

    2.  ITR sends Map-Request to Map-Resolver

    3.  Map-Resolver delivers Map-Request to Map-Server

    4.  Map-Server delivers Map-Request to ETR

    5.  ETR returns Map-Reply to ITR; ITR caches EID-to-RLOC(s) mapping

    6.  ITR uses mapping to encapsulate to ETR; sends user packet to ETR

    7.  ETR decapsulates packet, delivers to Dest-EID

    The ITR first sends a Map-Request packet, giving the destination EID
    it needs a mapping for, to its MR.  The MR will look in its cache of
    delegation information to find the vertex which is the most specific
    in the delegation tree for that destination EID .  If it does not
    have the address of an appropriate MS, it will query the DDT system,
    recursively if need be, in order to eventually find the address of
    such an MS.

    When it has the MS's address, it will send the Map-Request on to the
    MS, which then usually sends it on to an appropriate ETR.  The ETR
    sends a Map-Reply to the ITR which needs the mapping; from then on,
    processing of user packets through that ITR to that ultimate
    destination proceeds as above.

    To the best of our knowledge, in all LISP implementations, the
    original user packet will have been discarded, and not queued waiting
    for the mapping to be returned.  When the host retransmits such a
    packet, the mapping will be there, and the packet will be forwarded.
    Alternatively, it might have been forwarded using a PITR to avoid
    being dropped (Section 6.4).

10.  Part II

    {{comment from editors: is that the role of an introductory document
    to enter in such level of details and discuss (mostly) all fields of
    the protocol? }}

No.
It should just describe the architecture of the entire LISP system, making it easier to read the rest of the LISP specifications and providing a *basis* for discussion about the details of the LISP protocols.


11.  Design Approach

    {{Suggestion by editors: Remove this section, it does not describe/
    discuss anything relevant, it is only providing a reference to
    another non-WG document.}}



Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 24]

Internet-Draft              LISP Introduction                  July 2014


    Before describing LISP's components in more detail below, it it worth
    pointing out that what may seem, in some cases, like odd (or poor)
    design approaches do in fact result from the application of a
    thought-through, and consistent, design philosophy used in creating
    them. {{Subjective: maybe JMH, Dino can help with better words?}}

    This design philosophy is covered in detail in
    [I-D.ietf-lisp-perspective], Section "Design"), and readers who are
    interested in the 'why' of various mechanisms should consult that;
    reading it may make clearer the reasons for some engineering choices
    in the mechanisms given here.

12.  xTRs

    As mentioned above (in Section 8.1), xTRs are the essential LISP data
    plane elements.  This section explores some advanced topics related
    to xTRs.

    {{Suggestion by editors: remove next paragraph, brings nothing)}}

    Careful rules have been specified for both TTL and ECN [RFC3168] to
    ensure that passage through xTRs does not interfere with the
    operation of these mechanisms.  In addition, care has been taken to
    ensure that traceroute works when xTRs are involved.

12.1.  When to Encapsulate

    An ITR knows that an ultimate destination is running LISP (remember
    that the actual destination machine itself probably knows nothing
    about LISP), and thus that it should perform LISP processing on a
    packet (including potential encapsulation) if it has an entry in its
    local mapping cache that covers the destination address (it is then
    called an EID).

    Conversely, if the cache contains a negative entry (indicating that
    the ITR has previously attempted to find a mapping that covers this
    EID, and it has been informed by the mapping system that no such
    mapping exists), it knows the ultimate destination is not running
    LISP, and the packet can be forwarded natively (i.e. not LISP-
    encapsulated).

    Note that the ITR cannot simply depend on the appearance, or non-
    appearance, of the destination in the routing tables in the Internet
    core, as a way to tell if a destination is a LISP node or not.  That
    is because mechanisms to allow interoperation of LISP sites and
    legacy sites necessarily involve advertising LISP sites' EIDs into
    the Internet core; in other words, LISP sites which need to




Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 25]

Internet-Draft              LISP Introduction                  July 2014


    interoperate with legacy nodes will appear in the Internet core
    routing tables, along with non-LISP sites.

12.2.  UDP Encapsulation Details

    Use of UDP (instead of, say, a LISP-specific protocol number) was
    driven by the fact that many routers and middle boxes filter out
    unknown protocols, so adopting a non-UDP encapsulation would have
    compromised the initial deployment of LISP.

    The UDP source port used for encapsulating packet is computed with a
    5-way hash of the original source and destination in the inner
    header, along with the ports, and the protocol.  This is because many
    ISPs use multiple parallel paths (so-called Equal Cost Multi-Path),
    and load-share across them.  Using such a hash in the source-port in
    the outer header both allows LISP traffic to be load-shared, and also
    ensures that packets from individual connections are delivered in
    order (since most ISPs try to ensure that packets for a particular
    flow follow a single path, and hence do not become disordered).

    The UDP checksum is zero because the inner packet usually already has
    a end-end checksum, and the outer checksum adds no value ([Saltzer]).
    {{Suggestion by editors: not sure that next statement is correct}} In
    most exising hardware, computing such a checksum (and checking it at
    the other end) would also present a major load, for no benefit.

12.3.  Header Control Channel

    {{Suggestion by editors: Rewrite this section to improve readability,
    use standard terminology (e.g., Cache Coherence/Reachability instead
    of "Header Control Channel").  Split the mechanisms depending on its
    goal (cache coherence/reachability) and describe them under the same
    context.}}

    LISP provides a multiplexed channel in the encapsulation header.  It
    is mostly (but not entirely) used for control purposes.  The general
    concept is that the header starts with a flags field, and it also
    includes two data fields, the contents and meaning of which vary,
    depending on which flags are set.  This allows these fields to be
    multiplexed among a number of different low-duty-cycle functions,
    while minimizing the space overhead of the LISP.

12.3.1.  Mapping Versioning

    One important use of the multiplexed control channel is mapping
    versioning; i.e. the discovery of when the mapping cached in an ITR
    is outdated.  To allow an ITR to discover this, identifying sequence
    numbers are applied to different versions of a mappping [RFC6834].



Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 26]

Internet-Draft              LISP Introduction                  July 2014


    This allows an ITR to easily discover when a cached mapping has been
    updated by a more recent variant.

    Version numbers are available in control messages (Map-Replies), but
    the initial concept is that to limit control message overhead, the
    versioning mechanism should primarily use the multiplexed user data
    header control channel.

    Versioning can operate in both directions: an ITR can advise an ETR
    what version of a mapping it is currently using (so the ETR can
    notify it if there is a more recent version), and ETRs can let ITRs
    know what the current mapping version is (so the ITRs can request an
    update, if their copy is outdated).

12.3.2.  Echo Nonces

    Another important use of the header control channel is for a
    mechanism known as the Nonce Echo, which is used as an efficient
    method for ITRs to check the reachability of neighbour ETRs.

    Basically, an ITR which has to determine that an ETR is up, and
    reachable, sends a nonce to that ETR, carried in the encapsulation
    header; when that ETR (also acting as an ITR) sends some other user
    data packet back to the ITR (acting in turn as an ETR), that nonce is
    carried in the header of that packet, allowing the original ITR to
    confirm that its packets are reaching that ETR.

    Note that a lack of a response is not necessarily proof that
    something has gone wrong - but it strongly suggests that something
    has, so other actions (e.g. a switch to an alternative ETR, if one is
    listed; a direct probe; etc) are advised.  (See Section 16.5 for more
    about Echo Nonces.)

12.3.3.  Instances

    {{Suggestion by editors: Move and extend this section: - Instance ID
    is not a cache-coherence/reachability algorithm.  Describe where and
    what is the Instance ID field Explain its applications}}

    The LISP data-plane header is also used to support VPN and multi-
    tenant networks.  Since there is only one destination UDP port used
    for carriage of user data packets, and the source port is used for
    multiplexing, there is no other way to differentiate among different
    destination EID spaces (which are often overlapped in VPNs and multi-
    tenant networks).






Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 27]

Internet-Draft              LISP Introduction                  July 2014


12.4.  Probing

    RLOC-Probing is a mechanism method that an ITR can use to determine
    with that an ETR is up and reachable from the ITR.  As a side-
    benefit, it gives RTT estimates.

    To probe the reachability of an RLOC, an ITR sends a specially marked
    Map-Request directly to the ETR it wishes information about; that ETR
    sends back a specially marked Map-Reply.  A Map-Request message and a
    Map-Reply message are used, rather than a special probing control-
    message pair, because as a side-benefit the ITR can discover if the
    mapping has been updated since it cached it.

    {{Suggestion from editors: remove the following sentence as it is not
    motivated by strong arguments}} The probing mechanism is rather
    heavy-weight and expensive (compared to mechanisms like the Echo-
    Nonce), since it costs a control message from each side, so it should
    only be used sparingly.

    If the number of active neighbour ETRs of the ITR is large, use of
    RLOC-Probing to check on their reachability will result in
    considerable control traffic; such control traffic has to be spread
    out to prevent a load peak.

    Obviously, if RLOC-Probing is the only mechanism being used to detect
    unreachable neighbour ETRs, the rate at which RLOC-Probing is done
    will control the timeliness of the detection of loss of reachability.
    There is thus a tradeoff between overhead and responsiveness,
    particular when an ITR has a large fanout of neighbour ETRs.

12.5.  Mapping Lifetimes and Timeouts

    {{Suggestion by editors: Remove this section, TTL is a simple well-
    known concept, we suggest to include a sentence (and hence remove
    this section) in the control-plane section stating that mappings
    include a TTL.

    Mappings come with a Time-To-Live, which indicate how long the
    creator of the mapping expects them to be useful for.

    Mappings might also be discarded before the TTL expires, depending on
    what strategies the ITR is using to maintain its cache; if the
    maximum cache size is fixed, or the ITR needs to reclaim memory,
    mappings which have not been used recently may be discarded.  (After
    all, there is no harm in so doing; a future reference will merely
    cause that mapping to be reloaded.)

    {{Contents may change before TTL expires?}}



Cabellos-Aparicio (Ed.) Expires January 17, 2015               [Page 28]

Internet-Draft              LISP Introduction                  July 2014


12.6.  Mapping Gleaning in ETRs

    {{Suggestion by editors: Remove this section, gleaning is discouraged
    since it rises many security concerns.}}

    As an optimization to the mapping acquisition process, ETRs are
    allowed to glean mappings from incoming user data packets, and also
    from incoming Map-Request control messages.  This is not secure, and
    so any such mapping must be verified by sending a Map-Request to get
    an authoritative mapping.

    The value of gleaning is that most communications are two-way, and so
    if host A is sending packets to host B (therefore needing B's
    EID->RLOC mapping), very likely B will soon be sending packets back
    to A (and thus needing A's EID->RLOC mapping).  Without gleaning,
    this would sometimes result in a delay, and the dropping of the first
    return packet; this is felt to be very undesirable.

12.7.  MTU Issues

    Several mechanisms have been proposed for dealing with packets which
    are too large to transit the path from a particular ITR to a given
    ETR.

    In one, called the stateful approach, the ITR keeps a per-ETR record
    of the maximum size allowed, and sends an ICMP Too Big message to the

_______________________________________________
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

--------------010307020201040600000808-- From nobody Wed Aug 6 10:58:30 2014 Return-Path: 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 69F2C1A03D8 for ; Wed, 6 Aug 2014 10:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.602 X-Spam-Level: X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 v_-M61pN7f2E for ; Wed, 6 Aug 2014 10:58:26 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBDDE1A0416 for ; Wed, 6 Aug 2014 10:58:23 -0700 (PDT) Received: from CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) by CO1PR05MB268.namprd05.prod.outlook.com (10.141.71.26) with Microsoft SMTP Server (TLS) id 15.0.995.14; Wed, 6 Aug 2014 17:58:21 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) with Microsoft SMTP Server (TLS) id 15.0.995.14; Wed, 6 Aug 2014 17:58:20 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.110]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.110]) with mapi id 15.00.0995.014; Wed, 6 Aug 2014 17:58:19 +0000 From: Ronald Bonica To: LISP mailing list list Thread-Topic: draft-ietf-lisp-introduction-04 (Part 1) Thread-Index: Ac+xnIvNkMXR6dZVTxGD4JQhzdx2tQ== Date: Wed, 6 Aug 2014 17:58:18 +0000 Message-ID: <66bae15549d145a7bcd88223de7ad0ee@CO1PR05MB442.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02951C14DC x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(33646002)(77096002)(83322001)(107886001)(229853001)(107046002)(86362001)(81342001)(106356001)(105586002)(81542001)(92566001)(79102001)(87936001)(110136001)(4396001)(77982001)(54356999)(101416001)(83072002)(85852003)(2656002)(85306004)(50986999)(46102001)(99396002)(66066001)(76576001)(76482001)(74316001)(74502001)(80022001)(21056001)(20776003)(99286002)(31966008)(74662001)(95666004)(64706001)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB444; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/Gy0B43V1QtI-TP-JPmQWM-KBrfc Subject: [lisp] draft-ietf-lisp-introduction-04 (Part 1) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 17:58:28 -0000 Folks, The following are a few comments regarding draft-ietf-lisp-introduction-04.= Expect further comments in the next few days. - Section 1 adds no value. I agree with the editor's suggestion to remove. - Section 2 is empty. So clearly, I agree with the editor's suggestion to r= emove. - Section 3 contains a few broken definitions. But sooner or later, you wil= l need a Glossary. So, I disagree with the editor's suggestion to remove th= e entire section. Please change the name of this section from "Initial Glos= sary" to "Glossary" or "Terminology". Then delete its contents. Then import= whatever definitions you need, verbatim, from RFCs 6830-6836. This should = cover most of the terminology that you need. It will also prevent you from = redefining words. If you find that you still need to define a few terms, pl= ease do so. - Section 4 adds no value. I agree with the editor's suggestion to remove. - Section 5 adds no value. I agree with the editor's suggestion to remove. - Section 7.3 needs to be rethought. LISP doesn't provide TE, in the same s= ense that MPLS does. It's quite different. - Section 7.4 adds no value. I agree with the editor's suggestion to remove= . - Section 7.5 is not in charter. I agree with the editor's suggestion to re= move. - Section 7.7 is not in charter. I agree with the editor's suggestion to re= move. - Section 7.8 adds no value. I agree with the editor's suggestion to remove= . - Appendix A is redundant with Section 3. I agree with the editor's suggest= ion to remove - Appendix B contains interesting information, but does not contribute to t= he goals of the draft. I agree with the editor's suggestion to remove it. - Please add a short "Introduction" before the Glossary. It should read as = follows: "The Internet is experiencing problems A, B and C. LISP solves this problem= by doing D, E and F. LISP will solve A, B and C because [....] D, E, and F distinguish LISP from existing routing protocols. The archit= ectural tradeoffs associated with D, E and F are [....].=20 Standby for more comments. Ron Bonica From nobody Wed Aug 6 11:30:33 2014 Return-Path: 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 ED0111ABD18 for ; Wed, 6 Aug 2014 11:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.602 X-Spam-Level: X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 7EyEI0lsXN1W for ; Wed, 6 Aug 2014 11:30:28 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CE8A1A063B for ; Wed, 6 Aug 2014 11:30:28 -0700 (PDT) Received: from CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) by CO1PR05MB332.namprd05.prod.outlook.com (10.141.69.20) with Microsoft SMTP Server (TLS) id 15.0.995.14; Wed, 6 Aug 2014 18:30:24 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) with Microsoft SMTP Server (TLS) id 15.0.995.14; Wed, 6 Aug 2014 18:30:23 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.110]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.110]) with mapi id 15.00.0995.014; Wed, 6 Aug 2014 18:30:23 +0000 From: Ronald Bonica To: LISP mailing list list Thread-Topic: draft-ietf-lisp-introduction-04 (Part 2) Thread-Index: Ac+xpHNWYu57YFJuQG6PpydKNK4Qrg== Date: Wed, 6 Aug 2014 18:30:23 +0000 Message-ID: <2c0d62b578de4c7eb9ef414690cbb1c5@CO1PR05MB442.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02951C14DC x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(77096002)(33646002)(229853001)(83322001)(107886001)(107046002)(86362001)(106356001)(81342001)(105586002)(81542001)(79102001)(92566001)(87936001)(110136001)(4396001)(77982001)(54356999)(101416001)(83072002)(85852003)(2656002)(85306004)(50986999)(46102001)(99396002)(66066001)(76576001)(76482001)(74316001)(74502001)(80022001)(21056001)(20776003)(99286002)(31966008)(95666004)(74662001)(64706001)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB444; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/8stjT-AMMaUXImD21YOA_7scyCU Subject: [lisp] draft-ietf-lisp-introduction-04 (Part 2) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 18:30:31 -0000 Folks, The following text is lifted from Section 6.1. At best, it is difficult to = parse. At worst, it is incorrect. Is there a better way to distinguish betw= een an IED and a LOC? Rn "The second key concept is that if one wants to be as forward-looking as po= ssible, conceptually one should think of the two kinds of names (EIDs and = RLOCs) as naming different classes of entities. On the one hand, EIDs are used to name nodes - or rather, their end- end c= ommunication entities. RLOC(s), on the other hand, name interfaces, i.e. p= laces to which the system of routers sends packets. This distinction, the formal recognition of different kinds of entities ("= endpoints" and interfaces), and their association with the two different cl= asses of names, is also important. Clearly recognizing interfaces and endp= oints as distinctly separate classes of objects is another improvement to t= he existing Internet" architecture." From nobody Wed Aug 6 11:58:03 2014 Return-Path: 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 100F41B27D6 for ; Wed, 6 Aug 2014 11:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Xo_QTSyX53uE for ; Wed, 6 Aug 2014 11:57:58 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (dns-bn1lp0143.outbound.protection.outlook.com [207.46.163.143]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 456D51B27D2 for ; Wed, 6 Aug 2014 11:57:57 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.0.995.14; Wed, 6 Aug 2014 18:57:54 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.110]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.110]) with mapi id 15.00.0995.014; Wed, 6 Aug 2014 18:57:54 +0000 From: Ronald Bonica To: LISP mailing list list Thread-Topic: draft-ietf-lisp-introduction-04 (Part 3) Thread-Index: Ac+xplSWhfzVPftgQfa8OfG0BIHHYQ== Date: Wed, 6 Aug 2014 18:57:54 +0000 Message-ID: <4a21b4f2c26d40b5bb5cecca5b1d4018@CO1PR05MB442.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02951C14DC x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(99396002)(77096002)(33646002)(54356999)(74316001)(229853001)(2656002)(110136001)(20776003)(86362001)(95666004)(105586002)(77982001)(76482001)(46102001)(87936001)(99286002)(64706001)(80022001)(85306004)(106356001)(74502001)(74662001)(79102001)(31966008)(66066001)(101416001)(92566001)(21056001)(107886001)(76576001)(83322001)(107046002)(85852003)(81542001)(50986999)(83072002)(81342001)(4396001)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB443; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/xAQAZRXmQbqcQaZSduK5403UUNw Subject: [lisp] draft-ietf-lisp-introduction-04 (Part 3) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 18:58:00 -0000 Folks, The editors correctly observe that Section 6.2 needs to be rewritten. A bet= ter approach would be to note that LISP is a map-and-encap strategy. An ing= ress encapsulation endpoint: - accepts a packet that is addressed from one address space (EID) - maps the EID addresses to corresponding addresses in another space (LOC) - encapsulates the incoming packet in another that is addressed using LOC s= pace - forwards the packet to the egress encapsulation endpoint where it is de-e= ncapsulated In this regard, LISP is similar to many other encapsulation and VPN technol= ogies (e.g., GRE, L3VPN).=20 LISP is different from GRE and L3VPN because it pulls mapping information t= o itself. By contrast, GRE mapping information is generally configured stat= ically. L3VPN mapping information is pushed by BGP. Therefore, LISP must de= al with the problems of stale mapping information and cache misses. Also, L= ISP must deal with the problem of egress encapsulation node liveness. Ron Bonica From nobody Wed Aug 6 14:06:40 2014 Return-Path: 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 1B5D31A0263 for ; Wed, 6 Aug 2014 14:06:39 -0700 (PDT) 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 cr3JRLRyIH8w for ; Wed, 6 Aug 2014 14:06:37 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8C9E1A0250 for ; Wed, 6 Aug 2014 14:06:37 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id et14so4087936pad.21 for ; Wed, 06 Aug 2014 14:06:37 -0700 (PDT) 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=Y7Cf7/G6vwnXeGfjIJIxMG2QuR2ic3XU5HdSO7P2oP4=; b=mDoUrxWeLk9zzMNyAH2H7HUtYPe2pb9dJbkvTLeGV0Cjoa7i9zHsVgX8PJ59+qer3W iqeETLsxUvebivSEa55iOj7TMr5O5YVrdnVh9Ht/DxQNuEgIzYNeta28S7vkSEqisMLE bKQbB+gki21yP3OO2+mtZRX3hnTJ3b2Vr2u+krWKAEw9ZDwIZ4hpZdVecWa4/U5D0+zs WRcUPzqBMVIhhRLmlHBW0DeHWGy6jXJ1TgL0LfOZtNc7yhe1ksNcgtp19OFB+lMN8tq+ 66nkwzZ9udJj8Zg7ttVrpNbnVZxTw6aZwkPusZpB1yTYni7SV/acDk3dIDY0A8gIWMcY Gg0A== X-Received: by 10.66.168.204 with SMTP id zy12mr6660188pab.19.1407359197388; Wed, 06 Aug 2014 14:06:37 -0700 (PDT) Received: from [10.151.220.72] (50-206-16-189-static.hfc.comcastbusiness.net. [50.206.16.189]) by mx.google.com with ESMTPSA id ms9sm3220802pdb.19.2014.08.06.14.06.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 14:06:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dino Farinacci In-Reply-To: <4a21b4f2c26d40b5bb5cecca5b1d4018@CO1PR05MB442.namprd05.prod.outlook.com> Date: Wed, 6 Aug 2014 14:06:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <25146EB9-0AC1-4443-8D2C-ADC15A66794E@gmail.com> References: <4a21b4f2c26d40b5bb5cecca5b1d4018@CO1PR05MB442.namprd05.prod.outlook.com> To: Ronald Bonica X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/hofSB7RUszssWy_k0CLvHVNcyyY Cc: LISP mailing list list Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 21:06:39 -0000 > LISP is different from GRE and L3VPN because it pulls mapping = information to itself. By contrast, GRE mapping information is generally = configured statically. L3VPN mapping information is pushed by BGP. = Therefore, LISP must deal with the problems of stale mapping information = and cache misses. Also, LISP must deal with the problem of egress = encapsulation node liveness. Ron, I have to keep you honest here. It doesn't matter if you pull or = push, ANY information that is distributed can be stale.=20 If a route changes in BGP and there is a congested path and the Update = is continually being retransmitted by TCP to get to the BGP peer, that = BGP peer has stale information. Dino From nobody Thu Aug 7 08:28:04 2014 Return-Path: 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 B3AD61B2D81 for ; Thu, 7 Aug 2014 08:27:56 -0700 (PDT) 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 2--NbU9N2wtQ for ; Thu, 7 Aug 2014 08:27:52 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001: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 CFE4F1B2BED for ; Thu, 7 Aug 2014 08:27:17 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id rd18so4803077iec.9 for ; Thu, 07 Aug 2014 08:27:17 -0700 (PDT) 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:content-transfer-encoding; bh=/g8RKZkOC87598b3OyPAuX8tJGSKMi7kgaE9SXeW3ek=; b=MCdO/7vy6v2rx1tX4aEpEQFYnVdjPkb8Z0sc3E4OALKWymABid5AlQjbMwQVoxU6/p h8Gz2is379zcw83TX8TCEbJKXRqX+1RCX3LMs2APWyV6Me55nKmT87+i8NrfITGFcQLX UyqbikO3+llFTbcc8DfdSQjHWa7pN8qEfsFMgV87XoBOHSWmtF/IZFHYHJGxl/pMZnJo uDQRiGrYBwkPzSBN0DFzm1t/bN0Fv1vZhrEhuv4ck9tTVgIURPWW8sOYLHgCh6m1VyU0 pNaZZKqc/Z3FCei8EsAd6xui3+mPUVXga4HQ3qQqz6G8UHTnHNYjD+Utymmw+hCl33+Z yr/g== MIME-Version: 1.0 X-Received: by 10.42.16.2 with SMTP id n2mr4773462ica.93.1407425237025; Thu, 07 Aug 2014 08:27:17 -0700 (PDT) Received: by 10.107.3.13 with HTTP; Thu, 7 Aug 2014 08:27:16 -0700 (PDT) In-Reply-To: <66bae15549d145a7bcd88223de7ad0ee@CO1PR05MB442.namprd05.prod.outlook.com> References: <66bae15549d145a7bcd88223de7ad0ee@CO1PR05MB442.namprd05.prod.outlook.com> Date: Thu, 7 Aug 2014 17:27:16 +0200 Message-ID: From: Albert Cabellos To: Ronald Bonica Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/hA6XBjfTPdgz-ZDFSsXR0ei8zh0 Cc: LISP mailing list list Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 1) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 15:27:57 -0000 Hi Ron, Thanks for your comments, please see my reply below: On Wed, Aug 6, 2014 at 7:58 PM, Ronald Bonica wrote: > Folks, > > The following are a few comments regarding draft-ietf-lisp-introduction-0= 4. Expect further comments in the next few days. > > - Section 1 adds no value. I agree with the editor's suggestion to remove= . > > - Section 2 is empty. So clearly, I agree with the editor's suggestion to= remove. > > - Section 3 contains a few broken definitions. But sooner or later, you w= ill need a Glossary. So, I disagree with the editor's suggestion to remove = the entire section. Please change the name of this section from "Initial Gl= ossary" to "Glossary" or "Terminology". Then delete its contents. Then impo= rt whatever definitions you need, verbatim, from RFCs 6830-6836. This shoul= d cover most of the terminology that you need. It will also prevent you fro= m redefining words. If you find that you still need to define a few terms, = please do so. > Agreed, we should use the terminology as defined in RFCs 68030-6836. This will actually make the rest of the RFCs easier to read, one of the goals of LISP-INTRO. > - Section 4 adds no value. I agree with the editor's suggestion to remove= . > > - Section 5 adds no value. I agree with the editor's suggestion to remove= . > > - Section 7.3 needs to be rethought. LISP doesn't provide TE, in the same= sense that MPLS does. It's quite different. > RFC6830 states that LISP offers TE. Albert > - Section 7.4 adds no value. I agree with the editor's suggestion to remo= ve. > > - Section 7.5 is not in charter. I agree with the editor's suggestion to = remove. > > - Section 7.7 is not in charter. I agree with the editor's suggestion to = remove. > > - Section 7.8 adds no value. I agree with the editor's suggestion to remo= ve. > > - Appendix A is redundant with Section 3. I agree with the editor's sugge= stion to remove > > - Appendix B contains interesting information, but does not contribute to= the goals of the draft. I agree with the editor's suggestion to remove it. > > - Please add a short "Introduction" before the Glossary. It should read a= s follows: > > "The Internet is experiencing problems A, B and C. LISP solves this probl= em by doing D, E and F. LISP will solve A, B and C because [....] > > D, E, and F distinguish LISP from existing routing protocols. The arch= itectural tradeoffs associated with D, E and F are [....]. > > > Standby for more comments. > > > > Ron Bonica > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Thu Aug 7 08:48:48 2014 Return-Path: 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 6539F1B2C2B for ; Thu, 7 Aug 2014 08:48:47 -0700 (PDT) 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 hrIhJuaKcFAc for ; Thu, 7 Aug 2014 08:48:44 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2B591B2827 for ; Thu, 7 Aug 2014 08:48:44 -0700 (PDT) Received: by mail-ig0-f180.google.com with SMTP id l13so4712623iga.1 for ; Thu, 07 Aug 2014 08:48:44 -0700 (PDT) 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:content-transfer-encoding; bh=7Pck/ge8nTfq0NrqV6NYgUtFyCwND7mm9ZYmef30xyU=; b=DwpZOSHnhRB3OEwImZZJGCnw3Pn+BKqt3hkfwD9nBOF0Tqi678xtjMUvmsO7/EyR23 vnfR+Q3HypuhphuZnz+RyVKPjphYXvFetZWle/QG/uYbu2u1Wp/H4avimktE0Z90Dpmh uQVRiB/t79ZUAe6RUI2iXgfKFY28LxNGTAyA9FJZwbVFRjfaUTWP4+QIgo7IaV9hIgv7 TKuM9BTeHoi2+ClvbWkBptU2wvrBHE+KQs1OY/2AFdzUHG9m6vmx1WCwG1mo5P3pR1Zp 3yfEMo8sKIfXtgfkbmBKeuBSepDyoZA6XvlWzWN/KQ/2U5mUyzYmzv5qTesJyV1yj3nq 296g== MIME-Version: 1.0 X-Received: by 10.42.216.148 with SMTP id hi20mr5080214icb.12.1407426523205; Thu, 07 Aug 2014 08:48:43 -0700 (PDT) Received: by 10.107.3.13 with HTTP; Thu, 7 Aug 2014 08:48:43 -0700 (PDT) In-Reply-To: <2c0d62b578de4c7eb9ef414690cbb1c5@CO1PR05MB442.namprd05.prod.outlook.com> References: <2c0d62b578de4c7eb9ef414690cbb1c5@CO1PR05MB442.namprd05.prod.outlook.com> Date: Thu, 7 Aug 2014 17:48:43 +0200 Message-ID: From: Albert Cabellos To: Ronald Bonica Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/i8JgI719p-A0V3s_tsi8ipIQPBQ Cc: LISP mailing list list Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 15:48:47 -0000 Hi Ron On Wed, Aug 6, 2014 at 8:30 PM, Ronald Bonica wrote: > Folks, > > The following text is lifted from Section 6.1. At best, it is difficult t= o parse. At worst, it is incorrect. Is there a better way to distinguish be= tween an IED and a LOC? > What about stating that RLOCs are topologically assigned to network attachment points while EIDs are independent of the topology and used to identify devices. Albert > Rn > > "The second key concept is that if one wants to be as forward-looking as = possible, conceptually one should think of the two kinds of names (EIDs an= d RLOCs) as naming different classes of entities. > > On the one hand, EIDs are used to name nodes - or rather, their end- end= communication entities. RLOC(s), on the other hand, name interfaces, i.e.= places to which the system of routers sends packets. > > This distinction, the formal recognition of different kinds of entities = ("endpoints" and interfaces), and their association with the two different = classes of names, is also important. Clearly recognizing interfaces and en= dpoints as distinctly separate classes of objects is another improvement to= the existing Internet" architecture." > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Thu Aug 7 08:52:11 2014 Return-Path: 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 BBF9E1B286F for ; Thu, 7 Aug 2014 08:52:08 -0700 (PDT) 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 ngTM2feDiMVL for ; Thu, 7 Aug 2014 08:52:06 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B65C31B282F for ; Thu, 7 Aug 2014 08:52:06 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id z10so5439318pdj.16 for ; Thu, 07 Aug 2014 08:52:06 -0700 (PDT) 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=m83QV4jNhzOFl3dU3Bu9xHV5toqZipiOwDYjbmShlV0=; b=tC+dAhWUmKTt2CBnC9Ay+19EuGl8Ws1+Ih+nDq4pTRx5U5s91iq6+x8zix/omNB7v5 aKJyNvgyG8SUf5x2Dw0wFLEDfPpnPJjVZvm+dxBncwBqhN7wff5hTOERjVZFMPMfPL1a At2D4iy6M2HZIgtWmzDi+HY5yJXYwwCl9869SCBbFBWS9+csq6TV39zN6KC9lBjydKFg oXQ+ZAbXxsRSqJyOnQR9S8rrQfjGe3o3MZrdq+p/V2DJYyw9D8KcC1DhOLFKFXfU8I3T bNOGLz5V012W2lEIdpJbrYtz8H61wsGht9lG4GzFP1DMUTUkn9pkC5i4pvhiwu018vab ywaw== X-Received: by 10.68.68.234 with SMTP id z10mr2960072pbt.59.1407426726420; Thu, 07 Aug 2014 08:52:06 -0700 (PDT) Received: from [192.168.1.231] ([207.145.253.66]) by mx.google.com with ESMTPSA id n3sm183262pde.47.2014.08.07.08.52.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Aug 2014 08:52:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dino Farinacci In-Reply-To: Date: Thu, 7 Aug 2014 08:52:04 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <2c0d62b578de4c7eb9ef414690cbb1c5@CO1PR05MB442.namprd05.prod.outlook.com> To: Albert Cabellos X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/KCNftAtuIQbMLNfXet5kvpzxSWw Cc: LISP mailing list list Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 15:52:09 -0000 > What about stating that RLOCs are topologically assigned to network > attachment points while EIDs are independent of the topology and used > to identify devices. A perfect and concise definition. Dino From nobody Sat Aug 9 07:12:06 2014 Return-Path: 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 689851B2861 for ; Sat, 9 Aug 2014 07:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 Kv6gMW67fJGd for ; Sat, 9 Aug 2014 07:11:55 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C911A8546 for ; Sat, 9 Aug 2014 07:07:57 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b13so6673809wgh.34 for ; Sat, 09 Aug 2014 07:07:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=9NS6VJ6OaifkUjGtjWn2A+maon4a9EzfY0aofS1BYyo=; b=CZSTbscZA5/8StqUKKm9F6ltTl6CadmqUHdh9PJNEse3wI5ARNfb5Us+jK1LKJjFwa EObXVyjuJ3fj7a2m9INaNH0olMxop1pOTlkiUzFZTilRbE4apH8xMDevDs9oXk9jG3Ox oYPhrZQbpTMX+7YeipoqoZ993v1ws2tUeewd9d28ZEPhrHOKI8Eha15t5A453knNbMvy kpmcHdE1+phDVB1k+zUfsEKFQOk+DzgpCi7gfCrsJ7+Adj5WpJujHi+Y4PWsaFL9/tDD sd8oPC1pC2T2iVz3E3TMUdqFzmTnCyLEMQRzTu4PMgMdrqIHH68T7IxcDRh4M968jdTo Wjew== X-Gm-Message-State: ALoCoQkYKckmBJqSNvUhep7LfpXVbcnXZbA/ZkpptKokh9B2SUySOw8+tgd9OWGvGLgIQAVZ4f8a X-Received: by 10.180.88.167 with SMTP id bh7mr11492427wib.12.1407593276118; Sat, 09 Aug 2014 07:07:56 -0700 (PDT) Received: from [192.168.1.6] ([95.239.118.63]) by mx.google.com with ESMTPSA id gc8sm19425231wic.3.2014.08.09.07.07.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Aug 2014 07:07:55 -0700 (PDT) From: Luigi Iannone Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sat, 9 Aug 2014 16:07:52 +0200 To: LISP mailing list list Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/c9bth7pQK2VluZtgqHE4zbXg1lQ Subject: [lisp] LISP WG Minutes 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 14:12:04 -0000 All, minutes of the WG session in Toronto are now online: http://www.ietf.org/proceedings/90/minutes/minutes-90-lisp If you have any corrections please submit them to the Chairs by Monday = 1st September 2014. Ciao Luigi= From nobody Mon Aug 11 07:38:41 2014 Return-Path: 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 33FEE1A03CF for ; Mon, 11 Aug 2014 07:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 NOC5CDsynSxp for ; Mon, 11 Aug 2014 07:38:37 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0186.outbound.protection.outlook.com [207.46.163.186]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AB371A0386 for ; Mon, 11 Aug 2014 07:38:37 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Mon, 11 Aug 2014 14:38:33 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.224]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.224]) with mapi id 15.00.1005.008; Mon, 11 Aug 2014 14:38:34 +0000 From: Ronald Bonica To: "acabello@ac.upc.edu" Thread-Topic: [lisp] draft-ietf-lisp-introduction-04 (Part 2) Thread-Index: Ac+xpHNWYu57YFJuQG6PpydKNK4QrgAsp1qAAMa2SDA= Date: Mon, 11 Aug 2014 14:38:34 +0000 Message-ID: <7c32ce118ae647c7bbff214282dd08d9@CO1PR05MB442.namprd05.prod.outlook.com> References: <2c0d62b578de4c7eb9ef414690cbb1c5@CO1PR05MB442.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03008837BD x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(13464003)(377454003)(51704005)(24454002)(199002)(189002)(110136001)(107046002)(95666004)(99286002)(80022001)(2351001)(19580405001)(83322001)(33646002)(19580395003)(106356001)(105586002)(50986999)(54356999)(85306004)(15975445006)(99396002)(64706001)(66066001)(81542001)(21056001)(20776003)(76176999)(81342001)(76576001)(74316001)(86362001)(4396001)(87936001)(2656002)(85852003)(2171001)(83072002)(92566001)(77096002)(74662001)(74502001)(46102001)(77982001)(76482001)(101416001)(31966008)(79102001)(2501001)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB444; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/jzeuEWtb7aKb582vbrRidL6Ehk0 Cc: LISP mailing list list Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 14:38:39 -0000 SGkgQWxiZXJ0LCANCg0KWW91ciBkZWZpbml0aW9uIG1pc3NlcyBvbmUgc21hbGwgYnV0IGltcG9y dGFudCBwb2ludC4gVGhlIGRlZ3JlZSB0byB3aGljaCBhbiBFSUQgY2FycmllcyB0b3BvbG9naWNh bCBpbmZvcm1hdGlvbiBkZXBlbmRzIGxhcmdlbHkgdXBvbiB0aGUgb2JzZXJ2ZXIncyBsb2NhdGlv bi4NCg0KRm9yIGV4YW1wbGUsIGFzc3VtZSB0aGF0IGEgTElTUCBzaXRlIGlzIHNlcnZlZCBieSB0 d28gWFRScyBhbmQgYm90aCBYVFJzIGdvIGRvd24uIE5vZGVzIHdpdGhpbiB0aGUgc2l0ZSBjYW4g c3RpbGwgY29tbXVuaWNhdGUgd2l0aCBvbmUgYW5vdGhlciwgZXZlbiB0aG91Z2ggbm8gZGV2aWNl IHRoYXQgaXMgb3BlcmF0aW5nIGhhcyBhIExPQ0FUT1IuIEluIHRoaXMgY2FzZSwgd2hlcmUgZG9l cyB0b3BvbG9naWNhbCBpbmZvcm1hdGlvbiBjb21lIGZyb20/DQoNCkFsc28sIHdoZW4gYW4gRUlE IGlzIGFkdmVydGlzZWQgaW50byB0aGUgZ2xvYmFsIEludGVybmV0IGJ5IGEgUElUUiwgZG9lcyBp dCBjb250aW51ZSB0byBiZSBhbiBFSUQ/IElmIHNvLCBkb2VzIGl0IGNvbnRpbnVlIHRvIGJlIGRl dm9pZCBvZiBsb2NhdGlvbiBzZW1hbnRpY3M/DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFJvbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IEFsYmVydCBDYWJlbGxvcyBbbWFpbHRvOmFsYmVydC5jYWJlbGxvc0BnbWFpbC5jb21d DQo+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMDcsIDIwMTQgMTE6NDkgQU0NCj4gVG86IFJvbmFs ZCBCb25pY2ENCj4gQ2M6IExJU1AgbWFpbGluZyBsaXN0IGxpc3QNCj4gU3ViamVjdDogUmU6IFts aXNwXSBkcmFmdC1pZXRmLWxpc3AtaW50cm9kdWN0aW9uLTA0IChQYXJ0IDIpDQo+IA0KPiBIaSBS b24NCj4gDQo+IA0KPiANCj4gT24gV2VkLCBBdWcgNiwgMjAxNCBhdCA4OjMwIFBNLCBSb25hbGQg Qm9uaWNhIDxyYm9uaWNhQGp1bmlwZXIubmV0Pg0KPiB3cm90ZToNCj4gPiBGb2xrcywNCj4gPg0K PiA+IFRoZSBmb2xsb3dpbmcgdGV4dCBpcyBsaWZ0ZWQgZnJvbSBTZWN0aW9uIDYuMS4gQXQgYmVz dCwgaXQgaXMgZGlmZmljdWx0IHRvIHBhcnNlLg0KPiBBdCB3b3JzdCwgaXQgaXMgaW5jb3JyZWN0 LiBJcyB0aGVyZSBhIGJldHRlciB3YXkgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiBhbiBJRUQNCj4g YW5kIGEgTE9DPw0KPiA+DQo+IA0KPiBXaGF0IGFib3V0IHN0YXRpbmcgdGhhdCBSTE9DcyBhcmUg dG9wb2xvZ2ljYWxseSBhc3NpZ25lZCB0byBuZXR3b3JrDQo+IGF0dGFjaG1lbnQgcG9pbnRzIHdo aWxlIEVJRHMgYXJlIGluZGVwZW5kZW50IG9mIHRoZSB0b3BvbG9neSBhbmQgdXNlZCB0bw0KPiBp ZGVudGlmeSBkZXZpY2VzLg0KPiANCj4gQWxiZXJ0DQo+IA0KPiA+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBSbg0KPiA+DQo+ID4gIlRoZSBzZWNvbmQga2V5IGNv bmNlcHQgaXMgdGhhdCBpZiBvbmUgd2FudHMgdG8gYmUgYXMgZm9yd2FyZC1sb29raW5nIGFzDQo+ IHBvc3NpYmxlLCBjb25jZXB0dWFsbHkgb25lIHNob3VsZCB0aGluayBvZiB0aGUgdHdvIGtpbmRz IG9mIG5hbWVzICAoRUlEcyBhbmQNCj4gUkxPQ3MpIGFzIG5hbWluZyBkaWZmZXJlbnQgY2xhc3Nl cyBvZiBlbnRpdGllcy4NCj4gPg0KPiA+ICBPbiB0aGUgb25lIGhhbmQsIEVJRHMgYXJlIHVzZWQg dG8gbmFtZSBub2RlcyAtIG9yIHJhdGhlciwgdGhlaXIgZW5kLSBlbmQNCj4gY29tbXVuaWNhdGlv biBlbnRpdGllcy4gIFJMT0MocyksIG9uIHRoZSBvdGhlciBoYW5kLCBuYW1lIGludGVyZmFjZXMs IGkuZS4NCj4gcGxhY2VzIHRvIHdoaWNoIHRoZSBzeXN0ZW0gb2Ygcm91dGVycyBzZW5kcyBwYWNr ZXRzLg0KPiA+DQo+ID4gIFRoaXMgZGlzdGluY3Rpb24sIHRoZSBmb3JtYWwgcmVjb2duaXRpb24g b2YgZGlmZmVyZW50IGtpbmRzIG9mIGVudGl0aWVzDQo+ICgiZW5kcG9pbnRzIiBhbmQgaW50ZXJm YWNlcyksIGFuZCB0aGVpciBhc3NvY2lhdGlvbiB3aXRoIHRoZSB0d28gZGlmZmVyZW50DQo+IGNs YXNzZXMgb2YgbmFtZXMsIGlzIGFsc28gaW1wb3J0YW50LiAgQ2xlYXJseSByZWNvZ25pemluZyBp bnRlcmZhY2VzIGFuZA0KPiBlbmRwb2ludHMgYXMgZGlzdGluY3RseSBzZXBhcmF0ZSBjbGFzc2Vz IG9mIG9iamVjdHMgaXMgYW5vdGhlciBpbXByb3ZlbWVudCB0bw0KPiB0aGUgZXhpc3RpbmcgSW50 ZXJuZXQiICBhcmNoaXRlY3R1cmUuIg0KPiA+DQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gbGlzcCBtYWlsaW5nIGxpc3QN Cj4gPiBsaXNwQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9saXNwDQo= From nobody Mon Aug 11 08:40:50 2014 Return-Path: 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 3B63D1A0522 for ; Mon, 11 Aug 2014 08:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 VQ9Izxkex-tH for ; Mon, 11 Aug 2014 08:40:41 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DC2C1A03CF for ; Mon, 11 Aug 2014 08:40:41 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Mon, 11 Aug 2014 15:40:39 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.224]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.224]) with mapi id 15.00.1005.008; Mon, 11 Aug 2014 15:40:39 +0000 From: Ronald Bonica To: "acabello@ac.upc.edu" Thread-Topic: [lisp] draft-ietf-lisp-introduction-04 (Part 1) Thread-Index: Ac+xnIvNkMXR6dZVTxGD4JQhzdx2tQAt4XUAAMk3P6A= Date: Mon, 11 Aug 2014 15:40:39 +0000 Message-ID: References: <66bae15549d145a7bcd88223de7ad0ee@CO1PR05MB442.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03008837BD x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(51704005)(189002)(199002)(76576001)(85306004)(86362001)(79102001)(80022001)(101416001)(66066001)(74316001)(85852003)(46102001)(77096002)(87936001)(64706001)(76482001)(2171001)(2656002)(92566001)(77982001)(83072002)(20776003)(4396001)(99286002)(95666004)(2351001)(107046002)(31966008)(74662001)(74502001)(110136001)(105586002)(106356001)(83322001)(76176999)(54356999)(21056001)(99396002)(33646002)(50986999)(81342001)(81542001)(2501001)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB441; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/U8vHbmyD0HV_u2qhb2r4gV36JbQ Cc: LISP mailing list list Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 1) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 15:40:43 -0000 SGkgQWxiZXJ0LA0KDQpMSVNQIHNvbHZlcyBvbmUgcGFydCBvZiB0aGUgVEUgcHJvYmxlbS4gVGhh dCBpcywgaXQgYWxsb3dzIHRoZSBJVFIgdG8gY2hvb3NlIHRoZSBFVFIgdGhyb3VnaCB3aGljaCB0 cmFmZmljIGVudGVycyB0aGUgZGVzdGluYXRpb24gTElTUCBzaXRlLiBIb3dldmVyLCBpdCBkb2Vz bid0IGRldGVybWluZSB0aGUgcGF0aCB0aGF0IHRyYWZmaWMgdGFrZXMgYmV0d2VlbiBJRVRSIGFu ZCBFVFIuIFNvLCBpdCB0aGF0IHNlbnNlLCBMSVNQIFRFIGlzIGRpZmZlcmVudCBmcm9tIHRyYWZm aWMgZW5naW5lZXJpbmcgd2l0aCBNUExTLg0KDQpBbHNvLCBJIGFtIG5vdCBzdXJlIHRoYXQgaXQg aXMgKmFsd2F5cyogYSBnb29kIGlkZWEgdG8gbGV0IHRoZSBJVFIgY2hvb3NlIHRoZSBFVFIgdGhy b3VnaCB3aGljaCB0cmFmZmljIGVudGVycyB0aGUgZGVzdGluYXRpb24gTElTUCBzaXRlLiBBIGRp c2N1c3Npb24gb2Ygd2hlbiB0aGlzIGlzIGFuZCBpc24ndCBhIGdvb2QgaWRlYSBtaWdodCBiZSBh cHByb3ByaWF0ZSBpbiB0aGUgaW50cm8gZG9jdW1lbnQuDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb24NCg0KPiA+ IC0gU2VjdGlvbiA3LjMgbmVlZHMgdG8gYmUgcmV0aG91Z2h0LiBMSVNQIGRvZXNuJ3QgcHJvdmlk ZSBURSwgaW4gdGhlIHNhbWUNCj4gc2Vuc2UgdGhhdCBNUExTIGRvZXMuIEl0J3MgcXVpdGUgZGlm ZmVyZW50Lg0KPiA+DQo+IA0KPiBSRkM2ODMwIHN0YXRlcyB0aGF0IExJU1Agb2ZmZXJzIFRFLg0K PiANCg0K From nobody Mon Aug 11 08:51:44 2014 Return-Path: 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 EA7281A0652 for ; Mon, 11 Aug 2014 08:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.62 X-Spam-Level: X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, J_CHICKENPOX_45=0.6, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 3v3q-iqb_UIQ for ; Mon, 11 Aug 2014 08:51:39 -0700 (PDT) Received: from osiris.lip6.fr (osiris.lip6.fr [IPv6:2001:660:3302:283c::1e]) by ietfa.amsl.com (Postfix) with ESMTP id D763C1A050E for ; Mon, 11 Aug 2014 08:51:38 -0700 (PDT) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by osiris.lip6.fr (8.14.7/lip6) with ESMTP id s7BFpYDp005316 for ; Mon, 11 Aug 2014 17:51:35 +0200 (CEST) X-pt: osiris.lip6.fr Received: from [192.168.1.184] (AFontenayssB-152-1-52-220.w82-121.abo.wanadoo.fr [82.121.226.220]) (authenticated bits=0) by tibre.lip6.fr (8.14.7/8.13.3) with ESMTP id s7BFoHTv021415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 11 Aug 2014 17:50:18 +0200 (MEST) Message-ID: <53E8E639.20701@lip6.fr> Date: Mon, 11 Aug 2014 17:50:17 +0200 From: Matthieu Coudron User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: lisp@ietf.org References: <20140704130144.20502.78491.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (osiris.lip6.fr [132.227.60.30]); Mon, 11 Aug 2014 17:51:35 +0200 (CEST) X-Scanned-By: MIMEDefang 2.74 on 132.227.60.30 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/W-Iph0l89xbYf89f12cgteJ7S7o Cc: Stefano Secci Subject: Re: [lisp] Fwd: New Version Notification for draft-rodrigueznatal-lisp-oam-00.txt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 15:51:41 -0000 Dear all, we reviewed the draft and following offline discussions with Albert, you will find below a few comments. Best regards, Matthieu Coudron Stefano Secci ____________________________ 2. Underlay definition "The underlay corresponds to the RLOC space" This appears as too restrictive, as information about the underlay could come also from local AS/domain-level information such as traffic engineering databases, monitoring tools, etc, unaware of LISP. ____________________________ 3.2 MPTCP "Each of these sub-flows behaves as a legacy TCP flow and hence, from the network point of view, each sub-flow is a different TCP session. The network conditions over the different paths the sub-flows follow affect the whole MPTCP session. Since MPTCP has to keep the aggregate session consistent, each aggregated flow can perform as good as the worst of the sub flows it integrates." This paragraph seems incorrect. MPTCP RFC 6182 section 2.1 states that MPTCP should be at least as good as TCP, which in practice is true except in a few cases (e.g., if a subflow with a large share of the window becomes inactive, then you need to wait several timeouts before being able to be aggressive enough on other subflows). The RFC does not precisely address the scheduling mechanisms, but if for instance you consider the Linux implementation (http://www.multipath-tcp.org), it sends a maximum amount of data on the subflow with the lowest RTT and once its window is full, it will send on the 2nd lowest RTT subflow etc... so providing there is enough buffering at each endpoint, in terms of sheer throughput MPTCP should be able to aggregate all the subflows independently of their latency. It is true though that if packets are not scheduled carefully on each subflow, then application latency may increase. At LIP6, we already run LISP+MPTCP coupling experimentations (LISP providing topology informations and forwarding capabilities to the MPTCP layer), we documented last year in this article “Cross-layer Cooperation to Boost Multipath TCP Performance in Cloud Networks†available at: http://www-phare.lip6.fr/~secci/papers/CoSePuRaGa-CLOUDNET13.pdf . In our experiment, RTTs of the different paths were close to each other, which lead to very good performance, as the lower the RTT gap the better MPTCP performance. See here another interesting article about this matter: "How hard can it be? Designing and Implementing a Deployable MPTCP" available at https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf ____________________________ 4. Requirements / Device Discovery "This is solved for xTRs by sending Map Register messages." Did you mean Map Requests? Or can you explain why only Map Register? ____________________________ 4. Requirements / Forwarding Actions "These actions can be implemented as extensions to the current specifications of LISP-TE or LISP-SR or be defined by means of a new LCAF." Here it would be better not to exclude existing LCAF. For the MPTCP use-case, we have a prototype using already proposed LCAF messages. ____________________________ 7. Security Considerations "When including capabilities to allow for the discovery of devices and its capabilities, as well as the collection of metrics regarding the underlay and the local device itself, it should be taken into consideration that proper controls are put in place to enforce strict policies as to which devices can access what type(s) of information." Do you have any protocol in mind to get metrics from the overlay to the underlay? Relevant nodes should be chosen carefully so that they are not malicious or misfunctioning. For instance the TCP RTT seen by a VM is higher than one seen by a physical machine due to the hypervisor scheduling latency. On 11/08/2014 16:46, Matthieu Coudron wrote: > ---------- Forwarded message ---------- > From: Alberto Rodriguez-Natal > Date: 2014-07-04 15:16 GMT+02:00 > Subject: [lisp] Fwd: New Version Notification for > draft-rodrigueznatal-lisp-oam-00.txt > To: "lisp@ietf.org list" > > > Dear all, > > We have just submitted a new draft discussing OAM (Operations > Administration Management) use-cases and requirements for LISP. > > Please, feel free to review it and provide feedback. > > Thanks, > Alberto > > ---------- Forwarded message ---------- > From: > Date: Fri, Jul 4, 2014 at 10:01 PM > Subject: New Version Notification for draft-rodrigueznatal-lisp-oam-00.txt > To: Albert Cabellos-Aparicio , Marc > Portoles-Comeras , Alberto Rodriguez-Natal > , Michael Kowal , Darrel Lewis > , Fabio Maino > > > > A new version of I-D, draft-rodrigueznatal-lisp-oam-00.txt > has been successfully submitted by Alberto Rodriguez-Natal and posted to the > IETF repository. > > Name: draft-rodrigueznatal-lisp-oam > Revision: 00 > Title: LISP-OAM (Operations Administration Management): Use > cases and requirements > Document date: 2014-07-04 > Group: Individual Submission > Pages: 13 > URL: > http://www.ietf.org/internet-drafts/draft-rodrigueznatal-lisp-oam-00.txt > Status: https://datatracker.ietf.org/doc/draft-rodrigueznatal-lisp-oam/ > Htmlized: http://tools.ietf.org/html/draft-rodrigueznatal-lisp-oam-00 > > > Abstract: > This document describes Operations Administration and Management > (OAM) use-cases and the requirements that they have towards the LISP > architecture. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Aug 11 09:00:31 2014 Return-Path: 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 51CA31A069F for ; Mon, 11 Aug 2014 09:00:29 -0700 (PDT) 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 PHvUINABrWFo for ; Mon, 11 Aug 2014 09:00:27 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CC281A06A5 for ; Mon, 11 Aug 2014 09:00:26 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id fp1so11057987pdb.27 for ; Mon, 11 Aug 2014 09:00:26 -0700 (PDT) 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=9bsvCk20KTN1nwAazKPtdpWkyb11r631bxHMfls51SQ=; b=ZT+u93lsXvjZvrAOta3SdzGR73WeH2sNguARvFrXQifiz4BliUXFGJ4GH2GqwzpcF8 AoOfq6JnzXdYxGzJhTSMFUqYSmkKzR3oYRAklkWGkohUznpIEeD8plX6mB22Bm7R0S34 9eKxrJgubCn/8YcQmc7HPkd+ZXRkHSrFqP+zzOsyn6sizroSWWP5gjsp5YHG2UOKuRsA QtKxRBkvyIAYflKF90Kp5ey5QgHl1oCiUIb6mxM4RM90cmsAerTfPTM1NXcaAFO3Jlgk LnaDYY3bOsaUadahZYrjfXDtrqHmZW6EHKsKDMh4jwZwPUvi3PsOcatg5+s6bVd2VxlZ GweA== X-Received: by 10.68.139.162 with SMTP id qz2mr2213130pbb.153.1407772826128; Mon, 11 Aug 2014 09:00:26 -0700 (PDT) Received: from [192.168.1.231] ([207.145.253.66]) by mx.google.com with ESMTPSA id re8sm18075605pdb.61.2014.08.11.09.00.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Aug 2014 09:00:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dino Farinacci In-Reply-To: Date: Mon, 11 Aug 2014 09:00:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <48B5B6E2-F0A6-4BCA-927F-05AAC9C2B365@gmail.com> References: <66bae15549d145a7bcd88223de7ad0ee@CO1PR05MB442.namprd05.prod.outlook.com> To: Ronald Bonica X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/U0OpzMLSh37n3kYyThFG4NKlNzU Cc: LISP mailing list list Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 1) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 16:00:29 -0000 > Hi Albert, >=20 > LISP solves one part of the TE problem. That is, it allows the ITR to = choose the ETR through which traffic enters the destination LISP site. = However, it doesn't determine the path that traffic takes between IETR = and ETR. So, it that sense, LISP TE is different from traffic = engineering with MPLS. Read draft-farinacci-lisp-te Ron. A path CAN be chosen. And it is a = super-set of functionality that MPLS-TE provides. > Also, I am not sure that it is *always* a good idea to let the ITR = choose the ETR through which traffic enters the destination LISP site. A = discussion of when this is and isn't a good idea might be appropriate in = the intro document. The intro document should not be subjective. We should have learned from = previous mistakes on this topic. Dino >=20 > Ron >=20 >>> - Section 7.3 needs to be rethought. LISP doesn't provide TE, in the = same >> sense that MPLS does. It's quite different. >>>=20 >>=20 >> RFC6830 states that LISP offers TE. >>=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Aug 11 09:46:27 2014 Return-Path: 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 77D961A04A8 for ; Mon, 11 Aug 2014 09:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZFrL20wRNZ_s for ; Mon, 11 Aug 2014 09:46:19 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (dns-bn1lp0143.outbound.protection.outlook.com [207.46.163.143]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 229771A0222 for ; Mon, 11 Aug 2014 09:46:19 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Mon, 11 Aug 2014 16:46:16 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.224]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.224]) with mapi id 15.00.1005.008; Mon, 11 Aug 2014 16:46:16 +0000 From: Ronald Bonica To: Dino Farinacci Thread-Topic: [lisp] draft-ietf-lisp-introduction-04 (Part 1) Thread-Index: Ac+xnIvNkMXR6dZVTxGD4JQhzdx2tQAt4XUAAMk3P6AAARr1gAABCz6A Date: Mon, 11 Aug 2014 16:46:16 +0000 Message-ID: <31979c44421744caa338b7b61851352f@CO1PR05MB442.namprd05.prod.outlook.com> References: <66bae15549d145a7bcd88223de7ad0ee@CO1PR05MB442.namprd05.prod.outlook.com> <48B5B6E2-F0A6-4BCA-927F-05AAC9C2B365@gmail.com> In-Reply-To: <48B5B6E2-F0A6-4BCA-927F-05AAC9C2B365@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03008837BD x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(51704005)(377454003)(13464003)(92566001)(33646002)(83072002)(110136001)(76576001)(81342001)(87936001)(2656002)(74662001)(19580405001)(81542001)(85852003)(77982001)(83322001)(19580395003)(4396001)(20776003)(74316001)(76176999)(1411001)(79102001)(101416001)(76482001)(99396002)(54356999)(80022001)(50986999)(66066001)(46102001)(77096002)(64706001)(15975445006)(99286002)(86362001)(107046002)(21056001)(95666004)(74502001)(93886004)(85306004)(31966008)(106356001)(105586002)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB443; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/CNBXqmCPogECjoP6QI6_e4p8xPc Cc: LISP mailing list list Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 1) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 16:46:22 -0000 Dino, I am not convinced that draft-farinacci-lisp-te provides a superset of the = functionality provided by MPLS-TE. A more accurate statement would be to sa= y that it provides a partially overlapping set of functionality. That said, I think that it is possible to avoid the entire argument not usi= ng the words "Traffic Engineering". A better approach would be to describe = what LISP offers in this area, explicitly, in a few paragraphs. = Ron > -----Original Message----- > From: Dino Farinacci [mailto:farinacci@gmail.com] > Sent: Monday, August 11, 2014 12:00 PM > To: Ronald Bonica > Cc: Albert Cabellos; LISP mailing list list > Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 1) >=20 >=20 > > Hi Albert, > > > > LISP solves one part of the TE problem. That is, it allows the ITR to c= hoose > the ETR through which traffic enters the destination LISP site. However, = it > doesn't determine the path that traffic takes between IETR and ETR. So, i= t > that sense, LISP TE is different from traffic engineering with MPLS. >=20 > Read draft-farinacci-lisp-te Ron. A path CAN be chosen. And it is a super= -set > of functionality that MPLS-TE provides. >=20 > > Also, I am not sure that it is *always* a good idea to let the ITR choo= se the > ETR through which traffic enters the destination LISP site. A discussion = of > when this is and isn't a good idea might be appropriate in the intro > document. >=20 > The intro document should not be subjective. We should have learned from > previous mistakes on this topic. >=20 > Dino >=20 > > > > Ron > > > >>> - Section 7.3 needs to be rethought. LISP doesn't provide TE, in the = same > >> sense that MPLS does. It's quite different. > >>> > >> > >> RFC6830 states that LISP offers TE. > >> > > > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Aug 11 09:59:58 2014 Return-Path: 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 41E631A0664 for ; Mon, 11 Aug 2014 09:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.602 X-Spam-Level: X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 7af4vcPxx7hj for ; Mon, 11 Aug 2014 09:59:54 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C07C1A0473 for ; Mon, 11 Aug 2014 09:59:51 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Mon, 11 Aug 2014 16:59:43 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.224]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.224]) with mapi id 15.00.1005.008; Mon, 11 Aug 2014 16:59:43 +0000 From: Ronald Bonica To: Dino Farinacci Thread-Topic: [lisp] draft-ietf-lisp-introduction-04 (Part 3) Thread-Index: Ac+xplSWhfzVPftgQfa8OfG0BIHHYQAE/j0AAPKPgFA= Date: Mon, 11 Aug 2014 16:59:43 +0000 Message-ID: References: <4a21b4f2c26d40b5bb5cecca5b1d4018@CO1PR05MB442.namprd05.prod.outlook.com> <25146EB9-0AC1-4443-8D2C-ADC15A66794E@gmail.com> In-Reply-To: <25146EB9-0AC1-4443-8D2C-ADC15A66794E@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03008837BD x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(13464003)(377454003)(51704005)(87936001)(2656002)(4396001)(92566001)(85852003)(83072002)(86362001)(74316001)(101416001)(77982001)(76482001)(1411001)(74502001)(46102001)(79102001)(31966008)(74662001)(77096002)(19580405001)(19580395003)(83322001)(33646002)(95666004)(99286002)(110136001)(107046002)(80022001)(85306004)(64706001)(99396002)(54356999)(66066001)(76576001)(81342001)(81542001)(20776003)(76176999)(21056001)(105586002)(106356001)(50986999)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB444; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/q7Jo7t_e_7ITAhOCr-qSjjyCYw8 Cc: LISP mailing list list Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 16:59:56 -0000 Dino, You have a very good point!=20 In order to help the reader understand the difference between LISP and BGP,= it might be a good idea to add a few pages that compare and contrast the t= wo. It should answer the following questions: - In BGP, how does the producer of a route know that it is time to push it - In LISP, how does the consumer of a route know that it is time to pull it - In BGP, what happens when the control path between the producer and consu= mer of a route becomes degraded or unusable - In LISP, what happens when the control path between the producer and cons= umer of a route becomes degraded or unusable = Ron > -----Original Message----- > From: Dino Farinacci [mailto:farinacci@gmail.com] > Sent: Wednesday, August 06, 2014 5:07 PM > To: Ronald Bonica > Cc: LISP mailing list list > Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) >=20 >=20 > > LISP is different from GRE and L3VPN because it pulls mapping informati= on > to itself. By contrast, GRE mapping information is generally configured > statically. L3VPN mapping information is pushed by BGP. Therefore, LISP > must deal with the problems of stale mapping information and cache misses= . > Also, LISP must deal with the problem of egress encapsulation node livene= ss. >=20 > Ron, I have to keep you honest here. It doesn't matter if you pull or pus= h, > ANY information that is distributed can be stale. >=20 > If a route changes in BGP and there is a congested path and the Update is > continually being retransmitted by TCP to get to the BGP peer, that BGP p= eer > has stale information. >=20 > Dino From nobody Mon Aug 11 10:28:59 2014 Return-Path: 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 87C7C1A045E for ; Mon, 11 Aug 2014 10:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 2CunRdrm9z6X for ; Mon, 11 Aug 2014 10:28:54 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6FE91A0037 for ; Mon, 11 Aug 2014 10:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3013; q=dns/txt; s=iport; t=1407778135; x=1408987735; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BLbeBpGyGZxbgGzmVf40oH1d5RwyYsHDN3Z/snLUcaw=; b=ZqpvesW3U3ST6hinFA1CPPR5P/37Ativ+O7LEfUm8E/F4jjuqcFf4HQy NryT/s7JoBbdsi8Th9PydFr7Q/Fr+B60AHMpErDV61tVZy2bzNeWV/m4R Gf+mYhplRMiEABMJh4c+nj41y2bJlotzv/uhrYqcd9eC8p/ORPin5mkMv 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFADL96FOtJV2Z/2dsb2JhbABQCoMNUlvMewqHSAGBHBZ3hAMBAQEDAQEBAWQHCwUHBAIBCA4DAQMBAQEnByEGCxQDBggCBA4FiC4DCQgNvG4NhWATBIl/gyCBUSkzBwaDKYEdAQSRGYkNggmOSYYyg1xsgUc X-IronPort-AV: E=Sophos;i="5.01,843,1400025600"; d="scan'208";a="346677048" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 11 Aug 2014 17:28:34 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s7BHSXUL016789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Aug 2014 17:28:33 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.207]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Mon, 11 Aug 2014 12:28:33 -0500 From: "Darrel Lewis (darlewis)" To: Ronald Bonica Thread-Topic: [lisp] draft-ietf-lisp-introduction-04 (Part 2) Thread-Index: AQHPtYms2NHYOwoYKki5wORS2jeY6w== Date: Mon, 11 Aug 2014 17:28:32 +0000 Message-ID: <8DD89C22-E176-4D62-AFE4-1C71B04A6281@cisco.com> References: <2c0d62b578de4c7eb9ef414690cbb1c5@CO1PR05MB442.namprd05.prod.outlook.com> <7c32ce118ae647c7bbff214282dd08d9@CO1PR05MB442.namprd05.prod.outlook.com> In-Reply-To: <7c32ce118ae647c7bbff214282dd08d9@CO1PR05MB442.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.253.183] Content-Type: text/plain; charset="Windows-1252" Content-ID: <99528D38D698DA46871F60D25268CCF4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/tTHSoZ300VQRuh42-N0wqRgjWBg Cc: LISP mailing list list Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 17:28:56 -0000 Ron, It strikes me that we=92ve had discussions on what an EID is many, many tim= es before on this list. Perhaps looking at those archived conversations wou= ld be useful.=20 -Darrel On Aug 11, 2014, at 7:38 AM, Ronald Bonica wrote: > Hi Albert,=20 >=20 > Your definition misses one small but important point. The degree to which= an EID carries topological information depends largely upon the observer's= location. >=20 > For example, assume that a LISP site is served by two XTRs and both XTRs = go down. Nodes within the site can still communicate with one another, even= though no device that is operating has a LOCATOR. In this case, where does= topological information come from? >=20 > Also, when an EID is advertised into the global Internet by a PITR, does = it continue to be an EID? If so, does it continue to be devoid of location = semantics? >=20 > = Ron >=20 >> -----Original Message----- >> From: Albert Cabellos [mailto:albert.cabellos@gmail.com] >> Sent: Thursday, August 07, 2014 11:49 AM >> To: Ronald Bonica >> Cc: LISP mailing list list >> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2) >>=20 >> Hi Ron >>=20 >>=20 >>=20 >> On Wed, Aug 6, 2014 at 8:30 PM, Ronald Bonica >> wrote: >>> Folks, >>>=20 >>> The following text is lifted from Section 6.1. At best, it is difficult= to parse. >> At worst, it is incorrect. Is there a better way to distinguish between = an IED >> and a LOC? >>>=20 >>=20 >> What about stating that RLOCs are topologically assigned to network >> attachment points while EIDs are independent of the topology and used to >> identify devices. >>=20 >> Albert >>=20 >>> Rn >>>=20 >>> "The second key concept is that if one wants to be as forward-looking a= s >> possible, conceptually one should think of the two kinds of names (EIDs= and >> RLOCs) as naming different classes of entities. >>>=20 >>> On the one hand, EIDs are used to name nodes - or rather, their end- en= d >> communication entities. RLOC(s), on the other hand, name interfaces, i.= e. >> places to which the system of routers sends packets. >>>=20 >>> This distinction, the formal recognition of different kinds of entities >> ("endpoints" and interfaces), and their association with the two differe= nt >> classes of names, is also important. Clearly recognizing interfaces and >> endpoints as distinctly separate classes of objects is another improveme= nt to >> the existing Internet" architecture." >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> 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 From nobody Mon Aug 11 10:29:06 2014 Return-Path: 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 C95141A0467 for ; Mon, 11 Aug 2014 10:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 ldBsv7DilNpH for ; Mon, 11 Aug 2014 10:28:58 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 647D41A045E for ; Mon, 11 Aug 2014 10:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=869; q=dns/txt; s=iport; t=1407778139; x=1408987739; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NnoIDQrwEVF292B3jPcuBSMSv8pNAWomxJGbj/oxiuM=; b=hmeZCsvJEW+CRbmcgQJ7inbR38DvUc8J5lNMvDNLVlDqrO+Vq8XLWFYV zGaaVEQiMOXZ6cbvcONLBqKJv5eLkO9pQUn3zY1+Im9MWU17WHRPU99Pq L3X2niQy2GZ+RAu/gFmGHIbOP4nSKnYuZGqvhpL4HbrauXx4u8mwsLsGy Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAP376FOtJA2F/2dsb2JhbABagw2BLdRNAYEcFneEBAEBAwE6PxACAQgOKBAyJQIEDgWIOgjCZxePGTMHgy+BHQEEkRmGXoQ4lHuDXGyBRw X-IronPort-AV: E=Sophos;i="5.01,843,1400025600"; d="scan'208";a="346681836" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-6.cisco.com with ESMTP; 11 Aug 2014 17:28:59 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s7BHSvt4000417 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Aug 2014 17:28:57 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.207]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Mon, 11 Aug 2014 12:28:57 -0500 From: "Darrel Lewis (darlewis)" To: Ronald Bonica Thread-Topic: [lisp] draft-ietf-lisp-introduction-04 (Part 3) Thread-Index: AQHPtYm6D5xplLFzuUS6j3F4gns7rQ== Date: Mon, 11 Aug 2014 17:28:56 +0000 Message-ID: References: <4a21b4f2c26d40b5bb5cecca5b1d4018@CO1PR05MB442.namprd05.prod.outlook.com> <25146EB9-0AC1-4443-8D2C-ADC15A66794E@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.253.183] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/rRuoUk8RXvpUAnkt9KkTDi92adE Cc: LISP mailing list list Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 17:29:00 -0000 On Aug 11, 2014, at 9:59 AM, Ronald Bonica wrote: >=20 > In order to help the reader understand the difference between LISP and BG= P, it might be a good idea to add a few pages that compare and contrast the= two. It should answer the following questions: >=20 > - In BGP, how does the producer of a route know that it is time to push i= t > - In LISP, how does the consumer of a route know that it is time to pull = it > - In BGP, what happens when the control path between the producer and con= sumer of a route becomes degraded or unusable > - In LISP, what happens when the control path between the producer and co= nsumer of a route becomes degraded or unusable >=20 > = Ron I eagerly await your suggested text. -D= From nobody Mon Aug 11 12:39:21 2014 Return-Path: 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 631961A0110 for ; Mon, 11 Aug 2014 12:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Ly0ytN81LNWh for ; Mon, 11 Aug 2014 12:39:18 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 207461A00C3 for ; Mon, 11 Aug 2014 12:39:18 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Mon, 11 Aug 2014 19:39:15 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.224]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.224]) with mapi id 15.00.1005.008; Mon, 11 Aug 2014 19:39:14 +0000 From: Ronald Bonica To: "Darrel Lewis (darlewis)" Thread-Topic: [lisp] draft-ietf-lisp-introduction-04 (Part 2) Thread-Index: Ac+xpHNWYu57YFJuQG6PpydKNK4QrgAsp1qAAMa2SDAABfCQAAAEiDow Date: Mon, 11 Aug 2014 19:39:14 +0000 Message-ID: <0bd2234a8e454f6ebfdb255d94e420c2@CO1PR05MB442.namprd05.prod.outlook.com> References: <2c0d62b578de4c7eb9ef414690cbb1c5@CO1PR05MB442.namprd05.prod.outlook.com> <7c32ce118ae647c7bbff214282dd08d9@CO1PR05MB442.namprd05.prod.outlook.com> <8DD89C22-E176-4D62-AFE4-1C71B04A6281@cisco.com> In-Reply-To: <8DD89C22-E176-4D62-AFE4-1C71B04A6281@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03008837BD x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(13464003)(377454003)(51704005)(24454002)(199002)(189002)(107046002)(110136001)(80022001)(33646002)(99286002)(95666004)(19580395003)(83322001)(106356001)(105586002)(50986999)(54356999)(93886004)(15975445006)(66066001)(64706001)(99396002)(20776003)(85306004)(21056001)(76176999)(76576001)(81542001)(81342001)(74316001)(86362001)(4396001)(87936001)(2656002)(85852003)(83072002)(92566001)(77096002)(74662001)(19580405001)(74502001)(77982001)(46102001)(76482001)(101416001)(79102001)(31966008)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB444; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/Cvz5Hl9DkXnW1kkUALMmH4k3TLQ Cc: LISP mailing list list Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 19:39:20 -0000 Darrel, Yes, we have. Sadly, I don't recall every having seen a satisfactory answer= on the mailing list. Can you point me to one? = Ron > -----Original Message----- > From: Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] > Sent: Monday, August 11, 2014 1:29 PM > To: Ronald Bonica > Cc: Darrel Lewis (darlewis); acabello@ac.upc.edu; LISP mailing list list > Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2) >=20 > Ron, >=20 > It strikes me that we've had discussions on what an EID is many, many tim= es > before on this list. Perhaps looking at those archived conversations woul= d be > useful. >=20 > -Darrel >=20 >=20 > On Aug 11, 2014, at 7:38 AM, Ronald Bonica wrote: >=20 > > Hi Albert, > > > > Your definition misses one small but important point. The degree to whi= ch > an EID carries topological information depends largely upon the observer'= s > location. > > > > For example, assume that a LISP site is served by two XTRs and both XTR= s > go down. Nodes within the site can still communicate with one another, ev= en > though no device that is operating has a LOCATOR. In this case, where doe= s > topological information come from? > > > > Also, when an EID is advertised into the global Internet by a PITR, doe= s it > continue to be an EID? If so, does it continue to be devoid of location > semantics? > > > > > > Ron > > > >> -----Original Message----- > >> From: Albert Cabellos [mailto:albert.cabellos@gmail.com] > >> Sent: Thursday, August 07, 2014 11:49 AM > >> To: Ronald Bonica > >> Cc: LISP mailing list list > >> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2) > >> > >> Hi Ron > >> > >> > >> > >> On Wed, Aug 6, 2014 at 8:30 PM, Ronald Bonica > >> wrote: > >>> Folks, > >>> > >>> The following text is lifted from Section 6.1. At best, it is difficu= lt to parse. > >> At worst, it is incorrect. Is there a better way to distinguish > >> between an IED and a LOC? > >>> > >> > >> What about stating that RLOCs are topologically assigned to network > >> attachment points while EIDs are independent of the topology and used > >> to identify devices. > >> > >> Albert > >> > >>> Rn > >>> > >>> "The second key concept is that if one wants to be as > >>> forward-looking as > >> possible, conceptually one should think of the two kinds of names > >> (EIDs and > >> RLOCs) as naming different classes of entities. > >>> > >>> On the one hand, EIDs are used to name nodes - or rather, their end- > >>> end > >> communication entities. RLOC(s), on the other hand, name interfaces, = i.e. > >> places to which the system of routers sends packets. > >>> > >>> This distinction, the formal recognition of different kinds of > >>> entities > >> ("endpoints" and interfaces), and their association with the two > >> different classes of names, is also important. Clearly recognizing > >> interfaces and endpoints as distinctly separate classes of objects is > >> another improvement to the existing Internet" architecture." > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 From nobody Mon Aug 11 14:37:58 2014 Return-Path: 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 57B641A0137 for ; Mon, 11 Aug 2014 14:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 jpU6QJoaJyVc for ; Mon, 11 Aug 2014 14:37:55 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6FC1A00F9 for ; Mon, 11 Aug 2014 14:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3882; q=dns/txt; s=iport; t=1407793075; x=1409002675; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RB2CqeAQ3+93FgbZBRpE2X4PDRlgSyBNQCIc3i98zvA=; b=HAzewau/IyH3JJz/2H4L2eytH8vxrNt+LaQ1mgpxwgCSe4b7N+gKIYLS JLQLTy1gAV2tHMoimCI9hbXPuLvVYUjjGFayiuYIuEHA7NHASzN7hy9d1 RxhEP5qvNB1U1Q9tUy930Nd7+cZ3kEPjuFdXkZuAG6g/ZhGcjOSqkBmD6 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAFI36VOtJA2B/2dsb2JhbABQCoMNUlvMfQqHSAGBEhZ3hAMBAQEDAQEBATctBwsFBwQCAQgOAwEDAQEBHgkHIQYLFAMGCAIEDgWILgMJCA29Rw2FahMEiX+DIIFRKTMHBoMpgR0FkRmJDYIJjkmGMoNcbIFH X-IronPort-AV: E=Sophos;i="5.01,844,1400025600"; d="scan'208";a="68357373" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-4.cisco.com with ESMTP; 11 Aug 2014 21:37:54 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s7BLbs2S018794 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Aug 2014 21:37:54 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.207]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Mon, 11 Aug 2014 16:37:54 -0500 From: "Darrel Lewis (darlewis)" To: Ronald Bonica Thread-Topic: [lisp] draft-ietf-lisp-introduction-04 (Part 2) Thread-Index: AQHPtYms2NHYOwoYKki5wORS2jeY6w== Date: Mon, 11 Aug 2014 21:37:54 +0000 Message-ID: <20932882-7298-47D7-AA45-0C19E4E8E662@cisco.com> References: <2c0d62b578de4c7eb9ef414690cbb1c5@CO1PR05MB442.namprd05.prod.outlook.com> <7c32ce118ae647c7bbff214282dd08d9@CO1PR05MB442.namprd05.prod.outlook.com> <8DD89C22-E176-4D62-AFE4-1C71B04A6281@cisco.com> <0bd2234a8e454f6ebfdb255d94e420c2@CO1PR05MB442.namprd05.prod.outlook.com> In-Reply-To: <0bd2234a8e454f6ebfdb255d94e420c2@CO1PR05MB442.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.253.183] Content-Type: text/plain; charset="us-ascii" Content-ID: <76602FBF0E1A8442A8D045A114D55EBF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/AX4V3xDu1HH-nRe1U60c30CHLRk Cc: LISP mailing list list Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 21:37:57 -0000 I believe the satisfactory answer is the one that ended up in the definitio= ns section of RFC 6830. -D On Aug 11, 2014, at 12:39 PM, Ronald Bonica wrote: > Darrel, >=20 > Yes, we have. Sadly, I don't recall every having seen a satisfactory answ= er on the mailing list. Can you point me to one? >=20 > = Ron >=20 >=20 >> -----Original Message----- >> From: Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] >> Sent: Monday, August 11, 2014 1:29 PM >> To: Ronald Bonica >> Cc: Darrel Lewis (darlewis); acabello@ac.upc.edu; LISP mailing list list >> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2) >>=20 >> Ron, >>=20 >> It strikes me that we've had discussions on what an EID is many, many ti= mes >> before on this list. Perhaps looking at those archived conversations wou= ld be >> useful. >>=20 >> -Darrel >>=20 >>=20 >> On Aug 11, 2014, at 7:38 AM, Ronald Bonica wrote: >>=20 >>> Hi Albert, >>>=20 >>> Your definition misses one small but important point. The degree to whi= ch >> an EID carries topological information depends largely upon the observer= 's >> location. >>>=20 >>> For example, assume that a LISP site is served by two XTRs and both XTR= s >> go down. Nodes within the site can still communicate with one another, e= ven >> though no device that is operating has a LOCATOR. In this case, where do= es >> topological information come from? >>>=20 >>> Also, when an EID is advertised into the global Internet by a PITR, doe= s it >> continue to be an EID? If so, does it continue to be devoid of location >> semantics? >>>=20 >>>=20 >>> Ron >>>=20 >>>> -----Original Message----- >>>> From: Albert Cabellos [mailto:albert.cabellos@gmail.com] >>>> Sent: Thursday, August 07, 2014 11:49 AM >>>> To: Ronald Bonica >>>> Cc: LISP mailing list list >>>> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2) >>>>=20 >>>> Hi Ron >>>>=20 >>>>=20 >>>>=20 >>>> On Wed, Aug 6, 2014 at 8:30 PM, Ronald Bonica >>>> wrote: >>>>> Folks, >>>>>=20 >>>>> The following text is lifted from Section 6.1. At best, it is difficu= lt to parse. >>>> At worst, it is incorrect. Is there a better way to distinguish >>>> between an IED and a LOC? >>>>>=20 >>>>=20 >>>> What about stating that RLOCs are topologically assigned to network >>>> attachment points while EIDs are independent of the topology and used >>>> to identify devices. >>>>=20 >>>> Albert >>>>=20 >>>>> Rn >>>>>=20 >>>>> "The second key concept is that if one wants to be as >>>>> forward-looking as >>>> possible, conceptually one should think of the two kinds of names >>>> (EIDs and >>>> RLOCs) as naming different classes of entities. >>>>>=20 >>>>> On the one hand, EIDs are used to name nodes - or rather, their end- >>>>> end >>>> communication entities. RLOC(s), on the other hand, name interfaces, = i.e. >>>> places to which the system of routers sends packets. >>>>>=20 >>>>> This distinction, the formal recognition of different kinds of >>>>> entities >>>> ("endpoints" and interfaces), and their association with the two >>>> different classes of names, is also important. Clearly recognizing >>>> interfaces and endpoints as distinctly separate classes of objects is >>>> another improvement to the existing Internet" architecture." >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> 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 >=20 From nobody Mon Aug 11 15:09:42 2014 Return-Path: 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 044BD1A0197 for ; Mon, 11 Aug 2014 15:09:39 -0700 (PDT) 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 qrliQtB6V5T9 for ; Mon, 11 Aug 2014 15:09:37 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DD971A01D8 for ; Mon, 11 Aug 2014 15:09:37 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id y10so11429397pdj.21 for ; Mon, 11 Aug 2014 15:09:37 -0700 (PDT) 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=tmHXN5snv+sVtgmkHyxkHcqSb/htTkBvW1PZjZVQXLo=; b=cJ86/y3BFN82cfLQXNWHgTWYTquiEjiLBdHZDrNnJ/GycJNu1jVvC/zzCkl2JPJ5w2 TUJQJ82naVydPiXw8H/kJ5U2wTWVFue1aTV8Bz6fPjdTxGOAg7LdoicHuxCnimc3oVez jXKVTRfZ3FTAC1qIraFRn6nZt+WGUxSZY68vpYR8ZwSI+uR4a8UT7WRxgIj9oR9k5JMS t7WnRVWD7knuvEkZ25cJrupX5u3B5j/e79HUX2cC6LRLANyYGbi35CtI84RB7S+Yedmv SoRPpgTsH4kZIw3JgqhgJMoj828HWwZz6oqyUo20N9JUjjnzr7rd+qtU5jkdaVvv2ahi /eJA== X-Received: by 10.68.223.34 with SMTP id qr2mr519640pbc.29.1407794976945; Mon, 11 Aug 2014 15:09:36 -0700 (PDT) Received: from [192.168.1.231] ([207.145.253.66]) by mx.google.com with ESMTPSA id rq7sm5958119pab.15.2014.08.11.15.08.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Aug 2014 15:09:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dino Farinacci In-Reply-To: Date: Mon, 11 Aug 2014 15:08:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4a21b4f2c26d40b5bb5cecca5b1d4018@CO1PR05MB442.namprd05.prod.outlook.com> <25146EB9-0AC1-4443-8D2C-ADC15A66794E@gmail.com> To: Ronald Bonica X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/l57yBduKe1gHTb3GkRxaipybP3s Cc: LISP mailing list list Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 22:09:39 -0000 It is not a LISP versus BGP comparison we need to do. Because if we did = that, then we would have to compare LISP with mobile-IP, IPsec, DNS, and = other similar features that overlap. Plus there are enivronments where LISP is used where BGP doesn't exist, = so how could we compare. Dino On Aug 11, 2014, at 9:59 AM, Ronald Bonica wrote: > Dino, >=20 > You have a very good point!=20 >=20 > In order to help the reader understand the difference between LISP and = BGP, it might be a good idea to add a few pages that compare and = contrast the two. It should answer the following questions: >=20 > - In BGP, how does the producer of a route know that it is time to = push it > - In LISP, how does the consumer of a route know that it is time to = pull it > - In BGP, what happens when the control path between the producer and = consumer of a route becomes degraded or unusable > - In LISP, what happens when the control path between the producer and = consumer of a route becomes degraded or unusable >=20 > = Ron >=20 >=20 >> -----Original Message----- >> From: Dino Farinacci [mailto:farinacci@gmail.com] >> Sent: Wednesday, August 06, 2014 5:07 PM >> To: Ronald Bonica >> Cc: LISP mailing list list >> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) >>=20 >>=20 >>> LISP is different from GRE and L3VPN because it pulls mapping = information >> to itself. By contrast, GRE mapping information is generally = configured >> statically. L3VPN mapping information is pushed by BGP. Therefore, = LISP >> must deal with the problems of stale mapping information and cache = misses. >> Also, LISP must deal with the problem of egress encapsulation node = liveness. >>=20 >> Ron, I have to keep you honest here. It doesn't matter if you pull or = push, >> ANY information that is distributed can be stale. >>=20 >> If a route changes in BGP and there is a congested path and the = Update is >> continually being retransmitted by TCP to get to the BGP peer, that = BGP peer >> has stale information. >>=20 >> Dino >=20 From nobody Mon Aug 11 15:56:01 2014 Return-Path: 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 16BA71A06D4 for ; Mon, 11 Aug 2014 15:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.602 X-Spam-Level: X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 n6GRx9Ek2Xax for ; Mon, 11 Aug 2014 15:55:57 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7EF01A06A3 for ; Mon, 11 Aug 2014 15:55:57 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Mon, 11 Aug 2014 22:55:55 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.224]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.224]) with mapi id 15.00.1005.008; Mon, 11 Aug 2014 22:55:55 +0000 From: Ronald Bonica To: "Darrel Lewis (darlewis)" Thread-Topic: [lisp] draft-ietf-lisp-introduction-04 (Part 3) Thread-Index: Ac+xplSWhfzVPftgQfa8OfG0BIHHYQAE/j0AAPKPgFAAAUu5AAALY9jQ Date: Mon, 11 Aug 2014 22:55:54 +0000 Message-ID: References: <4a21b4f2c26d40b5bb5cecca5b1d4018@CO1PR05MB442.namprd05.prod.outlook.com> <25146EB9-0AC1-4443-8D2C-ADC15A66794E@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03008837BD x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(189002)(199002)(51704005)(13464003)(24454002)(99286002)(86362001)(46102001)(66066001)(77096002)(64706001)(106356001)(105586002)(95666004)(107046002)(93886004)(74502001)(21056001)(31966008)(85306004)(85852003)(77982001)(81542001)(74662001)(83322001)(19580395003)(19580405001)(76576001)(110136001)(92566001)(83072002)(33646002)(2656002)(87936001)(81342001)(79102001)(54356999)(101416001)(76176999)(50986999)(76482001)(80022001)(99396002)(4396001)(20776003)(74316001)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB443; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/36_H8YcUh-R6tZAZqOY6Pq0fY-M Cc: LISP mailing list list Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 22:55:59 -0000 Darrel, Fair enough.=20 Could the editors leave an empty section between the sections that are now = numbered 6.4 and 6.5. The Title of that section is "Differences Between LIS= P and BGP". I will provide text within the next week or so. Ron > -----Original Message----- > From: Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] > Sent: Monday, August 11, 2014 1:29 PM > To: Ronald Bonica > Cc: Darrel Lewis (darlewis); Dino Farinacci; LISP mailing list list > Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) >=20 >=20 > On Aug 11, 2014, at 9:59 AM, Ronald Bonica wrote: >=20 > > > > In order to help the reader understand the difference between LISP and > BGP, it might be a good idea to add a few pages that compare and contrast > the two. It should answer the following questions: > > > > - In BGP, how does the producer of a route know that it is time to push= it > > - In LISP, how does the consumer of a route know that it is time to pul= l it > > - In BGP, what happens when the control path between the producer and > consumer of a route becomes degraded or unusable > > - In LISP, what happens when the control path between the producer and > consumer of a route becomes degraded or unusable > > > > = Ron >=20 > I eagerly await your suggested text. >=20 > -D From nobody Mon Aug 11 16:09:57 2014 Return-Path: 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 B4EFB1A0743 for ; Mon, 11 Aug 2014 16:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 4S4Do1yhxFJL for ; Mon, 11 Aug 2014 16:09:43 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E4061A01EF for ; Mon, 11 Aug 2014 16:09:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1873; q=dns/txt; s=iport; t=1407798583; x=1409008183; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4m1WpbnX3RL/I1g5rbJpdZPFLUgqXtd3xgR8DKWj+iQ=; b=G/iCyz0F2uxzDGeQ/isEZEeAiU5fIIoLBKTalqxjpuyqDD6srNrgTbWn tFULKQ8q+vsxEftvcyfxoPfTTP+E80kFB+miZyO/dyVP7k2g73ywe60Z0 2bCMCVxX3mQ5mTrOR3tk0o3lcM4xBECY6JQ+DJO1WE3Jv2OfVxdRCiTAb 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFANlM6VOtJA2I/2dsb2JhbABagw2BLdRbAYESFneEAwEBAQRuCwwEAgEIDgMEAQEBJwcyFAkIAgQOBYhCw2gXjxkIKwcGgymBHQEEkRmGXoQ4lHuDXGyBRw X-IronPort-AV: E=Sophos;i="5.01,845,1400025600"; d="scan'208";a="343646585" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-9.cisco.com with ESMTP; 11 Aug 2014 23:09:42 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s7BN9grc002375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Aug 2014 23:09:42 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.207]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Mon, 11 Aug 2014 18:09:42 -0500 From: "Darrel Lewis (darlewis)" To: Ronald Bonica Thread-Topic: [lisp] draft-ietf-lisp-introduction-04 (Part 3) Thread-Index: AQHPtYm6D5xplLFzuUS6j3F4gns7rQ== Date: Mon, 11 Aug 2014 23:09:41 +0000 Message-ID: <47A3E14F-CF89-458D-A351-63B1072FB3C4@cisco.com> References: <4a21b4f2c26d40b5bb5cecca5b1d4018@CO1PR05MB442.namprd05.prod.outlook.com> <25146EB9-0AC1-4443-8D2C-ADC15A66794E@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.253.183] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/BlLHpF4RhdBoJ6_2f0QdRv-eYSo Cc: LISP mailing list list Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 23:09:47 -0000 I mentioned that I=92d want to see the text before supporting (or opposing)= its inclusion=85 So adding sections seems somewhat premature. -D On Aug 11, 2014, at 3:55 PM, Ronald Bonica wrote: > >=20 > Darrel, >=20 > Fair enough.=20 >=20 > Could the editors leave an empty section between the sections that are no= w numbered 6.4 and 6.5. The Title of that section is "Differences Between L= ISP and BGP". I will provide text within the next week or so. >=20 > Ron >=20 >=20 >> -----Original Message----- >> From: Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] >> Sent: Monday, August 11, 2014 1:29 PM >> To: Ronald Bonica >> Cc: Darrel Lewis (darlewis); Dino Farinacci; LISP mailing list list >> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) >>=20 >>=20 >> On Aug 11, 2014, at 9:59 AM, Ronald Bonica wrote: >>=20 >>>=20 >>> In order to help the reader understand the difference between LISP and >> BGP, it might be a good idea to add a few pages that compare and contras= t >> the two. It should answer the following questions: >>>=20 >>> - In BGP, how does the producer of a route know that it is time to push= it >>> - In LISP, how does the consumer of a route know that it is time to pul= l it >>> - In BGP, what happens when the control path between the producer and >> consumer of a route becomes degraded or unusable >>> - In LISP, what happens when the control path between the producer and >> consumer of a route becomes degraded or unusable >>>=20 >>> = Ron >>=20 >> I eagerly await your suggested text. >>=20 >> -D From nobody Mon Aug 11 16:11:54 2014 Return-Path: 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 C7A311A071B for ; Mon, 11 Aug 2014 16:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 7B4QERNL0rEg for ; Mon, 11 Aug 2014 16:11:49 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCA131A070D for ; Mon, 11 Aug 2014 16:11:48 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Mon, 11 Aug 2014 23:11:45 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.224]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.224]) with mapi id 15.00.1005.008; Mon, 11 Aug 2014 23:11:45 +0000 From: Ronald Bonica To: "Darrel Lewis (darlewis)" Thread-Topic: [lisp] draft-ietf-lisp-introduction-04 (Part 2) Thread-Index: Ac+xpHNWYu57YFJuQG6PpydKNK4QrgAsp1qAAMa2SDAABfCQAAAEiDowAAQtSQAAAsypoA== Date: Mon, 11 Aug 2014 23:11:45 +0000 Message-ID: <0d8087164f8f4cca864868011c555ea7@CO1PR05MB442.namprd05.prod.outlook.com> References: <2c0d62b578de4c7eb9ef414690cbb1c5@CO1PR05MB442.namprd05.prod.outlook.com> <7c32ce118ae647c7bbff214282dd08d9@CO1PR05MB442.namprd05.prod.outlook.com> <8DD89C22-E176-4D62-AFE4-1C71B04A6281@cisco.com> <0bd2234a8e454f6ebfdb255d94e420c2@CO1PR05MB442.namprd05.prod.outlook.com> <20932882-7298-47D7-AA45-0C19E4E8E662@cisco.com> In-Reply-To: <20932882-7298-47D7-AA45-0C19E4E8E662@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03008837BD x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(51704005)(189002)(13464003)(199002)(24454002)(76576001)(86362001)(79102001)(85306004)(80022001)(101416001)(76482001)(66066001)(85852003)(93886004)(77096002)(64706001)(87936001)(46102001)(2656002)(92566001)(77982001)(83072002)(20776003)(4396001)(99286002)(95666004)(107046002)(31966008)(74662001)(74502001)(110136001)(19580395003)(105586002)(83322001)(106356001)(15975445006)(74316001)(54356999)(21056001)(76176999)(99396002)(19580405001)(50986999)(81542001)(81342001)(33646002)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB441; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/-PYS8uvC4R2dIIKyz4NlfE2e0uc Cc: LISP mailing list list Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 23:11:52 -0000 Darrel, The definitions offered by Albert and seconded by Dino is clear and succinc= t. This because they make blanket statements about the EID being independen= t of locator semantics and the RLOC being independent of identifier semanti= cs. By contrast, the RFC 6830 definitions of EID and RLOC are closer to being t= echnically correct. This is because the hedge around the issue of whether t= he EID is really devoid of locator semantics. Sadly, the RFC 6830 definitio= ns never really spell out the degree to which EIDs can carry locator semant= ics. Also, the RFC 6830 definitions are verbose and difficult to parse. As a WG, we need to come to consensus on this issue and document it in a ma= nner that is comprehensible to newcomers reading the document. = Ron > -----Original Message----- > From: Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] > Sent: Monday, August 11, 2014 5:38 PM > To: Ronald Bonica > Cc: Darrel Lewis (darlewis); acabello@ac.upc.edu; LISP mailing list list > Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2) >=20 > I believe the satisfactory answer is the one that ended up in the definit= ions > section of RFC 6830. >=20 > -D > On Aug 11, 2014, at 12:39 PM, Ronald Bonica wrote: >=20 > > Darrel, > > > > Yes, we have. Sadly, I don't recall every having seen a satisfactory an= swer > on the mailing list. Can you point me to one? > > > > > > Ron > > > > > >> -----Original Message----- > >> From: Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] > >> Sent: Monday, August 11, 2014 1:29 PM > >> To: Ronald Bonica > >> Cc: Darrel Lewis (darlewis); acabello@ac.upc.edu; LISP mailing list > >> list > >> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2) > >> > >> Ron, > >> > >> It strikes me that we've had discussions on what an EID is many, many > >> times before on this list. Perhaps looking at those archived > >> conversations would be useful. > >> > >> -Darrel > >> > >> > >> On Aug 11, 2014, at 7:38 AM, Ronald Bonica wrote= : > >> > >>> Hi Albert, > >>> > >>> Your definition misses one small but important point. The degree to > >>> which > >> an EID carries topological information depends largely upon the > >> observer's location. > >>> > >>> For example, assume that a LISP site is served by two XTRs and both > >>> XTRs > >> go down. Nodes within the site can still communicate with one > >> another, even though no device that is operating has a LOCATOR. In > >> this case, where does topological information come from? > >>> > >>> Also, when an EID is advertised into the global Internet by a PITR, > >>> does it > >> continue to be an EID? If so, does it continue to be devoid of > >> location semantics? > >>> > >>> > >>> Ron > >>> > >>>> -----Original Message----- > >>>> From: Albert Cabellos [mailto:albert.cabellos@gmail.com] > >>>> Sent: Thursday, August 07, 2014 11:49 AM > >>>> To: Ronald Bonica > >>>> Cc: LISP mailing list list > >>>> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2) > >>>> > >>>> Hi Ron > >>>> > >>>> > >>>> > >>>> On Wed, Aug 6, 2014 at 8:30 PM, Ronald Bonica > >>>> wrote: > >>>>> Folks, > >>>>> > >>>>> The following text is lifted from Section 6.1. At best, it is diffi= cult to > parse. > >>>> At worst, it is incorrect. Is there a better way to distinguish > >>>> between an IED and a LOC? > >>>>> > >>>> > >>>> What about stating that RLOCs are topologically assigned to network > >>>> attachment points while EIDs are independent of the topology and > >>>> used to identify devices. > >>>> > >>>> Albert > >>>> > >>>>> Rn > >>>>> > >>>>> "The second key concept is that if one wants to be as > >>>>> forward-looking as > >>>> possible, conceptually one should think of the two kinds of names > >>>> (EIDs and > >>>> RLOCs) as naming different classes of entities. > >>>>> > >>>>> On the one hand, EIDs are used to name nodes - or rather, their > >>>>> end- end > >>>> communication entities. RLOC(s), on the other hand, name interfaces= , > i.e. > >>>> places to which the system of routers sends packets. > >>>>> > >>>>> This distinction, the formal recognition of different kinds of > >>>>> entities > >>>> ("endpoints" and interfaces), and their association with the two > >>>> different classes of names, is also important. Clearly recognizing > >>>> interfaces and endpoints as distinctly separate classes of objects > >>>> is another improvement to the existing Internet" architecture." > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > > From nobody Mon Aug 11 16:13:35 2014 Return-Path: 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 18F621A071B for ; Mon, 11 Aug 2014 16:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 VMPxGDrHBfTh for ; Mon, 11 Aug 2014 16:13:31 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CC451A070D for ; Mon, 11 Aug 2014 16:13:30 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Mon, 11 Aug 2014 23:13:28 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.224]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.224]) with mapi id 15.00.1005.008; Mon, 11 Aug 2014 23:13:28 +0000 From: Ronald Bonica To: "Darrel Lewis (darlewis)" Thread-Topic: [lisp] draft-ietf-lisp-introduction-04 (Part 3) Thread-Index: Ac+xplSWhfzVPftgQfa8OfG0BIHHYQAE/j0AAPKPgFAAAUu5AAALY9jQAACCs4AAABcC4A== Date: Mon, 11 Aug 2014 23:13:28 +0000 Message-ID: References: <4a21b4f2c26d40b5bb5cecca5b1d4018@CO1PR05MB442.namprd05.prod.outlook.com> <25146EB9-0AC1-4443-8D2C-ADC15A66794E@gmail.com> <47A3E14F-CF89-458D-A351-63B1072FB3C4@cisco.com> In-Reply-To: <47A3E14F-CF89-458D-A351-63B1072FB3C4@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03008837BD x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(51704005)(189002)(13464003)(199002)(24454002)(76576001)(86362001)(79102001)(85306004)(80022001)(101416001)(76482001)(66066001)(85852003)(93886004)(77096002)(64706001)(87936001)(46102001)(2656002)(92566001)(77982001)(83072002)(20776003)(4396001)(99286002)(95666004)(107046002)(31966008)(74662001)(74502001)(110136001)(19580395003)(105586002)(83322001)(106356001)(74316001)(54356999)(21056001)(76176999)(99396002)(19580405001)(50986999)(81542001)(81342001)(33646002)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB441; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/JEtLZtRreWPHxqo0VNKCucCZIFY Cc: LISP mailing list list Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 23:13:33 -0000 Darrel, Clearly, this is a WG document and the entire WG gets a chance to review, a= ccept or reject a contribution. That goes without saying for any document. = Ron > -----Original Message----- > From: Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] > Sent: Monday, August 11, 2014 7:10 PM > To: Ronald Bonica > Cc: Darrel Lewis (darlewis); Dino Farinacci; LISP mailing list list > Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) >=20 > >=20 > I mentioned that I'd want to see the text before supporting (or opposing)= its > inclusion... So adding sections seems somewhat premature. >=20 >=20 > -D > On Aug 11, 2014, at 3:55 PM, Ronald Bonica wrote: >=20 > > > > > > Darrel, > > > > Fair enough. > > > > Could the editors leave an empty section between the sections that are > now numbered 6.4 and 6.5. The Title of that section is "Differences Betwe= en > LISP and BGP". I will provide text within the next week or so. > > > > Ron > > > > > >> -----Original Message----- > >> From: Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] > >> Sent: Monday, August 11, 2014 1:29 PM > >> To: Ronald Bonica > >> Cc: Darrel Lewis (darlewis); Dino Farinacci; LISP mailing list list > >> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) > >> > >> > >> On Aug 11, 2014, at 9:59 AM, Ronald Bonica wrote= : > >> > >>> > >>> In order to help the reader understand the difference between LISP > >>> and > >> BGP, it might be a good idea to add a few pages that compare and > >> contrast the two. It should answer the following questions: > >>> > >>> - In BGP, how does the producer of a route know that it is time to > >>> push it > >>> - In LISP, how does the consumer of a route know that it is time to > >>> pull it > >>> - In BGP, what happens when the control path between the producer > >>> and > >> consumer of a route becomes degraded or unusable > >>> - In LISP, what happens when the control path between the producer > >>> and > >> consumer of a route becomes degraded or unusable > >>> > >>> > >>> Ron > >> > >> I eagerly await your suggested text. > >> > >> -D From nobody Mon Aug 11 16:32:02 2014 Return-Path: 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 484461A0161 for ; Mon, 11 Aug 2014 16:32:01 -0700 (PDT) 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 9H4PCdcPsuXO for ; Mon, 11 Aug 2014 16:31:59 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15E311A006A for ; Mon, 11 Aug 2014 16:31:59 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id y13so5649838pdi.31 for ; Mon, 11 Aug 2014 16:31:58 -0700 (PDT) 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=A5ERbGm++unSS16SAAO4pU0r6vwhgpZZS3rxB2AV8fI=; b=0Ja/O3xIRgIgvSpsEGTV6Wjq+kKOgt7nWjkJp0iWWJ8njBA86Fe/KYEBuJu4AaVM1X IoHkraPLjxi73l1P6GOrX69GXWMDGjyrZ63gFHSFZuYQB8roP+vV+BBiTr1V1tKsnm8j rYHcnREmtFINH+m8nDg2CNubwrbIKrWJtQFLISEjdEcgl2cgdlTvsvh8ECqpSGOlNq+M tHMEXnxXciHSKQb970TTxF8si+pOvitmfZsMZnTSzyrYBtgZyezMKFEN1tJZNcHGqkpp DHBz0I26iphKICpn2R9z7pnRJo0Ff1+vz1CFdWQpE0eLRVx1F6VS8HXZ3xMTqJH+F40j 7vJA== X-Received: by 10.66.65.230 with SMTP id a6mr861710pat.18.1407799918607; Mon, 11 Aug 2014 16:31:58 -0700 (PDT) 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 cr2sm12548961pbc.35.2014.08.11.16.31.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Aug 2014 16:31:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dino Farinacci In-Reply-To: <0d8087164f8f4cca864868011c555ea7@CO1PR05MB442.namprd05.prod.outlook.com> Date: Mon, 11 Aug 2014 16:31:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5D8FD44A-3FF8-413F-8B96-52C7C55C7A92@gmail.com> References: <2c0d62b578de4c7eb9ef414690cbb1c5@CO1PR05MB442.namprd05.prod.outlook.com> <7c32ce118ae647c7bbff214282dd08d9@CO1PR05MB442.namprd05.prod.outlook.com> <8DD89C22-E176-4D62-AFE4-1C71B04A6281@cisco.com> <0bd2234a8e454f6ebfdb255d94e420c2@CO1PR05MB442.namprd05.prod.outlook.com> <20932882-7298-47D7-AA45-0C19E4E8E662@cisco.com> <0d8087164f8f4cca864868011c555ea7@CO1PR05MB442.namprd05.prod.outlook.com> To: Ronald Bonica X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/nS9gqrpHesleKpvpPOS8-zebJr0 Cc: LISP mailing list list Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 23:32:01 -0000 > Darrel, >=20 > The definitions offered by Albert and seconded by Dino is clear and = succinct. This because they make blanket statements about the EID being = independent of locator semantics and the RLOC being independent of = identifier semantics. >=20 > By contrast, the RFC 6830 definitions of EID and RLOC are closer to = being technically correct. This is because the hedge around the issue of = whether the EID is really devoid of locator semantics. Sadly, the RFC = 6830 definitions never really spell out the degree to which EIDs can = carry locator semantics. Also, the RFC 6830 definitions are verbose and = difficult to parse. >=20 > As a WG, we need to come to consensus on this issue and document it in = a manner that is comprehensible to newcomers reading the document. Let's have descriptions where they are needed and formal definitions in = the specs that were already published. And we should have the intro = document make the descriptions more coarser than the technical = definitions in the specs. Agree? Dino >=20 > = Ron >=20 >=20 >=20 >> -----Original Message----- >> From: Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] >> Sent: Monday, August 11, 2014 5:38 PM >> To: Ronald Bonica >> Cc: Darrel Lewis (darlewis); acabello@ac.upc.edu; LISP mailing list = list >> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2) >>=20 >> I believe the satisfactory answer is the one that ended up in the = definitions >> section of RFC 6830. >>=20 >> -D >> On Aug 11, 2014, at 12:39 PM, Ronald Bonica = wrote: >>=20 >>> Darrel, >>>=20 >>> Yes, we have. Sadly, I don't recall every having seen a satisfactory = answer >> on the mailing list. Can you point me to one? >>>=20 >>>=20 >>> Ron >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] >>>> Sent: Monday, August 11, 2014 1:29 PM >>>> To: Ronald Bonica >>>> Cc: Darrel Lewis (darlewis); acabello@ac.upc.edu; LISP mailing list >>>> list >>>> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2) >>>>=20 >>>> Ron, >>>>=20 >>>> It strikes me that we've had discussions on what an EID is many, = many >>>> times before on this list. Perhaps looking at those archived >>>> conversations would be useful. >>>>=20 >>>> -Darrel >>>>=20 >>>>=20 >>>> On Aug 11, 2014, at 7:38 AM, Ronald Bonica = wrote: >>>>=20 >>>>> Hi Albert, >>>>>=20 >>>>> Your definition misses one small but important point. The degree = to >>>>> which >>>> an EID carries topological information depends largely upon the >>>> observer's location. >>>>>=20 >>>>> For example, assume that a LISP site is served by two XTRs and = both >>>>> XTRs >>>> go down. Nodes within the site can still communicate with one >>>> another, even though no device that is operating has a LOCATOR. In >>>> this case, where does topological information come from? >>>>>=20 >>>>> Also, when an EID is advertised into the global Internet by a = PITR, >>>>> does it >>>> continue to be an EID? If so, does it continue to be devoid of >>>> location semantics? >>>>>=20 >>>>>=20 >>>>> Ron >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Albert Cabellos [mailto:albert.cabellos@gmail.com] >>>>>> Sent: Thursday, August 07, 2014 11:49 AM >>>>>> To: Ronald Bonica >>>>>> Cc: LISP mailing list list >>>>>> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2) >>>>>>=20 >>>>>> Hi Ron >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Wed, Aug 6, 2014 at 8:30 PM, Ronald Bonica = >>>>>> wrote: >>>>>>> Folks, >>>>>>>=20 >>>>>>> The following text is lifted from Section 6.1. At best, it is = difficult to >> parse. >>>>>> At worst, it is incorrect. Is there a better way to distinguish >>>>>> between an IED and a LOC? >>>>>>>=20 >>>>>>=20 >>>>>> What about stating that RLOCs are topologically assigned to = network >>>>>> attachment points while EIDs are independent of the topology and >>>>>> used to identify devices. >>>>>>=20 >>>>>> Albert >>>>>>=20 >>>>>>> Rn >>>>>>>=20 >>>>>>> "The second key concept is that if one wants to be as >>>>>>> forward-looking as >>>>>> possible, conceptually one should think of the two kinds of names >>>>>> (EIDs and >>>>>> RLOCs) as naming different classes of entities. >>>>>>>=20 >>>>>>> On the one hand, EIDs are used to name nodes - or rather, their >>>>>>> end- end >>>>>> communication entities. RLOC(s), on the other hand, name = interfaces, >> i.e. >>>>>> places to which the system of routers sends packets. >>>>>>>=20 >>>>>>> This distinction, the formal recognition of different kinds of >>>>>>> entities >>>>>> ("endpoints" and interfaces), and their association with the two >>>>>> different classes of names, is also important. Clearly = recognizing >>>>>> interfaces and endpoints as distinctly separate classes of = objects >>>>>> is another improvement to the existing Internet" architecture." >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> 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 >>>=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Aug 11 16:33:11 2014 Return-Path: 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 464761A0720 for ; Mon, 11 Aug 2014 16:33:09 -0700 (PDT) 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 kTGk6RKBt7qz for ; Mon, 11 Aug 2014 16:33:07 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB21F1A06CF for ; Mon, 11 Aug 2014 16:33:07 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id eu11so11848292pac.4 for ; Mon, 11 Aug 2014 16:33:06 -0700 (PDT) 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=15szvJjdeCnh5vZBMRtvPt4dlw7FmvMqFzemIcSKlDE=; b=bCm7bdnK2aluNsH8BvhirXzPwWy2+pLS8I8uOs9FzHO91qsHByN7j4viq3HRAkvoAs 5bnxs5n3mDI1PY/jdXOOHMdvOgym+0euxIVZO1VJQxzplqe1SuFjZYU3P6yd0Sn+QW2g +tzDS779zheIEzGgXTeuBLg/80b9jfsz32/yoCRKlA8je2jy94r7GaJXqk/K8Wt7Tw+6 TSb1z4RhQxA29EtVX1O2itO5b0QbVP9TF4VYhZdnoaEV8zACS1deMritBO9yBd5sqQDY JugPaNzEdeZBJrar7KRXF6YTvLKyHCk61stj+il6MF/R0X6KS2xWvHtwLpL2D0m7L+Qd B3HA== X-Received: by 10.66.162.130 with SMTP id ya2mr856944pab.26.1407799986150; Mon, 11 Aug 2014 16:33:06 -0700 (PDT) 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 oz7sm19276813pdb.77.2014.08.11.16.33.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Aug 2014 16:33:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dino Farinacci In-Reply-To: Date: Mon, 11 Aug 2014 16:32:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4a21b4f2c26d40b5bb5cecca5b1d4018@CO1PR05MB442.namprd05.prod.outlook.com> <25146EB9-0AC1-4443-8D2C-ADC15A66794E@gmail.com> <47A3E14F-CF89-458D-A351-63B1072FB3C4@cisco.com> To: Ronald Bonica X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/hrLOv6POwrqcoIFZNXDfT3ymPrI Cc: LISP mailing list list Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 23:33:09 -0000 We should not compare LISP to any other protocol. We should define what = LISP is. BGP and LISP solve different problems. Dino On Aug 11, 2014, at 4:13 PM, Ronald Bonica wrote: > Darrel, >=20 > Clearly, this is a WG document and the entire WG gets a chance to = review, accept or reject a contribution. That goes without saying for = any document. >=20 > = Ron >=20 >> -----Original Message----- >> From: Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] >> Sent: Monday, August 11, 2014 7:10 PM >> To: Ronald Bonica >> Cc: Darrel Lewis (darlewis); Dino Farinacci; LISP mailing list list >> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) >>=20 >> >>=20 >> I mentioned that I'd want to see the text before supporting (or = opposing) its >> inclusion... So adding sections seems somewhat premature. >>=20 >>=20 >> -D >> On Aug 11, 2014, at 3:55 PM, Ronald Bonica = wrote: >>=20 >>> >>>=20 >>> Darrel, >>>=20 >>> Fair enough. >>>=20 >>> Could the editors leave an empty section between the sections that = are >> now numbered 6.4 and 6.5. The Title of that section is "Differences = Between >> LISP and BGP". I will provide text within the next week or so. >>>=20 >>> Ron >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] >>>> Sent: Monday, August 11, 2014 1:29 PM >>>> To: Ronald Bonica >>>> Cc: Darrel Lewis (darlewis); Dino Farinacci; LISP mailing list list >>>> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) >>>>=20 >>>>=20 >>>> On Aug 11, 2014, at 9:59 AM, Ronald Bonica = wrote: >>>>=20 >>>>>=20 >>>>> In order to help the reader understand the difference between LISP >>>>> and >>>> BGP, it might be a good idea to add a few pages that compare and >>>> contrast the two. It should answer the following questions: >>>>>=20 >>>>> - In BGP, how does the producer of a route know that it is time to >>>>> push it >>>>> - In LISP, how does the consumer of a route know that it is time = to >>>>> pull it >>>>> - In BGP, what happens when the control path between the producer >>>>> and >>>> consumer of a route becomes degraded or unusable >>>>> - In LISP, what happens when the control path between the producer >>>>> and >>>> consumer of a route becomes degraded or unusable >>>>>=20 >>>>>=20 >>>>> Ron >>>>=20 >>>> I eagerly await your suggested text. >>>>=20 >>>> -D >=20 From nobody Mon Aug 11 16:39:21 2014 Return-Path: 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 D881A1A073D for ; Mon, 11 Aug 2014 16:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.602 X-Spam-Level: X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 IMW7WayKNrK1 for ; Mon, 11 Aug 2014 16:39:10 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B79951A0731 for ; Mon, 11 Aug 2014 16:39:09 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB315.namprd05.prod.outlook.com (10.141.69.146) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Mon, 11 Aug 2014 23:39:07 +0000 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.0.1005.10; Mon, 11 Aug 2014 23:39:05 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.224]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.224]) with mapi id 15.00.1005.008; Mon, 11 Aug 2014 23:39:05 +0000 From: Ronald Bonica To: Dino Farinacci Thread-Topic: [lisp] draft-ietf-lisp-introduction-04 (Part 2) Thread-Index: Ac+xpHNWYu57YFJuQG6PpydKNK4QrgAsp1qAAMa2SDAABfCQAAAEiDowAAQtSQAAAsypoAABKYMAAAAvyJA= Date: Mon, 11 Aug 2014 23:39:04 +0000 Message-ID: <8691dc326ac842e2bfcd60110bb2e712@CO1PR05MB442.namprd05.prod.outlook.com> References: <2c0d62b578de4c7eb9ef414690cbb1c5@CO1PR05MB442.namprd05.prod.outlook.com> <7c32ce118ae647c7bbff214282dd08d9@CO1PR05MB442.namprd05.prod.outlook.com> <8DD89C22-E176-4D62-AFE4-1C71B04A6281@cisco.com> <0bd2234a8e454f6ebfdb255d94e420c2@CO1PR05MB442.namprd05.prod.outlook.com> <20932882-7298-47D7-AA45-0C19E4E8E662@cisco.com> <0d8087164f8f4cca864868011c555ea7@CO1PR05MB442.namprd05.prod.outlook.com> <5D8FD44A-3FF8-413F-8B96-52C7C55C7A92@gmail.com> In-Reply-To: <5D8FD44A-3FF8-413F-8B96-52C7C55C7A92@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:; x-forefront-prvs: 03008837BD x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(51704005)(199002)(189002)(50986999)(21056001)(54356999)(33646002)(76176999)(110136001)(83322001)(99396002)(93886004)(101416001)(85306004)(76576001)(87936001)(4396001)(77096002)(74662001)(64706001)(1411001)(31966008)(46102001)(74502001)(86362001)(107046002)(74316001)(76482001)(106356001)(92566001)(2656002)(77982001)(99286002)(81342001)(80022001)(83072002)(81542001)(66066001)(20776003)(85852003)(79102001)(105586002)(95666004)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB442; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/Y4HXzbX5Qr7O-j9iWPL6sjWXNe8 Cc: LISP mailing list list Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 23:39:14 -0000 Dino, Exactly! The Intro doc needs text that is a) easy to parse and b) technical= ly correct. This will certainly be more coarse that the definition in 6830,= but probably a little more verbose than what we have already proposed. Ron >=20 > Let's have descriptions where they are needed and formal definitions in t= he > specs that were already published. And we should have the intro document > make the descriptions more coarser than the technical definitions in the > specs. Agree? >=20 > Dino From nobody Mon Aug 11 17:52:04 2014 Return-Path: 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 CAFD01A000E for ; Mon, 11 Aug 2014 17:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 CXi5q468qrBs for ; Mon, 11 Aug 2014 17:52:00 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C18C1A0026 for ; Mon, 11 Aug 2014 17:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3188; q=dns/txt; s=iport; t=1407804720; x=1409014320; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FoAkudyUf5rDfHMM/kV8Wmvj9eswfW5okJAkj4+0/io=; b=VLUeNPhSNdbio8jpL7rZKfsTf9fuyAmU6b8dP3+Zfy03TnoSeEj1n8js iPC6HPHluFpDf8rcg9jR/kj05vR3DuPWc51HoMI5K4z1/1MUhrMco1pIn UJcykKH5NPMHtcXhI4Z4nsfcZkjYxsvRFX0wVs+6CWchFa/zuLlWP7E7v k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAFFk6VOtJA2D/2dsb2JhbABagw1SzVQKh0gBgRAWd4QDAQEBAwEBAQE3NAsFBwQCAQgRBAEBAR4JByEGCxQJCAIEDgWILgMJCA29Zw2FbBMEjR+BeggrBwaDKYEdBZEZhl6CL4IJjkmGMoNcbA X-IronPort-AV: E=Sophos;i="5.01,845,1400025600"; d="scan'208";a="346764532" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-5.cisco.com with ESMTP; 12 Aug 2014 00:51:59 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s7C0px39020490 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Aug 2014 00:51:59 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.199]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Mon, 11 Aug 2014 19:51:59 -0500 From: "Victor Moreno (vimoreno)" To: Dino Farinacci Thread-Topic: [lisp] draft-ietf-lisp-introduction-04 (Part 3) Thread-Index: Ac+xplSWhfzVPftgQfa8OfG0BIHHYQAPeHIAAPLWAoAAAQU3AAALa1AAAAB7O4AAACHTAAAArXMA///CSNY= Date: Tue, 12 Aug 2014 00:51:58 +0000 Message-ID: <2719F4DB-275C-4791-BC4A-EA15C21502FE@cisco.com> References: <4a21b4f2c26d40b5bb5cecca5b1d4018@CO1PR05MB442.namprd05.prod.outlook.com> <25146EB9-0AC1-4443-8D2C-ADC15A66794E@gmail.com> <47A3E14F-CF89-458D-A351-63B1072FB3C4@cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/9uJlbEejeYerysdTdJke2Y_Vw8k Cc: LISP mailing list list Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 00:52:02 -0000 +1 I am however interested in the comparison, but I don't see it as part of an= introduction or other lisp specification document=20 Victor > On Aug 11, 2014, at 4:33 PM, "Dino Farinacci" wrote= : >=20 > We should not compare LISP to any other protocol. We should define what L= ISP is. BGP and LISP solve different problems. >=20 > Dino >=20 >> On Aug 11, 2014, at 4:13 PM, Ronald Bonica wrote: >>=20 >> Darrel, >>=20 >> Clearly, this is a WG document and the entire WG gets a chance to review= , accept or reject a contribution. That goes without saying for any documen= t. >>=20 >> = Ron >>=20 >>> -----Original Message----- >>> From: Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] >>> Sent: Monday, August 11, 2014 7:10 PM >>> To: Ronald Bonica >>> Cc: Darrel Lewis (darlewis); Dino Farinacci; LISP mailing list list >>> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) >>>=20 >>> >>>=20 >>> I mentioned that I'd want to see the text before supporting (or opposin= g) its >>> inclusion... So adding sections seems somewhat premature. >>>=20 >>>=20 >>> -D >>>> On Aug 11, 2014, at 3:55 PM, Ronald Bonica wrote= : >>>>=20 >>>> >>>>=20 >>>> Darrel, >>>>=20 >>>> Fair enough. >>>>=20 >>>> Could the editors leave an empty section between the sections that are >>> now numbered 6.4 and 6.5. The Title of that section is "Differences Bet= ween >>> LISP and BGP". I will provide text within the next week or so. >>>>=20 >>>> Ron >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] >>>>> Sent: Monday, August 11, 2014 1:29 PM >>>>> To: Ronald Bonica >>>>> Cc: Darrel Lewis (darlewis); Dino Farinacci; LISP mailing list list >>>>> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) >>>>>=20 >>>>>=20 >>>>>> On Aug 11, 2014, at 9:59 AM, Ronald Bonica wro= te: >>>>>>=20 >>>>>>=20 >>>>>> In order to help the reader understand the difference between LISP >>>>>> and >>>>> BGP, it might be a good idea to add a few pages that compare and >>>>> contrast the two. It should answer the following questions: >>>>>>=20 >>>>>> - In BGP, how does the producer of a route know that it is time to >>>>>> push it >>>>>> - In LISP, how does the consumer of a route know that it is time to >>>>>> pull it >>>>>> - In BGP, what happens when the control path between the producer >>>>>> and >>>>> consumer of a route becomes degraded or unusable >>>>>> - In LISP, what happens when the control path between the producer >>>>>> and >>>>> consumer of a route becomes degraded or unusable >>>>>>=20 >>>>>>=20 >>>>>> Ron >>>>>=20 >>>>> I eagerly await your suggested text. >>>>>=20 >>>>> -D >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Tue Aug 12 14:40:34 2014 Return-Path: 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 498581A00E2 for ; Tue, 12 Aug 2014 14:40:32 -0700 (PDT) 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 h7qGrsLRqCOb for ; Tue, 12 Aug 2014 14:40:30 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 950AF1A00AE for ; Tue, 12 Aug 2014 14:40:30 -0700 (PDT) Received: by mail-ig0-f170.google.com with SMTP id h3so9388529igd.1 for ; Tue, 12 Aug 2014 14:40:29 -0700 (PDT) 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=IcPDHlXYExuecdqJLU34OdN59vUYGGfUGR4/YcCKElI=; b=CujP4t2PN/1O6VGSO3h3NCmdS9Vih21dIPsSER3YRITgfMWt1gEvoLNRawtSEAa7t5 oAtV2Uk4bihCpjUofh0AW1Ms8EKobJF45+fduBIlhYtSH798klutDiGCXvoiiLv4/iW5 TKLnCRW+SymnQ/4C/OCnZyLe1ZjWQnryMLsvHWyXWkoJH/1bjSeWEZiUVC/gh5PUl5z7 elYh5TImwrOyhIqZDYfDpUVW8u2RXSkUSPu3WeRhq8zEpqkE3SU5N6kzN2SaEKrZS2+U uIEsP0+9t793B05qCf2AC+5ctM9ddQ6nlzL8F4xcYvhI7JgH070/XbRLUVOQpohMb1UA Ojaw== MIME-Version: 1.0 X-Received: by 10.42.16.2 with SMTP id n2mr1425914ica.93.1407879629723; Tue, 12 Aug 2014 14:40:29 -0700 (PDT) Received: by 10.107.3.13 with HTTP; Tue, 12 Aug 2014 14:40:29 -0700 (PDT) In-Reply-To: <8691dc326ac842e2bfcd60110bb2e712@CO1PR05MB442.namprd05.prod.outlook.com> References: <2c0d62b578de4c7eb9ef414690cbb1c5@CO1PR05MB442.namprd05.prod.outlook.com> <7c32ce118ae647c7bbff214282dd08d9@CO1PR05MB442.namprd05.prod.outlook.com> <8DD89C22-E176-4D62-AFE4-1C71B04A6281@cisco.com> <0bd2234a8e454f6ebfdb255d94e420c2@CO1PR05MB442.namprd05.prod.outlook.com> <20932882-7298-47D7-AA45-0C19E4E8E662@cisco.com> <0d8087164f8f4cca864868011c555ea7@CO1PR05MB442.namprd05.prod.outlook.com> <5D8FD44A-3FF8-413F-8B96-52C7C55C7A92@gmail.com> <8691dc326ac842e2bfcd60110bb2e712@CO1PR05MB442.namprd05.prod.outlook.com> Date: Tue, 12 Aug 2014 23:40:29 +0200 Message-ID: From: Albert Cabellos To: Ronald Bonica Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/29r-pZSOdg4W0NoMjeu3frZDGCI Cc: LISP mailing list list Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 2) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 21:40:32 -0000 Hi Ron The text that I suggested was meant for the introduction section, not as a definition of the term. Albert On Tue, Aug 12, 2014 at 1:39 AM, Ronald Bonica wrote: > Dino, > > Exactly! The Intro doc needs text that is a) easy to parse and b) technically correct. This will certainly be more coarse that the definition in 6830, but probably a little more verbose than what we have already proposed. > > Ron > > > >> >> Let's have descriptions where they are needed and formal definitions in the >> specs that were already published. And we should have the intro document >> make the descriptions more coarser than the technical definitions in the >> specs. Agree? >> >> Dino > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Tue Aug 12 14:46:45 2014 Return-Path: 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 326481A09D2 for ; Tue, 12 Aug 2014 14:46:43 -0700 (PDT) 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 n4wM9srKJcCM for ; Tue, 12 Aug 2014 14:46:40 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECDB91A09CE for ; Tue, 12 Aug 2014 14:46:36 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id hn18so8125208igb.10 for ; Tue, 12 Aug 2014 14:46:36 -0700 (PDT) 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=QcP3jms6aTGd0ktaEAez773nLM5ejgT4xzjz+ryQsn0=; b=XinWFyKrKiVfD0v+riCiviOyaNONgqqoKJGH2G0esT8ltpsWXSZQOvhr78ffXhqzsd VsjN87x1dj75wa5ruWDEyHdaVrCeL7cClOY0gSgbVrw2HVwWU6Z9TpAVoY35JAb2wUmR Wc8F9ENColOObl6MTshdj9HAlsGR99yO2KAy90RVelN0PLzYMlUVSrWxi2ZUz2DQDCfc HVb7M00hlvZn7WF8cERqePfNL5lzcGRRE87wBhMYIE3lMcI52eFvgsw2iXN79wRIXZaP lZ1x7PObWZPXWKwDkrfP2L2JNp11mArvuEDUvP/yi6PyhZdcYIYeBr2Jydy7wheytEMY gKyg== MIME-Version: 1.0 X-Received: by 10.42.216.148 with SMTP id hi20mr1346920icb.12.1407879996100; Tue, 12 Aug 2014 14:46:36 -0700 (PDT) Received: by 10.107.3.13 with HTTP; Tue, 12 Aug 2014 14:46:36 -0700 (PDT) In-Reply-To: <2719F4DB-275C-4791-BC4A-EA15C21502FE@cisco.com> References: <4a21b4f2c26d40b5bb5cecca5b1d4018@CO1PR05MB442.namprd05.prod.outlook.com> <25146EB9-0AC1-4443-8D2C-ADC15A66794E@gmail.com> <47A3E14F-CF89-458D-A351-63B1072FB3C4@cisco.com> <2719F4DB-275C-4791-BC4A-EA15C21502FE@cisco.com> Date: Tue, 12 Aug 2014 23:46:36 +0200 Message-ID: From: Albert Cabellos To: "Victor Moreno (vimoreno)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/WZPHOPEp54JS3IHO4V8FqJ1mTjo Cc: LISP mailing list list Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 21:46:43 -0000 +1 The main goal of the document is to introduce LISP, we should avoid comparisons. Albert On Tue, Aug 12, 2014 at 2:51 AM, Victor Moreno (vimoreno) wrote: > > +1 > > I am however interested in the comparison, but I don't see it as part of an introduction or other lisp specification document > Victor > >> On Aug 11, 2014, at 4:33 PM, "Dino Farinacci" wrote: >> >> We should not compare LISP to any other protocol. We should define what LISP is. BGP and LISP solve different problems. >> >> Dino >> >>> On Aug 11, 2014, at 4:13 PM, Ronald Bonica wrote: >>> >>> Darrel, >>> >>> Clearly, this is a WG document and the entire WG gets a chance to review, accept or reject a contribution. That goes without saying for any document. >>> >>> Ron >>> >>>> -----Original Message----- >>>> From: Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] >>>> Sent: Monday, August 11, 2014 7:10 PM >>>> To: Ronald Bonica >>>> Cc: Darrel Lewis (darlewis); Dino Farinacci; LISP mailing list list >>>> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) >>>> >>>> >>>> >>>> I mentioned that I'd want to see the text before supporting (or opposing) its >>>> inclusion... So adding sections seems somewhat premature. >>>> >>>> >>>> -D >>>>> On Aug 11, 2014, at 3:55 PM, Ronald Bonica wrote: >>>>> >>>>> >>>>> >>>>> Darrel, >>>>> >>>>> Fair enough. >>>>> >>>>> Could the editors leave an empty section between the sections that are >>>> now numbered 6.4 and 6.5. The Title of that section is "Differences Between >>>> LISP and BGP". I will provide text within the next week or so. >>>>> >>>>> Ron >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] >>>>>> Sent: Monday, August 11, 2014 1:29 PM >>>>>> To: Ronald Bonica >>>>>> Cc: Darrel Lewis (darlewis); Dino Farinacci; LISP mailing list list >>>>>> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) >>>>>> >>>>>> >>>>>>> On Aug 11, 2014, at 9:59 AM, Ronald Bonica wrote: >>>>>>> >>>>>>> >>>>>>> In order to help the reader understand the difference between LISP >>>>>>> and >>>>>> BGP, it might be a good idea to add a few pages that compare and >>>>>> contrast the two. It should answer the following questions: >>>>>>> >>>>>>> - In BGP, how does the producer of a route know that it is time to >>>>>>> push it >>>>>>> - In LISP, how does the consumer of a route know that it is time to >>>>>>> pull it >>>>>>> - In BGP, what happens when the control path between the producer >>>>>>> and >>>>>> consumer of a route becomes degraded or unusable >>>>>>> - In LISP, what happens when the control path between the producer >>>>>>> and >>>>>> consumer of a route becomes degraded or unusable >>>>>>> >>>>>>> >>>>>>> Ron >>>>>> >>>>>> I eagerly await your suggested text. >>>>>> >>>>>> -D >> >> _______________________________________________ >> 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 From nobody Wed Aug 13 07:58:20 2014 Return-Path: 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 817271A0750 for ; Wed, 13 Aug 2014 07:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 Un7N5P7kzrdB for ; Wed, 13 Aug 2014 07:58:17 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A54AC1A072D for ; Wed, 13 Aug 2014 07:58:16 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id n3so8524341wiv.2 for ; Wed, 13 Aug 2014 07:58:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=sWRGETec6KUJZicMPtzPrPYjtYnmWG18l8p459jmbng=; b=deuETX90SqwNyIqnHmu52c+6+GrB7PVSAGfF1G0Ibi/Ph/Mpx3PH2jOoWr/KrnLDwz c/EC7hGWtQQ8ncV6LoHWhdnOTYpmKCWq/h6cev/Avtki3imXss/GfWhcMlesFMaY5xtH yJnWCXeaH8WT46HD1maT7C3HeY7By3w8J3Zpp3m2R2/1YoXnaD9mWdS5dxLYNBnX92NJ e+h52S4Ew6e9LHasAQzCug6f+hrq0i7vP8C/DBPAoguLVhpTddIM/g1mae4W5nWC8kBK HmGTMx4sXtN2kLqri/dTiRe44Md5cf5AnU3A9r6OXCa7w7cnQSbRoABaoL5hP8t+PixK tSjw== X-Gm-Message-State: ALoCoQkeXPgyn8UaE2o3scuwp9ZUe2el+OstcW6sScZiW4vDjDxfT3o2bXJGg8iIu6vRnTaLig+y X-Received: by 10.180.39.172 with SMTP id q12mr5428288wik.55.1407941895286; Wed, 13 Aug 2014 07:58:15 -0700 (PDT) Received: from [192.168.1.9] (host236-116-dynamic.37-79-r.retail.telecomitalia.it. [79.37.116.236]) by mx.google.com with ESMTPSA id y10sm9220562wie.18.2014.08.13.07.58.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Aug 2014 07:58:14 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Luigi Iannone In-Reply-To: Date: Wed, 13 Aug 2014 16:57:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4a21b4f2c26d40b5bb5cecca5b1d4018@CO1PR05MB442.namprd05.prod.outlook.com> <25146EB9-0AC1-4443-8D2C-ADC15A66794E@gmail.com> <47A3E14F-CF89-458D-A351-63B1072FB3C4@cisco.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/o-vCYtkVhW-F_cW9gJoGPPe_5U8 Cc: LISP mailing list list Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 14:58:18 -0000 As a personal opinion, I tend to agree with Dino.=20 It might be better to compare pull vs push model without the specifics = of BGP (or nay other push-based solution). Independently from whether we compare vs BGP or not, it is still worth = to have such discussion in the document IMHO. Luigi On 12 Aug 2014, at 01:32, Dino Farinacci wrote: > We should not compare LISP to any other protocol. We should define = what LISP is. BGP and LISP solve different problems. >=20 > Dino >=20 > On Aug 11, 2014, at 4:13 PM, Ronald Bonica = wrote: >=20 >> Darrel, >>=20 >> Clearly, this is a WG document and the entire WG gets a chance to = review, accept or reject a contribution. That goes without saying for = any document. >>=20 >> = Ron >>=20 >>> -----Original Message----- >>> From: Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] >>> Sent: Monday, August 11, 2014 7:10 PM >>> To: Ronald Bonica >>> Cc: Darrel Lewis (darlewis); Dino Farinacci; LISP mailing list list >>> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) >>>=20 >>> >>>=20 >>> I mentioned that I'd want to see the text before supporting (or = opposing) its >>> inclusion... So adding sections seems somewhat premature. >>>=20 >>>=20 >>> -D >>> On Aug 11, 2014, at 3:55 PM, Ronald Bonica = wrote: >>>=20 >>>> >>>>=20 >>>> Darrel, >>>>=20 >>>> Fair enough. >>>>=20 >>>> Could the editors leave an empty section between the sections that = are >>> now numbered 6.4 and 6.5. The Title of that section is "Differences = Between >>> LISP and BGP". I will provide text within the next week or so. >>>>=20 >>>> Ron >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] >>>>> Sent: Monday, August 11, 2014 1:29 PM >>>>> To: Ronald Bonica >>>>> Cc: Darrel Lewis (darlewis); Dino Farinacci; LISP mailing list = list >>>>> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) >>>>>=20 >>>>>=20 >>>>> On Aug 11, 2014, at 9:59 AM, Ronald Bonica = wrote: >>>>>=20 >>>>>>=20 >>>>>> In order to help the reader understand the difference between = LISP >>>>>> and >>>>> BGP, it might be a good idea to add a few pages that compare and >>>>> contrast the two. It should answer the following questions: >>>>>>=20 >>>>>> - In BGP, how does the producer of a route know that it is time = to >>>>>> push it >>>>>> - In LISP, how does the consumer of a route know that it is time = to >>>>>> pull it >>>>>> - In BGP, what happens when the control path between the producer >>>>>> and >>>>> consumer of a route becomes degraded or unusable >>>>>> - In LISP, what happens when the control path between the = producer >>>>>> and >>>>> consumer of a route becomes degraded or unusable >>>>>>=20 >>>>>>=20 >>>>>> Ron >>>>>=20 >>>>> I eagerly await your suggested text. >>>>>=20 >>>>> -D >>=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Wed Aug 13 17:59:27 2014 Return-Path: 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 05F091A065E for ; Wed, 13 Aug 2014 17:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.602 X-Spam-Level: X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 UY_8-JjA95-K for ; Wed, 13 Aug 2014 17:59:24 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7680A1A065B for ; Wed, 13 Aug 2014 17:59:24 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Thu, 14 Aug 2014 00:59:21 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.224]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.53]) with mapi id 15.00.1005.008; Thu, 14 Aug 2014 00:59:22 +0000 From: Ronald Bonica To: Luigi Iannone , Dino Farinacci Thread-Topic: [lisp] draft-ietf-lisp-introduction-04 (Part 3) Thread-Index: Ac+xplSWhfzVPftgQfa8OfG0BIHHYQAE/j0AAPKPgFAAAUu5AAALY9jQAACCs4AAABcC4AAAuEQAAFKWEQAAFEonsA== Date: Thu, 14 Aug 2014 00:59:21 +0000 Message-ID: <826389c8aa8a4b2590e04fcee008add9@CO1PR05MB442.namprd05.prod.outlook.com> References: <4a21b4f2c26d40b5bb5cecca5b1d4018@CO1PR05MB442.namprd05.prod.outlook.com> <25146EB9-0AC1-4443-8D2C-ADC15A66794E@gmail.com> <47A3E14F-CF89-458D-A351-63B1072FB3C4@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03030B9493 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(24454002)(189002)(13464003)(199003)(377454003)(51704005)(83072002)(76482001)(77096002)(86362001)(77982001)(74502001)(79102001)(74662001)(92566001)(85852003)(2656002)(46102001)(101416001)(31966008)(74316001)(99286002)(80022001)(95666004)(107046002)(54356999)(19580395003)(33646002)(85306004)(105586002)(76576001)(64706001)(81542001)(4396001)(83322001)(19580405001)(87936001)(15975445006)(50986999)(20776003)(106356001)(21056001)(108616004)(81342001)(66066001)(93886004)(76176999)(99396002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB444; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/R5hDBEZZW7TBssk3kE0dcla1O8s Cc: LISP mailing list list Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 00:59:26 -0000 Luigi, You and Dino both have a good point. We don't want to turn the LISP intro d= ocument into a beauty contest between BGP and LISP. However, we do want to = explain what LISP is and what makes it unique. The pull model is certainly among LISP's salient characteristics. So, the n= ew section should discuss the following: - benefits of the pull model - challenges presented by the pull model - LISP machinery designed to address those challenges I would be glad to propose some text for that section. Ron > -----Original Message----- > From: Luigi Iannone [mailto:ggx@gigix.net] > Sent: Wednesday, August 13, 2014 10:58 AM > To: Dino Farinacci > Cc: Ronald Bonica; LISP mailing list list > Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) >=20 > As a personal opinion, I tend to agree with Dino. >=20 > It might be better to compare pull vs push model without the specifics of > BGP (or nay other push-based solution). >=20 > Independently from whether we compare vs BGP or not, it is still worth to > have such discussion in the document IMHO. >=20 > Luigi >=20 >=20 >=20 > On 12 Aug 2014, at 01:32, Dino Farinacci wrote: >=20 > > We should not compare LISP to any other protocol. We should define what > LISP is. BGP and LISP solve different problems. > > > > Dino > > > > On Aug 11, 2014, at 4:13 PM, Ronald Bonica wrote: > > > >> Darrel, > >> > >> Clearly, this is a WG document and the entire WG gets a chance to revi= ew, > accept or reject a contribution. That goes without saying for any documen= t. > >> > >> > >> Ron > >> > >>> -----Original Message----- > >>> From: Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] > >>> Sent: Monday, August 11, 2014 7:10 PM > >>> To: Ronald Bonica > >>> Cc: Darrel Lewis (darlewis); Dino Farinacci; LISP mailing list list > >>> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) > >>> > >>> > >>> > >>> I mentioned that I'd want to see the text before supporting (or > >>> opposing) its inclusion... So adding sections seems somewhat > premature. > >>> > >>> > >>> -D > >>> On Aug 11, 2014, at 3:55 PM, Ronald Bonica > wrote: > >>> > >>>> > >>>> > >>>> Darrel, > >>>> > >>>> Fair enough. > >>>> > >>>> Could the editors leave an empty section between the sections that > >>>> are > >>> now numbered 6.4 and 6.5. The Title of that section is "Differences > >>> Between LISP and BGP". I will provide text within the next week or so= . > >>>> > >>>> Ron > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Darrel Lewis (darlewis) [mailto:darlewis@cisco.com] > >>>>> Sent: Monday, August 11, 2014 1:29 PM > >>>>> To: Ronald Bonica > >>>>> Cc: Darrel Lewis (darlewis); Dino Farinacci; LISP mailing list > >>>>> list > >>>>> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 3) > >>>>> > >>>>> > >>>>> On Aug 11, 2014, at 9:59 AM, Ronald Bonica > wrote: > >>>>> > >>>>>> > >>>>>> In order to help the reader understand the difference between > >>>>>> LISP and > >>>>> BGP, it might be a good idea to add a few pages that compare and > >>>>> contrast the two. It should answer the following questions: > >>>>>> > >>>>>> - In BGP, how does the producer of a route know that it is time > >>>>>> to push it > >>>>>> - In LISP, how does the consumer of a route know that it is time > >>>>>> to pull it > >>>>>> - In BGP, what happens when the control path between the > producer > >>>>>> and > >>>>> consumer of a route becomes degraded or unusable > >>>>>> - In LISP, what happens when the control path between the > >>>>>> producer and > >>>>> consumer of a route becomes degraded or unusable > >>>>>> > >>>>>> > >>>>>> Ron > >>>>> > >>>>> I eagerly await your suggested text. > >>>>> > >>>>> -D > >> > > > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp From nobody Sat Aug 16 02:31:54 2014 Return-Path: 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 548511A870E for ; Sat, 16 Aug 2014 02:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.149 X-Spam-Level: * X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, SPF_PASS=-0.001] autolearn=no 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 sOUe10lLHJ_x for ; Sat, 16 Aug 2014 02:31:52 -0700 (PDT) Received: from triangulum.uberspace.de (triangulum.uberspace.de [95.143.172.227]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC12E1A8708 for ; Sat, 16 Aug 2014 02:31:51 -0700 (PDT) Received: (qmail 12857 invoked from network); 16 Aug 2014 09:31:49 -0000 Received: from localhost (HELO www.bartschnet.de) (127.0.0.1) by triangulum.uberspace.de with SMTP; 16 Aug 2014 09:31:49 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 16 Aug 2014 11:31:48 +0200 From: Rene Bartsch To: IETF Message-ID: X-Sender: ietf@bartschnet.de User-Agent: Roundcube Webmail/1.0.1 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/3UDQYHa1gdaRK0cLFSWgtItV--s Subject: [lisp] Current state of NAT traversal in beta network 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 09:31:53 -0000 Hi, Lispmob 4.1 with NAT traversal support is available. Is there any kind of list which PxTRs in the beta network support RTR functionality for NAT traversal? Do mapping servers/resolvers need special functionality for NAT traversal? Renne -- Best regards, Rene Bartsch, B. Sc. Informatics From nobody Sun Aug 17 12:42:11 2014 Return-Path: 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 0C4A01A6FC8 for ; Sun, 17 Aug 2014 12:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 FSJXh8kk1f_E for ; Sun, 17 Aug 2014 12:42:08 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F33271A0151 for ; Sun, 17 Aug 2014 12:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2339; q=dns/txt; s=iport; t=1408304528; x=1409514128; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=daAPhqhKCvhu1GTGFzMTEPnApAJOuHWyV2/qhxpS40k=; b=XN7nEnQZnOygjYCLdNnHw4T0FtroGZiCq3wyhnenliydelkyUAltHvz2 DpyuBEdQpdWeRYwIcU/CXOzjTEQ3GrSTF1pc5v0udqYTk2Md0iaBAiQrM T36HC+1EeOlfYT5A4a38cY/ma3U6gtP6C89KEQisCkb5338sTp/aANpVb M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsFAFMF8VOtJV2P/2dsb2JhbABVA4MNU1cEzE0Kh1gBgQ0Wd4QEAQEDAQEBAUYlAQMHBQsCAQgOOCcLJQIEDgWIOggNwRIXjmoRAR0NFhACBRGCJ1MkgR0FhhGLFIQmhneBV5Msg11sAYEOOYEHAQEB X-IronPort-AV: E=Sophos;i="5.01,880,1400025600"; d="scan'208";a="69964726" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP; 17 Aug 2014 19:41:55 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s7HJftN7003690 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 17 Aug 2014 19:41:55 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Sun, 17 Aug 2014 14:41:54 -0500 From: "Gregg Schudel (gschudel)" To: Rene Bartsch Thread-Topic: [lisp] Current state of NAT traversal in beta network Thread-Index: AQHPuTTwzUSnONLuCkqzYRcw8LwEQpvViAAA Date: Sun, 17 Aug 2014 19:41:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.65.197] Content-Type: text/plain; charset="Windows-1252" Content-ID: <46801DA534D6F642BEFE0ADD0A747BB5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/8_Vcc8VrM07aUt7oIl2i34SepGU Cc: IETF Subject: Re: [lisp] Current state of NAT traversal in beta network 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 19:42:10 -0000 On Aug 16, 2014, at 2:31 AM, Rene Bartsch wrote: > Hi, >=20 > Lispmob 4.1 with NAT traversal support is available. >=20 > Is there any kind of list which PxTRs in the beta network support RTR fun= ctionality for NAT traversal? >=20 > Do mapping servers/resolvers need special functionality for NAT traversal= ? >=20 >=20 > Renne >=20 > --=20 > Best regards, >=20 > Rene Bartsch, B. Sc. Informatics >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp Hey Rene This mailer (lisp@ietf.org) (I would assume) is best used for IETF LISP Wor= king=20 Group questions. The LISP Beta Network is a multi-company/university effort to educate and i= nform about the=20 LISP protocol. While it=92s (obviously) running various LISP implementation= s, the operation=20 and support is not tied to the IETF or the working group. As noted on www.l= isp4.net,=20 questions about operations can be sent to lisp-ops@external.cisco.com (we h= appen to host the mailer). With regard to LISP NAT-Traversal,=20 * yes - lispmob (and also an appropriate place to ask questions -- lispmob.= org) does have=20 experimental code for NAT-T, and LISP Beta Network does have a few PxTRs = running experimental=20 NAT-T code (meaning they are now RTRs) for this purpose.=20 * yes, Map-Server/Map-Resolver functionality is also applied for NAT-T. Thi= s relationship=20 (between an MSMR and an RTR) is covered quite well in "draft-ermagan-lisp= -nat-traversal.06=94 (http://tools.ietf.org/id/draft-ermagan-lisp-nat-traversal-06.txt) If you=92d like to experiment with lispmob and NAT-T on LISP Beta Network, = please send an email to the lispmob team and they can help. (see the lispmob.org =93contact=94 p= age) Best regards, Gregg -------------------------------------------------------------------- .:|:.:|:. | gregg schudel (ccie#9591) LISP technical marketing engr cisco | mobile: +1 571 332 2222 email: gschudel@cisco.com -------------------------------------------------------------------- cisco corporate legal statement:=20 http://www.cisco.com/web/about/doing_business/legal/cri/index.html -------------------------------------------------------------------- From nobody Mon Aug 18 02:35:07 2014 Return-Path: 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 221651A0396 for ; Mon, 18 Aug 2014 02:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 Gr_Nuto8BkNV for ; Mon, 18 Aug 2014 02:34:59 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id E4A381A0395 for ; Mon, 18 Aug 2014 02:34:58 -0700 (PDT) Received: from gw-3.ac.upc.es (gw-3.ac.upc.es [147.83.30.9]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id s7I9aJjS018625 for ; Mon, 18 Aug 2014 11:36:19 +0200 Received: from mail-yk0-f174.google.com (mail-yk0-f174.google.com [209.85.160.174]) by gw-3.ac.upc.es (Postfix) with ESMTPSA id A5CE29B7 for ; Mon, 18 Aug 2014 11:34:56 +0200 (CEST) Received: by mail-yk0-f174.google.com with SMTP id q9so4038175ykb.19 for ; Mon, 18 Aug 2014 02:34:54 -0700 (PDT) X-Received: by 10.236.104.133 with SMTP id i5mr269087yhg.137.1408354494950; Mon, 18 Aug 2014 02:34:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.170.75.135 with HTTP; Mon, 18 Aug 2014 02:34:34 -0700 (PDT) In-Reply-To: <53E8E639.20701@lip6.fr> References: <20140704130144.20502.78491.idtracker@ietfa.amsl.com> <53E8E639.20701@lip6.fr> From: Alberto Rodriguez-Natal Date: Mon, 18 Aug 2014 11:34:34 +0200 Message-ID: To: Matthieu Coudron Content-Type: multipart/alternative; boundary=001a11c2c69463b5960500e415ea Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/hJQmKKngKFOGEuckzk_S8X-9RVc Cc: Stefano Secci , "lisp@ietf.org list" Subject: Re: [lisp] Fwd: New Version Notification for draft-rodrigueznatal-lisp-oam-00.txt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 09:35:04 -0000 --001a11c2c69463b5960500e415ea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Matthieu and Stefano, Thank you very much for reviewing the draft. Your comments are deeply appreciated. Please see inline. On Mon, Aug 11, 2014 at 5:50 PM, Matthieu Coudron wrote: > Dear all, > > we reviewed the draft and following offline discussions with Albert, you > will find below a few comments. > > Best regards, > Matthieu Coudron > Stefano Secci > > ____________________________ > 2. Underlay definition > "The underlay corresponds to the RLOC space" > This appears as too restrictive, as information about the underlay could > come also from local AS/domain-level information such as traffic > engineering databases, monitoring tools, etc, unaware of LISP. > > [AR] I think we could reword that. How about this text? "In most cases the underlay is equivalent to the RLOC space, however it can also comprise information from external sources such traffic engineering databases, monitoring tools, etc" > ____________________________ > 3.2 MPTCP > "Each of these sub-flows behaves as a legacy TCP flow and hence, from the > network point of view, each sub-flow is a different TCP session. The > network conditions over the different paths the sub-flows follow affect t= he > whole MPTCP session. Since MPTCP has to keep the aggregate session > consistent, each aggregated flow can perform as good as the worst of the > sub flows it integrates." > > This paragraph seems incorrect. MPTCP RFC 6182 section 2.1 states that > MPTCP should be at least as good as TCP, which in practice is true except > in a few cases (e.g., if a subflow with a large share of the window becom= es > inactive, then you need to wait several timeouts before being able to be > aggressive enough on other subflows). The RFC does not precisely address > the scheduling mechanisms, but if for instance you consider the Linux > implementation (http://www.multipath-tcp.org), it sends a maximum amount > of data on the subflow with the lowest RTT and once its window is full, i= t > will send on the 2nd lowest RTT subflow etc... so providing there is enou= gh > buffering at each endpoint, in terms of sheer throughput MPTCP should be > able to aggregate all the subflows independently of their latency. It is > true though that if packets are not scheduled carefully on each subflow, > then application latency may increase. > > [AR] I believe that we are on the same page here. The point that we tried to make here is that "on worst case scenario, MPTCP performs as good as TCP". Perhaps that was not stated clearly enough. Maybe we could keep this paragraph short (one sentence) and just point people to MPTCP RFC. Would that make sense? > At LIP6, we already run LISP+MPTCP coupling experimentations (LISP > providing topology informations and forwarding capabilities to the MPTCP > layer), we documented last year in this article =E2=80=9CCross-layer Coop= eration to > Boost Multipath TCP Performance in Cloud Networks=E2=80=9D available at: > http://www-phare.lip6.fr/~secci/papers/CoSePuRaGa-CLOUDNET13.pdf . In our > experiment, RTTs of the different paths were close to each other, which > lead to very good performance, as the lower the RTT gap the better MPTCP > performance. See here another interesting article about this matter: "Ho= w > hard can it be? Designing and Implementing a Deployable MPTCP" available = at > https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf > [AR] Thank you very much for the pointers, they provide good insight for this draft. They are greatly appreciated :) > > ____________________________ > 4. Requirements / Device Discovery > "This is solved for xTRs by sending Map Register messages." > > Did you mean Map Requests? Or can you explain why only Map Register? > > [AR] We were talking here about the fact that in vanilla LISP the MappingSystem can be aware of existing xTRs since they keep sending MapRegisters. The MapRegister process works already as an automated discovery mechanism. We'll extend the sentence to clarify this. > > ____________________________ > 4. Requirements / Forwarding Actions > > "These actions can be implemented as extensions to the current > specifications of LISP-TE or LISP-SR or be defined by means of a new LCAF= ." > > Here it would be better not to exclude existing LCAF. For the MPTCP > use-case, we have a prototype using already proposed LCAF messages. > [AR] Good point. How about this? "These actions can be implemented as extensions to the current specifications of LISP-TE or LISP-SR, leverage on reusing existing LCAF types or be defined by means of a new LCAF." > > ____________________________ > 7. Security Considerations > "When including capabilities to allow for the discovery of devices and it= s > capabilities, as well as the collection of metrics regarding the underlay > and the local device itself, it should be taken into consideration that > proper controls are put in place to enforce strict policies as to which > devices can access what type(s) of information." > > Do you have any protocol in mind to get metrics from the overlay to the > underlay? > [AR] We're currently discussing this. Nothing fixed yet ;) > Relevant nodes should be chosen carefully so that they are not malicious > or misfunctioning. For instance the TCP RTT seen by a VM is higher than o= ne > seen by a physical machine due to the hypervisor scheduling latency. [AR] That's indeed correct. We'll try to keep that in mind. Thanks again for your comments. We hope you can keep contributing to this draft :) Best, Alberto > > > > > On 11/08/2014 16:46, Matthieu Coudron wrote: > >> ---------- Forwarded message ---------- >> From: Alberto Rodriguez-Natal >> Date: 2014-07-04 15:16 GMT+02:00 >> Subject: [lisp] Fwd: New Version Notification for >> draft-rodrigueznatal-lisp-oam-00.txt >> To: "lisp@ietf.org list" >> >> >> Dear all, >> >> We have just submitted a new draft discussing OAM (Operations >> Administration Management) use-cases and requirements for LISP. >> >> Please, feel free to review it and provide feedback. >> >> Thanks, >> Alberto >> >> ---------- Forwarded message ---------- >> From: >> Date: Fri, Jul 4, 2014 at 10:01 PM >> Subject: New Version Notification for draft-rodrigueznatal-lisp-oam- >> 00.txt >> To: Albert Cabellos-Aparicio , Marc >> Portoles-Comeras , Alberto Rodriguez-Natal >> , Michael Kowal , Darrel Lewis >> , Fabio Maino >> >> >> >> A new version of I-D, draft-rodrigueznatal-lisp-oam-00.txt >> has been successfully submitted by Alberto Rodriguez-Natal and posted to >> the >> IETF repository. >> >> Name: draft-rodrigueznatal-lisp-oam >> Revision: 00 >> Title: LISP-OAM (Operations Administration Management): Use >> cases and requirements >> Document date: 2014-07-04 >> Group: Individual Submission >> Pages: 13 >> URL: >> http://www.ietf.org/internet-drafts/draft-rodrigueznatal-lisp-oam-00.txt >> Status: https://datatracker.ietf.org/ >> doc/draft-rodrigueznatal-lisp-oam/ >> Htmlized: http://tools.ietf.org/html/draft-rodrigueznatal-lisp-oam= - >> 00 >> >> >> Abstract: >> This document describes Operations Administration and Management >> (OAM) use-cases and the requirements that they have towards the LISP >> architecture. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> 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 > --001a11c2c69463b5960500e415ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Matthieu and Stefano,

Thank you very much for re= viewing the draft. Your comments are deeply appreciated.

Please see= inline.


On Mo= n, Aug 11, 2014 at 5:50 PM, Matthieu Coudron <matthieu.coudron@lip= 6.fr> wrote:
Dear all,

we reviewed the draft and following offline discussions with Albert, you wi= ll find below a few comments.

Best regards,
Matthieu Coudron
Stefano Secci

____________________________
2. Underlay definition
"The underlay corresponds to the RLOC space"
This appears as too restrictive, as information about the underlay could co= me also from local AS/domain-level information such as traffic engineering = databases, monitoring tools, etc, unaware of LISP.

[AR] I think we could rewo= rd that. How about this text?

"In most cases the underlay is equivalent to the RLOC space, however it can also comprise information from external sources such traffic=20 engineering databases, monitoring tools, etc"

=C2=A0
____________________________
3.2 MPTCP
"Each of these sub-flows behaves as a legacy TCP flow and hence, from = the network point of view, each sub-flow is a different TCP session. The ne= twork conditions over the different paths the sub-flows follow affect the w= hole MPTCP session.=C2=A0 Since MPTCP has to keep the aggregate session con= sistent, each aggregated flow can perform as good as the worst of the sub f= lows it integrates."

This paragraph seems incorrect. MPTCP RFC 6182 section 2.1 states that MPTC= P should be at least as good as TCP, which in practice is true except in a = few cases (e.g., if a subflow with a large share of the window becomes inac= tive, then you need to wait several timeouts before being able to be aggres= sive enough on other subflows). The RFC does not precisely address the sche= duling mechanisms, but if for instance you consider the Linux implementatio= n (http://www.mu= ltipath-tcp.org), it sends a maximum amount of data on the subfl= ow with the lowest RTT and once its window is full, it will send on the 2nd= lowest RTT subflow etc... so providing there is enough buffering at each e= ndpoint, in terms of sheer throughput MPTCP should be able to aggregate all= the subflows independently of their latency. It is true though that if pac= kets are not scheduled carefully on each subflow, then application latency = may=C2=A0 increase.


[AR] I believe that we are on the same page here. The point that we tried to=20 make here is that "on worst case scenario, MPTCP performs as good as= =20 TCP". Perhaps that was not stated clearly enough. Maybe=20 we could keep this paragraph short (one sentence) and just point people to MPTCP RFC. Would that make sense?
=C2=A0
At LIP6, we already run LISP+MPTCP coupling experimentations (LISP providin= g topology informations and forwarding capabilities to the MPTCP layer), we= documented last year in this article =E2=80=9CCross-layer Cooperation to B= oost Multipath TCP Performance in Cloud Networks=E2=80=9D available at: http://www-phare.lip6.fr/~secci/papers/CoSePuRaGa-<= u>CLOUDNET13.pdf . In our experiment, RTTs of the different paths w= ere close to each other, which lead to very good performance, as the lower = the RTT gap the better MPTCP performance.=C2=A0 See here another interestin= g article about this matter: "How hard can it be? Designing and Implem= enting a Deployable MPTCP" available at h= ttps://www.usenix.org/system/files/conference/nsdi12/nsdi12-f= inal125.pdf

[AR] Thank you very much for the pointers, they provi= de good insight for this draft. They are greatly appreciated :)
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
____________________________
4. Requirements / Device Discovery
"This is solved for xTRs by sending Map Register messages."

Did you mean Map Requests? Or can you explain why only Map Register?

[AR] We were talking here about the fact that in vani= lla LISP the=20 MappingSystem can be aware of existing xTRs since they keep sending=20 MapRegisters. The MapRegister process works already as an automated=20 discovery mechanism. We'll extend the sentence to clarify this.

____________________________
4. Requirements / Forwarding Actions

"These actions can be implemented as extensions to the current specifi= cations of LISP-TE or LISP-SR or be defined by means of a new LCAF."
Here it would be better not to exclude existing LCAF. For the MPTCP use-cas= e, we have a prototype using already proposed LCAF messages.

[AR] Good point. How about this?

"These actions can = be implemented as extensions to the current=20 specifications of LISP-TE or LISP-SR, leverage on reusing existing LCAF typ= es or be defined by means of a new=20 LCAF."

____________________________
7. Security Considerations
"When including capabilities to allow for the discovery of devices and= its capabilities, as well as the collection of metrics regarding the under= lay and the local device itself, it should be taken into consideration that= proper controls are put in=C2=A0 place to enforce strict policies as to wh= ich devices can access what type(s) of information."

Do you have any protocol in mind to get metrics from the overlay to the und= erlay?

[AR] We're currently discussing this. N= othing fixed yet ;)
=C2=A0
Relevant nodes should be chosen carefully so that they are not malicious or= misfunctioning. For instance the TCP RTT seen by a VM is higher than one s= een by a physical machine due to the hypervisor scheduling latency.

[AR] That's indeed correct. We'= ll try to keep that in mind.

Thank= s again for your comments. We hope you can keep contributing to this draft = :)

Best,
Alberto=C2=A0




On 11/08/2014 16:46, Matthieu Coudron wrote:
---------- Forwarded message ----------
From: Alberto Rodriguez-Natal <arnatal@ac.upc.edu>
Date: 2014-07-04 15:16 GMT+02:00
Subject: [lisp] Fwd: New Version Notification for
draft-rodrigueznatal-lisp-oam-00.txt
To: "lisp@ietf.org<= /a> list" <lisp@= ietf.org>


Dear all,

We have just submitted a new draft discussing OAM (Operations
Administration Management) use-cases and requirements for LISP.

Please, feel free to review it and provide feedback.

Thanks,
Alberto

---------- Forwarded message ----------
From: <int= ernet-drafts@ietf.org>
Date: Fri, Jul 4, 2014 at 10:01 PM
Subject: New Version Notification for draft-rodrigueznatal-lisp-oam-= 00.txt
To: Albert Cabellos-Aparicio <acabello@ac.upc.edu>, Marc
Portoles-Comeras <mportole@cisco.com>, Alberto Rodriguez-Natal
<arnatal@ac.upc.= edu>, Michael Kowal <mikowal@cisco.com>, Darrel Lewis
<darlewis@cisco.= com>, Fabio Maino <fmaino@cisco.com>



A new version of I-D, draft-rodrigueznatal-lisp-oam-00.txt
has been successfully submitted by Alberto Rodriguez-Natal and posted to th= e
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-rodrigueznatal-lisp-oam=
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 LISP-OAM (Operations Administratio= n Management): Use
cases and requirements
Document date:=C2=A0 2014-07-04
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 13
URL:
http://www.ietf.org/internet-drafts/draf= t-rodrigueznatal-lisp-oam-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatra= cker.ietf.org/doc/draft-rodrigueznatal-lisp-oam/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/ht= ml/draft-rodrigueznatal-lisp-oam-00


Abstract:
=C2=A0 =C2=A0 This document describes Operations Administration and Managem= ent
=C2=A0 =C2=A0 (OAM) use-cases and the requirements that they have towards t= he LISP
=C2=A0 =C2=A0 architecture.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



_______________________________________________
lisp mailing list
lisp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/lisp

_______________________________________________
lisp mailing list
lisp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/lisp

--001a11c2c69463b5960500e415ea-- From nobody Tue Aug 26 04:06:51 2014 Return-Path: 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 D8AF11A6F14 for ; Tue, 26 Aug 2014 04:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-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 cNdxf1ltNazd for ; Tue, 26 Aug 2014 04:06:42 -0700 (PDT) Received: from osiris.lip6.fr (osiris.lip6.fr [132.227.60.30]) by ietfa.amsl.com (Postfix) with ESMTP id DD0DC1A6F60 for ; Tue, 26 Aug 2014 04:06:41 -0700 (PDT) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by osiris.lip6.fr (8.14.9/lip6) with ESMTP id s7QB68Ne008656 ; Tue, 26 Aug 2014 13:06:08 +0200 (CEST) X-pt: osiris.lip6.fr Received: from [132.227.85.231] (portablecoudron [132.227.85.231]) (authenticated bits=0) by tibre.lip6.fr (8.14.7/8.13.3) with ESMTP id s7QB4qQP005901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 26 Aug 2014 13:04:52 +0200 (MEST) Message-ID: <53FC69D4.90806@lip6.fr> Date: Tue, 26 Aug 2014 13:04:52 +0200 From: Matthieu Coudron User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Alberto Rodriguez-Natal References: <20140704130144.20502.78491.idtracker@ietfa.amsl.com> <53E8E639.20701@lip6.fr> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (osiris.lip6.fr [132.227.60.30]); Tue, 26 Aug 2014 13:06:08 +0200 (CEST) X-Scanned-By: MIMEDefang 2.75 on 132.227.60.30 Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/uyWy63dU-mSf_EsQh6smfNsDKmI Cc: Stefano Secci , "lisp@ietf.org list" Subject: Re: [lisp] Fwd: New Version Notification for draft-rodrigueznatal-lisp-oam-00.txt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 11:06:47 -0000 We agree with your corrections. See comments inline. Cheers Matthieu Coudron Stefano Secci > ____________________________ > 2. Underlay definition > "The underlay corresponds to the RLOC space" > This appears as too restrictive, as information about the underlay > could come also from local AS/domain-level information such as > traffic engineering databases, monitoring tools, etc, unaware of LISP. > > [AR] I think we could reword that. How about this text? > > "In most cases the underlay is equivalent to the RLOC space, however it > can also comprise information from external sources such traffic > engineering databases, monitoring tools, etc" ok > ____________________________ > 3.2 MPTCP > "Each of these sub-flows behaves as a legacy TCP flow and hence, > from the network point of view, each sub-flow is a different TCP > session. The network conditions over the different paths the > sub-flows follow affect the whole MPTCP session. Since MPTCP has to > keep the aggregate session consistent, each aggregated flow can > perform as good as the worst of the sub flows it integrates." > > This paragraph seems incorrect. MPTCP RFC 6182 section 2.1 states > that MPTCP should be at least as good as TCP, which in practice is > true except in a few cases (e.g., if a subflow with a large share of > the window becomes inactive, then you need to wait several timeouts > before being able to be aggressive enough on other subflows). The > RFC does not precisely address the scheduling mechanisms, but if for > instance you consider the Linux implementation > (http://www.multipath-tcp.org)__, it sends a maximum amount of data > on the subflow with the lowest RTT and once its window is full, it > will send on the 2nd lowest RTT subflow etc... so providing there is > enough buffering at each endpoint, in terms of sheer throughput > MPTCP should be able to aggregate all the subflows independently of > their latency. It is true though that if packets are not scheduled > carefully on each subflow, then application latency may increase. > > > [AR] I believe that we are on the same page here. The point that we > tried to make here is that "on worst case scenario, MPTCP performs as > good as TCP". Perhaps that was not stated clearly enough. Maybe we could > keep this paragraph short (one sentence) and just point people to MPTCP > RFC. Would that make sense? Agreed with both points. The document should focus on how MPTCP can benefit from LISP and there are several ways. The one you present is to focus on maximally disjoint paths to support the best link backup scenario. If increased throughput is the goal of the scenario, then maximally disjoint paths may not be the best solution; the subflows could share some links as long as this link is not a bottleneck for the connection. An additional scenario could be to forward at least one subflow on a LISP path that is considered secure, e.g., over it it would be harder for an attacker to rebuild the stream of data. ____________________________ > 4. Requirements / Device Discovery > "This is solved for xTRs by sending Map Register messages." > > Did you mean Map Requests? Or can you explain why only Map Register? > > [AR] We were talking here about the fact that in vanilla LISP the > MappingSystem can be aware of existing xTRs since they keep sending > MapRegisters. The MapRegister process works already as an automated > discovery mechanism. We'll extend the sentence to clarify this. ok - it seems more appropriate to replace "xTRs" with "ETRs". > > ____________________________ > 4. Requirements / Forwarding Actions > > "These actions can be implemented as extensions to the current > specifications of LISP-TE or LISP-SR or be defined by means of a new > LCAF." > > Here it would be better not to exclude existing LCAF. For the MPTCP > use-case, we have a prototype using already proposed LCAF messages. > > > [AR] Good point. How about this? > > "These actions can be implemented as extensions to the current > specifications of LISP-TE or LISP-SR, leverage on reusing existing LCAF > types or be defined by means of a new LCAF." ok From nobody Sun Aug 31 06:22:15 2014 Return-Path: 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 B5A7E1A8976; Sun, 31 Aug 2014 06:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 L3TrRqzZGEKH; Sun, 31 Aug 2014 06:22:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31BE11A897D; Sun, 31 Aug 2014 06:22:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIX45381; Sun, 31 Aug 2014 13:22:00 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 31 Aug 2014 14:22:00 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml703-chm.china.huawei.com ([169.254.5.198]) with mapi id 14.03.0158.001; Sun, 31 Aug 2014 06:21:57 -0700 From: Linda Dunbar To: Dino Farinacci Thread-Topic: Questions on using LISP's signal free multicast for draft-ghanwani-nvo3-app-mcast-framework Thread-Index: Ac/EhQABYHv1vOWVT6W+msem4gUujQ== Date: Sun, 31 Aug 2014 13:21:57 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645DDEAFB@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.5.213] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645DDEAFBdfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/1_mgI_e6Zkl1Q2dxpTESHMoejwY Cc: "nvo3@ietf.org" , "lisp@ietf.org" Subject: [lisp] Questions on using LISP's signal free multicast for draft-ghanwani-nvo3-app-mcast-framework 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2014 13:22:05 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645DDEAFBdfweml701chm_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dino, At Toronto NV03 session, you suggested that draft-ghanwani-nvo3-app-mcast-f= ramework can use LISP's signal free multicast scheme. After studying the draft-farinacci-lisp-signal-free-multicast-00, I agree t= hat the proposed scheme can definitely solve the problem of application ini= tiated multicast in environment where underlay network don't support any IP= multicast protocol. But there are some issues of using the LISP's signal free multicast mechani= sm in Data Centers when NVEs, especially the server based hypervisor virtua= l switches, don't ( or can't) support the "General Receiver-site procedure= " documented in the "draft-farinacci-list-signal-free-multicast-00". The g= eneral receiver-site procedure requires egress edge (i.e. egress NVE) to te= rminate IGMP or PIM messages. But many NVEs (server based virtual switches)= don't terminate IGMP nor PIM. Therefore, NVO3 needs a simpler scheme for "Receiver NVEs". draft-ghanwan= i-nvo3-app-mcast-framework-00 suggests all IGMP messages are sent to "multi= cast server". Or "Multicast server" can fake "IGMP query" to all the NVEs, which forwarde= d down to applications. The reply (IGMP report) can be automatically sent b= ack to "multicast server" without NVE doing anything extra. What do you think? Linda --_000_4A95BA014132FF49AE685FAB4B9F17F645DDEAFBdfweml701chm_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dino,

 

At Toronto NV03 session, you suggested that draft-gh= anwani-nvo3-app-mcast-framework can use LISP’s signal free multicast = scheme.

After studying the draft-farinacci-lisp-signal-free-multicast-00, I agree that the prop= osed scheme can definitely solve the problem of application initiated multi= cast in environment where underlay network don’t support any IP multi= cast protocol.

 

But there are some iss= ues of using the LISP’s signal free multicast mechanism in Data Cente= rs when NVEs, especially the server based hypervisor virtual switches, &nbs= p;don’t ( or can’t) support the “General Receiver-site procedure” documented in the “draft-farinacci-list-signal-free= -multicast-00”.  The general receiver-site procedure requires eg= ress edge (i.e. egress NVE) to terminate IGMP or PIM messages. But many NVE= s (server based virtual switches) don’t terminate IGMP nor PIM.

 

Therefore, NVO3 needs = a simpler scheme for “Receiver NVEs”.   draft-ghanwan= i-nvo3-app-mcast-framework-00 suggests all IGMP messages are sent to “= ;multicast server”.

 

Or “Multicast se= rver” can fake “IGMP query” to all the NVEs, which forwar= ded down to applications. The reply (IGMP report) can be automatically sent= back to “multicast server” without NVE doing anything extra.

 

What do you think?

 

 

Linda=

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645DDEAFBdfweml701chm_-- From nobody Sun Aug 31 09:49:44 2014 Return-Path: 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 DC00F1A89B5; Sun, 31 Aug 2014 09:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 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, J_CHICKENPOX_42=0.6, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=no 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 NvsGZKv9hJvC; Sun, 31 Aug 2014 09:49:40 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 856DC1A89B4; Sun, 31 Aug 2014 09:49:40 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id lj1so10283324pab.28 for ; Sun, 31 Aug 2014 09:49:40 -0700 (PDT) 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=pEzI9w71BQb0gYFmOLrTDd5G6w33pAxZmRgMtp9+SuM=; b=DffCkVa7z4nmFMwBSiNuotJiF4ySOQiggnnKVKBrYtJ1QOXtiRX1epJTt5WuhBKUUP OhBFvnnewFL1YIg5AUIpdRSkPFKHasmjoAL0ZuyIfxLRGy2dEwXUOCm3wOoqfevEQUlH +/let/fdiBqpoOvUmQVNMap1Q3w7Wn2kCgSAi2wPcu06jJmXTq7NOe5pChGYLOwPN3Df QXShqtM4kGQ003kMGCZFgq5zZqh1MOCAz1CJxW85khni2Wq69DQ2r8GdufLsKfxgojn7 3K/fOmohvW+OuNyfOrbGrsmGGMuCASC03Y3zub8YJSnMXfzxHgRScNvB0dEL5fP8qDOP g7qQ== X-Received: by 10.68.103.4 with SMTP id fs4mr32782144pbb.58.1409503780122; Sun, 31 Aug 2014 09:49:40 -0700 (PDT) Received: from [10.221.158.193] ([166.170.38.63]) by mx.google.com with ESMTPSA id qa2sm8540636pdb.38.2014.08.31.09.49.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 31 Aug 2014 09:49:39 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-0C0492F4-2647-4DDA-A22E-3DFBB5C60685 Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (11D257) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645DDEAFB@dfweml701-chm> Date: Sun, 31 Aug 2014 09:49:37 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <4A95BA014132FF49AE685FAB4B9F17F645DDEAFB@dfweml701-chm> To: Linda Dunbar Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/Enf86qg-mujDqDiq7OVrlHmWnIc Cc: "nvo3@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] Questions on using LISP's signal free multicast for draft-ghanwani-nvo3-app-mcast-framework 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2014 16:49:42 -0000 --Apple-Mail-0C0492F4-2647-4DDA-A22E-3DFBB5C60685 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Dino, > =20 > At Toronto NV03 session, you suggested that draft-ghanwani-nvo3-app-mcast-= framework can use LISP=E2=80=99s signal free multicast scheme. > After studying the draft-farinacci-lisp-signal-free-multicast-00, I agree t= hat the proposed scheme can definitely solve the problem of application init= iated multicast in environment where underlay network don=E2=80=99t support a= ny IP multicast protocol. The design allows for either unicast or multicast RLOCs to be registered to t= he mapping system. So LISP signal-free multicast can be used when the underl= ay supports multicast.=20 > But there are some issues of using the LISP=E2=80=99s signal free multica= st mechanism in Data Centers when NVEs, especially the server based hypervis= or virtual switches, don=E2=80=99t ( or can=E2=80=99t) support the =E2=80=9C= General Receiver-site procedure=E2=80=9D documented in the =E2=80=9Cdraft-fa= rinacci-list-signal-free-multicast-00=E2=80=9D. The general Whatever the application is going to use to tell the network what multicast g= roups are joined can be used as well.=20 > receiver-site procedure requires egress edge (i.e. egress NVE) to terminat= e IGMP or PIM messages. But many NVEs (server based virtual switches) don=E2= =80=99t terminate IGMP nor PIM. Well if the virtual switch supports LISP, then the app directly tells the xT= R which groups it is joining.=20 And if the LISP xTR is one-hop northbound from the virtual switch, you can b= et the virtual switch does IGMP snooping.=20 > Therefore, NVO3 needs a simpler scheme for =E2=80=9CReceiver NVEs=E2=80=9D= . draft-ghanwani-nvo3-app-mcast-framework-00 suggests all IGMP messages ar= e sent to =E2=80=9Cmulticast server=E2=80=9D. That is not simpler - that adds a new component to the network.=20 And if you IGMP to a server why is that different than registering to a map-= server.=20 But since there is no precise serial spec'ed on how the NVE-to-NVA protocol w= orks no one can tell what can be leveraged for multicast.=20 LISP-signal-free-multicast works because the LISP mapping system protocols a= re well specified, implemented, and deployed.=20 > Or =E2=80=9CMulticast server=E2=80=9D can fake =E2=80=9CIGMP query=E2=80=9D= to all the NVEs, which forwarded down to applications. The reply (IGMP repo= rt) can be automatically sent back to =E2=80=9Cmulticast server=E2=80=9D wit= hout NVE doing anything extra. > =20 > What do you think? You want multicast routers to attach to the overlay. They don't send IGMP pa= ckets to each other. =20 IGMP is a host-to-router protocol and has been abused to be a host-to-switch= protocol. Let's stop the abuse. :-) Dino > =20 > =20 > Linda > =20 --Apple-Mail-0C0492F4-2647-4DDA-A22E-3DFBB5C60685 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Dino,

 

At Toronto NV03 session, you suggested that draft-gha= nwani-nvo3-app-mcast-framework can use LISP=E2=80=99s signal free multicast s= cheme.

After studying the draft-farinacci-lisp-signal-free-multicast-00, I agree that the propo= sed scheme can definitely solve the problem of application initiated multica= st in environment where underlay network don=E2=80=99t support any IP multic= ast protocol.


The design allows for either unicast o= r multicast RLOCs to be registered to the mapping system. So LISP signal-fre= e multicast can be used when the underlay supports multicast. 

=

 But there are so= me issues of using the LISP=E2=80=99s signal free multicast mechanism in Dat= a Centers when NVEs, especially the server based hypervisor virtual switches= ,  don=E2=80=99t ( or can=E2=80=99t) support the =E2=80=9CGeneral Recei= ver-site procedure=E2=80=9D documented in the =E2=80=9Cdraft-farinacci-list-signal-f= ree-multicast-00=E2=80=9D.  The general

<= div>
Whatever the application is going to use to tell the network w= hat multicast groups are joined can be used as well. 

receiver-site procedure requires egress edge (i.e. egress= NVE) to terminate IGMP or PIM messages. But many NVEs (server based virtual= switches) don=E2=80=99t terminate IGMP nor PIM.


Well if the virtual sw= itch supports LISP, then the app directly tells the xTR which groups it is j= oining. 

And if the LISP xTR is one-hop northb= ound from the virtual switch, you can bet the virtual switch does IGMP snoop= ing. 

 Therefore, NVO3 n= eeds a simpler scheme for =E2=80=9CReceiver NVEs=E2=80=9D.   draft= -ghanwani-nvo3-app-mcast-framework-00 suggests all IGMP messages are sent to= =E2=80=9Cmulticast server=E2=80=9D.


<= /div>That is not simpler - that adds a new component to the network. 

And if you IGMP to a server why is that different th= an registering to a map-server. 

But since the= re is no precise serial spec'ed on how the NVE-to-NVA protocol works no one c= an tell what can be leveraged for multicast. 

= LISP-signal-free-multicast works because the LISP mapping system protocols a= re well specified, implemented, and deployed. 

 Or =E2=80=9CMult= icast server=E2=80=9D can fake =E2=80=9CIGMP query=E2=80=9D to all the NVEs,= which forwarded down to applications. The reply (IGMP report) can be automa= tically sent back to =E2=80=9Cmulticast server=E2=80=9D without NVE doing an= ything extra.

 

What do you think?

=

You want multicast routers to attach to th= e overlay. They don't send IGMP packets to each other.  

=
IGMP is a host-to-router protocol and has been abused to be a hos= t-to-switch protocol. Let's stop the abuse.  :-)

Dino

=

 

 

Linda<= /span>

 

= --Apple-Mail-0C0492F4-2647-4DDA-A22E-3DFBB5C60685-- From nobody Sun Aug 31 18:30:23 2014 Return-Path: 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 DDAD01A90AD; Sun, 31 Aug 2014 18:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 U2exJ_r30GLA; Sun, 31 Aug 2014 18:30:13 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0075.outbound.protection.outlook.com [213.199.154.75]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 024D81A90A9; Sun, 31 Aug 2014 18:30:12 -0700 (PDT) Received: from DBXPR06MB399.eurprd06.prod.outlook.com (10.141.14.23) by DBXPR06MB397.eurprd06.prod.outlook.com (10.141.14.20) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Mon, 1 Sep 2014 01:30:10 +0000 Received: from DBXPR06MB399.eurprd06.prod.outlook.com ([10.141.14.23]) by DBXPR06MB399.eurprd06.prod.outlook.com ([10.141.14.23]) with mapi id 15.00.1015.018; Mon, 1 Sep 2014 01:30:10 +0000 From: Sharon Barkai To: Dino Farinacci Thread-Topic: [lisp] Questions on using LISP's signal free multicast for draft-ghanwani-nvo3-app-mcast-framework Thread-Index: Ac/EhQABYHv1vOWVT6W+msem4gUujQAtoyeAABIuFvc= Date: Mon, 1 Sep 2014 01:30:10 +0000 Message-ID: <08828D0D-CB6C-41FA-A149-AE61422FD246@Contextream.com> References: <4A95BA014132FF49AE685FAB4B9F17F645DDEAFB@dfweml701-chm>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2600:1010:b126:3af5:3cdd:8650:c332:6ded] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03218BFD9F x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(189002)(76104003)(199003)(377454003)(106356001)(46102001)(4396001)(90102001)(230783001)(2656002)(21056001)(82746002)(20776003)(101416001)(80022001)(33656002)(64706001)(105586002)(15975445006)(76482001)(50986999)(19617315012)(85306004)(19580405001)(110136001)(77982001)(92726001)(107046002)(36756003)(1411001)(92566001)(86362001)(83716003)(31966008)(87936001)(76176999)(54356999)(79102001)(81542001)(19580395003)(95666004)(83072002)(74502001)(19625215002)(85852003)(83322001)(16236675004)(99396002)(81342001)(104396001)(3826002)(80792004); DIR:OUT; SFP:; SCL:1; SRVR:DBXPR06MB397; H:DBXPR06MB399.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_08828D0DCB6C41FAA149AE61422FD246Contextreamcom_" MIME-Version: 1.0 X-OriginatorOrg: Contextream.com Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/M2bb8K32pxd4_CWOtr4had4zGq8 Cc: "nvo3@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] Questions on using LISP's signal free multicast for draft-ghanwani-nvo3-app-mcast-framework 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 01:30:16 -0000 --_000_08828D0DCB6C41FAA149AE61422FD246Contextreamcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We could do an OpenDaylight implementation of Signaling Free Mcast over the= OVS. Set the flow table to catch PIM and IGMP as packetIn from OVS to the = ODL controller. That would easily translate to mapping (NVA) API and wire t= he OVS to mcast tree using flows. OVS + ODL will form the NVE. There may be interest as people look for at least easy tap solution mapping= -flow that can be enhanced to support app-mcast. --szb On Aug 31, 2014, at 9:49 AM, "Dino Farinacci" > wrote: Dino, At Toronto NV03 session, you suggested that draft-ghanwani-nvo3-app-mcast-f= ramework can use LISP's signal free multicast scheme. After studying the draft-farinacci-lisp-signal-free-multicast-00, I agree t= hat the proposed scheme can definitely solve the problem of application ini= tiated multicast in environment where underlay network don't support any IP= multicast protocol. The design allows for either unicast or multicast RLOCs to be registered to= the mapping system. So LISP signal-free multicast can be used when the und= erlay supports multicast. But there are some issues of using the LISP's signal free multicast mechan= ism in Data Centers when NVEs, especially the server based hypervisor virtu= al switches, don't ( or can't) support the "General Receiver-site procedur= e" documented in the "draft-farinacci-list-signal-free-multicast-00". The = general Whatever the application is going to use to tell the network what multicast= groups are joined can be used as well. receiver-site procedure requires egress edge (i.e. egress NVE) to terminate= IGMP or PIM messages. But many NVEs (server based virtual switches) don't = terminate IGMP nor PIM. Well if the virtual switch supports LISP, then the app directly tells the x= TR which groups it is joining. And if the LISP xTR is one-hop northbound from the virtual switch, you can = bet the virtual switch does IGMP snooping. Therefore, NVO3 needs a simpler scheme for "Receiver NVEs". draft-ghanwa= ni-nvo3-app-mcast-framework-00 suggests all IGMP messages are sent to "mult= icast server". That is not simpler - that adds a new component to the network. And if you IGMP to a server why is that different than registering to a map= -server. But since there is no precise serial spec'ed on how the NVE-to-NVA protocol= works no one can tell what can be leveraged for multicast. LISP-signal-free-multicast works because the LISP mapping system protocols = are well specified, implemented, and deployed. Or "Multicast server" can fake "IGMP query" to all the NVEs, which forward= ed down to applications. The reply (IGMP report) can be automatically sent = back to "multicast server" without NVE doing anything extra. What do you think? You want multicast routers to attach to the overlay. They don't send IGMP p= ackets to each other. IGMP is a host-to-router protocol and has been abused to be a host-to-switc= h protocol. Let's stop the abuse. :-) Dino Linda _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --_000_08828D0DCB6C41FAA149AE61422FD246Contextreamcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
We could do an OpenDaylight implementation of Signaling Free Mcast ove= r the OVS. Set the flow table to catch PIM and IGMP as packetIn from OVS to= the ODL controller. That would easily translate to mapping (NVA) API and w= ire the OVS to mcast tree using flows. OVS + ODL will form the NVE. 

There may be interest as people look for at least easy tap solution ma= pping-flow that can be enhanced to support app-mcast.

--szb

On Aug 31, 2014, at 9:49 AM, "Dino Farinacci" <farinacci@gmail.com> wrote:

Din= o,

 

At Toronto NV03 session, you suggested that draft-gh= anwani-nvo3-app-mcast-framework can use LISP’s signal free multicast = scheme.

After studying the draft-farinacci-lisp-signal-free-multicast-00, I agree that the prop= osed scheme can definitely solve the problem of application initiated multi= cast in environment where underlay network don’t support any IP multi= cast protocol.


The design allows for either unicast or multicast RLOCs to be registered to= the mapping system. So LISP signal-free multicast can be used when the und= erlay supports multicast. 

 But there are= some issues of using the LISP’s signal free multicast mechanism in D= ata Centers when NVEs, especially the server based hypervisor virtual switches,  don’t ( or can’t) support t= he “General Receiver-site procedure” documented in the “d= raft-farinacci-list-signal-free-multicast-00”.  The general


Whatever the application is going to use to tell the network what multicast= groups are joined can be used as well. 

receiver-site procedure requir= es egress edge (i.e. egress NVE) to terminate IGMP or PIM messages. But man= y NVEs (server based virtual switches) don’t terminate IGMP nor PIM.


Well if the virtual switch supports LISP, then the app directly tells the x= TR which groups it is joining. 

And if the LISP xTR is one-hop northbound from the virtual switch, you= can bet the virtual switch does IGMP snooping. 

 Therefore, NV= O3 needs a simpler scheme for “Receiver NVEs”.   draf= t-ghanwani-nvo3-app-mcast-framework-00 suggests all IGMP messages are sent to “multicast server”.


That is not simpler - that adds a new component to the network. 

And if you IGMP to a server why is that different than registering to = a map-server. 

But since there is no precise serial spec'ed on how the NVE-to-NVA pro= tocol works no one can tell what can be leveraged for multicast. 

LISP-signal-free-multicast works because the LISP mapping system proto= cols are well specified, implemented, and deployed. 

 Or “Mul= ticast server” can fake “IGMP query” to all the NVEs, whi= ch forwarded down to applications. The reply (IGMP report) can be automatic= ally sent back to “multicast server” without NVE doing anything ext= ra.

 

What do you think?


You want multicast routers to attach to the overlay. They don't send IGMP p= ackets to each other.  

IGMP is a host-to-router protocol and has been abused to be a host-to-= switch protocol. Let's stop the abuse.  :-)

Dino

 

 

Linda=

 

_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ie= tf.org/mailman/listinfo/lisp
--_000_08828D0DCB6C41FAA149AE61422FD246Contextreamcom_-- From nobody Sun Aug 31 18:44:09 2014 Return-Path: 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 8640D1A90B5; Sun, 31 Aug 2014 18:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 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, J_CHICKENPOX_42=0.6, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=no 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 9qzY2-gw4MCq; Sun, 31 Aug 2014 18:44:03 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 291AA1A90B1; Sun, 31 Aug 2014 18:44:03 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id y13so4928661pdi.9 for ; Sun, 31 Aug 2014 18:44:02 -0700 (PDT) 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=UKJQ2Ffw9KujhrQWcPa/Zy651U4OsSS3aZMIHHw2mS8=; b=UyVA/GmdHGfwBAFGutm8LG5H5KokUAaow+9mAlkGNdkdLUWatAHaxWUJJ9mrTb5Ia8 qnGTdd2e7/OkHCy3te2+LCm9PJCFPL307Thu/k8wLOD9/cZcf4pbeqLqmSyVIp8+I2G+ aTDe5MIJ1VRE/YWnTjEdOzL/Aap4BDac/DlTSxs2DZvN5kAR7lljOLjr7rTttdmK33GZ 48EztCRPjwQxmFi+AwB0jF70Mol60ZJg9C96uLqmG2nrHLVpcPDCAHBkF4RKTMYf+0N3 tBrjvAPj9e4jRai6jHCxbaBLvAOPDKFX+HaA677G2XeD5Hk6QZF2DxyfuN5ElE42tDf6 GfjA== X-Received: by 10.68.247.137 with SMTP id ye9mr35361390pbc.69.1409535842753; Sun, 31 Aug 2014 18:44:02 -0700 (PDT) Received: from [10.221.158.193] ([166.170.38.63]) by mx.google.com with ESMTPSA id zr6sm6378276pbc.50.2014.08.31.18.43.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 31 Aug 2014 18:44:01 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-25E0FD02-3F31-4158-82F6-68D9D6587CFD Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (11D257) In-Reply-To: <08828D0D-CB6C-41FA-A149-AE61422FD246@Contextream.com> Date: Sun, 31 Aug 2014 18:43:57 -0700 Content-Transfer-Encoding: 7bit Message-Id: <8CEC58D5-EC9A-40E1-BF46-8BEA24AD46DF@gmail.com> References: <4A95BA014132FF49AE685FAB4B9F17F645DDEAFB@dfweml701-chm> <08828D0D-CB6C-41FA-A149-AE61422FD246@Contextream.com> To: Sharon Barkai Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/JlH5BjmAGeTit2ajYCTRVC2rY2w Cc: "nvo3@ietf.org" , "lisp@ietf.org" Subject: Re: [lisp] Questions on using LISP's signal free multicast for draft-ghanwani-nvo3-app-mcast-framework 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 01:44:04 -0000 --Apple-Mail-25E0FD02-3F31-4158-82F6-68D9D6587CFD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > We could do an OpenDaylight implementation of Signaling Free Mcast over th= e OVS. Set the flow table to catch PIM and IGMP as packetIn from OVS to the O= DL controller. That would easily translate to mapping (NVA) API and wire the= OVS to mcast tree using flows. OVS + ODL will form the NVE.=20 Sounds good. I have an implementation of lisp-signal-free-multicast if you w= ant to do interoperability testing with.=20 Dino > There may be interest as people look for at least easy tap solution mappin= g-flow that can be enhanced to support app-mcast. >=20 > --szb >=20 > On Aug 31, 2014, at 9:49 AM, "Dino Farinacci" wrote:= >=20 >> Dino, >>> =20 >>> At Toronto NV03 session, you suggested that draft-ghanwani-nvo3-app-mcas= t-framework can use LISP=E2=80=99s signal free multicast scheme. >>> After studying the draft-farinacci-lisp-signal-free-multicast-00, I agre= e that the proposed scheme can definitely solve the problem of application i= nitiated multicast in environment where underlay network don=E2=80=99t suppo= rt any IP multicast protocol. >>=20 >> The design allows for either unicast or multicast RLOCs to be registered t= o the mapping system. So LISP signal-free multicast can be used when the und= erlay supports multicast.=20 >>=20 >>> But there are some issues of using the LISP=E2=80=99s signal free multi= cast mechanism in Data Centers when NVEs, especially the server based hyperv= isor virtual switches, don=E2=80=99t ( or can=E2=80=99t) support the =E2=80= =9CGeneral Receiver-site procedure=E2=80=9D documented in the =E2=80=9Cdraft= -farinacci-list-signal-free-multicast-00=E2=80=9D. The general >>=20 >> Whatever the application is going to use to tell the network what multica= st groups are joined can be used as well.=20 >>=20 >>> receiver-site procedure requires egress edge (i.e. egress NVE) to termin= ate IGMP or PIM messages. But many NVEs (server based virtual switches) don=E2= =80=99t terminate IGMP nor PIM. >>=20 >> Well if the virtual switch supports LISP, then the app directly tells the= xTR which groups it is joining.=20 >>=20 >> And if the LISP xTR is one-hop northbound from the virtual switch, you ca= n bet the virtual switch does IGMP snooping.=20 >>=20 >>> Therefore, NVO3 needs a simpler scheme for =E2=80=9CReceiver NVEs=E2=80= =9D. draft-ghanwani-nvo3-app-mcast-framework-00 suggests all IGMP messages= are sent to =E2=80=9Cmulticast server=E2=80=9D. >>=20 >> That is not simpler - that adds a new component to the network.=20 >>=20 >> And if you IGMP to a server why is that different than registering to a m= ap-server.=20 >>=20 >> But since there is no precise serial spec'ed on how the NVE-to-NVA protoc= ol works no one can tell what can be leveraged for multicast.=20 >>=20 >> LISP-signal-free-multicast works because the LISP mapping system protocol= s are well specified, implemented, and deployed.=20 >>=20 >>> Or =E2=80=9CMulticast server=E2=80=9D can fake =E2=80=9CIGMP query=E2=80= =9D to all the NVEs, which forwarded down to applications. The reply (IGMP r= eport) can be automatically sent back to =E2=80=9Cmulticast server=E2=80=9D w= ithout NVE doing anything extra. >>> =20 >>> What do you think? >>=20 >> You want multicast routers to attach to the overlay. They don't send IGMP= packets to each other.=20 >>=20 >> IGMP is a host-to-router protocol and has been abused to be a host-to-swi= tch protocol. Let's stop the abuse. :-) >>=20 >> Dino >>=20 >>> =20 >>> =20 >>> Linda >>> =20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail-25E0FD02-3F31-4158-82F6-68D9D6587CFD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
We could do a= n OpenDaylight implementation of Signaling Free Mcast over the OVS. Set the f= low table to catch PIM and IGMP as packetIn from OVS to the ODL controller. T= hat would easily translate to mapping (NVA) API and wire the OVS to mcast tr= ee using flows. OVS + ODL will form the NVE. 

= Sounds good. I have an implementation of lisp-signal-free-multicast if you w= ant to do interoperability testing with. 

Dino

There may be interest as people look for at least easy tap solution map= ping-flow that can be enhanced to support app-mcast.

--szb

On Aug 31, 2014, at 9:49 AM, "Dino Farinacci" <farinacci@gmail.com> wrote:

Dino= ,

 

At Toronto NV03 session, you suggested that draft-gha= nwani-nvo3-app-mcast-framework can use LISP=E2=80=99s signal free multicast s= cheme.

After studying the draft-farinacci-lisp-signal-free-multicast-00, I agree that the propo= sed scheme can definitely solve the problem of application initiated multica= st in environment where underlay network don=E2=80=99t support any IP multic= ast protocol.


The design allows for either unicast or multicast RLOCs to be registered to t= he mapping system. So LISP signal-free multicast can be used when the underl= ay supports multicast. 

 But there are so= me issues of using the LISP=E2=80=99s signal free multicast mechanism in Dat= a Centers when NVEs, especially the server based hypervisor virtual switches,  don=E2=80=99t ( or can=E2=80=99t) suppor= t the =E2=80=9CGeneral Receiver-site procedure=E2=80=9D documented in the =E2= =80=9Cdraft-farinacci-list-signal-free-multicast-00=E2=80=9D.  The gene= ral


Whatever the application is going to use to tell the network what multicast g= roups are joined can be used as well. 

receiver-site procedure requires= egress edge (i.e. egress NVE) to terminate IGMP or PIM messages. But many N= VEs (server based virtual switches) don=E2=80=99t terminate IGMP nor PIM.


Well if the virtual switch supports LISP, then the app directly tells the xT= R which groups it is joining. 

And if the LISP xTR is one-hop northbound from the virtual switch, you c= an bet the virtual switch does IGMP snooping. 

 Therefore, NVO3 n= eeds a simpler scheme for =E2=80=9CReceiver NVEs=E2=80=9D.   draft= -ghanwani-nvo3-app-mcast-framework-00 suggests all IGMP messages are sent to =E2=80=9Cmulticast server=E2=80=9D.


That is not simpler - that adds a new component to the network. 

And if you IGMP to a server why is that different than registering to a= map-server. 

But since there is no precise serial spec'ed on how the NVE-to-NVA prot= ocol works no one can tell what can be leveraged for multicast. 

LISP-signal-free-multicast works because the LISP mapping system protoc= ols are well specified, implemented, and deployed. 

 Or =E2=80=9CMult= icast server=E2=80=9D can fake =E2=80=9CIGMP query=E2=80=9D to all the NVEs,= which forwarded down to applications. The reply (IGMP report) can be automa= tically sent back to =E2=80=9Cmulticast server=E2=80=9D without NVE doing anything e= xtra.

 

What do you think?

=

You want multicast routers to attach to the overlay. They don't send IGMP pa= ckets to each other.  

IGMP is a host-to-router protocol and has been abused to be a host-to-s= witch protocol. Let's stop the abuse.  :-)

Dino

 

 

Linda<= /span>

 

_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.iet= f.org/mailman/listinfo/lisp
= --Apple-Mail-25E0FD02-3F31-4158-82F6-68D9D6587CFD--