From rcallon@juniper.net Tue Jun 7 13:56:25 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103D711E81A8 for ; Tue, 7 Jun 2011 13:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDeioPwAaLqz for ; Tue, 7 Jun 2011 13:56:24 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id CE83C11E815D for ; Tue, 7 Jun 2011 13:56:17 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTe6QcbXxx768Mb8pXtz9K4LuVdFW07bT@postini.com; Tue, 07 Jun 2011 13:56:23 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 7 Jun 2011 13:55:42 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 7 Jun 2011 16:55:39 -0400 From: Ross Callon To: Dino Farinacci , Yakov Rekhter Date: Tue, 7 Jun 2011 16:55:39 -0400 Thread-Topic: Control Plane Load (was RE: [lisp] #27: ETR may claim a larger prefix than is delegated to it) Thread-Index: Acvvt7zovpEoKOOCQAeVv44AioVszA1miFyg Message-ID: References: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> <069.4b101056976476da12f5542a2fea551d@trac.tools.ietf.org> <979314C0-94B1-4C29-8F9B-91E8E27568BB@cisco.com> <201103311511.p2VFBFv39780@magenta.juniper.net> <1F7C6437-C8C0-4B15-AE30-2FF546E6F2A2@cisco.com> In-Reply-To: <1F7C6437-C8C0-4B15-AE30-2FF546E6F2A2@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: lisp issue tracker , "lisp@ietf.org" Subject: [lisp] Control Plane Load (was RE: #27: ETR may claim a larger prefix than is delegated to it) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2011 20:56:25 -0000 Dino recently said:=20 > In practice the implementation test mask-lengths and don't install =20 > coarse routes. Which caused me to wonder: Is there a fixed prefix length (such as perhaps = /24) which is the minimum prefix length that the implementation will instal= l? If you get a shorter prefix length than this, then what do you do? This is just one example (the one that happened to hit my mind today, I not= iced others in re-reading the LISP spec this past weekend) of something tha= t has been bothering me for a long time: We have no clue what the control p= lane load would actually be if LISP were widely deployed on a worldwide bas= is. I have seen a few papers which have tried to measure this, but all of t= he papers that I have seen (which I admit might not be all papers that exis= t) make an assumption such as:=20 The database is used to group=20 EID-to-RLOCs mappings with the granularity of existing BGP prefixes,=20 because, as for today, there is no sufficient information to predict=20 what will be the granularity of mappings in a LISP-enabled Internet. ** But it seems to be quite clear that the granularity of the EID-to-RLOC Data= base will be quite a bit finer than the current top-level Internet routing = table.=20 If we are serious about ever deploying LISP on a broad scale, then it would= seem to me that we should try to get a rough upper bound on the potential = cache thrashing and control plane load, rather than trying to measure optim= istic lower bounds on what this might be. To me this implies that any study= that is trying to measure the potential cache size, cache thrashing, or co= ntrol plane load should assume that the granularity of the EID-to-RLOC data= base may be host routes (since "host routes" is the only thing that we can = come up with that we can be moderately confident is a worst case scenario, = rather than an optimistic scenario).=20 Ross ** Note: This is a excerpt taken from "A Deep Dive into the LISP Cache" fro= m "Networking 2011", 9-13 May 2011 in Valencia, Spain (http://www.networkin= g2011.org/index.html). -----Original Message----- From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf Of Din= o Farinacci Sent: Thursday, March 31, 2011 11:24 AM To: Yakov Rekhter Cc: lisp issue tracker; lisp@ietf.org Subject: Re: [lisp] #27: ETR may claim a larger prefix than is delegated to= it > Dino, > >> We did in -11. Here is the text at the end of section 12. >> >> There is a potential security risk implicit in the fact that ETRs >> generate the EID prefix to which they are responding. In =20 >> theory, an >> ETR can claim a shorter prefix than it is actually responsible =20 >> for. >> Various mechanisms to ameliorate or resolve this issue will be >> examined in the future, [LISP-SEC]. > > The text should elaborate a bit on what is exactly the "potential > security risk", and specifically what are some of the implications > of that risk. "ETR can claim a shorter prefix than it is actually responsible for". > Also, replace "In theory" with "Thus" (as the ETR can do this not just > "in theory", but in practice as well). In practice the implementation test mask-lengths and don't install =20 coarse routes. Dino > > Yakov. > >> >> Dino >> >> On Mar 30, 2011, at 8:18 AM, lisp issue tracker wrote: >> >>> #27: ETR may claim a larger prefix than is delegated to it >>> >>> >>> Comment(by yakov@...): >>> >>> If the base LISP spec is not going to have additional mechanisms to >>> address over-claiming, then I would suggest to add to the base LISP >>> spec >>> some text that would just describe the issue of over-claiming, and >>> state >>> that handling this issue is outside the scope of the document. >>> >>> --=20 >>> ---------------------------------- >>> +----------------------------------------- >>> Reporter: hartmans-ietf@... | Owner: >>> Type: technical | Status: resolved >>> Priority: major | Component: draft-ietf-lisp >>> Severity: - | Resolution: fixed >>> Keywords: | >>> ---------------------------------- >>> +----------------------------------------- >>> >>> Ticket URL: >> :5 >>>> >>> lisp >>> LISP WG document issues >>> _______________________________________________ >>> 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 dino@cisco.com Tue Jun 7 15:16:00 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E109C11E8072 for ; Tue, 7 Jun 2011 15:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZ7964LJfkIH for ; Tue, 7 Jun 2011 15:15:59 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 326A411E80A8 for ; Tue, 7 Jun 2011 15:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=6380; q=dns/txt; s=iport; t=1307484957; x=1308694557; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=1FSHe5nVX1+A4huFRQ+FD6ptU1gCdqwhgoNbhl3DJiY=; b=igkdRzKw05tlegRZY9YH91k0XFjkhYc89syU6EZTjfe3o953WxjXGLz2 9KVEZRtn9XpMa813eJ/N8wZdBFcmTJKFxPWlt5A0ZjhoQ42nAnjKRRQl2 hltkoqOpgRknSbcOCkuPZd3CSwV35zBb+dkx/ZkgX5TkGFaf1Eg4zE29p w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwBAM6h7k2rRDoG/2dsb2JhbABTlzuOaXeIcaE1ng6GIQSGeIoShEyLGQ X-IronPort-AV: E=Sophos;i="4.65,334,1304294400"; d="scan'208";a="332206684" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2011 22:15:54 +0000 Received: from [192.168.1.2] (sjc-vpn7-1948.cisco.com [10.21.151.156]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p57MFr6m002911; Tue, 7 Jun 2011 22:15:53 GMT Message-Id: From: Dino Farinacci To: Ross Callon In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 7 Jun 2011 15:15:53 -0700 References: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> <069.4b101056976476da12f5542a2fea551d@trac.tools.ietf.org> <979314C0-94B1-4C29-8F9B-91E8E27568BB@cisco.com> <201103311511.p2VFBFv39780@magenta.juniper.net> <1F7C6437-C8C0-4B15-AE30-2FF546E6F2A2@cisco.com> X-Mailer: Apple Mail (2.936) Cc: "lisp@ietf.org" , lisp issue tracker Subject: Re: [lisp] Control Plane Load (was RE: #27: ETR may claim a larger prefix than is delegated to it) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2011 22:16:01 -0000 > Dino recently said: > >> In practice the implementation test mask-lengths and don't install >> coarse routes. > > Which caused me to wonder: Is there a fixed prefix length (such as > perhaps /24) which is the minimum prefix length that the > implementation will install? If you get a shorter prefix length than > this, then what do you do? Do not put the EID-prefix in the map-cache. > This is just one example (the one that happened to hit my mind > today, I noticed others in re-reading the LISP spec this past > weekend) of something that has been bothering me for a long time: We > have no clue what the control plane load would actually be if LISP > were widely deployed on a worldwide basis. I have seen a few papers > which have tried to measure this, but all of the papers that I have > seen (which I admit might not be all papers that exist) make an > assumption such as: How about if I venture to say the same as the DNS query load? How would that make you feel? > The database is used to group > EID-to-RLOCs mappings with the granularity of existing BGP prefixes, > because, as for today, there is no sufficient information to predict > what will be the granularity of mappings in a LISP-enabled > Internet. ** > > But it seems to be quite clear that the granularity of the EID-to- > RLOC Database will be quite a bit finer than the current top-level > Internet routing table. Could be, but what determines the granularity is the locator-set that you associate with a prefix. But note the EID-prefix is only stored where it is being used and not everywhere. So that is the tradeoff. If you are of the sort that doesn't care about packet stretch, then you could implement LISP like VA where must of the leafs would have a 0.0.0.0/0 map-cache entry (we are doing this with our LISP-MN experiments for NAT-traversal reasons). And then that level would have more specifics (maybe like 4 /4s and so on), like Paul Francis has presented on a number of occasions. Now please don't take this as a recommendation because I'm a fan of stretch equal to 1 in almost all cases. > If we are serious about ever deploying LISP on a broad scale, then > it would seem to me that we should try to Yes, we are serious. > get a rough upper bound on the potential cache thrashing and control > plane load, rather than trying to measure optimistic lower bounds on > what this might be. To me this implies that any study that is trying > to measure the That is why the drafts are experimental. We are gathering the data via the experiments. > potential cache size, cache thrashing, or control plane load should > assume that the granularity of the EID-to-RLOC database may be host > routes (since "host routes" is the only thing that we can come up > with that we can be moderately confident is a worst case scenario, > rather than an optimistic scenario). We see a lot of cache activity on the PITRs, even DOS attacks and in both a PC and router-based platforms, they seem to hold up but I agree we should get more data. The mapping database system only has host routes when /32s map to a locator-set. This can happen in a variety of use-cases. But the /32s are not sent around the ALT, they are kept local to the registering Map-Server. Think of the Map-Server as a "control-plane home agent". Dino > > Ross > > ** Note: This is a excerpt taken from "A Deep Dive into the LISP > Cache" from "Networking 2011", 9-13 May 2011 in Valencia, Spain (http://www.networking2011.org/index.html > ). > > -----Original Message----- > From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf > Of Dino Farinacci > Sent: Thursday, March 31, 2011 11:24 AM > To: Yakov Rekhter > Cc: lisp issue tracker; lisp@ietf.org > Subject: Re: [lisp] #27: ETR may claim a larger prefix than is > delegated to it > >> Dino, >> >>> We did in -11. Here is the text at the end of section 12. >>> >>> There is a potential security risk implicit in the fact that ETRs >>> generate the EID prefix to which they are responding. In >>> theory, an >>> ETR can claim a shorter prefix than it is actually responsible >>> for. >>> Various mechanisms to ameliorate or resolve this issue will be >>> examined in the future, [LISP-SEC]. >> >> The text should elaborate a bit on what is exactly the "potential >> security risk", and specifically what are some of the implications >> of that risk. > > "ETR can claim a shorter prefix than it is actually responsible for". > >> Also, replace "In theory" with "Thus" (as the ETR can do this not >> just >> "in theory", but in practice as well). > > In practice the implementation test mask-lengths and don't install > coarse routes. > > Dino > >> >> Yakov. >> >>> >>> Dino >>> >>> On Mar 30, 2011, at 8:18 AM, lisp issue tracker wrote: >>> >>>> #27: ETR may claim a larger prefix than is delegated to it >>>> >>>> >>>> Comment(by yakov@...): >>>> >>>> If the base LISP spec is not going to have additional mechanisms to >>>> address over-claiming, then I would suggest to add to the base LISP >>>> spec >>>> some text that would just describe the issue of over-claiming, and >>>> state >>>> that handling this issue is outside the scope of the document. >>>> >>>> -- >>>> ---------------------------------- >>>> +----------------------------------------- >>>> Reporter: hartmans-ietf@... | Owner: >>>> Type: technical | Status: resolved >>>> Priority: major | Component: draft-ietf-lisp >>>> Severity: - | Resolution: fixed >>>> Keywords: | >>>> ---------------------------------- >>>> +----------------------------------------- >>>> >>>> Ticket URL: >>> :5 >>>>> >>>> lisp >>>> LISP WG document issues >>>> _______________________________________________ >>>> 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 luigi@net.t-labs.tu-berlin.de Wed Jun 8 01:40:28 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B751621F846F for ; Wed, 8 Jun 2011 01:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UufiSHACiWJ for ; Wed, 8 Jun 2011 01:40:27 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:470:96b9:4:130:149:220:252]) by ietfa.amsl.com (Postfix) with ESMTP id 7746321F846E for ; Wed, 8 Jun 2011 01:40:26 -0700 (PDT) Received: from dyn119.net.t-labs.tu-berlin.de (dyn119.net.t-labs.tu-berlin.de [130.149.220.119]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id CBEEE70B903A; Wed, 8 Jun 2011 10:40:24 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luigi Iannone In-Reply-To: Date: Wed, 8 Jun 2011 10:40:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> <069.4b101056976476da12f5542a2fea551d@trac.tools.ietf.org> <979314C0-94B1-4C29-8F9B-91E8E27568BB@cisco.com> <201103311511.p2VFBFv39780@magenta.juniper.net> <1F7C6437-C8C0-4B15-AE30-2FF546E6F2A2@cisco.com> To: Ross Callon X-Mailer: Apple Mail (2.1084) Cc: "lisp@ietf.org" , lisp issue tracker Subject: Re: [lisp] Control Plane Load (was RE: #27: ETR may claim a larger prefix than is delegated to it) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2011 08:40:28 -0000 Hi Ross, On Jun 7, 2011, at 22:55 , Ross Callon wrote: >=20 > The database is used to group=20 > EID-to-RLOCs mappings with the granularity of existing BGP = prefixes,=20 > because, as for today, there is no sufficient information to = predict=20 > what will be the granularity of mappings in a LISP-enabled = Internet. ** >=20 As we state in that paper we do not have sufficient information to = venture a different granularity. IMHO, the assumption we made is a valid = starting point and we do not claim this is the future. LISP introduces = new ways to perform TE and the way these features will be used is = difficult to predict.=20 If you have any idea for a different set of measurement/evaluation let's = have a chat offline, may be I can help in evaluate different evolution = assumptions/ideas. =20 Luigi p.s. thanks for reading our paper=20 > But it seems to be quite clear that the granularity of the EID-to-RLOC = Database will be quite a bit finer than the current top-level Internet = routing table.=20 >=20 > If we are serious about ever deploying LISP on a broad scale, then it = would seem to me that we should try to get a rough upper bound on the = potential cache thrashing and control plane load, rather than trying to = measure optimistic lower bounds on what this might be. To me this = implies that any study that is trying to measure the potential cache = size, cache thrashing, or control plane load should assume that the = granularity of the EID-to-RLOC database may be host routes (since "host = routes" is the only thing that we can come up with that we can be = moderately confident is a worst case scenario, rather than an optimistic = scenario).=20 >=20 > Ross >=20 > ** Note: This is a excerpt taken from "A Deep Dive into the LISP = Cache" from "Networking 2011", 9-13 May 2011 in Valencia, Spain = (http://www.networking2011.org/index.html). >=20 > -----Original Message----- > From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf = Of Dino Farinacci > Sent: Thursday, March 31, 2011 11:24 AM > To: Yakov Rekhter > Cc: lisp issue tracker; lisp@ietf.org > Subject: Re: [lisp] #27: ETR may claim a larger prefix than is = delegated to it >=20 >> Dino, >>=20 >>> We did in -11. Here is the text at the end of section 12. >>>=20 >>> There is a potential security risk implicit in the fact that ETRs >>> generate the EID prefix to which they are responding. In =20 >>> theory, an >>> ETR can claim a shorter prefix than it is actually responsible =20 >>> for. >>> Various mechanisms to ameliorate or resolve this issue will be >>> examined in the future, [LISP-SEC]. >>=20 >> The text should elaborate a bit on what is exactly the "potential >> security risk", and specifically what are some of the implications >> of that risk. >=20 > "ETR can claim a shorter prefix than it is actually responsible for". >=20 >> Also, replace "In theory" with "Thus" (as the ETR can do this not = just >> "in theory", but in practice as well). >=20 > In practice the implementation test mask-lengths and don't install =20 > coarse routes. >=20 > Dino >=20 >>=20 >> Yakov. >>=20 >>>=20 >>> Dino >>>=20 >>> On Mar 30, 2011, at 8:18 AM, lisp issue tracker wrote: >>>=20 >>>> #27: ETR may claim a larger prefix than is delegated to it >>>>=20 >>>>=20 >>>> Comment(by yakov@...): >>>>=20 >>>> If the base LISP spec is not going to have additional mechanisms to >>>> address over-claiming, then I would suggest to add to the base LISP >>>> spec >>>> some text that would just describe the issue of over-claiming, and >>>> state >>>> that handling this issue is outside the scope of the document. >>>>=20 >>>> --=20 >>>> ---------------------------------- >>>> +----------------------------------------- >>>> Reporter: hartmans-ietf@... | Owner: >>>> Type: technical | Status: resolved >>>> Priority: major | Component: draft-ietf-lisp >>>> Severity: - | Resolution: fixed >>>> Keywords: | >>>> ---------------------------------- >>>> +----------------------------------------- >>>>=20 >>>> Ticket URL: = >>> :5 >>>>>=20 >>>> lisp >>>> LISP WG document issues >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >>>=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 luigi@net.t-labs.tu-berlin.de Wed Jun 8 01:49:12 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F5911E8122 for ; Wed, 8 Jun 2011 01:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixYGXibz56uz for ; Wed, 8 Jun 2011 01:49:12 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:470:96b9:4:130:149:220:252]) by ietfa.amsl.com (Postfix) with ESMTP id 264F011E809C for ; Wed, 8 Jun 2011 01:49:12 -0700 (PDT) Received: from dyn119.net.t-labs.tu-berlin.de (dyn119.net.t-labs.tu-berlin.de [130.149.220.119]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id B63B470B903A; Wed, 8 Jun 2011 10:49:10 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luigi Iannone In-Reply-To: Date: Wed, 8 Jun 2011 10:49:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5D2CC2A9-0AB6-43A6-AF99-35F125F10A57@net.t-labs.tu-berlin.de> References: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> <069.4b101056976476da12f5542a2fea551d@trac.tools.ietf.org> <979314C0-94B1-4C29-8F9B-91E8E27568BB@cisco.com> <201103311511.p2VFBFv39780@magenta.juniper.net> <1F7C6437-C8C0-4B15-AE30-2FF546E6F2A2@cisco.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1084) Cc: lisp issue tracker , "lisp@ietf.org" Subject: Re: [lisp] Control Plane Load (was RE: #27: ETR may claim a larger prefix than is delegated to it) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2011 08:49:13 -0000 On Jun 8, 2011, at 00:15 , Dino Farinacci wrote: >> Dino recently said: >>=20 >>> In practice the implementation test mask-lengths and don't install >>> coarse routes. >>=20 >> Which caused me to wonder: Is there a fixed prefix length (such as = perhaps /24) which is the minimum prefix length that the implementation = will install? If you get a shorter prefix length than this, then what do = you do? >=20 > Do not put the EID-prefix in the map-cache. >=20 >> This is just one example (the one that happened to hit my mind today, = I noticed others in re-reading the LISP spec this past weekend) of = something that has been bothering me for a long time: We have no clue = what the control plane load would actually be if LISP were widely = deployed on a worldwide basis. I have seen a few papers which have tried = to measure this, but all of the papers that I have seen (which I admit = might not be all papers that exist) make an assumption such as: >=20 > How about if I venture to say the same as the DNS query load? How = would that make you feel? >=20 In the paper "On the cost of caching locator/ID mapping" = (http://portal.acm.org/citation.cfm?id=3D1364663) there is a direct = comparison with the DNS traffic, showing that DNS queries and = Map-Request have similar dynamics, with the latter generating less = traffic. There are two things to consider: a) that study still assumes = BGP granularity; b) measurements are done from a single vantage point = (but using a different dataset would not change the general behavior = that much IMO). Luigi From rcallon@juniper.net Wed Jun 8 09:06:32 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A967F11E8174 for ; Wed, 8 Jun 2011 09:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vy5+ak-33CKm for ; Wed, 8 Jun 2011 09:06:32 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id BA84211E80E9 for ; Wed, 8 Jun 2011 09:06:25 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTe+eABWyOWXlQajrkXHRHJ808lZ2b9O8@postini.com; Wed, 08 Jun 2011 09:06:31 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 8 Jun 2011 09:05:20 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 8 Jun 2011 12:05:20 -0400 From: Ross Callon To: Luigi Iannone Date: Wed, 8 Jun 2011 12:05:19 -0400 Thread-Topic: [lisp] Control Plane Load (was RE: #27: ETR may claim a larger prefix than is delegated to it) Thread-Index: Acwlt7i+VEqiWh0cQm6f7nQsiK9CCgAO6Sww Message-ID: References: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> <069.4b101056976476da12f5542a2fea551d@trac.tools.ietf.org> <979314C0-94B1-4C29-8F9B-91E8E27568BB@cisco.com> <201103311511.p2VFBFv39780@magenta.juniper.net> <1F7C6437-C8C0-4B15-AE30-2FF546E6F2A2@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" , lisp issue tracker Subject: Re: [lisp] Control Plane Load (was RE: #27: ETR may claim a larger prefix than is delegated to it) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2011 16:06:32 -0000 > Hi Ross, >=20 > On Jun 7, 2011, at 22:55 , Ross Callon wrote: >>=20 >> The database is used to group=20 >> EID-to-RLOCs mappings with the granularity of existing BGP prefixes,=20 >> because, as for today, there is no sufficient information to predict=20 >> what will be the granularity of mappings in a LISP-enabled Internet. ** >=20 > As we state in that paper we do not have sufficient information to ventur= e a different > granularity. IMHO, the assumption we made is a valid starting point and w= e do not claim > this is the future. LISP introduces new ways to perform TE and the way th= ese features > will be used is difficult to predict.=20 The paper does indeed clearly state that we don't currently have sufficient= information to=20 know what the granularity will be.=20 > If you have any idea for a different set of measurement/evaluation let's = have a chat > offline, may be I can help in evaluate different evolution assumptions/id= eas. =20 > > Luigi Okay, will do.=20 Thanks, Ross From rcallon@juniper.net Wed Jun 8 09:16:49 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F611F0C44 for ; Wed, 8 Jun 2011 09:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.239 X-Spam-Level: X-Spam-Status: No, score=-106.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-lV+6lTQHYs for ; Wed, 8 Jun 2011 09:16:47 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB621F0C38 for ; Wed, 8 Jun 2011 09:16:43 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTe+gajXz0L6Lu9X5Esi4IHqREO/JgFnT@postini.com; Wed, 08 Jun 2011 09:16:47 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 8 Jun 2011 09:14:19 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 8 Jun 2011 12:14:18 -0400 From: Ross Callon To: Dino Farinacci Date: Wed, 8 Jun 2011 12:14:17 -0400 Thread-Topic: Control Plane Load (was RE: [lisp] #27: ETR may claim a larger prefix than is delegated to it) Thread-Index: AcwlYHnlUcRqznvqROWZGo1AoDOrRQAlfXMQ Message-ID: References: <060.ac703c54e9577175255bc2d3a9ba9079@trac.tools.ietf.org> <069.4b101056976476da12f5542a2fea551d@trac.tools.ietf.org> <979314C0-94B1-4C29-8F9B-91E8E27568BB@cisco.com> <201103311511.p2VFBFv39780@magenta.juniper.net> <1F7C6437-C8C0-4B15-AE30-2FF546E6F2A2@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: lisp issue tracker , "lisp@ietf.org" Subject: Re: [lisp] Control Plane Load (was RE: #27: ETR may claim a larger prefix than is delegated to it) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jun 2011 16:16:49 -0000 >> This is just one example (the one that happened to hit my mind =20 >> today, I noticed others in re-reading the LISP spec this past =20 >> weekend) of something that has been bothering me for a long time: We =20 >> have no clue what the control plane load would actually be if LISP =20 >> were widely deployed on a worldwide basis. I have seen a few papers =20 >> which have tried to measure this, but all of the papers that I have =20 >> seen (which I admit might not be all papers that exist) make an =20 >> assumption such as: > > How about if I venture to say the same as the DNS query load? How =20 > would that make you feel? For a host, it would not worry me at all. If it had to be handled by the co= ntrol plane of a PE router with a terabit data plane, it would scare me.=20 >... >> If we are serious about ever deploying LISP on a broad scale, then =20 >> it would seem to me that we should try to > > Yes, we are serious. that was my impression... >> get a rough upper bound on the potential cache thrashing and control =20 >> plane load, rather than trying to measure optimistic lower bounds on =20 >> what this might be. To me this implies that any study that is trying =20 >> to measure the... > > That is why the drafts are experimental. We are gathering the data via =20 > the experiments. The issue that concerns me relates to scaling. I have no doubt that this wo= uld work between 1,000 sites. Between 1,000,000,000 sites I have concerns.= =20 It seems fine to me to start with experiments, as long as we are clear that= these are experiments and that we don't (currently) have any complete plan= for LISP deployment that we agree will scale to cover the full Internet. >> ...potential cache size, cache thrashing, or control plane load should = =20 >> assume that the granularity of the EID-to-RLOC database may be host =20 >> routes (since "host routes" is the only thing that we can come up =20 >> with that we can be moderately confident is a worst case scenario, =20 >> rather than an optimistic scenario). > > We see a lot of cache activity on the PITRs, even DOS attacks and in =20 > both a PC and router-based platforms, they seem to hold up but I agree =20 > we should get more data. > > The mapping database system only has host routes when /32s map to a =20 > locator-set. This can happen in a variety of use-cases. But the /32s =20 > are not sent around the ALT, they are kept local to the registering =20 > Map-Server. My point was not that I actually expect the EID-to-RLOC Database to be prim= arily made up of /32's. My point is that this would give us an approximate = worse case measure of the potential cache thrashing and control plane load = (or at least some aspects thereof). This seems safer than having only an op= timistic "much better than we expect to be realistic" measurement. Of cours= e if the "better than best case" estimate says that we are fine, and the "= worse than worst case" estimate says that we are in trouble, then more thou= ght and/or experiments would be needed to figure out which is more accurate= .=20 Ross -----Original Message----- From: Dino Farinacci [mailto:dino@cisco.com]=20 Sent: Tuesday, June 07, 2011 6:16 PM To: Ross Callon Cc: Yakov Rekhter; lisp issue tracker; lisp@ietf.org Subject: Re: Control Plane Load (was RE: [lisp] #27: ETR may claim a larger= prefix than is delegated to it) > Dino recently said: > >> In practice the implementation test mask-lengths and don't install >> coarse routes. > > Which caused me to wonder: Is there a fixed prefix length (such as =20 > perhaps /24) which is the minimum prefix length that the =20 > implementation will install? If you get a shorter prefix length than =20 > this, then what do you do? Do not put the EID-prefix in the map-cache. > This is just one example (the one that happened to hit my mind =20 > today, I noticed others in re-reading the LISP spec this past =20 > weekend) of something that has been bothering me for a long time: We =20 > have no clue what the control plane load would actually be if LISP =20 > were widely deployed on a worldwide basis. I have seen a few papers =20 > which have tried to measure this, but all of the papers that I have =20 > seen (which I admit might not be all papers that exist) make an =20 > assumption such as: How about if I venture to say the same as the DNS query load? How =20 would that make you feel? > The database is used to group > EID-to-RLOCs mappings with the granularity of existing BGP prefixes, > because, as for today, there is no sufficient information to predict > what will be the granularity of mappings in a LISP-enabled =20 > Internet. ** > > But it seems to be quite clear that the granularity of the EID-to-=20 > RLOC Database will be quite a bit finer than the current top-level =20 > Internet routing table. Could be, but what determines the granularity is the locator-set that =20 you associate with a prefix. But note the EID-prefix is only stored =20 where it is being used and not everywhere. So that is the tradeoff. If you are of the sort that doesn't care about packet stretch, then =20 you could implement LISP like VA where must of the leafs would have a =20 0.0.0.0/0 map-cache entry (we are doing this with our LISP-MN =20 experiments for NAT-traversal reasons). And then that level would have =20 more specifics (maybe like 4 /4s and so on), like Paul Francis has =20 presented on a number of occasions. Now please don't take this as a recommendation because I'm a fan of =20 stretch equal to 1 in almost all cases. > If we are serious about ever deploying LISP on a broad scale, then =20 > it would seem to me that we should try to Yes, we are serious. > get a rough upper bound on the potential cache thrashing and control =20 > plane load, rather than trying to measure optimistic lower bounds on =20 > what this might be. To me this implies that any study that is trying =20 > to measure the That is why the drafts are experimental. We are gathering the data via =20 the experiments. > potential cache size, cache thrashing, or control plane load should =20 > assume that the granularity of the EID-to-RLOC database may be host =20 > routes (since "host routes" is the only thing that we can come up =20 > with that we can be moderately confident is a worst case scenario, =20 > rather than an optimistic scenario). We see a lot of cache activity on the PITRs, even DOS attacks and in =20 both a PC and router-based platforms, they seem to hold up but I agree =20 we should get more data. The mapping database system only has host routes when /32s map to a =20 locator-set. This can happen in a variety of use-cases. But the /32s =20 are not sent around the ALT, they are kept local to the registering =20 Map-Server. Think of the Map-Server as a "control-plane home agent". Dino > > Ross > > ** Note: This is a excerpt taken from "A Deep Dive into the LISP =20 > Cache" from "Networking 2011", 9-13 May 2011 in Valencia, Spain (http://w= ww.networking2011.org/index.html=20 > ). > > -----Original Message----- > From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf =20 > Of Dino Farinacci > Sent: Thursday, March 31, 2011 11:24 AM > To: Yakov Rekhter > Cc: lisp issue tracker; lisp@ietf.org > Subject: Re: [lisp] #27: ETR may claim a larger prefix than is =20 > delegated to it > >> Dino, >> >>> We did in -11. Here is the text at the end of section 12. >>> >>> There is a potential security risk implicit in the fact that ETRs >>> generate the EID prefix to which they are responding. In >>> theory, an >>> ETR can claim a shorter prefix than it is actually responsible >>> for. >>> Various mechanisms to ameliorate or resolve this issue will be >>> examined in the future, [LISP-SEC]. >> >> The text should elaborate a bit on what is exactly the "potential >> security risk", and specifically what are some of the implications >> of that risk. > > "ETR can claim a shorter prefix than it is actually responsible for". > >> Also, replace "In theory" with "Thus" (as the ETR can do this not =20 >> just >> "in theory", but in practice as well). > > In practice the implementation test mask-lengths and don't install > coarse routes. > > Dino > >> >> Yakov. >> >>> >>> Dino >>> >>> On Mar 30, 2011, at 8:18 AM, lisp issue tracker wrote: >>> >>>> #27: ETR may claim a larger prefix than is delegated to it >>>> >>>> >>>> Comment(by yakov@...): >>>> >>>> If the base LISP spec is not going to have additional mechanisms to >>>> address over-claiming, then I would suggest to add to the base LISP >>>> spec >>>> some text that would just describe the issue of over-claiming, and >>>> state >>>> that handling this issue is outside the scope of the document. >>>> >>>> --=20 >>>> ---------------------------------- >>>> +----------------------------------------- >>>> Reporter: hartmans-ietf@... | Owner: >>>> Type: technical | Status: resolved >>>> Priority: major | Component: draft-ietf-lisp >>>> Severity: - | Resolution: fixed >>>> Keywords: | >>>> ---------------------------------- >>>> +----------------------------------------- >>>> >>>> Ticket URL: >>> :5 >>>>> >>>> lisp >>>> LISP WG document issues >>>> _______________________________________________ >>>> 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 dino@cisco.com Mon Jun 13 00:09:29 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1914511E8097 for ; Mon, 13 Jun 2011 00:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqLDnf4Avwgw for ; Mon, 13 Jun 2011 00:09:28 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 16DDE22800B for ; Mon, 13 Jun 2011 00:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=9792; q=dns/txt; s=iport; t=1307948968; x=1309158568; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=cHunLUydmFCfFvhWNYsourpO2WbKUDD4JJWuyRJWED0=; b=eZuZuXc9+XJ0xS6y3K/dqkWMHIT7wZjUp0/+tdNfKIdxDWCs2mqMmSy5 453eXNbFw8hzQ5hpwAY11KUY6DUH3RdEcbd+R7MZrPZnZ361DnO0xRYte rNLbUOb8IAouJCtlhuUFsrxfMaQhPX4CNlZCfI1W1qVHeMbzNMS/NsJyN s=; X-IronPort-AV: E=Sophos;i="4.65,356,1304294400"; d="scan'208";a="335617808" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 13 Jun 2011 07:09:27 +0000 Received: from [192.168.1.4] ([10.21.75.248]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5D79QhR024943; Mon, 13 Jun 2011 07:09:26 GMT Message-Id: <96A53C26-D89A-4606-97F1-209D40ACDD82@cisco.com> From: Dino Farinacci To: Dino Farinacci In-Reply-To: <4099FE40-80F6-4E32-848C-C33990DB1343@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 13 Jun 2011 00:09:26 -0700 References: <4099FE40-80F6-4E32-848C-C33990DB1343@cisco.com> X-Mailer: Apple Mail (2.936) Cc: David Meyer , Stig Venaas , Jesus Arango , lisp@ietf.org Subject: Re: [lisp] Proposed changes for draft-ietf-lisp-multicast-06.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2011 07:09:29 -0000 I would like to ask the chairs, as well as Alia and Jesus if I can post this update. This email was posted 2 weeks ago and no replies were received. Dino On May 30, 2011, at 8:50 PM, Dino Farinacci wrote: > We have received WG last call comments on the LISP-multicast draft > from Jesus Arango and Alia Atlas. See enclosed our responses and a > proposed updated draft and html diff file. > > Jesus comments: > >> 1. Cross-talk duplication of multicast flows when using multiple >> RLOCS: >> Consider two receiver sites A and B with the following mappings: >> >> Site A: >> (S1, G) --> (RLOC1, G) >> (S2, G) --> (RLOC2, G) >> Site B: >> (S1, G) --> (RLOC2, G) >> >> This would cause Site A to receive duplicate packets for (S1,G). >> One copy >> would be encapsulated with source RLOC1 while the second copy will be > > All sites are suppose to hash to the same RLOC for a given (S- > EID,G). So Site B would use (RLOC1,G) as would Site A. > >> encapsulated with source RLOC2. There are multiple ways to address >> this >> issue: >> >> a. Perform neighbor verification as part of RPF check. This seemed >> obvious >> but it is worth noting that to my understanding this is not done in >> IOS. Can >> folks comment on why this is not done today? What is the viability >> of doing >> this? What is the current behavior in non-IOS platforms ? >> b. Use a single RLOC for multicast >> c. Anycast RLOC >> d. Propose a group-to-RLOC hashing mechanism where the hashing >> function >> dynamically adapts to addition/deletion of RLOCS while minimizing >> the impact >> on flows that are already stablished. > > What will happen is that if (S1,G) and (S2,G) map to core > distribution tree (RLOC2,G) then Site B will get packets for no > receivers. I have added a paragraph to section 8.1.2 to make this > clear. > > Alia comments: > >> What I most want to see in this draft is a clear description of what >> needs to implemented and how. It gives a good survey of the >> architectural possibilities and even makes suggestions at the end - >> but not quite sufficient to be clear in the details of what needs to >> be implemented for interoperability and what is for future >> experimentation. > > Everything in the spec needs to be implemented. Why would you think > differently? > >> a) Could you add a definition for uPITR? It is first used on p.9 in >> the mPETR definition and only on p. 22 is it described as >> "(where in unicast it acts as a "Proxy ITR", or an uPITR)" > > I do not want to duplicate the definition from the Interworking > spec. I will add a reference though. > >> b) Sec 4, second paragraph: "At this point in time, we don't see a >> requirement for different locator-sets, priority, and weight policies >> for multicast than we have for unicast." but there is an M Priority >> and M Weight in the [LISP] draft. Clarification as to why would be >> useful... (I know it is to get the RLOCs of the ITRs which shouldn't >> be used for unicast traffic.) > > I added a sentence. > >> I don't see a mechanism other than the M Priority to obtain the RLOCs >> associated with an ITR - since only ETR RLOCs would normally be >> included. > > I don't understand the comment. There is one locator-set, and the > RLOCs for encapsulating unicast packets to and the RLOCs for sending > multicast join messages to can be a different set within the locator- > set. > >> What would be good to add to the draft is the changes to be made to >> information such as the Map-Reply messages. E.g. >> Set the M Priority for all ETR RLOCs to be 255 >> Add the ITR RLOCs and set the Priority to 255 & the M Priority to >> something else. > > They are the same locators. The xTR has one locator-set, the RLOCs > are used as a destination for unicast packets or for a destination > for multicast joins. > >> c) What happens if the S-EID and S-RLOC collide? In particular, at > > You have to be more specific on what you mean here. > >> the ETR and ITR, it seems useful to specify that the xTR has >> knowledge >> of whether the packet was LISP-encapsulated & forwards it either to >> receivers that expect it un-LISP-encapsulated (ETR) or to receivers >> that expect it LISP-encapsulated (ITR). > > An EID and RLOC can have the same value just like in the unicast > scenario. > >> d) p. 15 end of MSDP: >> "And the choice can be made unilaterally because the ITR at the >> site will determine which namespace the destination peer address is >> out of by looking in the mapping database service." >> >> Is there an assumption in LISP that an EID and an RLOC MUST NOT have >> the same value?? I've seen this potentially implied, but not >> proscriptively stated. > > There is not architectural. > >> e) p. 22 first paragraph: >> "So the ETR knows to simply propagate the PIM Join/Prune message to >> a external-facing interface without converting the (S-EID,G) because >> it is an (S,G) where S is routable and reachable via core routing >> tables." >> >> In [INTWRK], it is clear that an EID may be globally routable. This >> creates a conflict here, where there is an assumption that if an IP >> address is globally routable, then it is not in the EID/RLOC mapping >> database. > > The text says: > > In this case, S-EID is not in the > > Farinacci, et al. Expires December 1, 2011 [Page > 21] > Internet-Draft LISP for Multicast Environments May > 2011 > > > mapping database because the source multicast site is using a > routable address and not an EID prefix address. So the ETR knows to > simply propagate the PIM Join/Prune message to a external-facing > interface without converting the (S-EID,G) because it is an (S,G) > where S is routable and reachable via core routing tables. > > So the ETR knows because "there is no mapping database entry and the > S-EID is routable". > >> Couldn't a more specific check be done along the lines of: >> if the S-EID is reachable via core routing and >> i) it is not in the mapping database or >> ii) it is in the mapping database, but there are no RLOCs with >> an M Priority other than 255? >> >> f) Text in 9.1.1, 9.1.2 doesn't match the headings well. For >> instance, in 9.1.1, there is discussion of how a LISP source site >> that >> sends to non-LISP or uLISP receiver sites also can send to LISP >> receiver sites. > > They actually are correct, but the first start out saying how the > trees are built from the receiver side so that text can support the > data-flow description that comes later. > >> In 9.1.2, maybe renaming it to non-mLISP Receiver Sites would be >> clearer? > > We stated up from the definition of a non-LISP receiver site. > Creating a new term would add to the number of combinations. The > spec doesn't need that extra complexity. > >> g) In 9.1.4, Mpriority and Mweight are finally mentioned - but as far >> as I can tell, they are needed earlier and for the pure mLISP to >> mLISP >> case. Please pull the discussion of this earlier. > > Can you be more specific please. > >> Also, this case is discussed in 9.1.1 last paragraph on p. 21 - but >> claimed that it is sufficient to look in the mapping database. Could >> you please combine these and bring more consistency to the draft? > > Combine what? Please be more specific. > >> h) In 9.1.5, is it possible to make a recommendation (e.g. an ITR >> SHOULD be able to send two packets based on what its oif-lists are? > > No, we want to leave it up to the implementation. > >> Isn't this already the case because the mLISP ITR could have >> internal-facing entries in the (S-EID,G) that need to be replicated >> without encapsulation and external-facing entries in the (S-RLOC, G) >> that need encapsulation? > > Yes, but those forwarding rules are up to the multicast routing > protocol run in the site. That is, if your comment is to document > this. > >> I understand that this isn't ideal because multiple copies of data >> are >> going into the core - but the trees are different there too. > > Which trees are different? > >> What I'm looking for is some normative text about what MUST/SHOULD be >> supported - even for experimental interoperability. > > If there are mPETRs deployed an ITR can use option 2. If not, option > 1 is the only option. > >> The second option seems like it comes naturally - if a Join comes for >> the (S-RLOC, G), then it is sent the encapsulated packet. > > Right, if joins come from the mPETRs. > >> g) p. 21 Sec 9.1.1 end of second paragraph: >> "It is important to note that the routable address for the host >> cannot >> be the same as an RLOC for the site. Because we want the ITRs to >> process a received PIM Join/Prune message from an external-facing >> interface to be propagated inside of the site so the site-part of >> the >> distribution tree is built." >> Is this supposed to be one sentence?? > > I fixed it up a bit. Thanks. > >> h) typo: p. 9 mPETR definition, last sentence: "co-loacted" -> co- >> located >> >> i) typo: p. 23 4th line from bottom: "oins to" -> joins to >> >> j) typo: p.27 first sentence: "MUST not" -> MUST NOT >> >> k) typo: Sec 11 last sentence: "addition to slow" -> "addition due >> to slow" >> >> l) [LISP] needs to be Normative - it has the packet formats! > > Fixed all these. Thanks. > > Thanks, > Dino/Dave/Stig/JohnZ > > ietf-lisp-multicast-06.txt> From terry.manderson@icann.org Mon Jun 13 02:28:08 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F7111E808E for ; Mon, 13 Jun 2011 02:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjffE4-Euq0F for ; Mon, 13 Jun 2011 02:28:07 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 0414011E808A for ; Mon, 13 Jun 2011 02:28:07 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 13 Jun 2011 02:28:06 -0700 From: Terry Manderson To: Dino Farinacci Date: Mon, 13 Jun 2011 02:29:06 -0700 Thread-Topic: [lisp] Proposed changes for draft-ietf-lisp-multicast-06.txt Thread-Index: AcwprDOPgScFbyYJSBmM2FWEyfQ7wQ== Message-ID: <393A16E6-DCC4-4370-96E7-DC8364DECD3F@icann.org> References: <4099FE40-80F6-4E32-848C-C33990DB1343@cisco.com> <96A53C26-D89A-4606-97F1-209D40ACDD82@cisco.com> In-Reply-To: <96A53C26-D89A-4606-97F1-209D40ACDD82@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Stig Venaas , David Meyer , Jesus Arango , "lisp@ietf.org" Subject: Re: [lisp] Proposed changes for draft-ietf-lisp-multicast-06.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2011 09:28:08 -0000 Alia and Jesus, Does the responses herein address your concerns? If not, why not? Cheers, Terry On 13/06/2011, at 5:09 PM, "Dino Farinacci" wrote: > I would like to ask the chairs, as well as Alia and Jesus if I can > post this update. >=20 > This email was posted 2 weeks ago and no replies were received. >=20 > Dino >=20 > On May 30, 2011, at 8:50 PM, Dino Farinacci wrote: >=20 >> We have received WG last call comments on the LISP-multicast draft >> from Jesus Arango and Alia Atlas. See enclosed our responses and a >> proposed updated draft and html diff file. >>=20 >> Jesus comments: >>=20 >>> 1. Cross-talk duplication of multicast flows when using multiple >>> RLOCS: >>> Consider two receiver sites A and B with the following mappings: >>>=20 >>> Site A: >>> (S1, G) --> (RLOC1, G) >>> (S2, G) --> (RLOC2, G) >>> Site B: >>> (S1, G) --> (RLOC2, G) >>>=20 >>> This would cause Site A to receive duplicate packets for (S1,G). >>> One copy >>> would be encapsulated with source RLOC1 while the second copy will be >>=20 >> All sites are suppose to hash to the same RLOC for a given (S- >> EID,G). So Site B would use (RLOC1,G) as would Site A. >>=20 >>> encapsulated with source RLOC2. There are multiple ways to address >>> this >>> issue: >>>=20 >>> a. Perform neighbor verification as part of RPF check. This seemed >>> obvious >>> but it is worth noting that to my understanding this is not done in >>> IOS. Can >>> folks comment on why this is not done today? What is the viability >>> of doing >>> this? What is the current behavior in non-IOS platforms ? >>> b. Use a single RLOC for multicast >>> c. Anycast RLOC >>> d. Propose a group-to-RLOC hashing mechanism where the hashing >>> function >>> dynamically adapts to addition/deletion of RLOCS while minimizing >>> the impact >>> on flows that are already stablished. >>=20 >> What will happen is that if (S1,G) and (S2,G) map to core >> distribution tree (RLOC2,G) then Site B will get packets for no >> receivers. I have added a paragraph to section 8.1.2 to make this >> clear. >>=20 >> Alia comments: >>=20 >>> What I most want to see in this draft is a clear description of what >>> needs to implemented and how. It gives a good survey of the >>> architectural possibilities and even makes suggestions at the end - >>> but not quite sufficient to be clear in the details of what needs to >>> be implemented for interoperability and what is for future >>> experimentation. >>=20 >> Everything in the spec needs to be implemented. Why would you think >> differently? >>=20 >>> a) Could you add a definition for uPITR? It is first used on p.9 in >>> the mPETR definition and only on p. 22 is it described as >>> "(where in unicast it acts as a "Proxy ITR", or an uPITR)" >>=20 >> I do not want to duplicate the definition from the Interworking >> spec. I will add a reference though. >>=20 >>> b) Sec 4, second paragraph: "At this point in time, we don't see a >>> requirement for different locator-sets, priority, and weight policies >>> for multicast than we have for unicast." but there is an M Priority >>> and M Weight in the [LISP] draft. Clarification as to why would be >>> useful... (I know it is to get the RLOCs of the ITRs which shouldn't >>> be used for unicast traffic.) >>=20 >> I added a sentence. >>=20 >>> I don't see a mechanism other than the M Priority to obtain the RLOCs >>> associated with an ITR - since only ETR RLOCs would normally be >>> included. >>=20 >> I don't understand the comment. There is one locator-set, and the >> RLOCs for encapsulating unicast packets to and the RLOCs for sending >> multicast join messages to can be a different set within the locator- >> set. >>=20 >>> What would be good to add to the draft is the changes to be made to >>> information such as the Map-Reply messages. E.g. >>> Set the M Priority for all ETR RLOCs to be 255 >>> Add the ITR RLOCs and set the Priority to 255 & the M Priority to >>> something else. >>=20 >> They are the same locators. The xTR has one locator-set, the RLOCs >> are used as a destination for unicast packets or for a destination >> for multicast joins. >>=20 >>> c) What happens if the S-EID and S-RLOC collide? In particular, at >>=20 >> You have to be more specific on what you mean here. >>=20 >>> the ETR and ITR, it seems useful to specify that the xTR has >>> knowledge >>> of whether the packet was LISP-encapsulated & forwards it either to >>> receivers that expect it un-LISP-encapsulated (ETR) or to receivers >>> that expect it LISP-encapsulated (ITR). >>=20 >> An EID and RLOC can have the same value just like in the unicast >> scenario. >>=20 >>> d) p. 15 end of MSDP: >>> "And the choice can be made unilaterally because the ITR at the >>> site will determine which namespace the destination peer address is >>> out of by looking in the mapping database service." >>>=20 >>> Is there an assumption in LISP that an EID and an RLOC MUST NOT have >>> the same value?? I've seen this potentially implied, but not >>> proscriptively stated. >>=20 >> There is not architectural. >>=20 >>> e) p. 22 first paragraph: >>> "So the ETR knows to simply propagate the PIM Join/Prune message to >>> a external-facing interface without converting the (S-EID,G) because >>> it is an (S,G) where S is routable and reachable via core routing >>> tables." >>>=20 >>> In [INTWRK], it is clear that an EID may be globally routable. This >>> creates a conflict here, where there is an assumption that if an IP >>> address is globally routable, then it is not in the EID/RLOC mapping >>> database. >>=20 >> The text says: >>=20 >> In this case, S-EID is not in the >>=20 >> Farinacci, et al. Expires December 1, 2011 [Page >> 21] >> Internet-Draft LISP for Multicast Environments May >> 2011 >>=20 >>=20 >> mapping database because the source multicast site is using a >> routable address and not an EID prefix address. So the ETR knows to >> simply propagate the PIM Join/Prune message to a external-facing >> interface without converting the (S-EID,G) because it is an (S,G) >> where S is routable and reachable via core routing tables. >>=20 >> So the ETR knows because "there is no mapping database entry and the >> S-EID is routable". >>=20 >>> Couldn't a more specific check be done along the lines of: >>> if the S-EID is reachable via core routing and >>> i) it is not in the mapping database or >>> ii) it is in the mapping database, but there are no RLOCs with >>> an M Priority other than 255? >>>=20 >>> f) Text in 9.1.1, 9.1.2 doesn't match the headings well. For >>> instance, in 9.1.1, there is discussion of how a LISP source site >>> that >>> sends to non-LISP or uLISP receiver sites also can send to LISP >>> receiver sites. >>=20 >> They actually are correct, but the first start out saying how the >> trees are built from the receiver side so that text can support the >> data-flow description that comes later. >>=20 >>> In 9.1.2, maybe renaming it to non-mLISP Receiver Sites would be >>> clearer? >>=20 >> We stated up from the definition of a non-LISP receiver site. >> Creating a new term would add to the number of combinations. The >> spec doesn't need that extra complexity. >>=20 >>> g) In 9.1.4, Mpriority and Mweight are finally mentioned - but as far >>> as I can tell, they are needed earlier and for the pure mLISP to >>> mLISP >>> case. Please pull the discussion of this earlier. >>=20 >> Can you be more specific please. >>=20 >>> Also, this case is discussed in 9.1.1 last paragraph on p. 21 - but >>> claimed that it is sufficient to look in the mapping database. Could >>> you please combine these and bring more consistency to the draft? >>=20 >> Combine what? Please be more specific. >>=20 >>> h) In 9.1.5, is it possible to make a recommendation (e.g. an ITR >>> SHOULD be able to send two packets based on what its oif-lists are? >>=20 >> No, we want to leave it up to the implementation. >>=20 >>> Isn't this already the case because the mLISP ITR could have >>> internal-facing entries in the (S-EID,G) that need to be replicated >>> without encapsulation and external-facing entries in the (S-RLOC, G) >>> that need encapsulation? >>=20 >> Yes, but those forwarding rules are up to the multicast routing >> protocol run in the site. That is, if your comment is to document >> this. >>=20 >>> I understand that this isn't ideal because multiple copies of data >>> are >>> going into the core - but the trees are different there too. >>=20 >> Which trees are different? >>=20 >>> What I'm looking for is some normative text about what MUST/SHOULD be >>> supported - even for experimental interoperability. >>=20 >> If there are mPETRs deployed an ITR can use option 2. If not, option >> 1 is the only option. >>=20 >>> The second option seems like it comes naturally - if a Join comes for >>> the (S-RLOC, G), then it is sent the encapsulated packet. >>=20 >> Right, if joins come from the mPETRs. >>=20 >>> g) p. 21 Sec 9.1.1 end of second paragraph: >>> "It is important to note that the routable address for the host >>> cannot >>> be the same as an RLOC for the site. Because we want the ITRs to >>> process a received PIM Join/Prune message from an external-facing >>> interface to be propagated inside of the site so the site-part of >>> the >>> distribution tree is built." >>> Is this supposed to be one sentence?? >>=20 >> I fixed it up a bit. Thanks. >>=20 >>> h) typo: p. 9 mPETR definition, last sentence: "co-loacted" -> co- >>> located >>>=20 >>> i) typo: p. 23 4th line from bottom: "oins to" -> joins to >>>=20 >>> j) typo: p.27 first sentence: "MUST not" -> MUST NOT >>>=20 >>> k) typo: Sec 11 last sentence: "addition to slow" -> "addition due >>> to slow" >>>=20 >>> l) [LISP] needs to be Normative - it has the packet formats! >>=20 >> Fixed all these. Thanks. >>=20 >> Thanks, >> Dino/Dave/Stig/JohnZ >>=20 >> > ietf-lisp-multicast-06.txt> >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Mon Jun 13 10:43:52 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F37911E8120 for ; Mon, 13 Jun 2011 10:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.392 X-Spam-Level: X-Spam-Status: No, score=-10.392 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_COMMENT_SAVED_URL=0.114, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17kvs3NquoFb for ; Mon, 13 Jun 2011 10:43:43 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id B8F8B11E80A9 for ; Mon, 13 Jun 2011 10:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=160712; q=dns/txt; s=iport; t=1307987023; x=1309196623; h=cc:message-id:from:to:in-reply-to:mime-version:subject: date:references; bh=lPWKyeMs92g4Knk/ArkRg8An0RZKbu6JhJQauEw0ooo=; b=fQfrYPwu10qD6XmaCN1SWmPxLTh4UM0piPsJOz7ycnLJqQ/uAKCr5U0y yvKJqK/QK4nIzsILlsyG8La4uGQ4kiY0gHqUS8gCYT2O8mHiyp7OzHBpm a9Bk4xc9Gafy5CrzIV0RGTQXjCHK6+cBXb5fQC7wif7HNo0XwxpRDAmiL g=; X-Files: rfcdiff-lisp-multicast-05-to-06.html, draft-ietf-lisp-multicast-06.txt : 71122, 73813 X-IronPort-AV: E=Sophos;i="4.65,359,1304294400"; d="txt'?html'217?scan'217,208,217";a="336027138" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 13 Jun 2011 17:43:43 +0000 Received: from [172.16.31.204] (sjc-vpn3-528.cisco.com [10.21.66.16]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5DHhfR1000677; Mon, 13 Jun 2011 17:43:42 GMT Message-Id: <977AFEF7-6325-434E-82D5-703D1F4CACDE@cisco.com> From: Dino Farinacci To: "Jesus Arango (jearango)" In-Reply-To: <1CE581BF755C2745B72D8094079B23CB0CA43E78@xmb-sjc-21b.amer.cisco.com> Content-Type: multipart/mixed; boundary=Apple-Mail-21--1032660532 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 13 Jun 2011 10:43:41 -0700 References: <4099FE40-80F6-4E32-848C-C33990DB1343@cisco.com> <96A53C26-D89A-4606-97F1-209D40ACDD82@cisco.com> <393A16E6-DCC4-4370-96E7-DC8364DECD3F@icann.org> <1CE581BF755C2745B72D8094079B23CB0CA43E78@xmb-sjc-21b.amer.cisco.com> X-Mailer: Apple Mail (2.936) Cc: "Stig Venaas \(svenaas\)" , "David Meyer \(dmm\)" , lisp@ietf.org Subject: Re: [lisp] Proposed changes for draft-ietf-lisp-multicast-06.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2011 17:43:52 -0000 --Apple-Mail-21--1032660532 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Enclosed. Dino --Apple-Mail-21--1032660532 Content-Disposition: attachment; filename=rfcdiff-lisp-multicast-05-to-06.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-lisp-multicast-05-to-06.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-multicast-05.txt draft-ietf-lisp-multicast-06.txt 
Network Working Group                                       D. Farinacci
Internet-Draft                                                  D. Meyer
Intended status: Experimental                                 J. Zwiebel
Expires: October 7, December 1, 2011                                      S. Venaas
                                                           cisco Systems
                                                           April 5,
                                                            May 30, 2011

                    LISP for Multicast Environments
                      draft-ietf-lisp-multicast-05
                      draft-ietf-lisp-multicast-06

Abstract

   This draft describes how inter-domain multicast routing will function
   in an environment where Locator/ID Separation is deployed using the
   LISP architecture.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 7, December 1, 2011.

Copyright Notice

   Copyright (c) 2011 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 BSD License.

Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  7
   4.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 10
   5.  Source Addresses versus Group Addresses  . . . . . . . . . . . 13
   6.  Locator Reachability Implications on LISP-Multicast  . . . . . 14
   7.  Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 15
   8.  LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 17
     8.1.  ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 17
       8.1.1.  Multiple RLOCs for an ITR  . . . . . . . . . . . . . . 17
       8.1.2.  Multiple ITRs for a LISP Source Site . . . . . . . . . 18
     8.2.  ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 18
     8.3.  Replication Locations  . . . . . . . . . . . . . . . . . . 18 19
   9.  LISP-Multicast Interworking  . . . . . . . . . . . . . . . . . 20
     9.1.  LISP and non-LISP Mixed Sites  . . . . . . . . . . . . . . 20
       9.1.1.  LISP Source Site to non-LISP Receiver Sites  . . . . . 21
       9.1.2.  Non-LISP Source Site to non-LISP Receiver  Sites . . . 22
       9.1.3.  Non-LISP Source Site to Any Receiver Site  . . . . . . 23
       9.1.4.  Unicast LISP Source Site to Any Receiver Sites . . . . 24
       9.1.5.  LISP Source Site to Any Receiver Sites . . . . . . . . 24
     9.2.  LISP Sites with Mixed Address Families . . . . . . . . . . 25
     9.3.  Making a Multicast Interworking Decision . . . . . . . . . 27
   10. Considerations when RP Addresses are Embedded in Group
       Addresses  . . . . . . . . . . . . . . . . . . . . . . . . . . 28
   11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 29
   12. Mtrace Considerations  . . . . . . . . . . . . . . . . . . . . 30
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 31
   14. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 32
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 33
     15.2. Informative References . . . . . . . . . . . . . . . . . . 33
   Appendix A.  Document Change Log . . . . . . . . . . . . . . . . . 35
     A.1.  Changes to draft-ietf-lisp-multicast-05.txt draft-ietf-lisp-multicast-06.txt  . . . . . . . 35
     A.2.  Changes to draft-ietf-lisp-multicast-04.txt draft-ietf-lisp-multicast-05.txt  . . . . . . . 35
     A.3.  Changes to draft-ietf-lisp-multicast-03.txt draft-ietf-lisp-multicast-04.txt  . . . . . . . 35
     A.4.  Changes to draft-ietf-lisp-multicast-02.txt draft-ietf-lisp-multicast-03.txt  . . . . . . . 35
     A.5.  Changes to draft-ietf-lisp-multicast-01.txt draft-ietf-lisp-multicast-02.txt  . . . . . . . 36
     A.6.  Changes to draft-ietf-lisp-multicast-01.txt  . . . . . . . 36
     A.7.  Changes to draft-ietf-lisp-multicast-00.txt  . . . . . . . 36
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37

1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   The Locator/ID Separation Architecture [LISP] provides a mechanism to
   separate out Identification and Location semantics from the current
   definition of an IP address.  By creating two namespaces, an EID
   namespace used by sites and a Locator (RLOC) namespace used by core
   routing, the core routing infrastructure can scale by doing
   topological aggregation of routing information.

   Since LISP creates a new namespace, a mapping function must exist to
   map a site's EID prefixes to its associated locators.  For unicast
   packets, both the source address and destination address must be
   mapped.  For multicast packets, only the source address needs to be
   mapped.  The destination group address doesn't need to be mapped
   because the semantics of an IPv4 or IPv6 group address are logical in
   nature and not topology-dependent.  Therefore, this specifications
   focuses on to map a source EID address of a multicast flow during
   distribution tree setup and packet delivery.

   This specification will address the following scenarios:

   1.  How a multicast source host in a LISP site sends multicast
       packets to receivers inside of its site as well as to receivers
       in other sites that are LISP enabled.

   2.  How inter-domain (or between LISP sites) multicast distribution
       trees are built and how forwarding of multicast packets leaving a
       source site toward receivers sites is performed.

   3.  What protocols are affected and what changes are required to such
       multicast protocols.

   4.  How ASM-mode, SSM-mode, and Bidir-mode service models will
       operate.

   5.  How multicast packet flow will occur for multiple combinations of
       LISP and non-LISP capable source and receiver sites, for example:

       A.  How multicast packets from a source host in a LISP site are
           sent to receivers in other sites when they are all non-LISP
           sites.

       B.  How multicast packets from a source host in a LISP site are
           sent to receivers in both LISP-enabled sites and non-LISP
           sites.

       C.  How multicast packets from a source host in a non-LISP site
           are sent to receivers in other sites when they are all LISP-
           enabled sites.

       D.  How multicast packets from a source host in a non-LISP site
           are sent to receivers in both LISP-enabled sites and non-LISP
           sites.

   This specification focuses on what changes are needed to the
   multicast routing protocols to support LISP-Multicast as well as
   other protocols used for inter-domain multicast, such as Multi-
   protocol BGP (MBGP) [RFC4760].  The approach proposed in this
   specification requires no changes to the multicast infrastructure
   inside of a site when all sources and receivers reside in that site,
   even when the site is LISP enabled.  That is, internal operation of
   multicast is unchanged regardless of whether or not the site is LISP
   enabled or whether or not receivers exist in other sites which are
   LISP-enabled.

   Therefore, we see changes only to PIM-ASM [RFC4601], MSDP [RFC3618],
   and PIM-SSM [RFC4607].  Bidir-PIM [RFC5015], which typically does not
   run in an inter-domain environment is not addressed in depth in this
   version of the specification.

   Also, the current version of this specification does not describe
   multicast-based Traffic Engineering relative to the TE-ITR and TE-ETR
   descriptions in [LISP].

3.  Definition of Terms

   The terminology in this section is consistent with the definitions in
   [LISP] but is extended specifically to deal with the application of
   the terminology to multicast routing.

   LISP-Multicast:   a reference to the design in this specification.
      That is, when any site that is participating in multicast
      communication has been upgraded to be a LISP site, the operation
      of control-plane and data-plane protocols is considered part of
      the LISP-Multicast architecture.

   Endpoint ID (EID):   a 32-bit (for IPv4) or 128-bit (for IPv6) value
      used in the source address field of the first (most inner) LISP
      header of a multicast packet.  The host obtains a destination
      group address the same way it obtains one today, as it would when
      it is a non-LISP site.  The source EID is obtained via existing
      mechanisms used to set a host's "local" IP address.  An EID is
      allocated to a host from an EID prefix block associated with the
      site the host is located in.  An EID can be used by a host to
      refer to another host, as when it joins an SSM (S-EID,G) route
      using IGMP version 3 [RFC4604].  LISP uses Provider Independent
      (PI) blocks for EIDs; such EIDs MUST NOT be used as LISP RLOCs.
      Note that EID blocks may be assigned in a hierarchical manner,
      independent of the network topology, to facilitate scaling of the
      mapping database.  In addition, an EID block assigned to a site
      may have site-local structure (subnetting) for routing within the
      site; this structure is not visible to the global routing system.

   Routing Locator (RLOC):   the IPv4 or IPv6 address of an ingress
      tunnel router (ITR), the router in the multicast source host's
      site that encapsulates multicast packets.  It is the output of a
      EID-to-RLOC mapping lookup.  An EID maps to one or more RLOCs.
      Typically, RLOCs are numbered from topologically-aggregatable
      blocks that are assigned to a site at each point to which it
      attaches to the global Internet; where the topology is defined by
      the connectivity of provider networks, RLOCs can be thought of as
      Provider Assigned (PA) addresses.  Multiple RLOCs can be assigned
      to the same ITR device or to multiple ITR devices at a site.

   Ingress Tunnel Router (ITR):   a router which accepts an IP multicast
      packet with a single IP header (more precisely, an IP packet that
      does not contain a LISP header).  The router treats this "inner"
      IP destination multicast address opaquely so it doesn't need to
      perform a map lookup on the group address because it is
      topologically insignificant.  The router then prepends an "outer"
      IP header with one of its globally-routable RLOCs as the source
      address field.  This RLOC is known to other multicast receiver
      sites which have used the mapping database to join a multicast
      tree for which the ITR is the root.  In general, an ITR receives
      IP packets from site end systems on one side and sends LISP-
      encapsulated multicast IP packets out all external interfaces
      which have been joined.

      An ITR would receive a multicast packet from a source inside of
      its site when 1) it is on the path from the multicast source to
      internally joined receivers, or 2) when it is on the path from the
      multicast source to externally joined receivers.

   Egress Tunnel Router (ETR):   a router that is on the path from a
      multicast source host in another site to a multicast receiver in
      its own site.  An ETR accepts a PIM Join/Prune message from a site
      internal PIM router destined for the source's EID in the multicast
      source site.  The ETR maps the source EID in the Join/Prune
      message to an RLOC address based on the EID-to-RLOC mapping.  This
      sets up the ETR to accept multicast encapsulated packets from the
      ITR in the source multicast site.  A multicast ETR decapsulates
      multicast encapsulated packets and replicates them on interfaces
      leading to internal receivers.

   xTR:   is a reference to an ITR or ETR when direction of data flow is
      not part of the context description. xTR refers to the router that
      is the tunnel endpoint.  Used synonymously with the term "Tunnel
      Router".  For example, "An xTR can be located at the Customer Edge
      (CE) router", meaning both ITR and ETR functionality can be at the
      CE router.

   LISP Header:   a term used in this document to refer to the outer
      IPv4 or IPv6 header, a UDP header, and a LISP header.  An ITR
      prepends headers and an ETR strips headers.  A LISP encapsulated
      multicast packet will have an "inner" header with the source EID
      in the source field; an "outer" header with the source RLOC in the
      source field: and the same globally unique group address in the
      destination field of both the inner and outer header.

   (S,G) State:   the formal definition is in the PIM Sparse Mode
      [RFC4601] specification.  For this specification, the term is used
      generally to refer to multicast state.  Based on its topological
      location, the (S,G) state resides in routers can be either
      (S-EID,G) state (at a location where the (S,G) state resides) or
      (S-RLOC,G) state (in the Internet core).

   (S-EID,G) State:   refers to multicast state in multicast source and
      receiver sites where S-EID is the IP address of the multicast
      source host (its EID).  An S-EID can appear in an IGMPv3 report,
      an MSDP SA message or a PIM Join/Prune message that travels inside
      of a site.

   (S-RLOC,G) State:   refers to multicast state in the core where S is
      a source locator (the IP address of a multicast ITR) of a site
      with a multicast source.  The (S-RLOC,G) is mapped from (S-EID,G)
      entry by doing a mapping database lookup for the EID prefix that
      S-EID maps to.  An S-RLOC can appear in a PIM Join/Prune message
      when it travels from an ETR to an ITR over the Internet core.

   uLISP Site:   a unicast only LISP site according to [LISP] which has
      not deployed the procedures of this specification and therefore,
      for multicast purposes, follows the procedures from Section 9.

   mPETR:   this is a multicast proxy-ETR that is responsible for
      advertising a very coarse EID prefix which non-LISP and uLISP
      sites can target their (S-EID,G) PIM Join/Prune message to. mPETRs
      are used so LISP source multicast sites can send multicast packets
      using source addresses from the EID namespace. mPETRs act as Proxy
      ETRs for supporting multicast routing in a LISP infrastructure.
      It is likely an uPITR [INTWORK] and a mPETR will be co-loacted co-located
      since the single device advertises a coarse EID-prefix in the
      underlying unicast routing system.

   Mixed Locator-Sets:   this is a locator-set for a LISP database
      mapping entry where the RLOC addresses in the locator-set are in
      both IPv4 and IPv6 format.

   Unicast Encapsulated PIM Join/Prune Message:   this is a standard PIM
      Join/Prune message (encapsulated in a LISP Encapsulated Control
      Message with destination UDP port 4342) which is sent by ETRs at
      multicast receiver sites to an ITR at a multicast source site.
      This message is sent periodically as long as there are interfaces
      in the oif-list for the (S-EID,G) entry the ETR is joining for.

4.  Basic Overview

   LISP, when used for unicast routing, increases the site's ability to
   control ingress traffic flows.  Egress traffic flows are controlled
   by the IGP in the source site.  For multicast, the IGP coupled with
   PIM can decide which path multicast packets ingress.  By using the
   traffic engineering features of LISP, a multicast source site can
   control the egress of its multicast traffic.  By controlling the
   priorities of locators from a mapping database entry, a source
   multicast site can control which way multicast receiver sites join to
   the source site.

   At this point in time, we don't see a requirement for different
   locator-sets, priority, and weight policies for multicast than we
   have for unicast.  However, when traffic engineering policies are
   different for unicast versus multicast flows, it will be desirable to
   use multicast-based priority and weight values in Map-Reply messages.

   The fundamental multicast forwarding model is to encapsulate a
   multicast packet into another multicast packet.  An ITR will
   encapsulate multicast packets received from sources that it serves in
   another LISP multicast header.  The destination group address from
   the inner header is copied to the destination address of the outer
   header.  The inner source address is the EID of the multicast source
   host and the outer source address is the RLOC of the encapsulating
   ITR.

   The LISP-Multicast architecture will follow this high-level protocol
   and operational sequence:

   1.  Receiver hosts in multicast sites will join multicast content the
       way they do today, they use IGMP.  When they use IGMPv3 where
       they specify source addresses, they use source EIDs, that is they
       join (S-EID,G).  If the multicast source is external to this
       receiver site, the PIM Join/Prune message flows toward the ETRs,
       finding the shortest exit (that is the closest exit for the Join/
       Prune message and the closest entrance for the multicast packet
       to the receiver).

   2.  The ETR does a mapping database lookup for S-EID.  If the mapping
       is cached from a previous lookup (from either a previous Join/
       Prune for the source multicast site or a unicast packet that went
       to the site), it will use the RLOC information from the mapping.
       The ETR will use the same priority and weighting mechanism as for
       unicast.  So the source site can decide which way multicast
       packets egress.

   3.  The ETR will build two PIM Join/Prune messages, one that contains
       a (S-EID,G) entry that is unicast to the ITR that matches the
       RLOC the ETR selects, and the other which contains a (S-RLOC,G)
       entry so the core network can create multicast state from this
       ETR to the ITR.

   4.  When the ITR gets the unicast Join/Prune message (see Section 3
       for formal definition), it will process (S-EID,G) entries in the
       message and propagate them inside of the site where it has
       explicit routing information for EIDs via the IGP.  When the ITR
       receives the (S-RLOC,G) PIM Join/Prune message it will process it
       like any other join it would get in today's Internet.  The S-RLOC
       address is the IP address of this ITR.

   5.  At this point there is (S-EID,G) state from the joining host in
       the receiver multicast site to the ETR of the receiver multicast
       site.  There is (S-RLOC,G) state across the core network from the
       ETR of the multicast receiver site to the ITR in the multicast
       source site and (S-EID,G) state in the source multicast site.
       Note, the (S-EID,G) state is the same S-EID in each multicast
       site.  As other ETRs join the same multicast tree, they can join
       through the same ITR (in which case the packet replication is
       done in the core) or a different ITR (in which case the packet
       replication is done at the source site).

   6.  When a packet is originated by the multicast host in the source
       site, it will flow to one or more ITRs which will prepend a LISP
       header by copying the group address to the outer destination
       address field and insert its own locator address in the outer
       source address field.  The ITR will look at its (S-RLOC,G) state,
       where S-RLOC is its own locator address, and replicate the packet
       on each interface a (S-RLOC,G) joined was received on.  The core
       has (S-RLOC,G) so where fanout occurs to multiple sites, a core
       router will do packet replication.

   7.  When either the source site or the core replicates the packet,
       the ETR will receive a LISP packet with a destination group
       address.  It will decapsulate packets because it has receivers
       for the group.  Otherwise, it would have not received the packets
       because it would not have joined.  The ETR decapsulates and does
       a (S-EID,G) lookup in its multicast FIB to forward packets out
       one or more interfaces to forward the packet to internal
       receivers.

   This architecture is consistent and scalable with the architecture
   presented in [LISP] where multicast state in the core operates on
   locators and multicast state at the sites operates on EIDs.

   Alternatively, [LISP] also has a mechanism where (S-EID,G) state can
   reside in the core through the use of RPF-vectors [RPFV] in PIM Join/
   Prune messages.  However, few PIM implementations support RPF vectors
   and LISP should avoid S-EID state in the core.  See Section 5 for
   details.

   However, we have some observations on the algorithm above.  We can
   scale the control plane but at the expense of sending data to sites
   which may have not joined the distribution tree where the
   encapsulated data is being delivered.  For example, one site joins
   (S-EID1,G) and another site joins (S-EID2,G).  Both EIDs are in the
   same multicast source site.  Both multicast receiver sites join to
   the same ITR with state (S-RLOC,G) where S-RLOC is the RLOC for the
   ITR.  The ITR joins both (S-EID1,G) and (S-EID2,G) inside of the
   site.  The ITR receives (S-RLOC,G) joins and populates the oif-list
   state for it.  Since both (S-EID1,G) and (S-EID2, G) map to the one
   (S-RLOC,G) packets will be delivered by the core to both multicast
   receiver sites even though each have joined a single source-based
   distribution tree.  This behavior is a consequence of the many-to-one
   mapping between S-EIDs and a S-RLOC.

   There is a possible solution to this problem which reduces the number
   of many-to-one occurrences of (S-EID,G) entries aggregating into a
   single (S-RLOC,G) entry.  If a physical ITR can be assigned multiple
   RLOC addresses and these addresses are advertised in mapping database
   entries, then ETRs at receiver sites have more RLOC address options
   and therefore can join different (RLOC,G) entries for each (S-EID,G)
   entry joined at the receiver site.  It would not scale to have a one-
   to-one relationship between the number of S-EID sources at a source
   site and the number of RLOCs assigned to all ITRs at the site, but we
   can reduce the "n" to a smaller number in the "n-to-1" relationship.
   And in turn, reduce the opportunity for data packets to be delivered
   to sites for groups not joined.

5.  Source Addresses versus Group Addresses

   Multicast group addresses don't have to be associated with either the
   EID or RLOC namespace.  They actually are a namespace of their own
   that can be treated as logical with relatively opaque allocation.
   So, by their nature, they don't detract from an incremental
   deployment of LISP-Multicast.

   As for source addresses, as in the unicast LISP scenario, there is a
   decoupling of identification from location.  In a LISP site, packets
   are originated from hosts using their allocated EIDs, those addresses
   are used to identify the host as well as where in the site's topology
   the host resides but not how and where it is attached to the
   Internet.

   Therefore, when multicast distribution tree state is created anywhere
   in the network on the path from any multicast receiver to a multicast
   source, EID state is maintained at the source and receiver multicast
   sites, and RLOC state is maintained in the core.  That is, a
   multicast distribution tree will be represented as a 3-tuple of
   {(S-EID,G) (S-RLOC,G) (S-EID,G)} where the first element of the
   3-tuple is the state stored in routers from the source to one or more
   ITRs in the source multicast site, the second element of the 3-tuple
   is the state stored in routers downstream of the ITR, in the core, to
   all LISP receiver multicast sites, and the third element in the
   3-tuple is the state stored in the routers downstream of each ETR, in
   each receiver multicast site, reaching each receiver.  Note that
   (S-EID,G) is the same in both the source and receiver multicast
   sites.

   The concatenation/mapping from the first element to the second
   element of the 3-tuples is done by the ITR and from the second
   element to the third element is done at the ETRs.

6.  Locator Reachability Implications on LISP-Multicast

   Multicast state as it is stored in the core is always (S,G) state as
   it exists today or (S-RLOC,G) state as it will exist when LISP sites
   are deployed.  The core routers cannot distinguish one from the
   other.  They don't need to because it is state that RPFs against the
   core routing tables in the RLOC namespace.  The difference is where
   the root of the distribution tree for a particular source is.  In the
   traditional multicast core, the source S is the source host's IP
   address.  For LISP-Multicast the source S is a single ITR of the
   multicast source site.

   An ITR is selected based on the LISP EID-to-RLOC mapping used when an
   ETR propagates a PIM Join/Prune message out of a receiver multicast
   site.  The selection is based on the same algorithm an ITR would use
   to select an ETR when sending a unicast packet to the site.  In the
   unicast case, the ITR can change on a per-packet basis depending on
   the reachability of the ETR.  So an ITR can change relatively easily
   using local reachability state.  However, in the multicast case, when
   an ITR goes unreachable, new distribution tree state must be built
   because the encapsulating root has changed.  This is more significant
   than an RPF-change event, where any router would typically locally
   change its RPF-interface for its existing tree state.  But when an
   encapsulating LISP-Multicast ITR goes unreachable, new distribution
   state must be rebuilt and reflect the new encapsulator.  Therefore,
   when an ITR goes unreachable, all ETRs that are currently joined to
   that ITR will have to trigger a new Join/Prune message for (S-RLOC,G)
   to the new ITR as well as send a unicast encapsulated Join/Prune
   message telling the new ITR which (S-EID,G) is being joined.

   This issue can be mitigated by using anycast addressing for the ITRs
   so the problem does reduce to an RPF change in the core, but still
   requires a unicast encapsulated Join/Prune message to tell the new
   ITR about (S-EID,G).  The problem with this approach is that the ETR
   really doesn't know when the ITR has changed so the new anycast ITR
   will get the (S-EID,G) state only when the ETR sends it the next time
   during its periodic sending procedures.

7.  Multicast Protocol Changes

   A number of protocols are used today for inter-domain multicast
   routing:

   IGMPv1-v3, MLDv1-v2:   These protocols do not require any changes for
      LISP-Multicast for two reasons.  One being that they are link-
      local and not used over site boundaries and second they advertise
      group addresses that don't need translation.  Where source
      addresses are supplied in IGMPv3 and MLDv2 messages, they are
      semantically regarded as EIDs and don't need to be converted to
      RLOCs until the multicast tree-building protocol, such as PIM, is
      received by the ETR at the site boundary.  Addresses used for IGMP
      and MLD come out of the source site's allocated addresses which
      are therefore from the EID namespace.

   MBGP:   Even though MBGP is not a multicast routing protocol, it is
      used to find multicast sources when the unicast BGP peering
      topology and the multicast MBGP peering topology are not
      congruent.  When MBGP is used in a LISP-Multicast environment, the
      prefixes which are advertised are from the RLOC namespace.  This
      allows receiver multicast sites to find a path to the source
      multicast site's ITRs.  MBGP peering addresses will be from the
      RLOC namespace.

   MSDP:   MSDP is used to announce active multicast sources to other
      routing domains (or LISP sites).  The announcements come from the
      PIM Rendezvous Points (RPs) from sites where there are active
      multicast sources sending to various groups.  In the context of
      LISP-Multicast, the source addresses advertised in MSDP will
      semantically be from the EID namespace since they describe the
      identity of a source multicast host.  It will be true that the
      state stored in MSDP caches from core routers will be from the EID
      namespace.  An RP address inside of site will be from the EID
      namespace so it can be advertised and reached by internal unicast
      routing mechanism.  However, for MSDP peer-RPF checking to work
      properly across sites, the RP addresses must be converted or
      mapped into a routable address that is advertised and maintained
      in the BGP routing tables in the core.  MSDP peering addresses can
      come out of either the EID or a routable address namespace.  And
      the choice can be made unilaterally because the ITR at the site
      will determine which namespace the destination peer address is out
      of by looking in the mapping database service.

   PIM-SSM:   In the simplest form of distribution tree building, when
      PIM operates in SSM mode, a source distribution tree is built and
      maintained across site boundaries.  In this case, there is a small
      modification to the operation of the PIM protocol (but not to any
      message format) to support taking a Join/Prune message originated
      inside of a LISP site with embedded addresses from the EID
      namespace and converting them to addresses from the RLOC namespace
      when the Join/Prune message crosses a site boundary.  This is
      similar to the requirements documented in [MNAT].

   PIM-Bidir:   Bidirectional PIM is typically run inside of a routing
      domain, but if deployed in an inter-domain environment, one would
      have to decide if the RP address of the shared-tree would be from
      the EID namespace or the RLOC namespace.  If the RP resides in a
      site-based router, then the RP address is from the EID namespace.
      If the RP resides in the core where RLOC addresses are routed,
      then the RP address is from the RLOC namespace.  This could be
      easily distinguishable if the EID address were well-known address
      allocation block from the RLOC namespace.  Also, when using
      Embedded-RP for RP determination [RFC3956], the format of the
      group address could indicate the namespace the RP address is from.
      However, refer to Section 10 for considerations core routers need
      to make when using Embedded-RP IPv6 group addresses.  When using
      Bidir-PIM for inter-domain multicast routing, it is recommended to
      use staticly configured RPs so core routers think the Bidir group
      is associated with an ITR's RLOC as the RP address and site
      routers think the Bidir group is associated with the site resident
      RP with an EID address.  With respect to DF-election in Bidir PIM,
      no changes are required since all messaging and addressing is
      link-local.

   PIM-ASM:   The ASM mode of PIM, the most popular form of PIM, is
      deployed in the Internet today is by having shared-trees within a
      site and using source-trees across sites.  By the use of MSDP and
      PIM-SSM techniques described above, we can get multicast
      connectivity across LISP sites.  Having said that, that means
      there are no special actions required for processing (*,G) or
      (S,G,R) Join/Prune messages since they all operate against the
      shared-tree which is site resident.  Just like with ASM, there is
      no (*,G) in the core when LISP-Multicast is in use.  This is also
      true for the RP-mapping mechanisms Auto-RP and BSR.

   Based on the protocol description above, the conclusion is that there
   are no protocol message format changes, just a translation function
   performed at the control-plane.  This will make for an easier and
   faster transition for LISP since fewer components in the network have
   to change.

   It should also be stated just like it is in [LISP] that no host
   changes, whatsoever, are required to have a multicast source host
   send multicast packets and for a multicast receiver host to receive
   multicast packets.

8.  LISP-Multicast Data-Plane Architecture

   The LISP-Multicast data-plane operation conforms to the operation and
   packet formats specified in [LISP].  However, encapsulating a
   multicast packet from an ITR is a much simpler process.  The process
   is simply to copy the inner group address to the outer destination
   address.  And to have the ITR use its own IP address (its RLOC), and
   as the source address.  The process is simpler for multicast because
   there is no EID-to-RLOC mapping lookup performed during packet
   forwarding.

   In the decapsulation case, the ETR simply removes the outer header
   and performs a multicast routing table lookup on the inner header
   (S-EID,G) addresses.  Then the oif-list for the (S-EID,G) entry is
   used to replicate the packet on site-facing interfaces leading to
   multicast receiver hosts.

   There is no Data-Probe logic for ETRs as there can be in the unicast
   forwarding case.

8.1.  ITR Forwarding Procedure

   The following procedure is used by an ITR, when it receives a
   multicast packet from a source inside of its site:

   1.  A multicast data packet sent by a host in a LISP site will have
       the source address equal to the host's EID and the destination
       address equal to the group address of the multicast group.  It is
       assumed the group information is obtained by current methods.
       The same is true for a multicast receiver to obtain the source
       and group address of a multicast flow.

   2.  When the ITR receives a multicast packet, it will have both S-EID
       state and S-RLOC state stored.  Since the packet was received on
       a site-facing interface, the RPF lookup is based on the S-EID
       state.  If the RPF check succeeds, then the oif-list contains
       interfaces that are site-facing and external-facing.  For the
       site-facing interfaces, no LISP header is prepended.  For the
       external-facing interfaces a LISP header is prepended.  When the
       ITR prepends a LISP header, it uses its own RLOC address as the
       source address and copies the group address supplied by the IP
       header the host built as the outer destination address.

8.1.1.  Multiple RLOCs for an ITR

   Typically, an ITR will have a single RLOC address but in some cases
   there could be multiple RLOC addresses assigned from either the same
   or different service providers.  In this case when (S-RLOC,G) Join/
   Prune messages are received for each RLOC, there is a oif-list
   merging action that must take place.  Therefore, when a packet is
   received from a site-facing interface that matches on a (S-EID,G)
   entry, the interfaces of the oif-list from all (RLOC,G) entries
   joined to the ITR as well as the site-facing oif-list joined for
   (S-EID,G) must be part be included in packet replication.  In
   addition to replicating for all types of oif-lists, each oif entry
   must be tagged with the RLOC address, so encapsulation uses the outer
   source address for the RLOC joined.

8.1.2.  Multiple ITRs for a LISP Source Site

   Note when ETRs from different multicast receiver sites receive
   (S-EID,G) joins, they may select a different S-RLOC for a multicast
   source site due to policy (the multicast ITR can return different
   multicast priority and weight values per ETR Map-Request).  In this
   case, the same (S-EID,G) is being realized by different (S-RLOC,G)
   state in the core.  This will not result in duplicate packets because
   each ITR in the multicast source site will choose their own RLOC for
   the source address for encapsulated multicast traffic.  The RLOC
   addresses are the ones joined by remote multicast ETRs.

   When different (S-EID,G) traffic is combined into a single (RLOC,G)
   core distribution tree, this may cause traffic to go to a receiver
   multicast site when it does not need to.  This happens when one
   receiver multicast site joins (S1-EID,Gi) through a core distribution
   tree of (RLOC1,Gi) and another multicast receiver site joins (S2-
   EID,Gi) through the same core distribution tree of (RLOC1,Gi).  When
   ETRs decapsulate such traffic, they should know from their local
   (S-EID,G) state if the packet should be forwarded.  If there is no
   (S-EID,G) state that matches the inner packet header, the packet is
   discarded.

8.2.  ETR Forwarding Procedure

   The following procedure is used by an ETR, when it receives a
   multicast packet from a source outside of its site:

   1.  When a multicast data packet is received by an ETR on an
       external-facing interface, it will do an RPF lookup on the S-RLOC
       state it has stored.  If the RPF check succeeds, the interfaces
       from the oif-list are used for replication to interfaces that are
       site-facing as well as interfaces that are external-facing (this
       ETR can also be a transit multicast router for receivers outside
       of its site).  When the packet is to be replicated for an
       external-facing interface, the LISP encapsulation header are not
       stripped.  When the packet is replicated for a site-facing
       interface, the encapsulation header is stripped.

   2.  The packet without a LISP header is now forwarded down the
       (S-EID,G) distribution tree in the receiver multicast site.

8.3.  Replication Locations

   Multicast packet replication can happen in the following topological
   locations:

   o  In an IGP multicast router inside a site which operates on S-EIDs.

   o  In a transit multicast router inside of the core which operates on
      S-RLOCs.

   o  At one or more ETR routers depending on the path a Join/Prune
      message exits a receiver multicast site.

   o  At one or more ITR routers in a source multicast site depending on
      what priorities are returned in a Map-Reply to receiver multicast
      sites.

   In the last case the source multicast site can do replication rather
   than having a single exit from the site.  But this only can occur
   when the priorities in the Map-Reply are modified for different
   receiver multicast site so that the PIM Join/Prune messages arrive at
   different ITRs.

   This policy technique, also used in [ALT] for unicast, is useful for
   multicast to mitigate the problems of changing distribution tree
   state as discussed in Section 6.

9.  LISP-Multicast Interworking

   This section will describe the multicast corollary to [INTWORK] which
   describes the interworking of multicast routing among LISP and non-
   LISP sites.

9.1.  LISP and non-LISP Mixed Sites

   Since multicast communication can involve more than two entities to
   communicate together, the combinations of interworking scenarios are
   more involved.  However, the state maintained for distribution trees
   at the sites is the same regardless of whether or not the site is
   LISP enabled or not.  So most of the implications are in the core
   with respect to storing routable EID prefixes from either PA or PI
   blocks.

   Before we enumerate the multicast interworking scenarios, we must
   define 3 deployment states of a site:

   o  A non-LISP site which will run PIM-SSM or PIM-ASM with MSDP as it
      does today.  The addresses for the site are globally routable.

   o  A site that deploys LISP for unicast routing.  The addresses for
      the site are not globally routable.  Let's define the name for
      this type of site as a uLISP site.

   o  A site that deploys LISP for both unicast and multicast routing.
      The addresses for the site are not globally routable.  Let's
      define the name for this type of site as a LISP-Multicast site.

   We will not consider a LISP site enabled for multicast purposes only
   but do consider a uLISP site as documented in [INTWORK].  In this
   section we don't discuss how a LISP site sends multicast packets when
   all receiver sites are LISP-Multicast enabled; that has been
   discussed in previous sections.

   The following scenarios exist to make LISP-Multicast sites interwork
   with non-LISP-Multicast sites:

   1.  A LISP site must be able to send multicast packets to receiver
       sites which are a mix of non-LISP sites and uLISP sites.

   2.  A non-LISP site must be able to send multicast packets to
       receiver sites which are a mix of non-LISP sites and uLISP sites.

   3.  A non-LISP site must be able to send multicast packets to
       receiver sites which are a mix of LISP sites, uLISP sites, and
       non-LISP sites.

   4.  A uLISP site must be able to send multicast packets to receiver
       sites which are a mix of LISP sites, uLISP sites, and non-LISP
       sites.

   5.  A LISP site must be able to send multicast packets to receiver
       sites which are a mix of LISP sites, uLISP sites, and non-LISP
       sites.

9.1.1.  LISP Source Site to non-LISP Receiver Sites

   In the first scenario, a site is LISP capable for both unicast and
   multicast traffic and as such operates on EIDs.  Therefore there is a
   possibility that the EID prefix block is not routable in the core.
   For LISP receiver multicast sites this isn't a problem but for non-
   LISP or uLISP receiver multicast sites, when a PIM Join/Prune message
   is received by the edge router, it has no route to propagate the
   Join/Prune message out of the site.  This is no different than the
   unicast case that LISP-NAT in [INTWORK] solves.

   LISP-NAT allows a unicast packet that exits a LISP site to get its
   source address mapped to a globally routable address before the ITR
   realizes that it should not encapsulate the packet destined to a non-
   LISP site.  For a multicast packet to leave a LISP site, distribution
   tree state needs to be built so the ITR can know where to send the
   packet.  So the receiver multicast sites need to know about the
   multicast source host by its routable address and not its EID
   address.  When this is the case, the routable address is the
   (S-RLOC,G) state that is stored and maintained in the core routers.
   It is important to note that the routable address for the host cannot
   be the same as an RLOC for the site.  Because site because we want the ITRs to
   process a received PIM Join/Prune message from an external-facing
   interface to be propagated inside of the site so the site-part of the
   distribution tree is built.

   Using a globally routable source address allows non-LISP and uLISP
   multicast receiver to join, create, and maintain a multicast
   distribution tree.  However, the LISP multicast receiver site will
   want to perform an EID-to-RLOC mapping table lookup when a PIM Join/
   Prune message is received on a site-facing interface.  It does this
   because it wants to find a (S-RLOC,G) entry to Join in the core.  So
   we have a conflict of behavior between the two types of sites.

   The solution to this problem is the same as when an ITR wants to send
   a unicast packet to a destination site but needs determine if the
   site is LISP capable or not.  When it is not LISP capable, the ITR
   does not encapsulate the packet.  So for the multicast case, when ETR
   receives a PIM Join/Prune message for (S-EID,G) state, it will do a
   mapping table lookup on S-EID.  In this case, S-EID is not in the
   mapping database because the source multicast site is using a
   routable address and not an EID prefix address.  So the ETR knows to
   simply propagate the PIM Join/Prune message to a external-facing
   interface without converting the (S-EID,G) because it is an (S,G)
   where S is routable and reachable via core routing tables.

   Now that the multicast distribution tree is built and maintained from
   any non-LISP or uLISP receiver multicast site, the way packet
   forwarding model is performed can be explained.

   Since the ITR in the source multicast site has never received a
   unicast encapsulated PIM Join/Prune message from any ETR in a
   receiver multicast site, it knows there are no LISP-Multicast
   receiver sites.  Therefore, there is no need for the ITR to
   encapsulate data.  Since it will know a priori (via configuration)
   that its site's EIDs are not routable, it assumes that the multicast
   packets from the source host are sent by a routable address.  That
   is, it is the responsibility of the multicast source host's system
   administrator to ensure that the source host sends multicast traffic
   using a routable source address.  When this happens, the ITR acts
   simply as a router and forwards the multicast packet like an ordinary
   multicast router.

   There is an alternative to using a LISP-NAT scheme just like there is
   for unicast [INTWORK] forwarding by using Proxy Tunnel Routers
   (PxTRs).  This can work the same way for multicast routing as well,
   but the difference is that non-LISP and uLISP sites will send PIM
   Join/Prune messages for (S-EID,G) which make their way in the core to
   multicast PxTRs.  Let's call this use of a PxTR as a "Multicast
   Proxy-ETR" (or mPETR).  Since the mPETRs advertise very coarse EID
   prefixes, they draw the PIM Join/Prune control traffic making them
   the target of the distribution tree.  To get multicast packets from
   the LISP source multicast sites, the tree needs to be built on the
   path from the mPETR to the LISP source multicast site.  To make this
   happen the mPETR acts as a "Proxy ETR" (where in unicast it acts as a
   "Proxy ITR", or an uPITR). uPITR [INTWORK]).

   The existence of mPETRs in the core allows source multicast site ITRs
   to encapsulate multicast packets according to (S-RLOC,G) state.  The
   (S-RLOC,G) state is built from the mPETRs to the multicast ITRs.  The
   encapsulated multicast packets are decapsulated by mPETRs and then
   forwarded according to (S-EID,G) state.  The (S-EID,G) state is built
   from the non-LISP and uLISP receiver multicast sites to the mPETRs.

9.1.2.  Non-LISP Source Site to non-LISP Receiver  Sites

   Clearly non-LISP multicast sites can send multicast packets to non-
   LISP receiver multicast sites.  That is what they do today.  However,
   discussion is required to show how non-LISP multicast sites send
   multicast packets to uLISP receiver multicast sites.

   Since uLISP receiver multicast sites are not targets of any (S,G)
   state, they simply send (S,G) PIM Join/Prune messages toward the non-
   LISP source multicast site.  Since the source multicast site, in this
   case has not been upgraded to LISP, all multicast source host
   addresses are routable.  So this case is simplified to where a uLISP
   receiver multicast site looks to the source multicast site as a non-
   LISP receiver multicast site.

9.1.3.  Non-LISP Source Site to Any Receiver Site

   When a non-LISP source multicast site has receivers in either a non-
   LISP/uLISP site or a LISP site, one needs to decide how the LISP
   receiver multicast site will attach to the distribution tree.  We
   know from Section 9.1.2 that non-LISP and uLISP receiver multicast
   sites can join the distribution tree, but a LISP receiver multicast
   site ETR will need to know if the source address of the multicast
   source host is routable or not.  We showed in Section 9.1.1 that an
   ETR, before it sends a PIM Join/Prune message on an external-facing
   interface, does a EID-to-RLOC mapping lookup to determine if it
   should convert the (S,G) state from a PIM Join/Prune message received
   on a site-facing interface to a (S-RLOC,G).  If the lookup fails, the
   ETR can conclude the source multicast site is a non-LISP site so it
   simply forwards the Join/Prune message (it also doesn't need to send
   a unicast encapsulated Join/Prune message because there is no ITR in
   a non-LISP site and there is namespace continuity between the ETR and
   source).

   For a non-LISP source multicast site, (S-EID,G) state could be
   limited to the edges of the network with the use of multicast proxy-
   ITRs (mPITRs).  The mPITRs can take native, unencapsulated multicast
   packets from non-LISP source multicast and uLISP sites and
   encapsulate them to ETRs in receiver multicast sites or to mPETRs
   that can decapsulate for non-LISP receiver multicast or uLISP sites.
   The mPITRs are responsible for sending (S-EID,G) joins to the non-
   LISP source multicast site.  To connect the distribution trees
   together, multicast ETRs will need to be configured with the mPITR's
   RLOC addresses so they can send both (S-RLOC,G) joins to build a
   distribution tree to the mPITR as well as for sending unicast oins joins
   to mPITRs so they can propogate (S-EID,G) joins into source multicast
   sites.  The use of mPITRs is undergoing more study and is work in
   progress.

9.1.4.  Unicast LISP Source Site to Any Receiver Sites

   In the last section, it was explained how an ETR in a multicast
   receiver site can determine if a source multicast site is LISP-
   enabled by looking into the mapping database.  When the source
   multicast site is a uLISP site, it is LISP enabled but the ITR, by
   definition is not capable of doing multicast encapsulation.  So for
   the purposes of multicast routing, the uLISP source multicast site is
   treated as non-LISP source multicast site.

   Non-LISP receiver multicast sites can join distribution trees to a
   uLISP source multicast site since the source site behaves, from a
   forwarding perspective, as a non-LISP source site.  This is also the
   case for a uLISP receiver multicast site since the ETR does not have
   multicast functionality built-in or enabled.

   Special considerations are required for LISP receiver multicast sites
   since they think the source multicast site is LISP capable, the ETR
   cannot know if ITR is LISP-Multicast capable.  To solve this problem,
   each mapping database entry will have a multicast 2-tuple (Mpriority,
   Mweight) per RLOC.  When the Mpriority is set to 255, the site is
   considered not multicast capable.  So an ETR in a LISP receiver
   multicast site can distinguish whether a LISP source multicast site
   is LISP-Multicast site from a uLISP site.

9.1.5.  LISP Source Site to Any Receiver Sites

   When a LISP source multicast site has receivers in LISP, non-LISP,
   and uLISP receiver multicast sites, it has a conflict about how it
   sends multicast packets.  The ITR can either encapsulate or natively
   forward multicast packets.  Since the receiver multicast sites are
   heterogeneous in their behavior, one packet forwarding mechanism
   cannot satisfy both.  However, if a LISP receiver multicast site acts
   like a uLISP site then it could receive packets like a non-LISP
   receiver multicast site making all receiver multicast sites have
   homogeneous behavior.  However, this poses the following issues:

   o  LISP-NAT techniques with routable addresses would be required in
      all cases.

   o  Or alternatively, mPETR deployment would be required forcing
      coarse EID prefix advertisement in the core.

   o  But what is most disturbing is that when all sites that
      participate are LISP-Multicast sites but then a non-LISP or uLISP
      site joins the distribution tree, then the existing joined LISP
      receiver multicast sites would have to change their behavior.
      This would create too much dynamic tree-building churn to be a
      viable alternative.

   So the solution space options are:

   1.  Make the LISP ITR in the source multicast site send two packets,
       one that is encapsulated with (S-RLOC,G) to reach LISP receiver
       multicast sites and another that is not encapsulated with
       (S-EID,G) to reach non-LISP and uLISP receiver multicast sites.

   2.  Make the LISP ITR always encapsulate packets with (S-RLOC,G) to
       reach LISP-Multicast sites and to reach mPETRs that can
       decapsulate and forward (S-EID,G) packets to non-LISP and uLISP
       receiver multicast sites.

9.2.  LISP Sites with Mixed Address Families

   A LISP database mapping entry that describes the locator-set,
   Mpriority and Mweight per locator address (RLOC), for an EID prefix
   associated with a site could have RLOC addresses in either IPv4 or
   IPv6 format.  When a mapping entry has a mix of RLOC formatted
   addresses, it is an implicit advertisement by the site that it is a
   dual-stack site.  That is, the site can receive IPv4 or IPv6 unicast
   packets.

   To distinguish if the site can receive dual-stack unicast packets as
   well as dual-stack multicast packets, the Mpriority value setting
   will be relative to an IPv4 or IPv6 RLOC See [LISP] for packet format
   details.

   If you consider the combinations of LISP, non-LISP, and uLISP sites
   sharing the same distribution tree and considering the capabilities
   of supporting IPv4, IPv6, or dual-stack, the number of total
   combinations grows beyond comprehension.

   Using some combinatorial math, we have the following profiles of a
   site and the combinations that can occur:

   1.  LISP-Multicast IPv4 Site

   2.  LISP-Multicast IPv6 Site

   3.  LISP-Multicast Dual-Stack Site

   4.  uLISP IPv4 Site

   5.  uLISP IPv6 Site
   6.  uLISP Dual-Stack Site

   7.  non-LISP IPv4 Site

   8.  non-LISP IPv6 Site

   9.  non-LISP Dual-Stack Site

   Lets define (m n) = m!/(n!*(m-n)!), pronounced "m choose n" to
   illustrate some combinatorial math below.

   When 1 site talks to another site, the combinatorial is (9 2), when 1
   site talks to another 2 sites, the combinatorial is (9 3).  If sum
   this up to (9 9), we have:

   (9 2) + (9 3) + (9 4) + (9 5) + (9 6) + (9 7) + (9 8) + (9 9) =

     36  +   84  +  126  +  126  +   84  +   36  +   9   +   1

   Which results in the total number of cases to be considered at 502.

   This combinatorial gets even worse when you consider a site using one
   address family inside of the site and the xTRs use the other address
   family (as in using IPv4 EIDs with IPv6 RLOCs or IPv6 EIDs with IPv4
   RLOCs).

   To rationalize this combinatorial nightmare, there are some
   guidelines which need to be put in place:

   o  Each distribution tree shared between sites will either be an IPv4
      distribution tree or an IPv6 distribution tree.  Therefore, we can
      avoid head-end replication by building and sending packets on each
      address family based distribution tree.  Even though there might
      be an urge to do multicast packet translation from one address
      family format to the other, it is a non-viable over-complicated
      urge.  Multicast ITRs will only encapsulate packets where the
      inner and outer headers are from the same address family.

   o  All LISP sites on a multicast distribution tree must share a
      common address family which is determined by the source site's
      locator-set in its LISP database mapping entry.  All receiver
      multicast sites will use the best RLOC priority controlled by the
      source multicast site.  This is true when the source site is
      either LISP-Multicast or uLISP capable.  This means that priority-
      based policy modification is prohibited.  When a receiver
      multicast site ETR receives a (S-EID,G) join, it must select a
      S-RLOC for the same address family as S-EID.

   o  A mixed multicast locator-set with the best multicast priority
      values MUST not NOT be configured on multicast ITRs.  A mixed locator-
      set can exist (for unicast use), but the multicast priorities MUST
      be the set for the same address family locators.

   o  When the source site is not LISP capable, it is up to how
      receivers find the source and group information for a multicast
      flow.  That mechanism decides the address family for the flow.

9.3.  Making a Multicast Interworking Decision

   This Multicast Interworking section has shown all combinations of
   multicast connectivity that could occur.  As you might have already
   concluded, this can be quite complicated and if the design is too
   ambitious, the dynamics of the protocol could cause a lot of
   instability.

   The trade-off decisions are hard to make and we want the same single
   solution to work for both IPv4 and IPv6 multicast.  It is imperative
   to have an incrementally deployable solution for all of IPv4 unicast
   and multicast and IPv6 unicast and multicast while minimizing (or
   eliminating) both unicast and multicast EID namespace state.

   Therefore the design decision to go with uPITRs [INTWORK] for unicast
   routing and mPETRs for multicast routing seems to be the sweet spot
   in the solution space so we can optimize state requirements and avoid head-
   end
   head-end data replication at ITRs.

10.  Considerations when RP Addresses are Embedded in Group Addresses

   When ASM and PIM-Bidir is used in an IPv6 inter-domain environment, a
   technique exists to embed the unicast address of an RP in a IPv6
   group address [RFC3956].  When routers in end sites process a PIM
   Join/Prune message which contain an embedded-RP group address, they
   extract the RP address from the group address and treat it from the
   EID namespace.  However, core routers do not have state for the EID
   namespace, need to extract an RP address from the RLOC namespace.

   Therefore, it is the responsibility of ETRs in multicast receiver
   sites to map the group address into a group address where the
   embedded-RP address is from the RLOC namespace.  The mapped RP-
   address is obtained from a EID-to-RLOC mapping database lookup.  The
   ETR will also send a unicast (*,G) Join/Prune message to the ITR so
   the branch of the distribution tree from the source site resident RP
   to the ITR is created.

   This technique is no different than the techniques described in this
   specification for translating (S,G) state and propagating Join/Prune
   messages into the core.  The only difference is that the (*,G) state
   in Join/Prune messages are mapped because they contain unicast
   addresses encoded in an Embedded-RP group address.

11.  Taking Advantage of Upgrades in the Core

   If the core routers are upgraded to support [RPFV] and [RFC5496],
   then we can pass EID specific data through the core without,
   possibly, having to store the state in the core.

   By doing this we can eliminate the ETR from unicast encapsulating PIM
   Join/Prune messages to the source site's ITR.

   However, this solution is restricted to a small set of workable cases
   which would not be good for general use of LISP-Multicast.  In
   addition due to slow convergence properties, it is not being
   recommended for LISP-Multicast.

12.  Mtrace Considerations

   Mtrace functionality must be consistent with unicast traceroute
   functionality where all hops from multicast receiver to multicast
   source are visible.

   The design for mtrace for use in LISP-Multicast environments is to be
   determined but should build upon the mtrace version 2 specified in
   [MTRACE].

13.  Security Considerations

   Refer to the [LISP] specification.

14.  Acknowledgments

   The authors would like to gratefully acknowledge the people who have
   contributed discussion, ideas, and commentary to the making of this
   proposal and specification.  People who provided expert review were
   Scott Brim, Greg Shepherd, and Dave Oran.  Other commentary from
   discussions at Summer 2008 Dublin IETF were Toerless Eckert and
   Ijsbrand Wijnands.

   We would also like to thank the MBONED working group for constructive
   and civil verbal feedback when this draft was presented at the Fall
   2008 IETF in Minneapolis.  In particular, good commentary came from
   Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou,
   Ron Bonica, and Lenny Guardino. Guardino, Alia Atlas, and Jesus Arango.

   An expert review of this specification was done by Yiqun Cai and
   Liming Wei. We thank them for their detailed comments.

   This work originated in the Routing Research Group (RRG) of the IRTF.
   The individual submission [MLISP] was converted into this IETF LISP
   working group draft.

15.  References

15.1.  Normative References

   [LISP]     Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-13.txt (work in progress), May 2011.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3618]  Fenner, B. and D. Meyer, "Multicast Source Discovery
              Protocol (MSDP)", RFC 3618, October 2003.

   [RFC3956]  Savola, P. and B. Haberman, "Embedding the Rendezvous
              Point (RP) Address in an IPv6 Multicast Address",
              RFC 3956, November 2004.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC4604]  Holbrook, H., Cain, B., and B. Haberman, "Using Internet
              Group Management Protocol Version 3 (IGMPv3) and Multicast
              Listener Discovery Protocol Version 2 (MLDv2) for Source-
              Specific Multicast", RFC 4604, August 2006.

   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, August 2006.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              January 2007.

   [RFC5015]  Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
              "Bidirectional Protocol Independent Multicast (BIDIR-
              PIM)", RFC 5015, October 2007.

   [RFC5496]  Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
              Forwarding (RPF) Vector TLV", RFC 5496, March 2009.

15.2.  Informative References

   [ALT]      Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative
              Topology (LISP-ALT)", draft-ietf-lisp-alt-06.txt (work in
              progress), March 2011.

   [INTWORK]  Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP
              with IPv4 and IPv6", draft-ietf-lisp-interworking-01.txt draft-ietf-lisp-interworking-02.txt
              (work in progress), March 2010.

   [LISP]     Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-12.txt (work in progress), April 2011.

   [MLISP]    Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
              "LISP for Multicast Environments",
              draft-farinacci-lisp-multicast-01.txt (work in progress),
              November 2008.

   [MNAT]     Wing, D. and T. Eckert, "Multicast Requirements for a
              Network Address (and  port) Translator (NAT)",
              draft-ietf-behave-multicast-07.txt (work in progress),
              June 2007.

   [MTRACE]   Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace
              Version 2: Traceroute Facility for IP Multicast",
              draft-ietf-mboned-mtrace-v2-03.txt (work in progress),
              March 2009.

   [RPFV]     Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector
              TLV", draft-ietf-pim-rpf-vector-06.txt (work in progress),
              February 2008.

Appendix A.  Document Change Log

A.1.  Changes to draft-ietf-lisp-multicast-06.txt

   o  Posted June 2011 to complete working group last call.

   o  Added paragraph to section 8.1.2 based on Jesus comment about
      making it more clear what happens when two (S-EID,G) trees use the
      same (RLOC,G) tree.

   o  Make more references to [INTWORK] when mentioning uPITRs and
      uPETRs.

   o  Made many changes based on editorial and wordsmithing comments
      from Alia.

A.2.  Changes to draft-ietf-lisp-multicast-05.txt

   o  Posted April 2011 to reset expiration timer.

   o  Updated references.

A.2.

A.3.  Changes to draft-ietf-lisp-multicast-04.txt

   o  Posted October 2010 to reset expiration timer.

   o  Updated references.

A.3.

A.4.  Changes to draft-ietf-lisp-multicast-03.txt

   o  Posted April 2010.

   o  Added section 8.1.2 to address Joel Halpern's comment about
      receiver sites joining the same source site via 2 different RLOCs,
      each being a separate ITR.

   o  Change all occurences of "mPTR" to "mPETR" to become more
      consistent with uPITRs and uPETRs described in [INTWORK].  That
      is, an mPETR is a LISP multicast router that decapsulates
      multicast packets that are encapsulated to it by ITRs in multicast
      source sites.

   o  Add clarifications in section 9 about how homogeneous multicast
      encapsulation should occur.  As well as describing in this
      section, how to deal with mixed-locator sets to avoid
      heterogeneous encapsulation.

   o  Introduce concept of mPITRs to help reduce (S-EID,G) to the edges
      of LISP global multicast network.

A.4.

A.5.  Changes to draft-ietf-lisp-multicast-02.txt

   o  Posted September 2009.

   o  Added Document Change Log appendix.

   o  Specify that the LISP Encapsulated Control Message be used for
      unicasting PIM Join/Prune messages from ETRs to ITRs.

A.5.

A.6.  Changes to draft-ietf-lisp-multicast-01.txt

   o  Posted November 2008.

   o  Specified that PIM Join/Prune unicast messages that get sent from
      ETRs to ITRs of a source multicast site get LISP encapsulated in
      destination UDP port 4342.

   o  Add multiple RLOCs per ITR per Yiqun's comments.

   o  Indicate how static RPs can be used when LISP is run using Bidir-
      PIM in the core.

   o  Editorial changes per Liming comments.

   o  Add Mttrace Considersations section.

A.6.

A.7.  Changes to draft-ietf-lisp-multicast-00.txt

   o  Posted April 2008.

   o  Renamed from draft-farinacci-lisp-multicast-01.txt.

Authors' Addresses

   Dino Farinacci
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: dino@cisco.com

   Dave Meyer
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: dmm@cisco.com

   John Zwiebel
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: jzwiebel@cisco.com

   Stig Venaas
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: stig@cisco.com
--Apple-Mail-21--1032660532 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-21--1032660532 Content-Disposition: attachment; filename=draft-ietf-lisp-multicast-06.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-multicast-06.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft D. Meyer Intended status: Experimental J. Zwiebel Expires: December 1, 2011 S. Venaas cisco Systems May 30, 2011 LISP for Multicast Environments draft-ietf-lisp-multicast-06 Abstract This draft describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the LISP architecture. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 1, 2011. Copyright Notice Copyright (c) 2011 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 Farinacci, et al. Expires December 1, 2011 [Page 1] =0C Internet-Draft LISP for Multicast Environments May 2011 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 BSD License. Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 7 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Source Addresses versus Group Addresses . . . . . . . . . . . 13 6. Locator Reachability Implications on LISP-Multicast . . . . . 14 7. Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 15 8. LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 17 8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 17 8.1.1. Multiple RLOCs for an ITR . . . . . . . . . . . . . . 17 8.1.2. Multiple ITRs for a LISP Source Site . . . . . . . . . 18 8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 18 8.3. Replication Locations . . . . . . . . . . . . . . . . . . 19 9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 20 9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 20 9.1.1. LISP Source Site to non-LISP Receiver Sites . . . . . 21 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites . . . 22 9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 23 9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . . 24 9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 24 9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 25 9.3. Making a Multicast Interworking Decision . . . . . . . . . 27 10. Considerations when RP Addresses are Embedded in Group Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 28 11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 29 12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 30 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 15.1. Normative References . . . . . . . . . . . . . . . . . . . 33 15.2. Informative References . . . . . . . . . . . . . . . . . . 33 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 35 A.1. Changes to draft-ietf-lisp-multicast-06.txt . . . . . . . 35 A.2. Changes to draft-ietf-lisp-multicast-05.txt . . . . . . . 35 A.3. Changes to draft-ietf-lisp-multicast-04.txt . . . . . . . 35 A.4. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 35 A.5. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 36 A.6. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 36 Farinacci, et al. Expires December 1, 2011 [Page 2] =0C Internet-Draft LISP for Multicast Environments May 2011 A.7. Changes to draft-ietf-lisp-multicast-00.txt . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 Farinacci, et al. Expires December 1, 2011 [Page 3] =0C Internet-Draft LISP for Multicast Environments May 2011 1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Farinacci, et al. Expires December 1, 2011 [Page 4] =0C Internet-Draft LISP for Multicast Environments May 2011 2. Introduction The Locator/ID Separation Architecture [LISP] provides a mechanism to separate out Identification and Location semantics from the current definition of an IP address. By creating two namespaces, an EID namespace used by sites and a Locator (RLOC) namespace used by core routing, the core routing infrastructure can scale by doing topological aggregation of routing information. Since LISP creates a new namespace, a mapping function must exist to map a site's EID prefixes to its associated locators. For unicast packets, both the source address and destination address must be mapped. For multicast packets, only the source address needs to be mapped. The destination group address doesn't need to be mapped because the semantics of an IPv4 or IPv6 group address are logical in nature and not topology-dependent. Therefore, this specifications focuses on to map a source EID address of a multicast flow during distribution tree setup and packet delivery. This specification will address the following scenarios: 1. How a multicast source host in a LISP site sends multicast packets to receivers inside of its site as well as to receivers in other sites that are LISP enabled. 2. How inter-domain (or between LISP sites) multicast distribution trees are built and how forwarding of multicast packets leaving a source site toward receivers sites is performed. 3. What protocols are affected and what changes are required to such multicast protocols. 4. How ASM-mode, SSM-mode, and Bidir-mode service models will operate. 5. How multicast packet flow will occur for multiple combinations of LISP and non-LISP capable source and receiver sites, for example: A. How multicast packets from a source host in a LISP site are sent to receivers in other sites when they are all non-LISP sites. B. How multicast packets from a source host in a LISP site are sent to receivers in both LISP-enabled sites and non-LISP sites. C. How multicast packets from a source host in a non-LISP site are sent to receivers in other sites when they are all LISP- Farinacci, et al. Expires December 1, 2011 [Page 5] =0C Internet-Draft LISP for Multicast Environments May 2011 enabled sites. D. How multicast packets from a source host in a non-LISP site are sent to receivers in both LISP-enabled sites and non-LISP sites. This specification focuses on what changes are needed to the multicast routing protocols to support LISP-Multicast as well as other protocols used for inter-domain multicast, such as Multi- protocol BGP (MBGP) [RFC4760]. The approach proposed in this specification requires no changes to the multicast infrastructure inside of a site when all sources and receivers reside in that site, even when the site is LISP enabled. That is, internal operation of multicast is unchanged regardless of whether or not the site is LISP enabled or whether or not receivers exist in other sites which are LISP-enabled. Therefore, we see changes only to PIM-ASM [RFC4601], MSDP [RFC3618], and PIM-SSM [RFC4607]. Bidir-PIM [RFC5015], which typically does not run in an inter-domain environment is not addressed in depth in this version of the specification. Also, the current version of this specification does not describe multicast-based Traffic Engineering relative to the TE-ITR and TE-ETR descriptions in [LISP]. Farinacci, et al. Expires December 1, 2011 [Page 6] =0C Internet-Draft LISP for Multicast Environments May 2011 3. Definition of Terms The terminology in this section is consistent with the definitions in [LISP] but is extended specifically to deal with the application of the terminology to multicast routing. LISP-Multicast: a reference to the design in this specification. That is, when any site that is participating in multicast communication has been upgraded to be a LISP site, the operation of control-plane and data-plane protocols is considered part of the LISP-Multicast architecture. Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source address field of the first (most inner) LISP header of a multicast packet. The host obtains a destination group address the same way it obtains one today, as it would when it is a non-LISP site. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID is allocated to a host from an EID prefix block associated with the site the host is located in. An EID can be used by a host to refer to another host, as when it joins an SSM (S-EID,G) route using IGMP version 3 [RFC4604]. LISP uses Provider Independent (PI) blocks for EIDs; such EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be assigned in a hierarchical manner, independent of the network topology, to facilitate scaling of the mapping database. In addition, an EID block assigned to a site may have site-local structure (subnetting) for routing within the site; this structure is not visible to the global routing system. Routing Locator (RLOC): the IPv4 or IPv6 address of an ingress tunnel router (ITR), the router in the multicast source host's site that encapsulates multicast packets. It is the output of a EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically-aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as Provider Assigned (PA) addresses. Multiple RLOCs can be assigned to the same ITR device or to multiple ITR devices at a site. Ingress Tunnel Router (ITR): a router which accepts an IP multicast packet with a single IP header (more precisely, an IP packet that does not contain a LISP header). The router treats this "inner" IP destination multicast address opaquely so it doesn't need to perform a map lookup on the group address because it is topologically insignificant. The router then prepends an "outer" IP header with one of its globally-routable RLOCs as the source address field. This RLOC is known to other multicast receiver Farinacci, et al. Expires December 1, 2011 [Page 7] =0C Internet-Draft LISP for Multicast Environments May 2011 sites which have used the mapping database to join a multicast tree for which the ITR is the root. In general, an ITR receives IP packets from site end systems on one side and sends LISP- encapsulated multicast IP packets out all external interfaces which have been joined. An ITR would receive a multicast packet from a source inside of its site when 1) it is on the path from the multicast source to internally joined receivers, or 2) when it is on the path from the multicast source to externally joined receivers. Egress Tunnel Router (ETR): a router that is on the path from a multicast source host in another site to a multicast receiver in its own site. An ETR accepts a PIM Join/Prune message from a site internal PIM router destined for the source's EID in the multicast source site. The ETR maps the source EID in the Join/Prune message to an RLOC address based on the EID-to-RLOC mapping. This sets up the ETR to accept multicast encapsulated packets from the ITR in the source multicast site. A multicast ETR decapsulates multicast encapsulated packets and replicates them on interfaces leading to internal receivers. xTR: is a reference to an ITR or ETR when direction of data flow is not part of the context description. xTR refers to the router that is the tunnel endpoint. Used synonymously with the term "Tunnel Router". For example, "An xTR can be located at the Customer Edge (CE) router", meaning both ITR and ETR functionality can be at the CE router. LISP Header: a term used in this document to refer to the outer IPv4 or IPv6 header, a UDP header, and a LISP header. An ITR prepends headers and an ETR strips headers. A LISP encapsulated multicast packet will have an "inner" header with the source EID in the source field; an "outer" header with the source RLOC in the source field: and the same globally unique group address in the destination field of both the inner and outer header. (S,G) State: the formal definition is in the PIM Sparse Mode [RFC4601] specification. For this specification, the term is used generally to refer to multicast state. Based on its topological location, the (S,G) state resides in routers can be either (S-EID,G) state (at a location where the (S,G) state resides) or (S-RLOC,G) state (in the Internet core). (S-EID,G) State: refers to multicast state in multicast source and receiver sites where S-EID is the IP address of the multicast source host (its EID). An S-EID can appear in an IGMPv3 report, an MSDP SA message or a PIM Join/Prune message that travels inside Farinacci, et al. Expires December 1, 2011 [Page 8] =0C Internet-Draft LISP for Multicast Environments May 2011 of a site. (S-RLOC,G) State: refers to multicast state in the core where S is a source locator (the IP address of a multicast ITR) of a site with a multicast source. The (S-RLOC,G) is mapped from (S-EID,G) entry by doing a mapping database lookup for the EID prefix that S-EID maps to. An S-RLOC can appear in a PIM Join/Prune message when it travels from an ETR to an ITR over the Internet core. uLISP Site: a unicast only LISP site according to [LISP] which has not deployed the procedures of this specification and therefore, for multicast purposes, follows the procedures from Section 9. mPETR: this is a multicast proxy-ETR that is responsible for advertising a very coarse EID prefix which non-LISP and uLISP sites can target their (S-EID,G) PIM Join/Prune message to. mPETRs are used so LISP source multicast sites can send multicast packets using source addresses from the EID namespace. mPETRs act as Proxy ETRs for supporting multicast routing in a LISP infrastructure. It is likely an uPITR [INTWORK] and a mPETR will be co-located since the single device advertises a coarse EID-prefix in the underlying unicast routing system. Mixed Locator-Sets: this is a locator-set for a LISP database mapping entry where the RLOC addresses in the locator-set are in both IPv4 and IPv6 format. Unicast Encapsulated PIM Join/Prune Message: this is a standard PIM Join/Prune message (encapsulated in a LISP Encapsulated Control Message with destination UDP port 4342) which is sent by ETRs at multicast receiver sites to an ITR at a multicast source site. This message is sent periodically as long as there are interfaces in the oif-list for the (S-EID,G) entry the ETR is joining for. Farinacci, et al. Expires December 1, 2011 [Page 9] =0C Internet-Draft LISP for Multicast Environments May 2011 4. Basic Overview LISP, when used for unicast routing, increases the site's ability to control ingress traffic flows. Egress traffic flows are controlled by the IGP in the source site. For multicast, the IGP coupled with PIM can decide which path multicast packets ingress. By using the traffic engineering features of LISP, a multicast source site can control the egress of its multicast traffic. By controlling the priorities of locators from a mapping database entry, a source multicast site can control which way multicast receiver sites join to the source site. At this point in time, we don't see a requirement for different locator-sets, priority, and weight policies for multicast than we have for unicast. However, when traffic engineering policies are different for unicast versus multicast flows, it will be desirable to use multicast-based priority and weight values in Map-Reply messages. The fundamental multicast forwarding model is to encapsulate a multicast packet into another multicast packet. An ITR will encapsulate multicast packets received from sources that it serves in another LISP multicast header. The destination group address from the inner header is copied to the destination address of the outer header. The inner source address is the EID of the multicast source host and the outer source address is the RLOC of the encapsulating ITR. The LISP-Multicast architecture will follow this high-level protocol and operational sequence: 1. Receiver hosts in multicast sites will join multicast content the way they do today, they use IGMP. When they use IGMPv3 where they specify source addresses, they use source EIDs, that is they join (S-EID,G). If the multicast source is external to this receiver site, the PIM Join/Prune message flows toward the ETRs, finding the shortest exit (that is the closest exit for the Join/ Prune message and the closest entrance for the multicast packet to the receiver). 2. The ETR does a mapping database lookup for S-EID. If the mapping is cached from a previous lookup (from either a previous Join/ Prune for the source multicast site or a unicast packet that went to the site), it will use the RLOC information from the mapping. The ETR will use the same priority and weighting mechanism as for unicast. So the source site can decide which way multicast packets egress. Farinacci, et al. Expires December 1, 2011 [Page 10] =0C Internet-Draft LISP for Multicast Environments May 2011 3. The ETR will build two PIM Join/Prune messages, one that contains a (S-EID,G) entry that is unicast to the ITR that matches the RLOC the ETR selects, and the other which contains a (S-RLOC,G) entry so the core network can create multicast state from this ETR to the ITR. 4. When the ITR gets the unicast Join/Prune message (see Section 3 for formal definition), it will process (S-EID,G) entries in the message and propagate them inside of the site where it has explicit routing information for EIDs via the IGP. When the ITR receives the (S-RLOC,G) PIM Join/Prune message it will process it like any other join it would get in today's Internet. The S-RLOC address is the IP address of this ITR. 5. At this point there is (S-EID,G) state from the joining host in the receiver multicast site to the ETR of the receiver multicast site. There is (S-RLOC,G) state across the core network from the ETR of the multicast receiver site to the ITR in the multicast source site and (S-EID,G) state in the source multicast site. Note, the (S-EID,G) state is the same S-EID in each multicast site. As other ETRs join the same multicast tree, they can join through the same ITR (in which case the packet replication is done in the core) or a different ITR (in which case the packet replication is done at the source site). 6. When a packet is originated by the multicast host in the source site, it will flow to one or more ITRs which will prepend a LISP header by copying the group address to the outer destination address field and insert its own locator address in the outer source address field. The ITR will look at its (S-RLOC,G) state, where S-RLOC is its own locator address, and replicate the packet on each interface a (S-RLOC,G) joined was received on. The core has (S-RLOC,G) so where fanout occurs to multiple sites, a core router will do packet replication. 7. When either the source site or the core replicates the packet, the ETR will receive a LISP packet with a destination group address. It will decapsulate packets because it has receivers for the group. Otherwise, it would have not received the packets because it would not have joined. The ETR decapsulates and does a (S-EID,G) lookup in its multicast FIB to forward packets out one or more interfaces to forward the packet to internal receivers. This architecture is consistent and scalable with the architecture presented in [LISP] where multicast state in the core operates on locators and multicast state at the sites operates on EIDs. Farinacci, et al. Expires December 1, 2011 [Page 11] =0C Internet-Draft LISP for Multicast Environments May 2011 Alternatively, [LISP] also has a mechanism where (S-EID,G) state can reside in the core through the use of RPF-vectors [RPFV] in PIM Join/ Prune messages. However, few PIM implementations support RPF vectors and LISP should avoid S-EID state in the core. See Section 5 for details. However, we have some observations on the algorithm above. We can scale the control plane but at the expense of sending data to sites which may have not joined the distribution tree where the encapsulated data is being delivered. For example, one site joins (S-EID1,G) and another site joins (S-EID2,G). Both EIDs are in the same multicast source site. Both multicast receiver sites join to the same ITR with state (S-RLOC,G) where S-RLOC is the RLOC for the ITR. The ITR joins both (S-EID1,G) and (S-EID2,G) inside of the site. The ITR receives (S-RLOC,G) joins and populates the oif-list state for it. Since both (S-EID1,G) and (S-EID2, G) map to the one (S-RLOC,G) packets will be delivered by the core to both multicast receiver sites even though each have joined a single source-based distribution tree. This behavior is a consequence of the many-to-one mapping between S-EIDs and a S-RLOC. There is a possible solution to this problem which reduces the number of many-to-one occurrences of (S-EID,G) entries aggregating into a single (S-RLOC,G) entry. If a physical ITR can be assigned multiple RLOC addresses and these addresses are advertised in mapping database entries, then ETRs at receiver sites have more RLOC address options and therefore can join different (RLOC,G) entries for each (S-EID,G) entry joined at the receiver site. It would not scale to have a one- to-one relationship between the number of S-EID sources at a source site and the number of RLOCs assigned to all ITRs at the site, but we can reduce the "n" to a smaller number in the "n-to-1" relationship. And in turn, reduce the opportunity for data packets to be delivered to sites for groups not joined. Farinacci, et al. Expires December 1, 2011 [Page 12] =0C Internet-Draft LISP for Multicast Environments May 2011 5. Source Addresses versus Group Addresses Multicast group addresses don't have to be associated with either the EID or RLOC namespace. They actually are a namespace of their own that can be treated as logical with relatively opaque allocation. So, by their nature, they don't detract from an incremental deployment of LISP-Multicast. As for source addresses, as in the unicast LISP scenario, there is a decoupling of identification from location. In a LISP site, packets are originated from hosts using their allocated EIDs, those addresses are used to identify the host as well as where in the site's topology the host resides but not how and where it is attached to the Internet. Therefore, when multicast distribution tree state is created anywhere in the network on the path from any multicast receiver to a multicast source, EID state is maintained at the source and receiver multicast sites, and RLOC state is maintained in the core. That is, a multicast distribution tree will be represented as a 3-tuple of {(S-EID,G) (S-RLOC,G) (S-EID,G)} where the first element of the 3-tuple is the state stored in routers from the source to one or more ITRs in the source multicast site, the second element of the 3-tuple is the state stored in routers downstream of the ITR, in the core, to all LISP receiver multicast sites, and the third element in the 3-tuple is the state stored in the routers downstream of each ETR, in each receiver multicast site, reaching each receiver. Note that (S-EID,G) is the same in both the source and receiver multicast sites. The concatenation/mapping from the first element to the second element of the 3-tuples is done by the ITR and from the second element to the third element is done at the ETRs. Farinacci, et al. Expires December 1, 2011 [Page 13] =0C Internet-Draft LISP for Multicast Environments May 2011 6. Locator Reachability Implications on LISP-Multicast Multicast state as it is stored in the core is always (S,G) state as it exists today or (S-RLOC,G) state as it will exist when LISP sites are deployed. The core routers cannot distinguish one from the other. They don't need to because it is state that RPFs against the core routing tables in the RLOC namespace. The difference is where the root of the distribution tree for a particular source is. In the traditional multicast core, the source S is the source host's IP address. For LISP-Multicast the source S is a single ITR of the multicast source site. An ITR is selected based on the LISP EID-to-RLOC mapping used when an ETR propagates a PIM Join/Prune message out of a receiver multicast site. The selection is based on the same algorithm an ITR would use to select an ETR when sending a unicast packet to the site. In the unicast case, the ITR can change on a per-packet basis depending on the reachability of the ETR. So an ITR can change relatively easily using local reachability state. However, in the multicast case, when an ITR goes unreachable, new distribution tree state must be built because the encapsulating root has changed. This is more significant than an RPF-change event, where any router would typically locally change its RPF-interface for its existing tree state. But when an encapsulating LISP-Multicast ITR goes unreachable, new distribution state must be rebuilt and reflect the new encapsulator. Therefore, when an ITR goes unreachable, all ETRs that are currently joined to that ITR will have to trigger a new Join/Prune message for (S-RLOC,G) to the new ITR as well as send a unicast encapsulated Join/Prune message telling the new ITR which (S-EID,G) is being joined. This issue can be mitigated by using anycast addressing for the ITRs so the problem does reduce to an RPF change in the core, but still requires a unicast encapsulated Join/Prune message to tell the new ITR about (S-EID,G). The problem with this approach is that the ETR really doesn't know when the ITR has changed so the new anycast ITR will get the (S-EID,G) state only when the ETR sends it the next time during its periodic sending procedures. Farinacci, et al. Expires December 1, 2011 [Page 14] =0C Internet-Draft LISP for Multicast Environments May 2011 7. Multicast Protocol Changes A number of protocols are used today for inter-domain multicast routing: IGMPv1-v3, MLDv1-v2: These protocols do not require any changes for LISP-Multicast for two reasons. One being that they are link- local and not used over site boundaries and second they advertise group addresses that don't need translation. Where source addresses are supplied in IGMPv3 and MLDv2 messages, they are semantically regarded as EIDs and don't need to be converted to RLOCs until the multicast tree-building protocol, such as PIM, is received by the ETR at the site boundary. Addresses used for IGMP and MLD come out of the source site's allocated addresses which are therefore from the EID namespace. MBGP: Even though MBGP is not a multicast routing protocol, it is used to find multicast sources when the unicast BGP peering topology and the multicast MBGP peering topology are not congruent. When MBGP is used in a LISP-Multicast environment, the prefixes which are advertised are from the RLOC namespace. This allows receiver multicast sites to find a path to the source multicast site's ITRs. MBGP peering addresses will be from the RLOC namespace. MSDP: MSDP is used to announce active multicast sources to other routing domains (or LISP sites). The announcements come from the PIM Rendezvous Points (RPs) from sites where there are active multicast sources sending to various groups. In the context of LISP-Multicast, the source addresses advertised in MSDP will semantically be from the EID namespace since they describe the identity of a source multicast host. It will be true that the state stored in MSDP caches from core routers will be from the EID namespace. An RP address inside of site will be from the EID namespace so it can be advertised and reached by internal unicast routing mechanism. However, for MSDP peer-RPF checking to work properly across sites, the RP addresses must be converted or mapped into a routable address that is advertised and maintained in the BGP routing tables in the core. MSDP peering addresses can come out of either the EID or a routable address namespace. And the choice can be made unilaterally because the ITR at the site will determine which namespace the destination peer address is out of by looking in the mapping database service. PIM-SSM: In the simplest form of distribution tree building, when PIM operates in SSM mode, a source distribution tree is built and maintained across site boundaries. In this case, there is a small modification to the operation of the PIM protocol (but not to any Farinacci, et al. Expires December 1, 2011 [Page 15] =0C Internet-Draft LISP for Multicast Environments May 2011 message format) to support taking a Join/Prune message originated inside of a LISP site with embedded addresses from the EID namespace and converting them to addresses from the RLOC namespace when the Join/Prune message crosses a site boundary. This is similar to the requirements documented in [MNAT]. PIM-Bidir: Bidirectional PIM is typically run inside of a routing domain, but if deployed in an inter-domain environment, one would have to decide if the RP address of the shared-tree would be from the EID namespace or the RLOC namespace. If the RP resides in a site-based router, then the RP address is from the EID namespace. If the RP resides in the core where RLOC addresses are routed, then the RP address is from the RLOC namespace. This could be easily distinguishable if the EID address were well-known address allocation block from the RLOC namespace. Also, when using Embedded-RP for RP determination [RFC3956], the format of the group address could indicate the namespace the RP address is from. However, refer to Section 10 for considerations core routers need to make when using Embedded-RP IPv6 group addresses. When using Bidir-PIM for inter-domain multicast routing, it is recommended to use staticly configured RPs so core routers think the Bidir group is associated with an ITR's RLOC as the RP address and site routers think the Bidir group is associated with the site resident RP with an EID address. With respect to DF-election in Bidir PIM, no changes are required since all messaging and addressing is link-local. PIM-ASM: The ASM mode of PIM, the most popular form of PIM, is deployed in the Internet today is by having shared-trees within a site and using source-trees across sites. By the use of MSDP and PIM-SSM techniques described above, we can get multicast connectivity across LISP sites. Having said that, that means there are no special actions required for processing (*,G) or (S,G,R) Join/Prune messages since they all operate against the shared-tree which is site resident. Just like with ASM, there is no (*,G) in the core when LISP-Multicast is in use. This is also true for the RP-mapping mechanisms Auto-RP and BSR. Based on the protocol description above, the conclusion is that there are no protocol message format changes, just a translation function performed at the control-plane. This will make for an easier and faster transition for LISP since fewer components in the network have to change. It should also be stated just like it is in [LISP] that no host changes, whatsoever, are required to have a multicast source host send multicast packets and for a multicast receiver host to receive multicast packets. Farinacci, et al. Expires December 1, 2011 [Page 16] =0C Internet-Draft LISP for Multicast Environments May 2011 8. LISP-Multicast Data-Plane Architecture The LISP-Multicast data-plane operation conforms to the operation and packet formats specified in [LISP]. However, encapsulating a multicast packet from an ITR is a much simpler process. The process is simply to copy the inner group address to the outer destination address. And to have the ITR use its own IP address (its RLOC), and as the source address. The process is simpler for multicast because there is no EID-to-RLOC mapping lookup performed during packet forwarding. In the decapsulation case, the ETR simply removes the outer header and performs a multicast routing table lookup on the inner header (S-EID,G) addresses. Then the oif-list for the (S-EID,G) entry is used to replicate the packet on site-facing interfaces leading to multicast receiver hosts. There is no Data-Probe logic for ETRs as there can be in the unicast forwarding case. 8.1. ITR Forwarding Procedure The following procedure is used by an ITR, when it receives a multicast packet from a source inside of its site: 1. A multicast data packet sent by a host in a LISP site will have the source address equal to the host's EID and the destination address equal to the group address of the multicast group. It is assumed the group information is obtained by current methods. The same is true for a multicast receiver to obtain the source and group address of a multicast flow. 2. When the ITR receives a multicast packet, it will have both S-EID state and S-RLOC state stored. Since the packet was received on a site-facing interface, the RPF lookup is based on the S-EID state. If the RPF check succeeds, then the oif-list contains interfaces that are site-facing and external-facing. For the site-facing interfaces, no LISP header is prepended. For the external-facing interfaces a LISP header is prepended. When the ITR prepends a LISP header, it uses its own RLOC address as the source address and copies the group address supplied by the IP header the host built as the outer destination address. 8.1.1. Multiple RLOCs for an ITR Typically, an ITR will have a single RLOC address but in some cases there could be multiple RLOC addresses assigned from either the same or different service providers. In this case when (S-RLOC,G) Join/ Farinacci, et al. Expires December 1, 2011 [Page 17] =0C Internet-Draft LISP for Multicast Environments May 2011 Prune messages are received for each RLOC, there is a oif-list merging action that must take place. Therefore, when a packet is received from a site-facing interface that matches on a (S-EID,G) entry, the interfaces of the oif-list from all (RLOC,G) entries joined to the ITR as well as the site-facing oif-list joined for (S-EID,G) must be part be included in packet replication. In addition to replicating for all types of oif-lists, each oif entry must be tagged with the RLOC address, so encapsulation uses the outer source address for the RLOC joined. 8.1.2. Multiple ITRs for a LISP Source Site Note when ETRs from different multicast receiver sites receive (S-EID,G) joins, they may select a different S-RLOC for a multicast source site due to policy (the multicast ITR can return different multicast priority and weight values per ETR Map-Request). In this case, the same (S-EID,G) is being realized by different (S-RLOC,G) state in the core. This will not result in duplicate packets because each ITR in the multicast source site will choose their own RLOC for the source address for encapsulated multicast traffic. The RLOC addresses are the ones joined by remote multicast ETRs. When different (S-EID,G) traffic is combined into a single (RLOC,G) core distribution tree, this may cause traffic to go to a receiver multicast site when it does not need to. This happens when one receiver multicast site joins (S1-EID,Gi) through a core distribution tree of (RLOC1,Gi) and another multicast receiver site joins (S2- EID,Gi) through the same core distribution tree of (RLOC1,Gi). When ETRs decapsulate such traffic, they should know from their local (S-EID,G) state if the packet should be forwarded. If there is no (S-EID,G) state that matches the inner packet header, the packet is discarded. 8.2. ETR Forwarding Procedure The following procedure is used by an ETR, when it receives a multicast packet from a source outside of its site: 1. When a multicast data packet is received by an ETR on an external-facing interface, it will do an RPF lookup on the S-RLOC state it has stored. If the RPF check succeeds, the interfaces from the oif-list are used for replication to interfaces that are site-facing as well as interfaces that are external-facing (this ETR can also be a transit multicast router for receivers outside of its site). When the packet is to be replicated for an external-facing interface, the LISP encapsulation header are not stripped. When the packet is replicated for a site-facing interface, the encapsulation header is stripped. Farinacci, et al. Expires December 1, 2011 [Page 18] =0C Internet-Draft LISP for Multicast Environments May 2011 2. The packet without a LISP header is now forwarded down the (S-EID,G) distribution tree in the receiver multicast site. 8.3. Replication Locations Multicast packet replication can happen in the following topological locations: o In an IGP multicast router inside a site which operates on S-EIDs. o In a transit multicast router inside of the core which operates on S-RLOCs. o At one or more ETR routers depending on the path a Join/Prune message exits a receiver multicast site. o At one or more ITR routers in a source multicast site depending on what priorities are returned in a Map-Reply to receiver multicast sites. In the last case the source multicast site can do replication rather than having a single exit from the site. But this only can occur when the priorities in the Map-Reply are modified for different receiver multicast site so that the PIM Join/Prune messages arrive at different ITRs. This policy technique, also used in [ALT] for unicast, is useful for multicast to mitigate the problems of changing distribution tree state as discussed in Section 6. Farinacci, et al. Expires December 1, 2011 [Page 19] =0C Internet-Draft LISP for Multicast Environments May 2011 9. LISP-Multicast Interworking This section will describe the multicast corollary to [INTWORK] which describes the interworking of multicast routing among LISP and non- LISP sites. 9.1. LISP and non-LISP Mixed Sites Since multicast communication can involve more than two entities to communicate together, the combinations of interworking scenarios are more involved. However, the state maintained for distribution trees at the sites is the same regardless of whether or not the site is LISP enabled or not. So most of the implications are in the core with respect to storing routable EID prefixes from either PA or PI blocks. Before we enumerate the multicast interworking scenarios, we must define 3 deployment states of a site: o A non-LISP site which will run PIM-SSM or PIM-ASM with MSDP as it does today. The addresses for the site are globally routable. o A site that deploys LISP for unicast routing. The addresses for the site are not globally routable. Let's define the name for this type of site as a uLISP site. o A site that deploys LISP for both unicast and multicast routing. The addresses for the site are not globally routable. Let's define the name for this type of site as a LISP-Multicast site. We will not consider a LISP site enabled for multicast purposes only but do consider a uLISP site as documented in [INTWORK]. In this section we don't discuss how a LISP site sends multicast packets when all receiver sites are LISP-Multicast enabled; that has been discussed in previous sections. The following scenarios exist to make LISP-Multicast sites interwork with non-LISP-Multicast sites: 1. A LISP site must be able to send multicast packets to receiver sites which are a mix of non-LISP sites and uLISP sites. 2. A non-LISP site must be able to send multicast packets to receiver sites which are a mix of non-LISP sites and uLISP sites. 3. A non-LISP site must be able to send multicast packets to receiver sites which are a mix of LISP sites, uLISP sites, and non-LISP sites. Farinacci, et al. Expires December 1, 2011 [Page 20] =0C Internet-Draft LISP for Multicast Environments May 2011 4. A uLISP site must be able to send multicast packets to receiver sites which are a mix of LISP sites, uLISP sites, and non-LISP sites. 5. A LISP site must be able to send multicast packets to receiver sites which are a mix of LISP sites, uLISP sites, and non-LISP sites. 9.1.1. LISP Source Site to non-LISP Receiver Sites In the first scenario, a site is LISP capable for both unicast and multicast traffic and as such operates on EIDs. Therefore there is a possibility that the EID prefix block is not routable in the core. For LISP receiver multicast sites this isn't a problem but for non- LISP or uLISP receiver multicast sites, when a PIM Join/Prune message is received by the edge router, it has no route to propagate the Join/Prune message out of the site. This is no different than the unicast case that LISP-NAT in [INTWORK] solves. LISP-NAT allows a unicast packet that exits a LISP site to get its source address mapped to a globally routable address before the ITR realizes that it should not encapsulate the packet destined to a non- LISP site. For a multicast packet to leave a LISP site, distribution tree state needs to be built so the ITR can know where to send the packet. So the receiver multicast sites need to know about the multicast source host by its routable address and not its EID address. When this is the case, the routable address is the (S-RLOC,G) state that is stored and maintained in the core routers. It is important to note that the routable address for the host cannot be the same as an RLOC for the site because we want the ITRs to process a received PIM Join/Prune message from an external-facing interface to be propagated inside of the site so the site-part of the distribution tree is built. Using a globally routable source address allows non-LISP and uLISP multicast receiver to join, create, and maintain a multicast distribution tree. However, the LISP multicast receiver site will want to perform an EID-to-RLOC mapping table lookup when a PIM Join/ Prune message is received on a site-facing interface. It does this because it wants to find a (S-RLOC,G) entry to Join in the core. So we have a conflict of behavior between the two types of sites. The solution to this problem is the same as when an ITR wants to send a unicast packet to a destination site but needs determine if the site is LISP capable or not. When it is not LISP capable, the ITR does not encapsulate the packet. So for the multicast case, when ETR receives a PIM Join/Prune message for (S-EID,G) state, it will do a mapping table lookup on S-EID. In this case, S-EID is not in the Farinacci, et al. Expires December 1, 2011 [Page 21] =0C Internet-Draft LISP for Multicast Environments May 2011 mapping database because the source multicast site is using a routable address and not an EID prefix address. So the ETR knows to simply propagate the PIM Join/Prune message to a external-facing interface without converting the (S-EID,G) because it is an (S,G) where S is routable and reachable via core routing tables. Now that the multicast distribution tree is built and maintained from any non-LISP or uLISP receiver multicast site, the way packet forwarding model is performed can be explained. Since the ITR in the source multicast site has never received a unicast encapsulated PIM Join/Prune message from any ETR in a receiver multicast site, it knows there are no LISP-Multicast receiver sites. Therefore, there is no need for the ITR to encapsulate data. Since it will know a priori (via configuration) that its site's EIDs are not routable, it assumes that the multicast packets from the source host are sent by a routable address. That is, it is the responsibility of the multicast source host's system administrator to ensure that the source host sends multicast traffic using a routable source address. When this happens, the ITR acts simply as a router and forwards the multicast packet like an ordinary multicast router. There is an alternative to using a LISP-NAT scheme just like there is for unicast [INTWORK] forwarding by using Proxy Tunnel Routers (PxTRs). This can work the same way for multicast routing as well, but the difference is that non-LISP and uLISP sites will send PIM Join/Prune messages for (S-EID,G) which make their way in the core to multicast PxTRs. Let's call this use of a PxTR as a "Multicast Proxy-ETR" (or mPETR). Since the mPETRs advertise very coarse EID prefixes, they draw the PIM Join/Prune control traffic making them the target of the distribution tree. To get multicast packets from the LISP source multicast sites, the tree needs to be built on the path from the mPETR to the LISP source multicast site. To make this happen the mPETR acts as a "Proxy ETR" (where in unicast it acts as a "Proxy ITR", or an uPITR [INTWORK]). The existence of mPETRs in the core allows source multicast site ITRs to encapsulate multicast packets according to (S-RLOC,G) state. The (S-RLOC,G) state is built from the mPETRs to the multicast ITRs. The encapsulated multicast packets are decapsulated by mPETRs and then forwarded according to (S-EID,G) state. The (S-EID,G) state is built from the non-LISP and uLISP receiver multicast sites to the mPETRs. 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites Clearly non-LISP multicast sites can send multicast packets to non- LISP receiver multicast sites. That is what they do today. However, Farinacci, et al. Expires December 1, 2011 [Page 22] =0C Internet-Draft LISP for Multicast Environments May 2011 discussion is required to show how non-LISP multicast sites send multicast packets to uLISP receiver multicast sites. Since uLISP receiver multicast sites are not targets of any (S,G) state, they simply send (S,G) PIM Join/Prune messages toward the non- LISP source multicast site. Since the source multicast site, in this case has not been upgraded to LISP, all multicast source host addresses are routable. So this case is simplified to where a uLISP receiver multicast site looks to the source multicast site as a non- LISP receiver multicast site. 9.1.3. Non-LISP Source Site to Any Receiver Site When a non-LISP source multicast site has receivers in either a non- LISP/uLISP site or a LISP site, one needs to decide how the LISP receiver multicast site will attach to the distribution tree. We know from Section 9.1.2 that non-LISP and uLISP receiver multicast sites can join the distribution tree, but a LISP receiver multicast site ETR will need to know if the source address of the multicast source host is routable or not. We showed in Section 9.1.1 that an ETR, before it sends a PIM Join/Prune message on an external-facing interface, does a EID-to-RLOC mapping lookup to determine if it should convert the (S,G) state from a PIM Join/Prune message received on a site-facing interface to a (S-RLOC,G). If the lookup fails, the ETR can conclude the source multicast site is a non-LISP site so it simply forwards the Join/Prune message (it also doesn't need to send a unicast encapsulated Join/Prune message because there is no ITR in a non-LISP site and there is namespace continuity between the ETR and source). For a non-LISP source multicast site, (S-EID,G) state could be limited to the edges of the network with the use of multicast proxy- ITRs (mPITRs). The mPITRs can take native, unencapsulated multicast packets from non-LISP source multicast and uLISP sites and encapsulate them to ETRs in receiver multicast sites or to mPETRs that can decapsulate for non-LISP receiver multicast or uLISP sites. The mPITRs are responsible for sending (S-EID,G) joins to the non- LISP source multicast site. To connect the distribution trees together, multicast ETRs will need to be configured with the mPITR's RLOC addresses so they can send both (S-RLOC,G) joins to build a distribution tree to the mPITR as well as for sending unicast joins to mPITRs so they can propogate (S-EID,G) joins into source multicast sites. The use of mPITRs is undergoing more study and is work in progress. Farinacci, et al. Expires December 1, 2011 [Page 23] =0C Internet-Draft LISP for Multicast Environments May 2011 9.1.4. Unicast LISP Source Site to Any Receiver Sites In the last section, it was explained how an ETR in a multicast receiver site can determine if a source multicast site is LISP- enabled by looking into the mapping database. When the source multicast site is a uLISP site, it is LISP enabled but the ITR, by definition is not capable of doing multicast encapsulation. So for the purposes of multicast routing, the uLISP source multicast site is treated as non-LISP source multicast site. Non-LISP receiver multicast sites can join distribution trees to a uLISP source multicast site since the source site behaves, from a forwarding perspective, as a non-LISP source site. This is also the case for a uLISP receiver multicast site since the ETR does not have multicast functionality built-in or enabled. Special considerations are required for LISP receiver multicast sites since they think the source multicast site is LISP capable, the ETR cannot know if ITR is LISP-Multicast capable. To solve this problem, each mapping database entry will have a multicast 2-tuple (Mpriority, Mweight) per RLOC. When the Mpriority is set to 255, the site is considered not multicast capable. So an ETR in a LISP receiver multicast site can distinguish whether a LISP source multicast site is LISP-Multicast site from a uLISP site. 9.1.5. LISP Source Site to Any Receiver Sites When a LISP source multicast site has receivers in LISP, non-LISP, and uLISP receiver multicast sites, it has a conflict about how it sends multicast packets. The ITR can either encapsulate or natively forward multicast packets. Since the receiver multicast sites are heterogeneous in their behavior, one packet forwarding mechanism cannot satisfy both. However, if a LISP receiver multicast site acts like a uLISP site then it could receive packets like a non-LISP receiver multicast site making all receiver multicast sites have homogeneous behavior. However, this poses the following issues: o LISP-NAT techniques with routable addresses would be required in all cases. o Or alternatively, mPETR deployment would be required forcing coarse EID prefix advertisement in the core. o But what is most disturbing is that when all sites that participate are LISP-Multicast sites but then a non-LISP or uLISP site joins the distribution tree, then the existing joined LISP receiver multicast sites would have to change their behavior. This would create too much dynamic tree-building churn to be a Farinacci, et al. Expires December 1, 2011 [Page 24] =0C Internet-Draft LISP for Multicast Environments May 2011 viable alternative. So the solution space options are: 1. Make the LISP ITR in the source multicast site send two packets, one that is encapsulated with (S-RLOC,G) to reach LISP receiver multicast sites and another that is not encapsulated with (S-EID,G) to reach non-LISP and uLISP receiver multicast sites. 2. Make the LISP ITR always encapsulate packets with (S-RLOC,G) to reach LISP-Multicast sites and to reach mPETRs that can decapsulate and forward (S-EID,G) packets to non-LISP and uLISP receiver multicast sites. 9.2. LISP Sites with Mixed Address Families A LISP database mapping entry that describes the locator-set, Mpriority and Mweight per locator address (RLOC), for an EID prefix associated with a site could have RLOC addresses in either IPv4 or IPv6 format. When a mapping entry has a mix of RLOC formatted addresses, it is an implicit advertisement by the site that it is a dual-stack site. That is, the site can receive IPv4 or IPv6 unicast packets. To distinguish if the site can receive dual-stack unicast packets as well as dual-stack multicast packets, the Mpriority value setting will be relative to an IPv4 or IPv6 RLOC See [LISP] for packet format details. If you consider the combinations of LISP, non-LISP, and uLISP sites sharing the same distribution tree and considering the capabilities of supporting IPv4, IPv6, or dual-stack, the number of total combinations grows beyond comprehension. Using some combinatorial math, we have the following profiles of a site and the combinations that can occur: 1. LISP-Multicast IPv4 Site 2. LISP-Multicast IPv6 Site 3. LISP-Multicast Dual-Stack Site 4. uLISP IPv4 Site 5. uLISP IPv6 Site Farinacci, et al. Expires December 1, 2011 [Page 25] =0C Internet-Draft LISP for Multicast Environments May 2011 6. uLISP Dual-Stack Site 7. non-LISP IPv4 Site 8. non-LISP IPv6 Site 9. non-LISP Dual-Stack Site Lets define (m n) =3D m!/(n!*(m-n)!), pronounced "m choose n" to illustrate some combinatorial math below. When 1 site talks to another site, the combinatorial is (9 2), when 1 site talks to another 2 sites, the combinatorial is (9 3). If sum this up to (9 9), we have: (9 2) + (9 3) + (9 4) + (9 5) + (9 6) + (9 7) + (9 8) + (9 9) =3D 36 + 84 + 126 + 126 + 84 + 36 + 9 + 1 Which results in the total number of cases to be considered at 502. This combinatorial gets even worse when you consider a site using one address family inside of the site and the xTRs use the other address family (as in using IPv4 EIDs with IPv6 RLOCs or IPv6 EIDs with IPv4 RLOCs). To rationalize this combinatorial nightmare, there are some guidelines which need to be put in place: o Each distribution tree shared between sites will either be an IPv4 distribution tree or an IPv6 distribution tree. Therefore, we can avoid head-end replication by building and sending packets on each address family based distribution tree. Even though there might be an urge to do multicast packet translation from one address family format to the other, it is a non-viable over-complicated urge. Multicast ITRs will only encapsulate packets where the inner and outer headers are from the same address family. o All LISP sites on a multicast distribution tree must share a common address family which is determined by the source site's locator-set in its LISP database mapping entry. All receiver multicast sites will use the best RLOC priority controlled by the source multicast site. This is true when the source site is either LISP-Multicast or uLISP capable. This means that priority- based policy modification is prohibited. When a receiver multicast site ETR receives a (S-EID,G) join, it must select a S-RLOC for the same address family as S-EID. Farinacci, et al. Expires December 1, 2011 [Page 26] =0C Internet-Draft LISP for Multicast Environments May 2011 o A mixed multicast locator-set with the best multicast priority values MUST NOT be configured on multicast ITRs. A mixed locator- set can exist (for unicast use), but the multicast priorities MUST be the set for the same address family locators. o When the source site is not LISP capable, it is up to how receivers find the source and group information for a multicast flow. That mechanism decides the address family for the flow. 9.3. Making a Multicast Interworking Decision This Multicast Interworking section has shown all combinations of multicast connectivity that could occur. As you might have already concluded, this can be quite complicated and if the design is too ambitious, the dynamics of the protocol could cause a lot of instability. The trade-off decisions are hard to make and we want the same single solution to work for both IPv4 and IPv6 multicast. It is imperative to have an incrementally deployable solution for all of IPv4 unicast and multicast and IPv6 unicast and multicast while minimizing (or eliminating) both unicast and multicast EID namespace state. Therefore the design decision to go with uPITRs [INTWORK] for unicast routing and mPETRs for multicast routing seems to be the sweet spot in the solution space so we can optimize state requirements and avoid head-end data replication at ITRs. Farinacci, et al. Expires December 1, 2011 [Page 27] =0C Internet-Draft LISP for Multicast Environments May 2011 10. Considerations when RP Addresses are Embedded in Group Addresses When ASM and PIM-Bidir is used in an IPv6 inter-domain environment, a technique exists to embed the unicast address of an RP in a IPv6 group address [RFC3956]. When routers in end sites process a PIM Join/Prune message which contain an embedded-RP group address, they extract the RP address from the group address and treat it from the EID namespace. However, core routers do not have state for the EID namespace, need to extract an RP address from the RLOC namespace. Therefore, it is the responsibility of ETRs in multicast receiver sites to map the group address into a group address where the embedded-RP address is from the RLOC namespace. The mapped RP- address is obtained from a EID-to-RLOC mapping database lookup. The ETR will also send a unicast (*,G) Join/Prune message to the ITR so the branch of the distribution tree from the source site resident RP to the ITR is created. This technique is no different than the techniques described in this specification for translating (S,G) state and propagating Join/Prune messages into the core. The only difference is that the (*,G) state in Join/Prune messages are mapped because they contain unicast addresses encoded in an Embedded-RP group address. Farinacci, et al. Expires December 1, 2011 [Page 28] =0C Internet-Draft LISP for Multicast Environments May 2011 11. Taking Advantage of Upgrades in the Core If the core routers are upgraded to support [RPFV] and [RFC5496], then we can pass EID specific data through the core without, possibly, having to store the state in the core. By doing this we can eliminate the ETR from unicast encapsulating PIM Join/Prune messages to the source site's ITR. However, this solution is restricted to a small set of workable cases which would not be good for general use of LISP-Multicast. In addition due to slow convergence properties, it is not being recommended for LISP-Multicast. Farinacci, et al. Expires December 1, 2011 [Page 29] =0C Internet-Draft LISP for Multicast Environments May 2011 12. Mtrace Considerations Mtrace functionality must be consistent with unicast traceroute functionality where all hops from multicast receiver to multicast source are visible. The design for mtrace for use in LISP-Multicast environments is to be determined but should build upon the mtrace version 2 specified in [MTRACE]. Farinacci, et al. Expires December 1, 2011 [Page 30] =0C Internet-Draft LISP for Multicast Environments May 2011 13. Security Considerations Refer to the [LISP] specification. Farinacci, et al. Expires December 1, 2011 [Page 31] =0C Internet-Draft LISP for Multicast Environments May 2011 14. Acknowledgments The authors would like to gratefully acknowledge the people who have contributed discussion, ideas, and commentary to the making of this proposal and specification. People who provided expert review were Scott Brim, Greg Shepherd, and Dave Oran. Other commentary from discussions at Summer 2008 Dublin IETF were Toerless Eckert and Ijsbrand Wijnands. We would also like to thank the MBONED working group for constructive and civil verbal feedback when this draft was presented at the Fall 2008 IETF in Minneapolis. In particular, good commentary came from Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou, Ron Bonica, Lenny Guardino, Alia Atlas, and Jesus Arango. An expert review of this specification was done by Yiqun Cai and Liming Wei. We thank them for their detailed comments. This work originated in the Routing Research Group (RRG) of the IRTF. The individual submission [MLISP] was converted into this IETF LISP working group draft. Farinacci, et al. Expires December 1, 2011 [Page 32] =0C Internet-Draft LISP for Multicast Environments May 2011 15. References 15.1. Normative References [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-13.txt (work in progress), May 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source- Specific Multicast", RFC 4604, August 2006. [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR- PIM)", RFC 5015, October 2007. [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, March 2009. 15.2. Informative References [ALT] Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative Topology (LISP-ALT)", draft-ietf-lisp-alt-06.txt (work in progress), March 2011. [INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP Farinacci, et al. Expires December 1, 2011 [Page 33] =0C Internet-Draft LISP for Multicast Environments May 2011 with IPv4 and IPv6", draft-ietf-lisp-interworking-02.txt (work in progress), March 2011. [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "LISP for Multicast Environments", draft-farinacci-lisp-multicast-01.txt (work in progress), November 2008. [MNAT] Wing, D. and T. Eckert, "Multicast Requirements for a Network Address (and port) Translator (NAT)", draft-ietf-behave-multicast-07.txt (work in progress), June 2007. [MTRACE] Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace Version 2: Traceroute Facility for IP Multicast", draft-ietf-mboned-mtrace-v2-03.txt (work in progress), March 2009. [RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector TLV", draft-ietf-pim-rpf-vector-06.txt (work in progress), February 2008. Farinacci, et al. Expires December 1, 2011 [Page 34] =0C Internet-Draft LISP for Multicast Environments May 2011 Appendix A. Document Change Log A.1. Changes to draft-ietf-lisp-multicast-06.txt o Posted June 2011 to complete working group last call. o Added paragraph to section 8.1.2 based on Jesus comment about making it more clear what happens when two (S-EID,G) trees use the same (RLOC,G) tree. o Make more references to [INTWORK] when mentioning uPITRs and uPETRs. o Made many changes based on editorial and wordsmithing comments from Alia. A.2. Changes to draft-ietf-lisp-multicast-05.txt o Posted April 2011 to reset expiration timer. o Updated references. A.3. Changes to draft-ietf-lisp-multicast-04.txt o Posted October 2010 to reset expiration timer. o Updated references. A.4. Changes to draft-ietf-lisp-multicast-03.txt o Posted April 2010. o Added section 8.1.2 to address Joel Halpern's comment about receiver sites joining the same source site via 2 different RLOCs, each being a separate ITR. o Change all occurences of "mPTR" to "mPETR" to become more consistent with uPITRs and uPETRs described in [INTWORK]. That is, an mPETR is a LISP multicast router that decapsulates multicast packets that are encapsulated to it by ITRs in multicast source sites. o Add clarifications in section 9 about how homogeneous multicast encapsulation should occur. As well as describing in this section, how to deal with mixed-locator sets to avoid heterogeneous encapsulation. Farinacci, et al. Expires December 1, 2011 [Page 35] =0C Internet-Draft LISP for Multicast Environments May 2011 o Introduce concept of mPITRs to help reduce (S-EID,G) to the edges of LISP global multicast network. A.5. Changes to draft-ietf-lisp-multicast-02.txt o Posted September 2009. o Added Document Change Log appendix. o Specify that the LISP Encapsulated Control Message be used for unicasting PIM Join/Prune messages from ETRs to ITRs. A.6. Changes to draft-ietf-lisp-multicast-01.txt o Posted November 2008. o Specified that PIM Join/Prune unicast messages that get sent from ETRs to ITRs of a source multicast site get LISP encapsulated in destination UDP port 4342. o Add multiple RLOCs per ITR per Yiqun's comments. o Indicate how static RPs can be used when LISP is run using Bidir- PIM in the core. o Editorial changes per Liming comments. o Add Mttrace Considersations section. A.7. Changes to draft-ietf-lisp-multicast-00.txt o Posted April 2008. o Renamed from draft-farinacci-lisp-multicast-01.txt. Farinacci, et al. Expires December 1, 2011 [Page 36] =0C Internet-Draft LISP for Multicast Environments May 2011 Authors' Addresses Dino Farinacci cisco Systems Tasman Drive San Jose, CA USA Email: dino@cisco.com Dave Meyer cisco Systems Tasman Drive San Jose, CA USA Email: dmm@cisco.com John Zwiebel cisco Systems Tasman Drive San Jose, CA USA Email: jzwiebel@cisco.com Stig Venaas cisco Systems Tasman Drive San Jose, CA USA Email: stig@cisco.com Farinacci, et al. Expires December 1, 2011 [Page 37] =0C --Apple-Mail-21--1032660532 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jun 13, 2011, at 9:11 AM, Jesus Arango (jearango) wrote: > Dino, Terry, > > I had not responded because I must have missed the original May 30 > email. I can't find the copy. Could you please resend the attachments > and/or text that addresses the comments ? > > Thanks > Jesus > > -----Original Message----- > From: Terry Manderson [mailto:terry.manderson@icann.org] > Sent: Monday, June 13, 2011 2:29 AM > To: Dino Farinacci (dino) > Cc: Dino Farinacci (dino); David Meyer (dmm); Stig Venaas (svenaas); > Jesus Arango (jearango); lisp@ietf.org > Subject: Re: [lisp] Proposed changes for > draft-ietf-lisp-multicast-06.txt > > Alia and Jesus, > > Does the responses herein address your concerns? If not, why not? > > Cheers, > Terry > > On 13/06/2011, at 5:09 PM, "Dino Farinacci" wrote: > >> I would like to ask the chairs, as well as Alia and Jesus if I can >> post this update. >> >> This email was posted 2 weeks ago and no replies were received. >> >> Dino >> >> On May 30, 2011, at 8:50 PM, Dino Farinacci wrote: >> >>> We have received WG last call comments on the LISP-multicast draft >>> from Jesus Arango and Alia Atlas. See enclosed our responses and a >>> proposed updated draft and html diff file. >>> >>> Jesus comments: >>> >>>> 1. Cross-talk duplication of multicast flows when using multiple >>>> RLOCS: >>>> Consider two receiver sites A and B with the following mappings: >>>> >>>> Site A: >>>> (S1, G) --> (RLOC1, G) >>>> (S2, G) --> (RLOC2, G) >>>> Site B: >>>> (S1, G) --> (RLOC2, G) >>>> >>>> This would cause Site A to receive duplicate packets for (S1,G). >>>> One copy >>>> would be encapsulated with source RLOC1 while the second copy will > be >>> >>> All sites are suppose to hash to the same RLOC for a given (S- >>> EID,G). So Site B would use (RLOC1,G) as would Site A. >>> >>>> encapsulated with source RLOC2. There are multiple ways to address >>>> this >>>> issue: >>>> >>>> a. Perform neighbor verification as part of RPF check. This seemed >>>> obvious >>>> but it is worth noting that to my understanding this is not done in >>>> IOS. Can >>>> folks comment on why this is not done today? What is the viability >>>> of doing >>>> this? What is the current behavior in non-IOS platforms ? >>>> b. Use a single RLOC for multicast >>>> c. Anycast RLOC >>>> d. Propose a group-to-RLOC hashing mechanism where the hashing >>>> function >>>> dynamically adapts to addition/deletion of RLOCS while minimizing >>>> the impact >>>> on flows that are already stablished. >>> >>> What will happen is that if (S1,G) and (S2,G) map to core >>> distribution tree (RLOC2,G) then Site B will get packets for no >>> receivers. I have added a paragraph to section 8.1.2 to make this >>> clear. >>> >>> Alia comments: >>> >>>> What I most want to see in this draft is a clear description of >>>> what >>>> needs to implemented and how. It gives a good survey of the >>>> architectural possibilities and even makes suggestions at the end - >>>> but not quite sufficient to be clear in the details of what needs >>>> to >>>> be implemented for interoperability and what is for future >>>> experimentation. >>> >>> Everything in the spec needs to be implemented. Why would you think >>> differently? >>> >>>> a) Could you add a definition for uPITR? It is first used on p.9 >>>> in >>>> the mPETR definition and only on p. 22 is it described as >>>> "(where in unicast it acts as a "Proxy ITR", or an uPITR)" >>> >>> I do not want to duplicate the definition from the Interworking >>> spec. I will add a reference though. >>> >>>> b) Sec 4, second paragraph: "At this point in time, we don't see a >>>> requirement for different locator-sets, priority, and weight > policies >>>> for multicast than we have for unicast." but there is an M >>>> Priority >>>> and M Weight in the [LISP] draft. Clarification as to why would be >>>> useful... (I know it is to get the RLOCs of the ITRs which >>>> shouldn't >>>> be used for unicast traffic.) >>> >>> I added a sentence. >>> >>>> I don't see a mechanism other than the M Priority to obtain the > RLOCs >>>> associated with an ITR - since only ETR RLOCs would normally be >>>> included. >>> >>> I don't understand the comment. There is one locator-set, and the >>> RLOCs for encapsulating unicast packets to and the RLOCs for sending >>> multicast join messages to can be a different set within the >>> locator- >>> set. >>> >>>> What would be good to add to the draft is the changes to be made to >>>> information such as the Map-Reply messages. E.g. >>>> Set the M Priority for all ETR RLOCs to be 255 >>>> Add the ITR RLOCs and set the Priority to 255 & the M Priority to >>>> something else. >>> >>> They are the same locators. The xTR has one locator-set, the RLOCs >>> are used as a destination for unicast packets or for a destination >>> for multicast joins. >>> >>>> c) What happens if the S-EID and S-RLOC collide? In particular, at >>> >>> You have to be more specific on what you mean here. >>> >>>> the ETR and ITR, it seems useful to specify that the xTR has >>>> knowledge >>>> of whether the packet was LISP-encapsulated & forwards it either to >>>> receivers that expect it un-LISP-encapsulated (ETR) or to receivers >>>> that expect it LISP-encapsulated (ITR). >>> >>> An EID and RLOC can have the same value just like in the unicast >>> scenario. >>> >>>> d) p. 15 end of MSDP: >>>> "And the choice can be made unilaterally because the ITR at the >>>> site will determine which namespace the destination peer address is >>>> out of by looking in the mapping database service." >>>> >>>> Is there an assumption in LISP that an EID and an RLOC MUST NOT >>>> have >>>> the same value?? I've seen this potentially implied, but not >>>> proscriptively stated. >>> >>> There is not architectural. >>> >>>> e) p. 22 first paragraph: >>>> "So the ETR knows to simply propagate the PIM Join/Prune message to >>>> a external-facing interface without converting the (S-EID,G) >>>> because >>>> it is an (S,G) where S is routable and reachable via core routing >>>> tables." >>>> >>>> In [INTWRK], it is clear that an EID may be globally routable. >>>> This >>>> creates a conflict here, where there is an assumption that if an IP >>>> address is globally routable, then it is not in the EID/RLOC >>>> mapping >>>> database. >>> >>> The text says: >>> >>> In this case, S-EID is not in the >>> >>> Farinacci, et al. Expires December 1, 2011 [Page >>> 21] >>> Internet-Draft LISP for Multicast Environments May >>> 2011 >>> >>> >>> mapping database because the source multicast site is using a >>> routable address and not an EID prefix address. So the ETR knows to >>> simply propagate the PIM Join/Prune message to a external-facing >>> interface without converting the (S-EID,G) because it is an (S,G) >>> where S is routable and reachable via core routing tables. >>> >>> So the ETR knows because "there is no mapping database entry and the >>> S-EID is routable". >>> >>>> Couldn't a more specific check be done along the lines of: >>>> if the S-EID is reachable via core routing and >>>> i) it is not in the mapping database or >>>> ii) it is in the mapping database, but there are no RLOCs with >>>> an M Priority other than 255? >>>> >>>> f) Text in 9.1.1, 9.1.2 doesn't match the headings well. For >>>> instance, in 9.1.1, there is discussion of how a LISP source site >>>> that >>>> sends to non-LISP or uLISP receiver sites also can send to LISP >>>> receiver sites. >>> >>> They actually are correct, but the first start out saying how the >>> trees are built from the receiver side so that text can support the >>> data-flow description that comes later. >>> >>>> In 9.1.2, maybe renaming it to non-mLISP Receiver Sites would be >>>> clearer? >>> >>> We stated up from the definition of a non-LISP receiver site. >>> Creating a new term would add to the number of combinations. The >>> spec doesn't need that extra complexity. >>> >>>> g) In 9.1.4, Mpriority and Mweight are finally mentioned - but as > far >>>> as I can tell, they are needed earlier and for the pure mLISP to >>>> mLISP >>>> case. Please pull the discussion of this earlier. >>> >>> Can you be more specific please. >>> >>>> Also, this case is discussed in 9.1.1 last paragraph on p. 21 - but >>>> claimed that it is sufficient to look in the mapping database. > Could >>>> you please combine these and bring more consistency to the draft? >>> >>> Combine what? Please be more specific. >>> >>>> h) In 9.1.5, is it possible to make a recommendation (e.g. an ITR >>>> SHOULD be able to send two packets based on what its oif-lists are? >>> >>> No, we want to leave it up to the implementation. >>> >>>> Isn't this already the case because the mLISP ITR could have >>>> internal-facing entries in the (S-EID,G) that need to be replicated >>>> without encapsulation and external-facing entries in the (S-RLOC, >>>> G) >>>> that need encapsulation? >>> >>> Yes, but those forwarding rules are up to the multicast routing >>> protocol run in the site. That is, if your comment is to document >>> this. >>> >>>> I understand that this isn't ideal because multiple copies of data >>>> are >>>> going into the core - but the trees are different there too. >>> >>> Which trees are different? >>> >>>> What I'm looking for is some normative text about what MUST/SHOULD > be >>>> supported - even for experimental interoperability. >>> >>> If there are mPETRs deployed an ITR can use option 2. If not, option >>> 1 is the only option. >>> >>>> The second option seems like it comes naturally - if a Join comes > for >>>> the (S-RLOC, G), then it is sent the encapsulated packet. >>> >>> Right, if joins come from the mPETRs. >>> >>>> g) p. 21 Sec 9.1.1 end of second paragraph: >>>> "It is important to note that the routable address for the host >>>> cannot >>>> be the same as an RLOC for the site. Because we want the ITRs to >>>> process a received PIM Join/Prune message from an external-facing >>>> interface to be propagated inside of the site so the site-part of >>>> the >>>> distribution tree is built." >>>> Is this supposed to be one sentence?? >>> >>> I fixed it up a bit. Thanks. >>> >>>> h) typo: p. 9 mPETR definition, last sentence: "co-loacted" -> co- >>>> located >>>> >>>> i) typo: p. 23 4th line from bottom: "oins to" -> joins to >>>> >>>> j) typo: p.27 first sentence: "MUST not" -> MUST NOT >>>> >>>> k) typo: Sec 11 last sentence: "addition to slow" -> "addition due >>>> to slow" >>>> >>>> l) [LISP] needs to be Normative - it has the packet formats! >>> >>> Fixed all these. Thanks. >>> >>> Thanks, >>> Dino/Dave/Stig/JohnZ >>> >>> >> ietf-lisp-multicast-06.txt>>> attachment.txt> >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail-21--1032660532-- From jmh@joelhalpern.com Mon Jun 13 11:15:56 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA6011E816C; Mon, 13 Jun 2011 11:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4RO1m0y7jew; Mon, 13 Jun 2011 11:15:55 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id 8E49311E813F; Mon, 13 Jun 2011 11:15:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id A14E43246437; Mon, 13 Jun 2011 11:15:53 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.35.166.101] (JMHWork.dhcp.nanog.merit.net [192.35.166.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 2A80032463A5; Mon, 13 Jun 2011 11:15:53 -0700 (PDT) Message-ID: <4DF653D7.2020205@joelhalpern.com> Date: Mon, 13 Jun 2011 14:15:51 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "lisp@ietf.org" , "karp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] Fwd: Nomcom 2011-12: Call for Volunteers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2011 18:15:56 -0000 Please consider volunterring for the nominating comittee. Thank you, Joel -------- Original Message -------- Subject: Nomcom 2011-12: Call for Volunteers Date: Fri, 10 Jun 2011 19:56:06 -0700 (PDT) From: NomCom Chair To: IETF Announcement list The IETF nominating committee process for 2011-12 has begun. The IETF nominating committee appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. The 10 nominating committee members are selected randomly from a pool of volunteers. The more volunteers, the better the chance we have of choosing a random yet representative cross section of the IETF population. The details of the nomcom process can be found in RFC 3777. To be eligible, volunteers for the nomcom need to have attended 3 of the past 5 IETF meetings as of the time this announcement goes out (i.e. IETF76-IETF80). If you qualify, and are not seeking appointment to any of the open positions this nomcom will be filling, please consider volunteering. The list of people and posts whose terms end with the March 2012 IETF meeting, and thus the positions for which the nominating committee is responsible, are as follows: IAB === Bernard Aboba Hannes Tschofenig Andrei Robachevsky Olaf Kolkman Spencer Dawkins Ross Callon IAOC ==== Marshall Eubanks IESG ==== Peter Saint-Andre (Applications) Jari Arkko (Internet) Dan Romascanu (Operations & Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) David Harrington (Transport) The primary activity for this nomcom will begin during IETF-81 in Quebec City and should be completed by January 2012. The nomcom will be collecting requirements from the community, as well as talking to candidates and to community members about candidates. There will be regularly scheduled conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. Please volunteer by sending an email to me before 11:59 pm EDT July 10, 2011 as follows: To: suresh.krishnan@ericsson.com Subject: Nomcom 2011-12 Volunteer Please include the following information in the body of the mail: Full Name: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name Current Primary Affiliation: // typically what goes in the Company // field in the IETF Registration Form Email Address(es): // all email addresses used to Register for the // past 5 IETF meetings // Please designate a Preferred email address for // contact if there is more than one email address Telephone number: // With country code (for confirmation if selected) Please expect an email response from me within 3 business days stating whether or not you are qualified. If you do not receive a response in this timeframe, please re-send your email with the tag "RESEND:" added to the subject line. If you are not yet sure you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing in that direction. I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process within the next few days. Thank you in advance for your participation. Suresh Krishnan Nomcom Chair 2011-2012 Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From akatlas@gmail.com Mon Jun 13 14:41:22 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F4C11E80AC for ; Mon, 13 Jun 2011 14:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLMlvossy3-9 for ; Mon, 13 Jun 2011 14:41:21 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 172D811E80A1 for ; Mon, 13 Jun 2011 14:41:21 -0700 (PDT) Received: by pxi20 with SMTP id 20so3674138pxi.27 for ; Mon, 13 Jun 2011 14:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PkRMZe9JVxGrOvcQotarN7SXMTKICT1tGPMxPkP3+9c=; b=MDtOMCZL2JnGP3n+0wrrukEgm0gUDoWldobQ7OO6wbb/FIskjarWmk7/81HgP1gd63 41rlH4SmVcqZ2C89pfgwm0rqeyjBecNUNSpbYLrxB30EmhW9+f4e7yV6p1sQYqBBlkPT EAzlpfwm6OeWnqJFHK/0JGIgQZtG5dPg4EpEU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KVYhRFm46arhs8yAOHcfhd6EZCVb1PsJEL2YTUzOSTFW2W2b7hylycjZJ4FURRX58D X/E7YT81favyvqbowymX0bDkM0UUIFcB1ZUBuDLFvAWR1QV0lIZRenpMNW5tlFq8ZkeZ YvdeT6e7uwzx8IERgjmqC0uVp38dd3E1Tr3UU= MIME-Version: 1.0 Received: by 10.68.13.73 with SMTP id f9mr2614037pbc.100.1308001280462; Mon, 13 Jun 2011 14:41:20 -0700 (PDT) Received: by 10.68.46.98 with HTTP; Mon, 13 Jun 2011 14:41:20 -0700 (PDT) In-Reply-To: <4099FE40-80F6-4E32-848C-C33990DB1343@cisco.com> References: <4099FE40-80F6-4E32-848C-C33990DB1343@cisco.com> Date: Mon, 13 Jun 2011 17:41:20 -0400 Message-ID: From: Alia Atlas To: Dino Farinacci Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Stig Venaas , Jesus Arango , lisp@ietf.org, David Meyer Subject: Re: [lisp] Proposed changes for draft-ietf-lisp-multicast-06.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2011 21:41:22 -0000 Dino, Comments are in-line On Mon, May 30, 2011 at 11:50 PM, Dino Farinacci wrote: > Alia comments: > >> What I most want to see in this draft is a clear description of what >> needs to implemented and how. =A0It gives a good survey of the >> architectural possibilities and even makes suggestions at the end - >> but not quite sufficient to be clear in the details of what needs to >> be implemented for interoperability and what is for future >> experimentation. > > Everything in the spec needs to be implemented. Why would you think > differently? There are places in the text where the phrasing is very unclear - for just = the first instance, there is the last paragraph in Sec 4: "There is a possible solution to this problem which reduces the number of many-to-one occurrences of (S-EID,G) entries aggregating into a single (S-RLOC,G) entry. If a physical ITR can be assigned multiple RLOC addresses and these addresses are advertised in mapping database entries, then ETRs at receiver sites have more RLOC address options and therefore can join different (RLOC,G) entries for each (S-EID,G) entry joined at the receiver site. It would not scale to have a one- to-one relationship between the number of S-EID sources at a source site and the number of RLOCs assigned to all ITRs at the site, but we can reduce the "n" to a smaller number in the "n-to-1" relationship. And in turn, reduce the opportunity for data packets to be delivered to sites for groups not joined." This doesn't give a way to force all receiver sites to select the same (RLOC,G) for a given (S-EID,G) as you replied was necessary to Jesus' comments. I can go through the draft again for each example - but phrasing of "it is possible", "a potential solution", "one approach", etc. do not indicate a requirement to implement for interoperability. >> a) Could you add a definition for uPITR? =A0It is first used on p.9 in >> the mPETR definition and only on p. 22 is it described as >> =A0"(where in unicast it acts as a "Proxy ITR", or an uPITR)" > > I do not want to duplicate the definition from the Interworking spec. I w= ill > add a reference though. Looks good >> b) Sec 4, second paragraph: "At this point in time, we don't see a >> requirement for different locator-sets, priority, and weight policies >> for multicast than we have for unicast." =A0but there is an M Priority >> and M Weight in the [LISP] draft. =A0Clarification as to why would be >> useful... (I know it is to get the RLOCs of the ITRs which shouldn't >> be used for unicast traffic.) > > I added a sentence. > >> I don't see a mechanism other than the M Priority to obtain the RLOCs >> associated with an ITR - since only ETR RLOCs would normally be >> included. > > I don't understand the comment. There is one locator-set, and the RLOCs f= or > encapsulating unicast packets to and the RLOCs for sending multicast join > messages to can be a different set within the locator-set. Ok - let me clarify. The set of RLOCs in a locator-set, until this draft, are for the ETR. For multicast, the set of RLOCs required must be for the ITR. IF the ITR and ETR are different, there must be a way of telling which RLOCs belong to an ITR and which belong to an ETR. The ONLY way that I can find to do this is from the M Priority and the Priority fields. If you intend that RLOCs with a priority=3D255 are assumed to be RLOCs associated with ITRs, then that should be clearly stated. I certainly assumed not - there can be reasons to have an inactive RLOC, as I understand it. >> What would be good to add to the draft is the changes to be made to >> information such as the Map-Reply messages. =A0E.g. >> =A0Set the M Priority for all ETR RLOCs to be 255 >> =A0Add the ITR RLOCs and set the Priority to 255 & the M Priority to >> =A0something else. > > They are the same locators. The xTR has one locator-set, the RLOCs are us= ed > as a destination for unicast packets or for a destination for multicast > joins. The unicast traffic needs to go to ETRs. The multicast traffic needs to go to ITRs. My understanding is that these can be deployed separately. If this is not the case for multicast, then that should certainly be stated! >> c) What happens if the S-EID and S-RLOC collide? =A0In particular, at > > You have to be more specific on what you mean here. Can an S-EID and an S-RLOC have the same value? If not, why not? >> the ETR and ITR, it seems useful to specify that the xTR has knowledge >> of whether the packet was LISP-encapsulated & forwards it either to >> receivers that expect it un-LISP-encapsulated (ETR) or to receivers >> that expect it LISP-encapsulated (ITR). If an S-EID and S-RLOC have the same value, what helps disambiguate them in a received multicast packet is whether the packet was LISP-encapsulated. > An EID and RLOC can have the same value just like in the unicast scenario= . That is what I initially assumed - but there are places in the drafts where it is assumed that one can tell an EID from an RLOC without any additional information or look-ups. I tried to pull them out in my comments and mentioned this as a general concern. >> d) p. 15 end of MSDP: >> =A0"And the choice can be made unilaterally because the ITR at the >> =A0site will determine which namespace the destination peer address is >> =A0out of by looking in the mapping database service." >> >> Is there an assumption in LISP that an EID and an RLOC MUST NOT have >> the same value?? =A0I've seen this potentially implied, but not >> proscriptively stated. > > There is not architectural. So how can the ITR determine which namespace the destination peer address i= s out of by looking in the mapping database service?? >> e) p. 22 first paragraph: >> =A0"So the ETR knows to simply propagate the PIM Join/Prune message to >> =A0a external-facing interface without converting the (S-EID,G) because >> =A0it is an (S,G) where S is routable and reachable via core routing >> =A0tables." >> >> In [INTWRK], it is clear that an EID may be globally routable. =A0This >> creates a conflict here, where there is an assumption that if an IP >> address is globally routable, then it is not in the EID/RLOC mapping >> database. > > The text says: > > =A0In this case, S-EID is not in the > > Farinacci, et al. =A0 =A0 =A0 Expires December 1, 2011 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 [Page 21] > Internet-Draft =A0 =A0 =A0 LISP for Multicast Environments =A0 =A0 =A0 = =A0 =A0 =A0May 2011 > > > =A0 mapping database because the source multicast site is using a > =A0 routable address and not an EID prefix address. =A0So the ETR knows t= o > =A0 simply propagate the PIM Join/Prune message to a external-facing > =A0 interface without converting the (S-EID,G) because it is an (S,G) > =A0 where S is routable and reachable via core routing tables. > > So the ETR knows because "there is no mapping database entry and the S-EI= D > is routable". But in [INTWRK}, the same IP address can be globally routable AND appear in the mapping database. Also, how does the ETR know that the S-EID is routable - by getting a negat= ive Map-Reply? Statements like that of "is using a routable address and not an EID prefix address" without any further hints imply that there isn't overlap of addresses. >> Couldn't a more specific check be done along the lines of: >> =A0if the S-EID is reachable via core routing and >> =A0 =A0 =A0i) it is not in the mapping database or >> =A0 =A0 =A0ii) it is in the mapping database, but there are no RLOCs wit= h >> =A0 =A0 =A0 =A0 =A0an M Priority other than 255? >> >> f) Text in 9.1.1, 9.1.2 doesn't match the headings well. =A0For >> instance, in 9.1.1, there is discussion of how a LISP source site that >> sends to non-LISP or uLISP receiver sites also can send to LISP >> receiver sites. > > They actually are correct, but the first start out saying how the trees a= re > built from the receiver side so that text can support the data-flow > description that comes later. > >> In 9.1.2, maybe renaming it to non-mLISP Receiver Sites would be >> clearer? > > We stated up from the definition of a non-LISP receiver site. Creating a = new > term would add to the number of combinations. The spec doesn't need that > extra complexity. > >> g) In 9.1.4, Mpriority and Mweight are finally mentioned - but as far >> as I can tell, they are needed earlier and for the pure mLISP to mLISP >> case. =A0Please pull the discussion of this earlier. > > Can you be more specific please. Please look at my comment (b) and further elaboration there. I think Mpriority is needed to find the RLOCs associated with an ITR. >> Also, this case is discussed in 9.1.1 last paragraph on p. 21 - but >> claimed that it is sufficient to look in the mapping database. =A0Could >> you please combine these and bring more consistency to the draft? > > Combine what? Please be more specific. How much more specific than the exact sections and paragraphs do you need? >> h) In 9.1.5, is it possible to make a recommendation (e.g. an ITR >> SHOULD be able to send two packets based on what its oif-lists are? > > No, we want to leave it up to the implementation. So both solutions must be implemented (see your response to my first question), configured, and managed??? Why? How will there be interoperable implementations? >> Isn't this already the case because the mLISP ITR could have >> internal-facing entries in the (S-EID,G) that need to be replicated >> without encapsulation and external-facing entries in the (S-RLOC, G) >> that need encapsulation? > > Yes, but those forwarding rules are up to the multicast routing protocol = run > in the site. That is, if your comment is to document this. So - clarity of understanding what needs to be done and ITR behavior is goo= d. Yes, please document this. As phrased, there's the appearance that an ITR doesn't normally need to duplicate packets. >> I understand that this isn't ideal because multiple copies of data are >> going into the core - but the trees are different there too. > > Which trees are different? The ones referred to in sec 9.1.5: " 1. Make the LISP ITR in the source multicast site send two packets, one that is encapsulated with (S-RLOC,G) to reach LISP receiver multicast sites and another that is not encapsulated with (S-EID,G) to reach non-LISP and uLISP receiver multicast sites." >> What I'm looking for is some normative text about what MUST/SHOULD be >> supported - even for experimental interoperability. > > If there are mPETRs deployed an ITR can use option 2. If not, option 1 is > the only option. So - why not require option 1 to be implemented? Is it a requirement to su= pport mPETRs? >> The second option seems like it comes naturally - if a Join comes for >> the (S-RLOC, G), then it is sent the encapsulated packet. > > Right, if joins come from the mPETRs. Regardless of where the join came from... Otherwise, how does the ITR know that the join is from an mPETR Alia >> g) p. 21 Sec 9.1.1 end of second paragraph: >> =A0"It is important to note that the routable address for the host canno= t >> =A0be the same as an RLOC for the site. =A0Because we want the ITRs to >> =A0process a received PIM Join/Prune message from an external-facing >> =A0interface to be propagated inside of the site so the site-part of the >> =A0distribution tree is built." >> Is this supposed to be one sentence?? > > I fixed it up a bit. Thanks. > >> h) typo: p. 9 mPETR definition, last sentence: =A0"co-loacted" -> co-loc= ated >> >> i) typo: p. 23 4th line from bottom: "oins to" -> joins to >> >> j) typo: p.27 first sentence: "MUST not" -> MUST NOT >> >> k) typo: Sec 11 last sentence: "addition to slow" -> "addition due to >> slow" >> >> l) [LISP] needs to be Normative - it has the packet formats! > > Fixed all these. Thanks. > > Thanks, > Dino/Dave/Stig/JohnZ > > > > > > > > > > > > > From akatlas@gmail.com Mon Jun 13 14:42:48 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D7911E80AC for ; Mon, 13 Jun 2011 14:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPFBCL3VpVnD for ; Mon, 13 Jun 2011 14:42:47 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 13CD011E80A1 for ; Mon, 13 Jun 2011 14:42:47 -0700 (PDT) Received: by pvh18 with SMTP id 18so2528198pvh.31 for ; Mon, 13 Jun 2011 14:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XXcF3qFh0Ab5gnhH1Gr5/r2rncx/zxPnf2JD8BrzXgw=; b=Q4Fvhzs9fQPITSv5UEJKAySJrqDoqLANinaZDMkexMyIzQWuv7QUn+iiVyO+UrurPA yNunAXuf9g5iLiEFFf2vkPjMFli0w7HIzH1V5p9c3J8n5ns1zn/ywJi6PFTF0PFuVSXH cmLECfWOK2/ArnLVZIVbjLFCQ90w/FjI5w59U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gndarF6gVPgTQ+KnPRsf+P4mkkM3nWHRezuFx2ZDhywYlPS1T5lUk3/fxOR7juPFoR KB8yB3AQqNcuhLMd8azZrkxC+0DX0LIiB6Pndji1w1hP3OA0eLT6hT8pyAkg63p+B5+r AxHCr7cCHPGchgo56pz67+0X7AaLgcCWeDnKM= MIME-Version: 1.0 Received: by 10.68.5.164 with SMTP id t4mr2603688pbt.167.1308001366725; Mon, 13 Jun 2011 14:42:46 -0700 (PDT) Received: by 10.68.46.98 with HTTP; Mon, 13 Jun 2011 14:42:46 -0700 (PDT) In-Reply-To: <393A16E6-DCC4-4370-96E7-DC8364DECD3F@icann.org> References: <4099FE40-80F6-4E32-848C-C33990DB1343@cisco.com> <96A53C26-D89A-4606-97F1-209D40ACDD82@cisco.com> <393A16E6-DCC4-4370-96E7-DC8364DECD3F@icann.org> Date: Mon, 13 Jun 2011 17:42:46 -0400 Message-ID: From: Alia Atlas To: Terry Manderson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Stig Venaas , David Meyer , Jesus Arango , "lisp@ietf.org" Subject: Re: [lisp] Proposed changes for draft-ietf-lisp-multicast-06.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2011 21:42:48 -0000 Sorry for the delay in responding. I've sent more detailed responses - but in general, I feel that more work is needed to address my concerns. Alia On Mon, Jun 13, 2011 at 5:29 AM, Terry Manderson wrote: > Alia and Jesus, > > Does the responses herein address your concerns? If not, why not? > > Cheers, > Terry > > On 13/06/2011, at 5:09 PM, "Dino Farinacci" wrote: > >> I would like to ask the chairs, as well as Alia and Jesus if I can >> post this update. >> >> This email was posted 2 weeks ago and no replies were received. >> >> Dino >> >> On May 30, 2011, at 8:50 PM, Dino Farinacci wrote: >> >>> We have received WG last call comments on the LISP-multicast draft >>> from Jesus Arango and Alia Atlas. See enclosed our responses and a >>> proposed updated draft and html diff file. >>> >>> Jesus comments: >>> >>>> 1. Cross-talk duplication of multicast flows when using multiple >>>> RLOCS: >>>> Consider two receiver sites A and B with the following mappings: >>>> >>>> Site A: >>>> (S1, G) --> (RLOC1, G) >>>> (S2, G) --> (RLOC2, G) >>>> Site B: >>>> (S1, G) --> (RLOC2, G) >>>> >>>> This would cause Site A to receive duplicate packets for (S1,G). >>>> One copy >>>> would be encapsulated with source RLOC1 while the second copy will be >>> >>> All sites are suppose to hash to the same RLOC for a given (S- >>> EID,G). So Site B would use (RLOC1,G) as would Site A. >>> >>>> encapsulated with source RLOC2. There are multiple ways to address >>>> this >>>> issue: >>>> >>>> a. Perform neighbor verification as part of RPF check. This seemed >>>> obvious >>>> but it is worth noting that to my understanding this is not done in >>>> IOS. Can >>>> folks comment on why this is not done today? What is the viability >>>> of doing >>>> this? What is the current behavior in non-IOS platforms ? >>>> b. Use a single RLOC for multicast >>>> c. Anycast RLOC >>>> d. Propose a group-to-RLOC hashing mechanism where the hashing >>>> function >>>> dynamically adapts to addition/deletion of RLOCS while minimizing >>>> the impact >>>> on flows that are already stablished. >>> >>> What will happen is that if (S1,G) and (S2,G) map to core >>> distribution tree (RLOC2,G) then Site B will get packets for no >>> receivers. I have added a paragraph to section 8.1.2 to make this >>> clear. >>> >>> Alia comments: >>> >>>> What I most want to see in this draft is a clear description of what >>>> needs to implemented and how. =A0It gives a good survey of the >>>> architectural possibilities and even makes suggestions at the end - >>>> but not quite sufficient to be clear in the details of what needs to >>>> be implemented for interoperability and what is for future >>>> experimentation. >>> >>> Everything in the spec needs to be implemented. Why would you think >>> differently? >>> >>>> a) Could you add a definition for uPITR? =A0It is first used on p.9 in >>>> the mPETR definition and only on p. 22 is it described as >>>> "(where in unicast it acts as a "Proxy ITR", or an uPITR)" >>> >>> I do not want to duplicate the definition from the Interworking >>> spec. I will add a reference though. >>> >>>> b) Sec 4, second paragraph: "At this point in time, we don't see a >>>> requirement for different locator-sets, priority, and weight policies >>>> for multicast than we have for unicast." =A0but there is an M Priority >>>> and M Weight in the [LISP] draft. =A0Clarification as to why would be >>>> useful... (I know it is to get the RLOCs of the ITRs which shouldn't >>>> be used for unicast traffic.) >>> >>> I added a sentence. >>> >>>> I don't see a mechanism other than the M Priority to obtain the RLOCs >>>> associated with an ITR - since only ETR RLOCs would normally be >>>> included. >>> >>> I don't understand the comment. There is one locator-set, and the >>> RLOCs for encapsulating unicast packets to and the RLOCs for sending >>> multicast join messages to can be a different set within the locator- >>> set. >>> >>>> What would be good to add to the draft is the changes to be made to >>>> information such as the Map-Reply messages. =A0E.g. >>>> Set the M Priority for all ETR RLOCs to be 255 >>>> Add the ITR RLOCs and set the Priority to 255 & the M Priority to >>>> something else. >>> >>> They are the same locators. The xTR has one locator-set, the RLOCs >>> are used as a destination for unicast packets or for a destination >>> for multicast joins. >>> >>>> c) What happens if the S-EID and S-RLOC collide? =A0In particular, at >>> >>> You have to be more specific on what you mean here. >>> >>>> the ETR and ITR, it seems useful to specify that the xTR has >>>> knowledge >>>> of whether the packet was LISP-encapsulated & forwards it either to >>>> receivers that expect it un-LISP-encapsulated (ETR) or to receivers >>>> that expect it LISP-encapsulated (ITR). >>> >>> An EID and RLOC can have the same value just like in the unicast >>> scenario. >>> >>>> d) p. 15 end of MSDP: >>>> "And the choice can be made unilaterally because the ITR at the >>>> site will determine which namespace the destination peer address is >>>> out of by looking in the mapping database service." >>>> >>>> Is there an assumption in LISP that an EID and an RLOC MUST NOT have >>>> the same value?? =A0I've seen this potentially implied, but not >>>> proscriptively stated. >>> >>> There is not architectural. >>> >>>> e) p. 22 first paragraph: >>>> "So the ETR knows to simply propagate the PIM Join/Prune message to >>>> a external-facing interface without converting the (S-EID,G) because >>>> it is an (S,G) where S is routable and reachable via core routing >>>> tables." >>>> >>>> In [INTWRK], it is clear that an EID may be globally routable. =A0This >>>> creates a conflict here, where there is an assumption that if an IP >>>> address is globally routable, then it is not in the EID/RLOC mapping >>>> database. >>> >>> The text says: >>> >>> In this case, S-EID is not in the >>> >>> Farinacci, et al. =A0 =A0 =A0 Expires December 1, 2011 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 [Page >>> 21] >>> Internet-Draft =A0 =A0 =A0 LISP for Multicast Environments =A0 =A0 =A0 = =A0 =A0 =A0May >>> 2011 >>> >>> >>> =A0mapping database because the source multicast site is using a >>> =A0routable address and not an EID prefix address. =A0So the ETR knows = to >>> =A0simply propagate the PIM Join/Prune message to a external-facing >>> =A0interface without converting the (S-EID,G) because it is an (S,G) >>> =A0where S is routable and reachable via core routing tables. >>> >>> So the ETR knows because "there is no mapping database entry and the >>> S-EID is routable". >>> >>>> Couldn't a more specific check be done along the lines of: >>>> if the S-EID is reachable via core routing and >>>> =A0 =A0 i) it is not in the mapping database or >>>> =A0 =A0 ii) it is in the mapping database, but there are no RLOCs with >>>> =A0 =A0 =A0 =A0 an M Priority other than 255? >>>> >>>> f) Text in 9.1.1, 9.1.2 doesn't match the headings well. =A0For >>>> instance, in 9.1.1, there is discussion of how a LISP source site >>>> that >>>> sends to non-LISP or uLISP receiver sites also can send to LISP >>>> receiver sites. >>> >>> They actually are correct, but the first start out saying how the >>> trees are built from the receiver side so that text can support the >>> data-flow description that comes later. >>> >>>> In 9.1.2, maybe renaming it to non-mLISP Receiver Sites would be >>>> clearer? >>> >>> We stated up from the definition of a non-LISP receiver site. >>> Creating a new term would add to the number of combinations. The >>> spec doesn't need that extra complexity. >>> >>>> g) In 9.1.4, Mpriority and Mweight are finally mentioned - but as far >>>> as I can tell, they are needed earlier and for the pure mLISP to >>>> mLISP >>>> case. =A0Please pull the discussion of this earlier. >>> >>> Can you be more specific please. >>> >>>> Also, this case is discussed in 9.1.1 last paragraph on p. 21 - but >>>> claimed that it is sufficient to look in the mapping database. =A0Coul= d >>>> you please combine these and bring more consistency to the draft? >>> >>> Combine what? Please be more specific. >>> >>>> h) In 9.1.5, is it possible to make a recommendation (e.g. an ITR >>>> SHOULD be able to send two packets based on what its oif-lists are? >>> >>> No, we want to leave it up to the implementation. >>> >>>> Isn't this already the case because the mLISP ITR could have >>>> internal-facing entries in the (S-EID,G) that need to be replicated >>>> without encapsulation and external-facing entries in the (S-RLOC, G) >>>> that need encapsulation? >>> >>> Yes, but those forwarding rules are up to the multicast routing >>> protocol run in the site. That is, if your comment is to document >>> this. >>> >>>> I understand that this isn't ideal because multiple copies of data >>>> are >>>> going into the core - but the trees are different there too. >>> >>> Which trees are different? >>> >>>> What I'm looking for is some normative text about what MUST/SHOULD be >>>> supported - even for experimental interoperability. >>> >>> If there are mPETRs deployed an ITR can use option 2. If not, option >>> 1 is the only option. >>> >>>> The second option seems like it comes naturally - if a Join comes for >>>> the (S-RLOC, G), then it is sent the encapsulated packet. >>> >>> Right, if joins come from the mPETRs. >>> >>>> g) p. 21 Sec 9.1.1 end of second paragraph: >>>> "It is important to note that the routable address for the host >>>> cannot >>>> be the same as an RLOC for the site. =A0Because we want the ITRs to >>>> process a received PIM Join/Prune message from an external-facing >>>> interface to be propagated inside of the site so the site-part of >>>> the >>>> distribution tree is built." >>>> Is this supposed to be one sentence?? >>> >>> I fixed it up a bit. Thanks. >>> >>>> h) typo: p. 9 mPETR definition, last sentence: =A0"co-loacted" -> co- >>>> located >>>> >>>> i) typo: p. 23 4th line from bottom: "oins to" -> joins to >>>> >>>> j) typo: p.27 first sentence: "MUST not" -> MUST NOT >>>> >>>> k) typo: Sec 11 last sentence: "addition to slow" -> "addition due >>>> to slow" >>>> >>>> l) [LISP] needs to be Normative - it has the packet formats! >>> >>> Fixed all these. Thanks. >>> >>> Thanks, >>> Dino/Dave/Stig/JohnZ >>> >>> >> ietf-lisp-multicast-06.txt> >> >> _______________________________________________ >> 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 dino@cisco.com Tue Jun 14 11:13:33 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6B621F8540 for ; Tue, 14 Jun 2011 11:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.48 X-Spam-Level: X-Spam-Status: No, score=-10.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I87o6Bo9TPp2 for ; Tue, 14 Jun 2011 11:13:31 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 86B8B21F84E2 for ; Tue, 14 Jun 2011 11:13:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=15072; q=dns/txt; s=iport; t=1308075211; x=1309284811; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=pIPkKWzXR7gCvcvE4K5lyRSUqqeOvyoM9ao3egvnC8k=; b=DsFKcBv+9n9keB73iazlIoFCBfI9eF/9jYhLGvt14FnVA+/MPyCxeXto 8bbvT6x0GHgHXkw56aAHNFOH3WGW52+rBERPO/JI2NXXDUbWGEugTwFBf nGQxayfp8rkXWrk+D18uDQRdyCAIy8RSOr90kQXA3GgFm+UdWa/FnwU+C c=; X-IronPort-AV: E=Sophos;i="4.65,365,1304294400"; d="scan'208";a="336866337" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 14 Jun 2011 18:13:26 +0000 Received: from dhcp-10-155-38-108.cisco.com (dhcp-10-155-38-108.cisco.com [10.155.38.108]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5EIDQWY029841; Tue, 14 Jun 2011 18:13:26 GMT Message-Id: <1635959D-266C-49A7-9D88-BB3C05DF3222@cisco.com> From: Dino Farinacci To: Jesus Arango In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 14 Jun 2011 11:13:25 -0700 References: X-Mailer: Apple Mail (2.936) Cc: "Stig Venaas \(svenaas\)" , "David Meyer \(dmm\)" , lisp@ietf.org Subject: Re: [lisp] Proposed changes for draft-ietf-lisp-multicast-06.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2011 18:13:34 -0000 > Thanks Dino, > > The new paragraph in 8.1.2 addresses unwanted traffic but doesn=92t =20= > address duplicate traffic. I understand it may be premature to =20 > settle for a solution as neither one may be what we want (see recap =20= > below). If that is case, it is up to you if you want to omit the =20 > issue for now or describe it without settling for a solution. That was intentional. The duplicate traffic issue is dealt with in the =20= first paragraph. Your comment raised a new issue of packets going to =20 unjoined ETRs needed to be documented. > There is a single source site with two source addresses (S1 and S2) =20= > and two RLOCS (RLOC1 and RLOC2). The RLOC set for S1 includes RLOC1 =20= > and RLOC2. The RLOC set for the prefix of S2 includes at least RLOC2. This won't happen unless you have a S-prefix that covers S1 and =20 another S-prefix, say more specific that covers S2. We had this discussion for unicast and the group decided to recommend =20= against overlapping prefixes for a site. So the multicast spec is =20 consistent with that. When we re-poen overlapping EID-prefixes for unicast, we will update =20 the multicast spec to be consistent again. > With the above notation in mind, consider a receiver site A with the =20= > following mappings: > > (S1, G) --> (RLOC1, G) > (S2, G) --> (RLOC2, G) > > Also consider receiver site B, from where RLOC1 has become =20 > unreachable, and as a result falls back to RLOC2 for the following =20 > mapping: > > (S1, G) --> (RLOC2, G) > > This will lead to duplicate (S1, G) traffic inside site A unless =20 > either of the following solutions is adopted: It will lead to duplicate traffic *going to* the ETR of site A but =20 does not get forwarded *into the site*, so no receivers inside of site =20= A receive duplicates. The ETR will only decapsulate and forward =20 traffic for (S1,G) when it is received on the joined RLOC1. > =95 The ETR at site A performs an upstream neighbor (RLOC) check = on =20 > (S1,G). This could be a solution yes. > =95 Site B does not switch to RLOC2 if RLOC1 becomes = unreachable. If you you that, then site B receivers get no traffic. Dino > > Jesus > > > > On 6/13/11 10:43 AM, "Dino Farinacci" wrote: > >> Enclosed. >> >> Dino >> >> >> >> >> >> >> >> >> On Jun 13, 2011, at 9:11 AM, Jesus Arango (jearango) wrote: >> >> > Dino, Terry, >> > >> > I had not responded because I must have missed the original May 30 >> > email. I can't find the copy. Could you please resend the =20 >> attachments >> > and/or text that addresses the comments ? >> > >> > Thanks >> > Jesus >> > >> > -----Original Message----- >> > From: Terry Manderson [mailto:terry.manderson@icann.org] >> > Sent: Monday, June 13, 2011 2:29 AM >> > To: Dino Farinacci (dino) >> > Cc: Dino Farinacci (dino); David Meyer (dmm); Stig Venaas =20 >> (svenaas); >> > Jesus Arango (jearango); lisp@ietf.org >> > Subject: Re: [lisp] Proposed changes for >> > draft-ietf-lisp-multicast-06.txt >> > >> > Alia and Jesus, >> > >> > Does the responses herein address your concerns? If not, why not? >> > >> > Cheers, >> > Terry >> > >> > On 13/06/2011, at 5:09 PM, "Dino Farinacci" wrote: >> > >> >> I would like to ask the chairs, as well as Alia and Jesus if I can >> >> post this update. >> >> >> >> This email was posted 2 weeks ago and no replies were received. >> >> >> >> Dino >> >> >> >> On May 30, 2011, at 8:50 PM, Dino Farinacci wrote: >> >> >> >>> We have received WG last call comments on the LISP-multicast =20 >> draft >> >>> from Jesus Arango and Alia Atlas. See enclosed our responses =20 >> and a >> >>> proposed updated draft and html diff file. >> >>> >> >>> Jesus comments: >> >>> >> >>>> 1. Cross-talk duplication of multicast flows when using multiple >> >>>> RLOCS: >> >>>> Consider two receiver sites A and B with the following mappings: >> >>>> >> >>>> Site A: >> >>>> (S1, G) --> (RLOC1, G) >> >>>> (S2, G) --> (RLOC2, G) >> >>>> Site B: >> >>>> (S1, G) --> (RLOC2, G) >> >>>> >> >>>> This would cause Site A to receive duplicate packets for (S1,G). >> >>>> One copy >> >>>> would be encapsulated with source RLOC1 while the second copy =20= >> will >> > be >> >>> >> >>> All sites are suppose to hash to the same RLOC for a given (S- >> >>> EID,G). So Site B would use (RLOC1,G) as would Site A. >> >>> >> >>>> encapsulated with source RLOC2. There are multiple ways to =20 >> address >> >>>> this >> >>>> issue: >> >>>> >> >>>> a. Perform neighbor verification as part of RPF check. This =20 >> seemed >> >>>> obvious >> >>>> but it is worth noting that to my understanding this is not =20 >> done in >> >>>> IOS. Can >> >>>> folks comment on why this is not done today? What is the =20 >> viability >> >>>> of doing >> >>>> this? What is the current behavior in non-IOS platforms ? >> >>>> b. Use a single RLOC for multicast >> >>>> c. Anycast RLOC >> >>>> d. Propose a group-to-RLOC hashing mechanism where the hashing >> >>>> function >> >>>> dynamically adapts to addition/deletion of RLOCS while =20 >> minimizing >> >>>> the impact >> >>>> on flows that are already stablished. >> >>> >> >>> What will happen is that if (S1,G) and (S2,G) map to core >> >>> distribution tree (RLOC2,G) then Site B will get packets for no >> >>> receivers. I have added a paragraph to section 8.1.2 to make this >> >>> clear. >> >>> >> >>> Alia comments: >> >>> >> >>>> What I most want to see in this draft is a clear description of >> >>>> what >> >>>> needs to implemented and how. It gives a good survey of the >> >>>> architectural possibilities and even makes suggestions at the =20= >> end - >> >>>> but not quite sufficient to be clear in the details of what =20 >> needs >> >>>> to >> >>>> be implemented for interoperability and what is for future >> >>>> experimentation. >> >>> >> >>> Everything in the spec needs to be implemented. Why would you =20 >> think >> >>> differently? >> >>> >> >>>> a) Could you add a definition for uPITR? It is first used on =20= >> p.9 >> >>>> in >> >>>> the mPETR definition and only on p. 22 is it described as >> >>>> "(where in unicast it acts as a "Proxy ITR", or an uPITR)" >> >>> >> >>> I do not want to duplicate the definition from the Interworking >> >>> spec. I will add a reference though. >> >>> >> >>>> b) Sec 4, second paragraph: "At this point in time, we don't =20 >> see a >> >>>> requirement for different locator-sets, priority, and weight >> > policies >> >>>> for multicast than we have for unicast." but there is an M >> >>>> Priority >> >>>> and M Weight in the [LISP] draft. Clarification as to why =20 >> would be >> >>>> useful... (I know it is to get the RLOCs of the ITRs which >> >>>> shouldn't >> >>>> be used for unicast traffic.) >> >>> >> >>> I added a sentence. >> >>> >> >>>> I don't see a mechanism other than the M Priority to obtain the >> > RLOCs >> >>>> associated with an ITR - since only ETR RLOCs would normally be >> >>>> included. >> >>> >> >>> I don't understand the comment. There is one locator-set, and the >> >>> RLOCs for encapsulating unicast packets to and the RLOCs for =20 >> sending >> >>> multicast join messages to can be a different set within the >> >>> locator- >> >>> set. >> >>> >> >>>> What would be good to add to the draft is the changes to be =20 >> made to >> >>>> information such as the Map-Reply messages. E.g. >> >>>> Set the M Priority for all ETR RLOCs to be 255 >> >>>> Add the ITR RLOCs and set the Priority to 255 & the M Priority =20= >> to >> >>>> something else. >> >>> >> >>> They are the same locators. The xTR has one locator-set, the =20 >> RLOCs >> >>> are used as a destination for unicast packets or for a =20 >> destination >> >>> for multicast joins. >> >>> >> >>>> c) What happens if the S-EID and S-RLOC collide? In =20 >> particular, at >> >>> >> >>> You have to be more specific on what you mean here. >> >>> >> >>>> the ETR and ITR, it seems useful to specify that the xTR has >> >>>> knowledge >> >>>> of whether the packet was LISP-encapsulated & forwards it =20 >> either to >> >>>> receivers that expect it un-LISP-encapsulated (ETR) or to =20 >> receivers >> >>>> that expect it LISP-encapsulated (ITR). >> >>> >> >>> An EID and RLOC can have the same value just like in the unicast >> >>> scenario. >> >>> >> >>>> d) p. 15 end of MSDP: >> >>>> "And the choice can be made unilaterally because the ITR at the >> >>>> site will determine which namespace the destination peer =20 >> address is >> >>>> out of by looking in the mapping database service." >> >>>> >> >>>> Is there an assumption in LISP that an EID and an RLOC MUST NOT >> >>>> have >> >>>> the same value?? I've seen this potentially implied, but not >> >>>> proscriptively stated. >> >>> >> >>> There is not architectural. >> >>> >> >>>> e) p. 22 first paragraph: >> >>>> "So the ETR knows to simply propagate the PIM Join/Prune =20 >> message to >> >>>> a external-facing interface without converting the (S-EID,G) >> >>>> because >> >>>> it is an (S,G) where S is routable and reachable via core =20 >> routing >> >>>> tables." >> >>>> >> >>>> In [INTWRK], it is clear that an EID may be globally routable. >> >>>> This >> >>>> creates a conflict here, where there is an assumption that if =20= >> an IP >> >>>> address is globally routable, then it is not in the EID/RLOC >> >>>> mapping >> >>>> database. >> >>> >> >>> The text says: >> >>> >> >>> In this case, S-EID is not in the >> >>> >> >>> Farinacci, et al. Expires December 1, 2011 =20= >> [Page >> >>> 21] >> >>> Internet-Draft LISP for Multicast Environments =20= >> May >> >>> 2011 >> >>> >> >>> >> >>> mapping database because the source multicast site is using a >> >>> routable address and not an EID prefix address. So the ETR =20 >> knows to >> >>> simply propagate the PIM Join/Prune message to a external-facing >> >>> interface without converting the (S-EID,G) because it is an (S,G) >> >>> where S is routable and reachable via core routing tables. >> >>> >> >>> So the ETR knows because "there is no mapping database entry =20 >> and the >> >>> S-EID is routable". >> >>> >> >>>> Couldn't a more specific check be done along the lines of: >> >>>> if the S-EID is reachable via core routing and >> >>>> i) it is not in the mapping database or >> >>>> ii) it is in the mapping database, but there are no RLOCs =20 >> with >> >>>> an M Priority other than 255? >> >>>> >> >>>> f) Text in 9.1.1, 9.1.2 doesn't match the headings well. For >> >>>> instance, in 9.1.1, there is discussion of how a LISP source =20 >> site >> >>>> that >> >>>> sends to non-LISP or uLISP receiver sites also can send to LISP >> >>>> receiver sites. >> >>> >> >>> They actually are correct, but the first start out saying how the >> >>> trees are built from the receiver side so that text can support =20= >> the >> >>> data-flow description that comes later. >> >>> >> >>>> In 9.1.2, maybe renaming it to non-mLISP Receiver Sites would be >> >>>> clearer? >> >>> >> >>> We stated up from the definition of a non-LISP receiver site. >> >>> Creating a new term would add to the number of combinations. The >> >>> spec doesn't need that extra complexity. >> >>> >> >>>> g) In 9.1.4, Mpriority and Mweight are finally mentioned - but =20= >> as >> > far >> >>>> as I can tell, they are needed earlier and for the pure mLISP to >> >>>> mLISP >> >>>> case. Please pull the discussion of this earlier. >> >>> >> >>> Can you be more specific please. >> >>> >> >>>> Also, this case is discussed in 9.1.1 last paragraph on p. 21 =20= >> - but >> >>>> claimed that it is sufficient to look in the mapping database. >> > Could >> >>>> you please combine these and bring more consistency to the =20 >> draft? >> >>> >> >>> Combine what? Please be more specific. >> >>> >> >>>> h) In 9.1.5, is it possible to make a recommendation (e.g. an =20= >> ITR >> >>>> SHOULD be able to send two packets based on what its oif-lists =20= >> are? >> >>> >> >>> No, we want to leave it up to the implementation. >> >>> >> >>>> Isn't this already the case because the mLISP ITR could have >> >>>> internal-facing entries in the (S-EID,G) that need to be =20 >> replicated >> >>>> without encapsulation and external-facing entries in the (S-=20 >> RLOC, >> >>>> G) >> >>>> that need encapsulation? >> >>> >> >>> Yes, but those forwarding rules are up to the multicast routing >> >>> protocol run in the site. That is, if your comment is to document >> >>> this. >> >>> >> >>>> I understand that this isn't ideal because multiple copies of =20= >> data >> >>>> are >> >>>> going into the core - but the trees are different there too. >> >>> >> >>> Which trees are different? >> >>> >> >>>> What I'm looking for is some normative text about what MUST/=20 >> SHOULD >> > be >> >>>> supported - even for experimental interoperability. >> >>> >> >>> If there are mPETRs deployed an ITR can use option 2. If not, =20 >> option >> >>> 1 is the only option. >> >>> >> >>>> The second option seems like it comes naturally - if a Join =20 >> comes >> > for >> >>>> the (S-RLOC, G), then it is sent the encapsulated packet. >> >>> >> >>> Right, if joins come from the mPETRs. >> >>> >> >>>> g) p. 21 Sec 9.1.1 end of second paragraph: >> >>>> "It is important to note that the routable address for the host >> >>>> cannot >> >>>> be the same as an RLOC for the site. Because we want the ITRs =20= >> to >> >>>> process a received PIM Join/Prune message from an external-=20 >> facing >> >>>> interface to be propagated inside of the site so the site-part =20= >> of >> >>>> the >> >>>> distribution tree is built." >> >>>> Is this supposed to be one sentence?? >> >>> >> >>> I fixed it up a bit. Thanks. >> >>> >> >>>> h) typo: p. 9 mPETR definition, last sentence: "co-loacted" -=20= >> > co- >> >>>> located >> >>>> >> >>>> i) typo: p. 23 4th line from bottom: "oins to" -> joins to >> >>>> >> >>>> j) typo: p.27 first sentence: "MUST not" -> MUST NOT >> >>>> >> >>>> k) typo: Sec 11 last sentence: "addition to slow" -> "addition =20= >> due >> >>>> to slow" >> >>>> >> >>>> l) [LISP] needs to be Normative - it has the packet formats! >> >>> >> >>> Fixed all these. Thanks. >> >>> >> >>> Thanks, >> >>> Dino/Dave/Stig/JohnZ >> >>> >> >>> > attachment.txt>> >>> ietf-lisp-multicast-06.txt>> >>> attachment.txt> >> >> >> >> _______________________________________________ >> >> lisp mailing list >> >> lisp@ietf.org >> >> https://www.ietf.org/mailman/listinfo/lisp >> From dino@cisco.com Mon Jun 20 11:53:32 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86A111E8129 for ; Mon, 20 Jun 2011 11:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.51 X-Spam-Level: X-Spam-Status: No, score=-10.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjw-6-fQ6vLU for ; Mon, 20 Jun 2011 11:53:30 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 7168011E80A5 for ; Mon, 20 Jun 2011 11:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=19224; q=dns/txt; s=iport; t=1308596007; x=1309805607; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=ePMOOmpszGvkwqaEUofsf/ZYvJ/7t4Xq3rQNXTAcqWQ=; b=NJ3BgwTdtkYTL1CeT1mZCdccxWGQ3/CefumJjNmQlRj6Y4MnvB3wUFVO VBeQWG3N5t9TWXVKJeRD0ZVsTtL/dW47i8jozut/EMpctUtjxjcuXm0q+ HOKwCD6Wyw6pSRES9vQ//u6jHHOHl4tZgSeuIu1YSfTh+9hinGopO4Sjk Q=; X-IronPort-AV: E=Sophos;i="4.65,395,1304294400"; d="scan'208";a="381150280" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 20 Jun 2011 18:51:58 +0000 Received: from [192.168.1.4] (sjc-vpn7-791.cisco.com [10.21.147.23]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5KIpv3o022975; Mon, 20 Jun 2011 18:51:57 GMT Message-Id: <9ACA6751-3A26-47CB-9126-72863469F4D2@cisco.com> From: Dino Farinacci To: Alia Atlas In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 20 Jun 2011 11:51:56 -0700 References: <4099FE40-80F6-4E32-848C-C33990DB1343@cisco.com> X-Mailer: Apple Mail (2.936) Cc: Stig Venaas , Jesus Arango , lisp@ietf.org, David Meyer Subject: Re: [lisp] Proposed changes for draft-ietf-lisp-multicast-06.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jun 2011 18:53:33 -0000 > Dino, > > Comments are in-line Thanks for the comments. See responses inline. > On Mon, May 30, 2011 at 11:50 PM, Dino Farinacci > wrote: > >> Alia comments: >> >>> What I most want to see in this draft is a clear description of what >>> needs to implemented and how. It gives a good survey of the >>> architectural possibilities and even makes suggestions at the end - >>> but not quite sufficient to be clear in the details of what needs to >>> be implemented for interoperability and what is for future >>> experimentation. >> >> Everything in the spec needs to be implemented. Why would you think >> differently? > > There are places in the text where the phrasing is very unclear - > for just the > first instance, there is the last paragraph in Sec 4: > > "There is a possible solution to this problem which reduces the number > of many-to-one occurrences of (S-EID,G) entries aggregating into a > single (S-RLOC,G) entry. If a physical ITR can be assigned multiple > RLOC addresses and these addresses are advertised in mapping > database > entries, then ETRs at receiver sites have more RLOC address options > and therefore can join different (RLOC,G) entries for each (S-EID,G) > entry joined at the receiver site. It would not scale to have a > one- > to-one relationship between the number of S-EID sources at a source > site and the number of RLOCs assigned to all ITRs at the site, but > we > can reduce the "n" to a smaller number in the "n-to-1" relationship. > And in turn, reduce the opportunity for data packets to be delivered > to sites for groups not joined." > > This doesn't give a way to force all receiver sites to select the same > (RLOC,G) for a given (S-EID,G) as you replied was necessary to Jesus' > comments. The above paragraph is showing a tradeoff between one-to-one state between (S-EID,G) and (S-RLOC,G). If you want good trees at the expense of core state, you go with this option. If you want to reduce core state, you use aggregate trees in the core which combine many (S- EID,G) entries into one (S-RLOC,G) entry. Jesus made a lot of comments, so I don't know how this paragraph relates to which comment. If you want to make this thread productive so we can proceed, you need to be very detailed in your commentary or there is nothing I can do to decide on how to deal with the comments. > I can go through the draft again for each example - but phrasing of > "it is possible", > "a potential solution", "one approach", etc. do not indicate a > requirement to implement > for interoperability. I am going to repeat. This draft is experimental. And there are a lot of potential solutions we have not thought about yet. The ones are presented make it obvious and convincing that the currently documented potential solutions should be considered by the implementation, allowing us to leave room for the implementation to create its own solution for experimentation and interoperability. If you think we have all the answers, and want us to document them, then we would be lieing. We don't want to lie. ;-) And I know you are not asking us to do that. >>> a) Could you add a definition for uPITR? It is first used on p.9 in >>> the mPETR definition and only on p. 22 is it described as >>> "(where in unicast it acts as a "Proxy ITR", or an uPITR)" >> >> I do not want to duplicate the definition from the Interworking >> spec. I will >> add a reference though. > > Looks good > >>> b) Sec 4, second paragraph: "At this point in time, we don't see a >>> requirement for different locator-sets, priority, and weight >>> policies >>> for multicast than we have for unicast." but there is an M Priority >>> and M Weight in the [LISP] draft. Clarification as to why would be >>> useful... (I know it is to get the RLOCs of the ITRs which shouldn't >>> be used for unicast traffic.) >> >> I added a sentence. >> >>> I don't see a mechanism other than the M Priority to obtain the >>> RLOCs >>> associated with an ITR - since only ETR RLOCs would normally be >>> included. >> >> I don't understand the comment. There is one locator-set, and the >> RLOCs for >> encapsulating unicast packets to and the RLOCs for sending >> multicast join >> messages to can be a different set within the locator-set. > > Ok - let me clarify. The set of RLOCs in a locator-set, until this > draft, are for the ETR. For multicast, the set of RLOCs required must Well, correction, they are for xTRs at the site. And the encoding allows you to list ITRs as well even though you would not use them as targets of encapsulation. You achieve this either by setting the priority to 255 or setting the corresponding R-bit/LSB bit to 0. > be for the ITR. IF the ITR and ETR are different, there must be a way > of telling which RLOCs belong to an ITR and which belong to an ETR. This is how you encode them in a Map-Reply, as an example of unicast ITRs A and B, and multicast ITRs C and D: locator-set-count:4 A, up: 1, uw: 50, mp: 255, mw: 0 B, up: 1, uw: 50, mp: 255, mw: 0 C, up: 255, uw: 0, mp: 1, mw: 50 D, up: 255, uw: 0, mp: 1, mw: 50 This describes a site that is doing active-active multihoming for unicast traffic by having ITRs, which received this Map-Reply, to load- split unicast flows across encapsulations to A and B. ITRs do not use C and D because the unicast priority is set to 255. A and B are not used for unicast Joins since the multicast priority is set to 255. When ETRs at a receiver site want to join an (EID,G), they will use C and D and load-split different (S-EID,G) entries across C and D in a active-active fashion. > The ONLY way that I can find to do this is from the M Priority and the > Priority fields. If you intend that RLOCs with a priority=255 are > assumed to be RLOCs associated with ITRs, then that should be clearly > stated. I certainly assumed not - there can be reasons to have an > inactive RLOC, as I understand it. Wherever the text says where to send joins and talks about priorities, each occurrence refers to "multicast priority". And the Basic Overview section says: At this point in time, we don't see a requirement for different locator-sets, priority, and weight policies for multicast than we have for unicast. However, when traffic engineering policies are different for unicast versus multicast flows, it will be desirable to use multicast-based priority and weight values in Map-Reply messages. >>> What would be good to add to the draft is the changes to be made to >>> information such as the Map-Reply messages. E.g. >>> Set the M Priority for all ETR RLOCs to be 255 >>> Add the ITR RLOCs and set the Priority to 255 & the M Priority to >>> something else. >> >> They are the same locators. The xTR has one locator-set, the RLOCs >> are used >> as a destination for unicast packets or for a destination for >> multicast >> joins. > > The unicast traffic needs to go to ETRs. The multicast traffic needs > to go to ITRs. My understanding is that these can be deployed > separately. If this is not the case for multicast, then that should > certainly be stated! There is one locator-set that is shared when but unicast and multicast priority is non-255. Otherwise, some locators are used for unicast- only and others can be used for multicast-only. >>> c) What happens if the S-EID and S-RLOC collide? In particular, at >> >> You have to be more specific on what you mean here. > > Can an S-EID and an S-RLOC have the same value? If not, why not? Yes, they will when a mPETR sends a native join to a non-LISP source multicast site. >>> the ETR and ITR, it seems useful to specify that the xTR has >>> knowledge >>> of whether the packet was LISP-encapsulated & forwards it either to >>> receivers that expect it un-LISP-encapsulated (ETR) or to receivers >>> that expect it LISP-encapsulated (ITR). > > If an S-EID and S-RLOC have the same value, what helps disambiguate > them > in a received multicast packet is whether the packet was LISP- > encapsulated. A LISP multicast packet is defined to be a UDP packet with a destination port of 4341. >> An EID and RLOC can have the same value just like in the unicast >> scenario. > > That is what I initially assumed - but there are places in the drafts > where it is assumed that one can tell an EID from an RLOC without any > additional information or look-ups. I tried to pull them out in my > comments and mentioned this as a general concern. Not true. If you have a specific location of this confusion, POINT OUT THE TEXT, and we can try to clarify it. >>> d) p. 15 end of MSDP: >>> "And the choice can be made unilaterally because the ITR at the >>> site will determine which namespace the destination peer address is >>> out of by looking in the mapping database service." >>> >>> Is there an assumption in LISP that an EID and an RLOC MUST NOT have >>> the same value?? I've seen this potentially implied, but not >>> proscriptively stated. >> >> There is not architectural. > > So how can the ITR determine which namespace the destination peer > address is > out of by looking in the mapping database service?? I don't understand the question. What is a destination peer address. Please use LISP defined terminology or else we be second guessing each other. > >>> e) p. 22 first paragraph: >>> "So the ETR knows to simply propagate the PIM Join/Prune message to >>> a external-facing interface without converting the (S-EID,G) >>> because >>> it is an (S,G) where S is routable and reachable via core routing >>> tables." >>> >>> In [INTWRK], it is clear that an EID may be globally routable. This >>> creates a conflict here, where there is an assumption that if an IP >>> address is globally routable, then it is not in the EID/RLOC mapping >>> database. >> >> The text says: >> >> In this case, S-EID is not in the >> >> Farinacci, et al. Expires December 1, 2011 >> [Page 21] >> Internet-Draft LISP for Multicast Environments May >> 2011 >> >> >> mapping database because the source multicast site is using a >> routable address and not an EID prefix address. So the ETR knows >> to >> simply propagate the PIM Join/Prune message to a external-facing >> interface without converting the (S-EID,G) because it is an (S,G) >> where S is routable and reachable via core routing tables. >> >> So the ETR knows because "there is no mapping database entry and >> the S-EID >> is routable". > > But in [INTWRK}, the same IP address can be globally routable AND > appear > in the mapping database. Then it can be reached either way. Not a problem. It is up the ITR to decide to encapsulate to the LISP site or send natively. > Also, how does the ETR know that the S-EID is routable - by getting > a negative > Map-Reply? It assumes it is routable if not in the mapping database. > Statements like that of "is using a routable address and not an EID > prefix address" > without any further hints imply that there isn't overlap of addresses. This string is in two locations in the spec. And it is here: Since the ITR in the source multicast site has never received a unicast encapsulated PIM Join/Prune message from any ETR in a receiver multicast site, it knows there are no LISP-Multicast receiver sites. Therefore, there is no need for the ITR to encapsulate data. Since it will know a priori (via configuration) that its site's EIDs are not routable, it assumes that the multicast packets from the source host are sent by a routable address. That is, it is the responsibility of the multicast source host's system administrator to ensure that the source host sends multicast traffic using a routable source address. When this happens, the ITR acts simply as a router and forwards the multicast packet like an ordinary multicast router. And here: The solution to this problem is the same as when an ITR wants to send a unicast packet to a destination site but needs determine if the site is LISP capable or not. When it is not LISP capable, the ITR does not encapsulate the packet. So for the multicast case, when ETR receives a PIM Join/Prune message for (S-EID,G) state, it will do a mapping table lookup on S-EID. In this case, S-EID is not in the Farinacci, et al. Expires December 1, 2011 [Page 21] Internet-Draft LISP for Multicast Environments May 2011 mapping database because the source multicast site is using a routable address and not an EID prefix address. So the ETR knows to simply propagate the PIM Join/Prune message to a external-facing interface without converting the (S-EID,G) because it is an (S,G) where S is routable and reachable via core routing tables. Does your comment pertain to these paragraphs. I can change the first to "using a routable source address (meaning that it is not in the mapping database system)". Would that suffice? The second occurrence says "In this case, the S-EID is not in the mapping database ...". So it is clear IMO. >>> Couldn't a more specific check be done along the lines of: >>> if the S-EID is reachable via core routing and >>> i) it is not in the mapping database or >>> ii) it is in the mapping database, but there are no RLOCs with >>> an M Priority other than 255? >>> >>> f) Text in 9.1.1, 9.1.2 doesn't match the headings well. For >>> instance, in 9.1.1, there is discussion of how a LISP source site >>> that >>> sends to non-LISP or uLISP receiver sites also can send to LISP >>> receiver sites. >> >> They actually are correct, but the first start out saying how the >> trees are >> built from the receiver side so that text can support the data-flow >> description that comes later. >> >>> In 9.1.2, maybe renaming it to non-mLISP Receiver Sites would be >>> clearer? >> >> We stated up from the definition of a non-LISP receiver site. >> Creating a new >> term would add to the number of combinations. The spec doesn't need >> that >> extra complexity. >> >>> g) In 9.1.4, Mpriority and Mweight are finally mentioned - but as >>> far >>> as I can tell, they are needed earlier and for the pure mLISP to >>> mLISP >>> case. Please pull the discussion of this earlier. >> >> Can you be more specific please. > > Please look at my comment (b) and further elaboration there. I think > Mpriority is > needed to find the RLOCs associated with an ITR. We already covered this and I hope you are satisfied with my response. If not, you need to PLEASE SITE TEXT SO WE CAN CORRECT IT. >>> Also, this case is discussed in 9.1.1 last paragraph on p. 21 - but >>> claimed that it is sufficient to look in the mapping database. >>> Could >>> you please combine these and bring more consistency to the draft? >> >> Combine what? Please be more specific. > > How much more specific than the exact sections and paragraphs do you > need? Point out text please in the email. >>> h) In 9.1.5, is it possible to make a recommendation (e.g. an ITR >>> SHOULD be able to send two packets based on what its oif-lists are? >> >> No, we want to leave it up to the implementation. > > So both solutions must be implemented (see your response to my first > question), configured, and managed??? Why? How will there be > interoperable implementations? > >>> Isn't this already the case because the mLISP ITR could have >>> internal-facing entries in the (S-EID,G) that need to be replicated >>> without encapsulation and external-facing entries in the (S-RLOC, G) >>> that need encapsulation? >> >> Yes, but those forwarding rules are up to the multicast routing >> protocol run >> in the site. That is, if your comment is to document this. > > So - clarity of understanding what needs to be done and ITR behavior > is good. > Yes, please document this. As phrased, there's the appearance that > an ITR > doesn't normally need to duplicate packets. I am sorry, I am not going to document PIM-DM, PIM-SM, DVMRP, MOSPF, IGMP, and MLD in this document. If that is your request, it is unreasonable and adds no value and just creates opportunity for complexity, confusion, and errors. >>> I understand that this isn't ideal because multiple copies of data >>> are >>> going into the core - but the trees are different there too. >> >> Which trees are different? > > The ones referred to in sec 9.1.5: > > " 1. Make the LISP ITR in the source multicast site send two > packets, > one that is encapsulated with (S-RLOC,G) to reach LISP receiver > multicast sites and another that is not encapsulated with > (S-EID,G) to reach non-LISP and uLISP receiver multicast sites." We have no choice but to do this. The receiver sites are incompatible. >>> What I'm looking for is some normative text about what MUST/SHOULD >>> be >>> supported - even for experimental interoperability. >> >> If there are mPETRs deployed an ITR can use option 2. If not, >> option 1 is >> the only option. > > So - why not require option 1 to be implemented? Is it a > requirement to support > mPETRs? Yes. >>> The second option seems like it comes naturally - if a Join comes >>> for >>> the (S-RLOC, G), then it is sent the encapsulated packet. >> >> Right, if joins come from the mPETRs. > > Regardless of where the join came from... > Otherwise, how does the ITR know that the join is from an mPETR The joins we are talking about here are native ones, not ECM based joins. So you don't know if they are coming from mPETRs or non-LISP receiver multicast sites. Dino > > Alia > >>> g) p. 21 Sec 9.1.1 end of second paragraph: >>> "It is important to note that the routable address for the host >>> cannot >>> be the same as an RLOC for the site. Because we want the ITRs to >>> process a received PIM Join/Prune message from an external-facing >>> interface to be propagated inside of the site so the site-part of >>> the >>> distribution tree is built." >>> Is this supposed to be one sentence?? >> >> I fixed it up a bit. Thanks. >> >>> h) typo: p. 9 mPETR definition, last sentence: "co-loacted" -> co- >>> located >>> >>> i) typo: p. 23 4th line from bottom: "oins to" -> joins to >>> >>> j) typo: p.27 first sentence: "MUST not" -> MUST NOT >>> >>> k) typo: Sec 11 last sentence: "addition to slow" -> "addition due >>> to >>> slow" >>> >>> l) [LISP] needs to be Normative - it has the packet formats! >> >> Fixed all these. Thanks. >> >> Thanks, >> Dino/Dave/Stig/JohnZ >> >> >> >> >> >> >> >> >> >> >> >> >> From internet-drafts@ietf.org Mon Jun 20 13:59:06 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D2F11E81D8; Mon, 20 Jun 2011 13:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcf59uzWR3t1; Mon, 20 Jun 2011 13:59:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6936011E80C5; Mon, 20 Jun 2011 13:59:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110620205905.28013.205.idtracker@ietfa.amsl.com> Date: Mon, 20 Jun 2011 13:59:05 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-multicast-06.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jun 2011 20:59:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP for Multicast Environments Author(s) : Dino Farinacci Dave Meyer John Zwiebel Stig Venaas Filename : draft-ietf-lisp-multicast-06.txt Pages : 37 Date : 2011-06-20 This draft describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the LISP architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-multicast-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-multicast-06.txt From dino@cisco.com Mon Jun 20 15:19:35 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375909E804C for ; Mon, 20 Jun 2011 15:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.527 X-Spam-Level: X-Spam-Status: No, score=-10.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elT2lv7+JEPb for ; Mon, 20 Jun 2011 15:19:33 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 15E039E8046 for ; Mon, 20 Jun 2011 15:19:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=25454; q=dns/txt; s=iport; t=1308608373; x=1309817973; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=k/SB9vwRrKY0viQIuI8prZIVopdwF41d7VeGXJd/I+U=; b=kWkTe6oeCYm80fkM6tA3MN5nwHZp+mbccXQiEeszA9yjZwCFNNdR/w4u JpTNSvYg50hGVq4gLVIzQwnPfV989vyBIbissvqDR7zg6cuKuRwiAQAJh jMLvnoZZSBSR+Ttz3B1+Irbrek+mTH1OnbE9mqwqNXrUzWCIxkmUK0huR g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADnG/02rRDoG/2dsb2JhbABFAQ2mZ3eIc6FOnh6DHQGDDASHIIo+hGCLQRw X-IronPort-AV: E=Sophos;i="4.65,396,1304294400"; d="scan'208";a="381346099" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 20 Jun 2011 22:19:32 +0000 Received: from [10.34.153.93] ([10.34.153.93]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5KMJW46025785; Mon, 20 Jun 2011 22:19:32 GMT Message-Id: <00D02FFF-2E45-4F5D-9DEC-F5F0961C62D3@cisco.com> From: Dino Farinacci To: Alia Atlas In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 20 Jun 2011 15:19:32 -0700 References: X-Mailer: Apple Mail (2.936) Cc: "lisp@ietf.org" Subject: Re: [lisp] Last call for draft-ietf-lisp-12 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jun 2011 22:19:35 -0000 > I have reviewed this this draft and think it needs more work before it > is ready to proceed. > I have a few general questions and comments - as well as text- > specific ones. Thanks for the thorough review Alia, it is appreciated. See responses in line. Sorry it took over a month to get back to you on this. > I hope this leads to fruitful discussion on the list. I am also happy > to add all of these to > the Issue Tracker if necessary. > > 1) Can an EID and an RLOC have the same value? They are different > namespaces, > but assumptions in the various drafts imply not. Could this please > be explicitly stated? See my explanation below. > 2) Where is the explicit text saying what EID-prefixes an ETR can > register or reply authoritatively? E.g. Can an ETR advertise a prefix > (10.1/16) with holes (10.1.1/24)? Answer should be no, of course, but > extremely clear > rules on this are needed. If the site has an EID-prefix of the /16 that is the one it Map- Replies for. We have rules in section 6.1.5 "EID-to-RLOC UDP Map-Reply Message" on how to send Map-Replies when there are overlapping EID- prefixes and there has been much discussion on this mailing list about it. > 3) Generally, a section specifying ETR behavior in regard to packets > is missing. What is specified is scattered widely. "in regard to packets" is not clear what you are asking for. Do you mean for decapsulation purposes? If so, in section 5.3 starting with text "When doing ETR/PETR decapsulation:" will explain it. > i) For instance, if an ETR receives a LISP encapsulated packet and > decapsulates it, > but does not have EID locally, what should the ETR do? Drop the packet. When decapsulation occurs, the inner header is inspected and what an IP router does today is what it does post decapsulation. > ii) Does an ETR have to do packet fragment reassembly? If an ETR > does not support > fragment reassembly, should it send an ICMP Too Big message and > drop the fragment? > What should an ETR do with a fragment directed to its RLOC? The ETR follows the IP and IPv6 specification in regards to reassemly of fragments. However, we try to avoid fragmentation. See section 5.4 "Dealing with Large Encapsulated Packets" for solutions. > 4) Generally, a section specifying ITR behavior in regard to packets > is missing. > i) For instance, if an ITR receives a Negative Map Reply indicated > "drop", should the ITR send an ICMP Destination Unreachable with > Host Unreachable? We did not want to specify this because in practice when this is done either the ICMP messages are either rate-limited or filtered so ICMP is not a reliable mechanism. Experimentation will tell us more on what to do. > ii) If an ITR receives an ICMP packet (other than TTL exceeded) to > its RLOC, how does it properly handle or forward it? Just like an IP router does today. > 5) Are interfaces inside the LISP site explicitly configured on the > xTR or is there a way for the ITR to identify them? That is up to the implementation, but the 3 cisco implementations do not have this explicit configuration. > Here are my questions tied specifically to the points in the text (and > some typos): Consider these done. I will comment for which comments we will make a change and when you don't see that, we did not make a change for your comment. > a) On p 8 in EID-prefix: > "A globally routed address block may be used by its assignee as an > EID block." > > There are comments in other drafts also being last-called that imply > it is possible to tell is a value is an EID or an RLOC - but other > places, such as this, where it is clear that a value may be both an > EID and an RLOC. An address is an EID for sake of encapsulation when it is found in the mapping database. Since EID namespace and RLOC namespace *architecturally* are different spaces, an EID and an RLOC can have the same value. In practice, we believe when a prefix is not in the BGP DFZ core routing tables and registered to the mapping database is when the personality of an IP address changes from an locator prefix to an EID-prefix. In practice, we have to deal with interworking, so we will find that EID-prefixes will be in the DFZ for transition purposes. And an EID- prefix and a regular route-prefix do not have to match, one can be a more-specific of the other which does complicate things. In any event, using more specific lookup matches, as we have been doing for decades in the routing system, will continue to happen. So if a destination address in a packet matches a more specific prefix in the mapping database, then the destination is considered an EID. If the more specific route is in the DFZ, then the destination is not considered an EID and is routed natively. I like to call the addresses we use today as locators or RLOCs. Not everyone agrees with this thinking because things are more complicated than that. But I would like to think the addresses that are in the DFZ routing table today are "topological locations" and when a locator or RLOC is used in LISP, it is exactly this same routable address that is used. > Clarification of this is important > > b) p. 10 Reencapsulating Tunnels: I do not see any references or > suggestions on how these would be used. I am also concerned about how > routing/forwarding loops are prevented. The rules for TTL decrement occur across these re-encapsulating boundaries. > Could this be explicitly set as for future study & experimentation? The use-cases are cropping up and yes we are experimenting with solutions for them. > I can see ways to make it work and ways that might fail - but nothing > providing details or mechanisms to avoid, detect, handle, or manage > problems. > > c) p. 13: 3rd paragraph from bottom: The discussion about prepending > additional LISP headers for TE doesn't give any indications or ideas > of how an ISP transit might identify that it needs to prepend a TE-ETR > RLOC or how it would find such an RLOC. Given the complete lack of > detail about this in this draft and the others being last-called, > please explicitly specify this as experimental and for future study. Please when you make comments, provide the text from the spec, so others reading this can understand the context. So for others, here is the paragraph that Alia is referring to: An additional LISP header may be prepended to packets by a TE-ITR when re-routing of the path for a packet is desired. An obvious instance of this would be an ISP router that needs to perform traffic engineering for packets flowing through its network. In such a situation, termed Recursive Tunneling, an ISP transit acts as an additional ingress tunnel router and the RLOC it uses for the new prepended header would be either a TE-ETR within the ISP (along intra-ISP traffic engineered path) or a TE-ETR within another ISP (an inter-ISP traffic engineered path, where an agreement to build such a path exists). It was mentioned at a working group meeting that a Traffic Engineering draft needs to be written, but since that is out of charter, it has not been assigned. Perhaps, when the working group changes charter after posting of the experimental RFCs, we can do this work. > Also, please change "An obvious instance of this would be..." to "A > potential use-case would be..." Consider this changed. > d) p. 13: 2nd paragraph from bottom: What is the appropriate behavior > for an ITR to do when it receives a packet that it would normally > prepend a LISP header to but cannot? Could you please add a "SHOULD > drop and SHOULD send back an ICMP message"? I don't see an > appropriate > code point defined yet... Here is the 2nd paragraph from the bottom of page 13: In order to avoid excessive packet overhead as well as possible encapsulation loops, this document mandates that a maximum of two LISP headers can be prepended to a packet. It is believed two headers is sufficient, where the first prepended header is used at a site for Location/Identity separation and second prepended header is used inside a service provider for Traffic Engineering purposes. > To contradict the idea that 2 headers is sufficient, just look at the > deployment draft where a LISP site is dangling off another LISP site - > causing 2 LISP headers and then the possibility of a Service Provider > wanting to prepend one for TE purposes. Right, when we go off and do the TE spec, we will decide if this should be lifted. We want this to be strict now because hardware engineers want a hard limit. My feedback from doing MPLS in hardware was that having it variable length and limitless was a huge problem. So most hardware implementations of MPLS ship with just 2 label stacks. > Third, please rephrase the "It is believed..." to something like "The > LISP experiment will presume..." or "LISP experimentation will start > with the assumption that..." I changed the text to "For initial LISP deployments, is is assumed two headers is sufficient". > e) Sec 5, first paragraph: How does an ITR that wants to encapsulate a > LISP-encapsulated packet for TE send back an ICMP Too Big message? You didn't get to section 5.4 yet. When you get there, you should have your answers. ;-) > f) Sec 5: There is no indication in the packet formats that IPv4 in > IPv6 or IPv6 in IPv4 SHOULD be supported. I don't care about long > format sections - but at a minimum, there should be a paragraph that > specifies the encapsulation possibilities: > > "A LISP packet consists of an outer header, a UDP header, and an > inner header. The following combinations MUST be supported: > i) IPv4 outer header and IPv4 inner header (in Sec. 5.1) > ii) IPv6 outer header and IPv4 inner header > iii) IPv6 outer header and IPv6 inner header (in Sec 5.2) > iv) IPv4 outer header and IPv6 inner header " I don't understand this comment. The summary is in the table of contents section names: 5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . . 16 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 17 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 17 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 19 > g) An explicit statement that a LISP data packet appears as a UDP > packet destined to port 4341 and a LISP control packet appears as a > UDP packet destined to port 4342 would help for those who skim packet > formats. You can find that here in section 5.3: UDP Header: The UDP header contains a ITR selected source port when encapsulating a packet. See Section 6.5 for details on the hash algorithm used to select a source port based on the 5-tuple of the inner header. The destination port MUST be set to the well-known IANA assigned port value 4341. and here for control packets: The LISP UDP-based messages are the Map-Request and Map-Reply messages. When a UDP Map-Request is sent, the UDP source port is chosen by the sender and the destination UDP port number is set to 4342. When a UDP Map-Reply is sent, the source UDP port number is set to 4342 and the destination UDP port number is copied from the source port of either the Map-Request or the invoking data packet. Implementations MUST be prepared to accept packets when either the source port or destination UDP port is set to 4342 due to NATs changing port number values. > h) p.19: When is it desirable to not have a Nonce value in a packet? > The Map-Version seems rather useful; which is required for support for > the initial LISP experimentation? When doing the echo-nonce Locator Reachability Algorithm. > Also, the Nonce field could use similar description to that on p.29 > for the Nonce value - at least as far as how to produce one and > what it is protecting against. It says it here: Nonce: An 8-byte random value created by the sender of the Map- Request. This nonce will be returned in the Map-Reply. The security of the LISP mapping protocol depends critically on the strength of the nonce in the Map-Request message. The nonce SHOULD be generated by a properly seeded pseudo-random (or strong Farinacci, et al. Expires December 8, 2011 [Page 29] Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 random) source. See [RFC4086] for advice on generating security- sensitive random data. > i) p. 20 L: The diagram indicates that the 2nd 32 bits are only > Locator Status Bits, but the description under the I bit indicates > that the I and L bit could be set at the same time - in which case the > 2nd 32 bits aren't just Locator Status Bits. Please align the diagram > and description to better match the existence of the I bit. I think you misread this. The text and the diagrams are consistent. And you must note the binary settings (with the notation of "x" as don't care bits). See here: L: The L bit is the Locator-Status-Bits field enabled bit. When this bit is set to 1, the Locator-Status-Bits in the second 32-bits of the LISP header are in use. x 1 x x 0 x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|flags| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator Status Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > j) typo: p. 20 V > "This bit indicates that the first 4 bytes of the LISP header is > encoded as:" > but it show the 8 bytes of the LISP header and the second 4 are shown > as being "Instance ID/Locator Status Bits" Right, the description wants to show the entire LISP header but wants you, the reader, to focus on the ulong that the V-bit is pertaining to. > Also, for the I bit, the last 4 bytes are referred to, but all 8 are > shown. Same as above comment. > k) p. 21 flags: I think this should be a "It MUST be set to 0 on > transmit and MUST be ignored on receipt" - if we want it to be really > available for the future... > > Same for the Reserved field on p.29, p.33 Consider text updated for all 3 places. > l) typo p. 21, end of LISTP Locator Status Bits: > "with that address taht the ETR is considered 'up'" -> ITR > I think the ITR is the one who decides and sets the LSBs... Fixed typo. No it is ETR. > m) p. 21/22: The TTL copying from inner to outer should be a MUST not > a SHOULD on encapsulation. The TTL copying from outer to inner should > be a MUST not a SHOULD on decapsulation. It was agreed on by the working group to be SHOULD. > Why does the draft say "when the Time to Live field of the outer > header is less than the Time to Live of the inner header"? How could > that not be the case if copying the TTL from inner to outer is > required? Please remove the text: Because there can be a bug on the ITR/PITR where it is violating the spec. > ", when the Time to Live field of the outer header is less than the > Time to Live of the inner header. Failing to perform this check can > cause the Time to Live of the inner header to increment across > encapsulation/decapsulation cycle. This check is also performed > when doing initial encapsulation when a packet comes to an ITR or > PITR destined for a LISP site." > > n) Sec 5.4: This says that both, either or neither of the mechanisms > can be implemented. However, in Sec 5.4.1, it says: > "An implementation MAY set the DF bit in such headers to 0 if it has > good reason to believe there are unresolvable path MTU issues > between the sending ITR and the receiving ETR." > > This transforms the requirement from being imposed just on the ITR to > something that the ETR has to deal with. If a LISP-encapsulated > packet is fragmented, then the ETR needs to do the reassembly. Right, and the ITR has violated the spec. The spec is saying that fragmentation is done first and encapsulation second so the end-system reassembles and not the ETR. > o) Sec 5.5: While an Instance ID allows disambiguation of addresses, I > do not see any means of requesting or obtaining a EID-to-RLOC mapping. > There is no such field in the Map-Request or Map-Reply messages. It > doesn't work with [ALT]. Please add a paragraph such as: > > "While a LISP header can contain an Instance ID, there are currently > no provisions for requesting or receiving an EID-to-RLOC mapping > that considers Instance-IDs. A LISP-NAT (described in [INTWRK]) may > provide a better solution for private addresses. The use of > Instance-ID as described here is provided for future study." The AFI encoded addresses can carry different address formats. Once AFI is called LCAF. See draft-farinacci-lisp-lcaf-05.txt for details. > p) Sec 6.1: "The following new UDP packet types are used to retrieve > EID-to-RLOC mappings" > > Please change to the more accurate: > > "The following new UDP packet formats are used for LISP control > packets. The different packet types are listed in Sec. 6.1.1." I changed to the first sentence. Thanks. > Please move Sec 6.1.1 to before Sec 6.1 - so that readers know the > allocated packet types before reading the descriptive text. This part introduces UDP. We go the the LISP header in the next sub- section. That is why it was sequenced that way. Note in section 6 there is no details of the format of the "LISP Message". > After the packet formats, please change: > "The LISP UDP-based messages are the Map-Request and Map-Reply > messages. When a UDP Map-Request is sent, the UDP source port is > chosen by the sender and the destination UDP port number is set to > 4342. When a UDP Map-Reply is sent, the source UDP port number is > set to 4342 and the destination UDP port number is copied from the > source port of either the Map-Request or the invoking data packet." > > to > > "When a Map-Request or a Map-Register, encapsulated or not, is sent, > the UDP source port is chosen by the sender and the destination UDP > port number is set to 4342. When a Map-Reply or Map-Notify is sent, > the source UDP port number is set to 4342 and the destination UDP > port number is copied from the source port of either the Map-Request > or the invoking data packet." I prefer to not change it to what you suggest. Because you could imply from your text that a Map-Register message is encapsulated. And each section indicates how each packet is sent. > q) Sec 6.1.2: Is the A bit ever non-zero for a Map-Request? We did not want to specify it but we were thinking of an option where the Map-Request sender could request an authoritative request so if there were cachers of a matching mapping, that the cachers would send to the ETRs. > r) Sec 6.1.2: Why is the p bit needed? What does a ETR do based upon > the Map-Request coming from a PITR (or not)? It is useful for debugging. The ETR could cache the number of PITRs that have sent Map-Requests to it. > s) Sec 6.1.3 first paragraph: Without LISP encapsulation and a > Map Server, there isn't a way for an ITR to send a Map-Request to a > destination-EID. If the ITR is connected to the ALT, it can send the Map-Request to a destination EID. It assumes that the ALT carries EID-prefixes in its routing system. > The Mapping Service is required for operation - so it should be ok for Not true. > the draft to mention the interfaces to it! How about replacing this > first paragraph with the below: > > "An ITR can need to send a Map-Request for numerous reasons (e.g. to > get a mapping for an EID, testing an RLOC for reachability, or > refreshing a mapping before TTL expiry). When the ITR knows an RLOC > for the relevant ETR (e.g. from the map-cache entry), the ITR can > create a Map-Request destined directly to that RLOC. If the ITR > does not know the relevant ETR to query, then the Mapping Service > [LISP-MS] must be used. To do this, the ITR creates a Map-Request > destined to the destination-EID and LISP encapsulates it as an > "Encapsulated Control Message" that is destined to the Mapping > Service [LISP-MS]. When an ITR receives a successful Map-Reply, the > ITR updates the cached set of RLOCs associated with the EID prefix > range." We don't want to say this right here because there are too many options and if we reduce the set, we don't want to rewrite this text. The API to the mapping system that xTRs use are the Map-Request, Map- Reply, and Map-Register messages. That we don't want to change if we change the mapping system. Right now, the mapping system is pretty modular and it is easy to change in and out without modifications to ITRs and ETRs. > t) p.33 Record TTL: > "Record TTL: The time in minutes the recipient of the Map-Reply will > store the mapping. If the TTL is 0, the entry SHOULD be removed > from the cache immediately. If the value is 0xffffffff, the > recipient can decide locally how long to store the mapping." > > Since the ITR controls its own cache and cache entries, what I think > you meant and would be more clear is: > > "Record TTL: The maximum time in minutes that the recipient of the > Map-Reply may store the mapping. If the TTL is 0, the entry MUST > be removed from the cache immediately. IF the value is 0xFFFFFFFF, > the mapping does not expire and may be stored indefinitely." You changed "will" to "may". We wanted stronger language than what you provided. We don't want ITRs to ignore TTL values. > u) p. 33 No-Action: What packet encapsulation can happen!??!! There's > no RLOC to send the packet to! Please clarify. I will fix and say, the packet is dropped. Thanks. > v) p. 33 Drop: On dropping the packet, is the sender ever notified? > What about some ICMP for troubleshooting? Up to the implementation. > w) p. 34 Weight: Why is the ETR specifying that all locators get equal > weight used for the ITR getting to decide? This seems like a valid > decision by the ETR! Why not use weight=0 means ITR gets to decide as > clearly specified on p.44 first full bullet? The ETR allows the ITR to decide *within the highest priority* set of locators. > x) p. 36 Mapping Protocol Data: [ALT] does not use this field. Please > remove the reference. Agree, will remove. > y) p.46: What happens when two ITRs send different LSB information > (e.g. in the case of a partitioned LISP site)? The ETR can note the fact and decide to probe each one to find out what is going on. If the LSBs are in conflict, the ETR can conclude that the site is partitioned. > z) p.53 2nd paragraph from end: Unsolicited SMR-based Map-Requests > MUST be sent to the mapping database system seems like an easy way to > do a DDoS on the mapping database system - and have them all look > valid and authenticated. That is not what the 2nd paragraph on page 53 says. Again, this is confusing to parse since you don't sight the exact text. Map-Requests of all kind need to be rate-limited if the implementation is spec compliant. If not, then the MR should rate-limit accepting them. We did not specify this since there are all sorts of ways to mitigate this and more experimentation will be necessary to understand solutions better. > aa) Sec 7: How is a tunnel encapsulated packet received by an ETR with > an EID in the destination? Do you mean a non-LISP-tunnel encapsulated > packet?? Years ago we used a concept of data-probes. That was a map-request in the form of an encapsulated data packet where the inner destination and outer destination were the same value. This assumed the core carried EID-prefixes. This is still in the spec because there are people who believe packets should not be dropped while waiting for a Map-Reply to be returned to an ITR. > ab) Sec 8 last bullet: > "The technique of re-encapsulation ensures that packets only require > one tunnel header. So if a packet needs to be rerouted, it is first > decapsulated by the ETR and then re-encapsulated with a new tunnel > header using a new RLOC." > > When would this legitimately happen? It seems like risking looping... When you want to redirect your encapsulation to an intermediate point for TE purposes, packet scrubbing purposes, to go through a stateful firewall, etc. And the TTL copying rules make it not loop forever. > ac) Sec 14: The list of LISP Control Packet types (Sec 6.1.1) should > also be an IANA registry... That has not been decided by the working group. > Looking forward to your responses, > Alia Thanks again, Dino/Vince/Darrel/Dave From terry.manderson@icann.org Mon Jun 20 20:55:11 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145EA21F84C2 for ; Mon, 20 Jun 2011 20:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyxbeS5xDPKq for ; Mon, 20 Jun 2011 20:55:10 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9C84021F84C0 for ; Mon, 20 Jun 2011 20:55:10 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 20 Jun 2011 20:55:10 -0700 From: Terry Manderson To: "lisp@ietf.org" Date: Mon, 20 Jun 2011 20:55:08 -0700 Thread-Topic: [lisp] last call for draft-ietf-lisp-alt-06 Thread-Index: AcwIXSATFgTVdxlqJUa2fJ2WScXDWgnaeLI9 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lisp] last call for draft-ietf-lisp-alt-06 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2011 03:55:11 -0000 We, the Co-Chairs, are calling the LC closed for this item. It was held open beyond the end date to ensure adequate time was given for substantive review. The write-up will commence soon. Thanks Terry On 2/05/11 10:08 AM, "Terry Manderson" wrote: > All, >=20 > The authors of draft-ietf-lisp-alt-06 have requested a work group last ca= ll. >=20 > Here starts the last call for this document, Joel and I will end the last > call on Monday the 16th May, 2011. >=20 > Please review the draft and provide any last comments. >=20 > Cheers > Terry >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From terry.manderson@icann.org Mon Jun 20 20:56:02 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95A6228003 for ; Mon, 20 Jun 2011 20:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqFo2XJ7XGa4 for ; Mon, 20 Jun 2011 20:56:02 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5CF11E80DB for ; Mon, 20 Jun 2011 20:55:23 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Mon, 20 Jun 2011 20:55:22 -0700 From: Terry Manderson To: "lisp@ietf.org" Date: Mon, 20 Jun 2011 20:55:20 -0700 Thread-Topic: [lisp] last call for draft-ietf-lisp-lig-02 Thread-Index: AcwIXQcKbIZ7qf1RM0atzvLX/oHXqwnagL4M Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lisp] last call for draft-ietf-lisp-lig-02 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2011 03:56:02 -0000 We, the Co-Chairs, are calling the LC closed for this item. It was held open beyond the end date to ensure adequate time was given for substantive review. The write-up will commence soon. Thanks Terry On 2/05/11 10:08 AM, "Terry Manderson" wrote: > All, >=20 > The authors of draft-ietf-lisp-lig-02 have requested a work group last ca= ll. >=20 > Here starts the last call for this document, Joel and I will end the last > call on Monday the 16th May, 2011. >=20 > Please review the draft and provide any last comments. >=20 > Cheers > Terry >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From terry.manderson@icann.org Mon Jun 20 20:56:03 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A273228009 for ; Mon, 20 Jun 2011 20:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzqGWrxUceFY for ; Mon, 20 Jun 2011 20:56:02 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 67F1B11E8190 for ; Mon, 20 Jun 2011 20:55:27 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 20 Jun 2011 20:55:27 -0700 From: Terry Manderson To: Terry Manderson , "lisp@ietf.org" Date: Mon, 20 Jun 2011 20:55:24 -0700 Thread-Topic: [lisp] last call for draft-ietf-lisp-map-versioning-01 Thread-Index: AcwIXP4ZAZvj0IKBPUCGA+5+28fNQgnag5P6 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lisp] last call for draft-ietf-lisp-map-versioning-01 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2011 03:56:03 -0000 We, the Co-Chairs, are calling the LC closed for this item. It was held open beyond the end date to ensure adequate time was given for substantive review. The write-up will commence soon. Thanks Terry On 2/05/11 10:07 AM, "Terry Manderson" wrote: > All, >=20 > The authors of draft-ietf-lisp-map-versioning-01 have requested a work gr= oup > last call. >=20 > Here starts the last call for this document, Joel and I will end the last > call on Monday the 16th May, 2011. >=20 > Please review the draft and provide any last comments. >=20 > Cheers > Terry >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From terry.manderson@icann.org Mon Jun 20 20:56:09 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33CB411E80ED for ; Mon, 20 Jun 2011 20:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14Ipra0Lc0uh for ; Mon, 20 Jun 2011 20:56:08 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 56F2B11E8100 for ; Mon, 20 Jun 2011 20:55:51 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Mon, 20 Jun 2011 20:55:50 -0700 From: Terry Manderson To: "lisp@ietf.org" Date: Mon, 20 Jun 2011 20:55:47 -0700 Thread-Topic: [lisp] last call for draft-ietf-lisp-ms-08 Thread-Index: AcwIXSYIOXpie1W8MEKPUF2qJj5lCAnafQVx Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lisp] last call for draft-ietf-lisp-ms-08 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2011 03:56:09 -0000 We, the Co-Chairs, are calling the LC closed for this item. It was held open beyond the end date to ensure adequate time was given for substantive review. The write-up will commence soon. Thanks Terry On 2/05/11 10:09 AM, "Terry Manderson" wrote: > All, >=20 > The authors of draft-ietf-lisp-ms-08 have requested a work group last cal= l. >=20 > Here starts the last call for this document, Joel and I will end the last > call on Monday the 16th May, 2011. >=20 > Please review the draft and provide any last comments. >=20 > Cheers > Terry >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From internet-drafts@ietf.org Tue Jun 21 14:21:08 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3831F0C41; Tue, 21 Jun 2011 14:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwkxwwZl3ytN; Tue, 21 Jun 2011 14:21:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB551F0C38; Tue, 21 Jun 2011 14:21:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110621212105.13573.17290.idtracker@ietfa.amsl.com> Date: Tue, 21 Jun 2011 14:21:05 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-13.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2011 21:21:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : Locator/ID Separation Protocol (LISP) Author(s) : Dino Farinacci Vince Fuller Dave Meyer Darrel Lewis Filename : draft-ietf-lisp-13.txt Pages : 90 Date : 2011-06-21 This draft describes a network-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. LISP can be incrementally deployed, without a "flag day", and offers traffic engineering, multi-homing, and mobility benefits even to early adopters, when there are relatively few LISP- capable sites. Design and development of LISP was largely motivated by the problem statement produced by the October, 2006 IAB Routing and Addressing Workshop. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-13.txt From dino@cisco.com Tue Jun 21 14:26:14 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF52D1F0C3E for ; Tue, 21 Jun 2011 14:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVdGCDfy1MMV for ; Tue, 21 Jun 2011 14:26:14 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id B85141F0C38 for ; Tue, 21 Jun 2011 14:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=560713; q=dns/txt; s=iport; t=1308691573; x=1309901173; h=message-id:from:to:mime-version:subject:date; bh=8PjpsVAVxHFG1pZqwAKXavvX5lebOGiS/0EkancVO+Y=; b=XaDEM/PkeCgpoExHdn6nR3vS6h9MSdsG7Th2/0rYnhZNtycViOBbElm3 jwoNT02tLEbtY/zmOpLp6BKYwKUVTJTCCT2gMfBorPtSYZuV7OlbnsRCQ fkIvgEaWh58pWRx4ttm3k7qoNoEVaZAofXvQCOkU2UXS4IXwWzS5HtoPt 8=; X-Files: rfcdiff-lisp-12-to-13.html, draft-ietf-lisp-13.txt, rfcdiff-lisp-multicast-05-to-06.html, draft-ietf-lisp-multicast-06.txt : 197781, 201281, 71272, 73867 X-IronPort-AV: E=Sophos;i="4.65,402,1304294400"; d="txt'?html'217?scan'217,208,217";a="382598785" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 21 Jun 2011 21:26:13 +0000 Received: from [172.16.31.204] (sjc-vpn5-1204.cisco.com [10.21.92.180]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5LLQ9tF008536 for ; Tue, 21 Jun 2011 21:26:09 GMT Message-Id: From: Dino Farinacci To: lisp@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-3--328112272 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 21 Jun 2011 14:26:09 -0700 X-Mailer: Apple Mail (2.936) Subject: [lisp] New revs of draft-ietf-lisp and draft-ietf-lisp-multicast X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jun 2011 21:26:15 -0000 --Apple-Mail-3--328112272 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Folks, the chairs have asked the authors to post a new revision of draft-ietf-lisp, draft-ietf-lisp-multicast, draft-ietf-lisp-ms, draft- ietf-lisp-alt, and draft-ietf-lisp-interwork to conclude working group last call. The latter 3 are coming but the main and multicast drafts have been posted, the drafts are enclosed, and diff files are enclosed. Here are a summary of changes: B.1. Changes to draft-ietf-lisp-13.txt o Posted June 2011 to complete working group last call. o Tracker item 87. Put Yakov suggested wording in the EID-prefix definition section to reference [INTERWORK] and [LISP-DEPLOY] about discussion on transition and access mechanisms. o Change "ITRs" to "ETRs" in the Locator Status Bit definition section and data packet description section per Damien's comment. o Remove the normative reference to [LISP-SEC] when describing the S-bit in the ECM and Map-Reply headers. o Tracker item 54. Added text from John Scudder in the "Packets Egressing a LISP Site" section. o Add sentence to the "Reencapsulating Tunnel" definition about how reencapsulation loops can occur when not coordinating among multiple mapping database systems. o Remove "In theory" from a sentence in the Security Considerations section. o Remove Security Area Statement title and reword section with Eliot's provided text. The text was agreed upon by LISP-WG chairs and Security ADs. o Remove word "potential" from the over-claiming paragraph of the Security Considerations section per Stephen's request. o Wordsmithing and other editorial comments from Alia. A.1. Changes to draft-ietf-lisp-multicast-06.txt o Posted June 2011 to complete working group last call. o Added paragraph to section 8.1.2 based on Jesus comment about making it more clear what happens when two (S-EID,G) trees use the same (RLOC,G) tree. o Make more references to [INTWORK] when mentioning uPITRs and uPETRs. o Made many changes based on editorial and wordsmithing comments from Alia. Thanks, Dino/Darrel/Vince/Dave/Stig/JohnZ --Apple-Mail-3--328112272 Content-Disposition: attachment; filename=rfcdiff-lisp-12-to-13.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-lisp-12-to-13.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-12.txt draft-ietf-lisp-13.txt 
Network Working Group                                       D. Farinacci
Internet-Draft                                                 V. Fuller
Intended status: Experimental                                   D. Meyer
Expires: October 28, December 23, 2011                                      D. Lewis
                                                           cisco Systems
                                                          April 26,
                                                           June 21, 2011

                 Locator/ID Separation Protocol (LISP)
                           draft-ietf-lisp-12
                           draft-ietf-lisp-13

Abstract

   This draft describes a network-based protocol that enables separation
   of IP addresses into two new numbering spaces: Endpoint Identifiers
   (EIDs) and Routing Locators (RLOCs).  No changes are required to
   either host protocol stacks or to the "core" of the Internet
   infrastructure.  LISP can be incrementally deployed, without a "flag
   day", and offers traffic engineering, multi-homing, and mobility
   benefits even to early adopters, when there are relatively few LISP-
   capable sites.

   Design and development of LISP was largely motivated by the problem
   statement produced by the October, 2006 IAB Routing and Addressing
   Workshop.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 28, December 23, 2011.

Copyright Notice

   Copyright (c) 2011 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 BSD License.

Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  7
   4.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14
   5.  LISP Encapsulation Details . . . . . . . . . . . . . . . . . . 16
     5.1.  LISP IPv4-in-IPv4 Header Format  . . . . . . . . . . . . . 17
     5.2.  LISP IPv6-in-IPv6 Header Format  . . . . . . . . . . . . . 17
     5.3.  Tunnel Header Field Descriptions . . . . . . . . . . . . . 19
     5.4.  Dealing with Large Encapsulated Packets  . . . . . . . . . 22
       5.4.1.  A Stateless Solution to MTU Handling . . . . . . . . . 23
       5.4.2.  A Stateful Solution to MTU Handling  . . . . . . . . . 24
     5.5.  Using Virtualization and Segmentation with LISP  . . . . . 24
   6.  EID-to-RLOC Mapping  . . . . . . . . . . . . . . . . . . . . . 26
     6.1.  LISP IPv4 and IPv6 Control Plane Packet Formats  . . . . . 26
       6.1.1.  LISP Packet Type Allocations . . . . . . . . . . . . . 28
       6.1.2.  Map-Request Message Format . . . . . . . . . . . . . . 28
       6.1.3.  EID-to-RLOC UDP Map-Request Message  . . . . . . . . . 31
       6.1.4.  Map-Reply Message Format . . . . . . . . . . . . . . . 32
       6.1.5.  EID-to-RLOC UDP Map-Reply Message  . . . . . . . . . . 36
       6.1.6.  Map-Register Message Format  . . . . . . . . . . . . . 38
       6.1.7.  Map-Notify Message Format  . . . . . . . . . . . . . . 40
       6.1.8.  Encapsulated Control Message Format  . . . . . . . . . 41
     6.2.  Routing Locator Selection  . . . . . . . . . . . . . . . . 43
     6.3.  Routing Locator Reachability . . . . . . . . . . . . . . . 45
       6.3.1.  Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 47
       6.3.2.  RLOC Probing Algorithm . . . . . . . . . . . . . . . . 48
     6.4.  EID Reachability within a LISP Site  . . . . . . . . . . . 49
     6.5.  Routing Locator Hashing  . . . . . . . . . . . . . . . . . 50
     6.6.  Changing the Contents of EID-to-RLOC Mappings  . . . . . . 50
       6.6.1.  Clock Sweep  . . . . . . . . . . . . . . . . . . . . . 51
       6.6.2.  Solicit-Map-Request (SMR)  . . . . . . . . . . . . . . 52
       6.6.3.  Database Map Versioning  . . . . . . . . . . . . . . . 54
   7.  Router Performance Considerations  . . . . . . . . . . . . . . 55
   8.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 56
     8.1.  First-hop/Last-hop Tunnel Routers  . . . . . . . . . . . . 57
     8.2.  Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 57
     8.3.  ISP Provider-Edge (PE) Tunnel Routers  . . . . . . . . . . 58
     8.4.  LISP Functionality with Conventional NATs  . . . . . . . . 58
     8.5.  Packets Egressing a LISP Site  . . . . . . . . . . . . . . 59
   9.  Traceroute Considerations  . . . . . . . . . . . . . . . . . . 60
     9.1.  IPv6 Traceroute  . . . . . . . . . . . . . . . . . . . . . 61
     9.2.  IPv4 Traceroute  . . . . . . . . . . . . . . . . . . . . . 61
     9.3.  Traceroute using Mixed Locators  . . . . . . . . . . . . . 61
   10. Mobility Considerations  . . . . . . . . . . . . . . . . . . . 63
     10.1. Site Mobility  . . . . . . . . . . . . . . . . . . . . . . 63
     10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 63
     10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 63
     10.4. Fast Network Mobility  . . . . . . . . . . . . . . . . . . 65
     10.5. LISP Mobile Node Mobility  . . . . . . . . . . . . . . . . 65
   11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 67
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 68
     12.1. IETF Security Area Statement . . . . . . . . . . . . . . . 69
   13. Network Management Considerations  . . . . . . . . . . . . . . 70
   14. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 71
     14.1. LISP Address Type Codes  . . . . . . . . . . . . . . . . . 71
     14.2. LISP UDP Port Numbers  . . . . . . . . . . . . . . . . . . 71
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 72
     15.2. Informative References . . . . . . . . . . . . . . . . . . 73
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 76 77
   Appendix B.  Document Change Log . . . . . . . . . . . . . . . . . 77 78
     B.1.  Changes to draft-ietf-lisp-12.txt draft-ietf-lisp-13.txt  . . . . . . . . . . . . 77 78
     B.2.  Changes to draft-ietf-lisp-11.txt draft-ietf-lisp-12.txt  . . . . . . . . . . . . 78
     B.3.  Changes to draft-ietf-lisp-10.txt draft-ietf-lisp-11.txt  . . . . . . . . . . . . 79 80
     B.4.  Changes to draft-ietf-lisp-09.txt draft-ietf-lisp-10.txt  . . . . . . . . . . . . 79 80
     B.5.  Changes to draft-ietf-lisp-08.txt draft-ietf-lisp-09.txt  . . . . . . . . . . . . 80 81
     B.6.  Changes to draft-ietf-lisp-07.txt draft-ietf-lisp-08.txt  . . . . . . . . . . . . 81
     B.7.  Changes to draft-ietf-lisp-06.txt draft-ietf-lisp-07.txt  . . . . . . . . . . . . 83
     B.8.  Changes to draft-ietf-lisp-05.txt draft-ietf-lisp-06.txt  . . . . . . . . . . . . 84 85
     B.9.  Changes to draft-ietf-lisp-04.txt draft-ietf-lisp-05.txt  . . . . . . . . . . . . 85 86
     B.10. Changes to draft-ietf-lisp-03.txt draft-ietf-lisp-04.txt  . . . . . . . . . . . . 86
     B.11. Changes to draft-ietf-lisp-02.txt draft-ietf-lisp-03.txt  . . . . . . . . . . . . 87 88
     B.12. Changes to draft-ietf-lisp-01.txt draft-ietf-lisp-02.txt  . . . . . . . . . . . . 87 88
     B.13. Changes to draft-ietf-lisp-01.txt  . . . . . . . . . . . . 89
     B.14. Changes to draft-ietf-lisp-00.txt  . . . . . . . . . . . . 87 89
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 88 90

1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   This document describes the Locator/Identifier Separation Protocol
   (LISP), which provides a set of functions for routers to exchange
   information used to map from non-routeable Endpoint Identifiers
   (EIDs) to routeable Routing Locators (RLOCs).  It also defines a
   mechanism for these LISP routers to encapsulate IP packets addressed
   with EIDs for transmission across an Internet that uses RLOCs for
   routing and forwarding.

   Creation of LISP was initially motivated by discussions during the
   IAB-sponsored Routing and Addressing Workshop held in Amsterdam in
   October, 2006 (see [RFC4984]).  A key conclusion of the workshop was
   that the Internet routing and addressing system was not scaling well
   in the face of the explosive growth of new sites; one reason for this
   poor scaling is the increasing number of multi-homed and other sites
   that cannot be addressed as part of topologically- or provider-based
   aggregated prefixes.  Additional work that more completely described
   the problem statement may be found in [RADIR].

   A basic observation, made many years ago in early networking research
   such as that documented in [CHIAPPA] and [RFC4984], is that using a
   single address field for both identifying a device and for
   determining where it is topologically located in the network requires
   optimization along two conflicting axes: for routing to be efficient,
   the address must be assigned topologically; for collections of
   devices to be easily and effectively managed, without the need for
   renumbering in response to topological change (such as that caused by
   adding or removing attachment points to the network or by mobility
   events), the address must explicitly not be tied to the topology.

   The approach that LISP takes to solving the routing scalability
   problem is to replace IP addresses with two new types of numbers:
   Routing Locators (RLOCs), which are topologically assigned to network
   attachment points (and are therefore amenable to aggregation) and
   used for routing and forwarding of packets through the network; and
   Endpoint Identifiers (EIDs), which are assigned independently from
   the network topology, are used for numbering devices, and are
   aggregated along administrative boundaries.  LISP then defines
   functions for mapping between the two numbering spaces and for
   encapsulating traffic originated by devices using non-routeable EIDs
   for transport across a network infrastructure that routes and
   forwards using RLOCs.  Both RLOCs and EIDs are syntactically-
   identical to IP addresses; it is the semantics of how they are used
   that differs.

   This document describes the protocol that implements these functions.
   The database which stores the mappings between EIDs and RLOCs is
   explicitly a separate "module" to facilitate experimentation with a
   variety of approaches.  One database design that is being developed
   and prototyped as part of the LISP working group work is [ALT].
   Others that have been described but not implemented include [CONS],
   [EMACS], [RPMD], [NERD].  Finally, [LISP-MS], documents a general-
   purpose service interface for accessing a mapping database; this
   interface is intended to make the mapping database modular so that
   different approaches can be tried without the need to modify
   installed xTRs.

   This experimental specification does not address automated key
   management.  Addressing automated key management which would be required is necessary for an
   Internet standard
   equivalent. standards.  See Section 12.1 12 for further security details.

3.  Definition of Terms

   Provider Independent (PI) Addresses:   PI addresses are an address
      block assigned from a pool where blocks are not associated with
      any particular location in the network (e.g. from a particular
      service provider), and is therefore not topologically aggregatable
      in the routing system.

   Provider Assigned (PA) Addresses:   PA addresses are an a address
      block assigned to a site by each service provider to which a site
      connects.  Typically, each block is sub-block of a service
      provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and
      is aggregated into the larger block before being advertised into
      the global Internet.  Traditionally, IP multihoming has been
      implemented by each multi-homed site acquiring its own, globally-
      visible prefix.  LISP uses only topologically-assigned and
      aggregatable address blocks for RLOCs, eliminating this
      demonstrably non-scalable practice.

   Routing Locator (RLOC):   A RLOC is an IPv4 or IPv6 address of an
      egress tunnel router (ETR).  A RLOC is the output of a EID-to-RLOC
      mapping lookup.  An EID maps to one or more RLOCs.  Typically,
      RLOCs are numbered from topologically-aggregatable blocks that are
      assigned to a site at each point to which it attaches to the
      global Internet; where the topology is defined by the connectivity
      of provider networks, RLOCs can be thought of as PA addresses.
      Multiple RLOCs can be assigned to the same ETR device or to
      multiple ETR devices at a site.

   Endpoint ID (EID):   An EID is a 32-bit (for IPv4) or 128-bit (for
      IPv6) value used in the source and destination address fields of
      the first (most inner) LISP header of a packet.  The host obtains
      a destination EID the same way it obtains an destination address
      today, for example through a Domain Name System (DNS) [RFC1034]
      lookup or Session Invitation Protocol (SIP) [RFC3261] exchange.
      The source EID is obtained via existing mechanisms used to set a
      host's "local" IP address.  An EID is allocated to a host from an
      EID-prefix block associated with the site where the host is
      located.  An EID can be used by a host to refer to other hosts.
      EIDs MUST NOT be used as LISP RLOCs.  Note that EID blocks may be
      assigned in a hierarchical manner, independent of the network
      topology, to facilitate scaling of the mapping database.  In
      addition, an EID block assigned to a site may have site-local
      structure (subnetting) for routing within the site; this structure
      is not visible to the global routing system.  When used in
      discussions with other Locator/ID separation proposals, a LISP EID
      will be called a "LEID".  Throughout this document, any references
      to "EID" refers to an LEID.

   EID-prefix:   An EID-prefix is a power-of-two block of EIDs which are
      allocated to a site by an address allocation authority.  EID-
      prefixes are associated with a set of RLOC addresses which make up
      a "database mapping".  EID-prefix allocations can be broken up
      into smaller blocks when an RLOC set is to be associated with the
      smaller EID-prefix.  A globally routed address block (whether PI
      or PA) is not inherently an EID-prefix.  A globally routed address
      block may be used by its assignee as an EID block.  The converse
      is not supported.  That is, a site which receives an explicitly
      allocated EID-prefix may not use that EID-prefix as a globally
      prefix.  This would require coordination and cooperation with the
      entities managing the mapping infrastructure.  Once this has been
      done, that block could be removed from the globally routed IP
      system, if other suitable transition and access mechanisms are in
      place.  The
      converse is not supported.  That is, a site which receives an
      explicitly allocated EID-prefix may not use that EID-prefix as a
      globally prefix.  Discussion of such transition and access mechanisms can be
      found in [INTERWORK] and [LISP-DEPLOY].

   End-system:   An end-system is an IPv4 or IPv6 device that originates
      packets with a single IPv4 or IPv6 header.  The end-system
      supplies an EID value for the destination address field of the IP
      header when communicating globally (i.e. outside of its routing
      domain).  An end-system can be a host computer, a switch or router
      device, or any network appliance.

   Ingress Tunnel Router (ITR):   An ITR is a router which accepts an IP
      packet with a single IP header (more precisely, an IP packet that
      does not contain a LISP header).  The router treats this "inner"
      IP destination address as an EID and performs an EID-to-RLOC
      mapping lookup.  The router then prepends an "outer" IP header
      with one of its globally-routable RLOCs in the source address
      field and the result of the mapping lookup in the destination
      address field.  Note that this destination RLOC may be an
      intermediate, proxy device that has better knowledge of the EID-
      to-RLOC mapping closer to the destination EID.  In general, an ITR
      receives IP packets from site end-systems on one side and sends
      LISP-encapsulated IP packets toward the Internet on the other
      side.

      Specifically, when a service provider prepends a LISP header for
      Traffic Engineering purposes, the router that does this is also
      regarded as an ITR.  The outer RLOC the ISP ITR uses can be based
      on the outer destination address (the originating ITR's supplied
      RLOC) or the inner destination address (the originating hosts
      supplied EID).

   TE-ITR:   A TE-ITR is an ITR that is deployed in a service provider
      network that prepends an additional LISP header for Traffic
      Engineering purposes.

   Egress Tunnel Router (ETR):   An ETR is a router that accepts an IP
      packet where the destination address in the "outer" IP header is
      one of its own RLOCs.  The router strips the "outer" header and
      forwards the packet based on the next IP header found.  In
      general, an ETR receives LISP-encapsulated IP packets from the
      Internet on one side and sends decapsulated IP packets to site
      end-systems on the other side.  ETR functionality does not have to
      be limited to a router device.  A server host can be the endpoint
      of a LISP tunnel as well.

   TE-ETR:   A TE-ETR is an ETR that is deployed in a service provider
      network that strips an outer LISP header for Traffic Engineering
      purposes.

   xTR:   A xTR is a reference to an ITR or ETR when direction of data
      flow is not part of the context description. xTR refers to the
      router that is the tunnel endpoint.  Used synonymously with the
      term "Tunnel Router".  For example, "An xTR can be located at the
      Customer Edge (CE) router", meaning both ITR and ETR functionality
      is at the CE router.

   EID-to-RLOC Cache:   The EID-to-RLOC cache is a short-lived, on-
      demand table in an ITR that stores, tracks, and is responsible for
      timing-out and otherwise validating EID-to-RLOC mappings.  This
      cache is distinct from the full "database" of EID-to-RLOC
      mappings, it is dynamic, local to the ITR(s), and relatively small
      while the database is distributed, relatively static, and much
      more global in scope.

   EID-to-RLOC Database:   The EID-to-RLOC database is a global
      distributed database that contains all known EID-prefix to RLOC
      mappings.  Each potential ETR typically contains a small piece of
      the database: the EID-to-RLOC mappings for the EID prefixes
      "behind" the router.  These map to one of the router's own,
      globally-visible, IP addresses.  The same database mapping entries
      MUST be configured on all ETRs for a given site.  In a steady
      state the EID-prefixes for the site and the locator-set for each
      EID-prefix MUST be the same on all ETRs.  Procedures to enforce
      and/or verify this are outside the scope of this document.  Note
      that there may be transient conditions when the EID-prefix for the
      site and locator-set for each EID-prefix may not be the same on
      all ETRs.  This has no negative implications.

   Recursive Tunneling:   Recursive tunneling occurs when a packet has
      more than one LISP IP header.  Additional layers of tunneling may
      be employed to implement traffic engineering or other re-routing
      as needed.  When this is done, an additional "outer" LISP header
      is added and the original RLOCs are preserved in the "inner"
      header.  Any references to tunnels in this specification refers to
      dynamic encapsulating tunnels and never are they statically
      configured.

   Reencapsulating Tunnels:   Reencapsulating tunneling occurs when an
      ETR removes a LISP header, then acts as an ITR to prepend another
      LISP header.  Doing this allows a packet to be re-routed by the
      re-encapsulating router without adding the overhead of additional
      tunnel headers.  Any references to tunnels in this specification
      refers to dynamic encapsulating tunnels and never are they
      statically configured.  When using multiple mapping database
      systems, care must be taken to not create reencapsulation loops.

   LISP Header:   a term used in this document to refer to the outer
      IPv4 or IPv6 header, a UDP header, and a LISP-specific 8-byte
      header that follows the UDP header, an ITR prepends or an ETR
      strips.

   Address Family Identifier (AFI):   a term used to describe an address
      encoding in a packet.  An address family currently pertains to an
      IPv4 or IPv6 address.  See [AFI] [AFI]/[AFI-REGISTRY] and [RFC1700] for
      details.  An AFI value of 0 used in this specification indicates
      an unspecified encoded address where the length of the address is
      0 bytes following the 16-bit AFI value of 0.

   Negative Mapping Entry:   A negative mapping entry, also known as a
      negative cache entry, is an EID-to-RLOC entry where an EID-prefix
      is advertised or stored with no RLOCs.  That is, the locator-set
      for the EID-to-RLOC entry is empty or has an encoded locator count
      of 0.  This type of entry could be used to describe a prefix from
      a non-LISP site, which is explicitly not in the mapping database.
      There are a set of well defined actions that are encoded in a
      Negative Map-Reply.

   Data Probe:   A data-probe is a LISP-encapsulated data packet where
      the inner header destination address equals the outer header
      destination address used to trigger a Map-Reply by a decapsulating
      ETR.  In addition, the original packet is decapsulated and
      delivered to the destination host.  A Data Probe is used in some
      of the mapping database designs to "probe" or request a Map-Reply
      from an ETR; in other cases, Map-Requests are used.  See each
      mapping database design for details.

   Proxy ITR (PITR):   A PITR is also known as a PTR is defined and
      described in [INTERWORK], a PITR acts like an ITR but does so on
      behalf of non-LISP sites which send packets to destinations at
      LISP sites.

   Proxy ETR (PETR):   A PETR is defined and described in [INTERWORK], a
      PETR acts like an ETR but does so on behalf of LISP sites which
      send packets to destinations at non-LISP sites.

   Route-returnability:  is an assumption that the underlying routing
      system will deliver packets to the destination.  When combined
      with a nonce that is provided by a sender and returned by a
      receiver limits off-path data insertion.

   LISP site:  is a set of routers in an edge network that are under a
      single technical administration.  LISP routers which reside in the
      edge network are the demarcation points to separate the edge
      network from the core network.

   Client-side:  a term used in this document to indicate a connection
      initiation attempt by an EID.  The ITR(s) at the LISP site are the
      first to get involved in obtaining database map cache entries by
      sending Map-Request messages.

   Server-side:  a term used in this document to indicate a connection
      initiation attempt is being accepted for a destination EID.  The
      ETR(s) at the destination LISP site are the first to send Map-
      Replies to the source site initiating the connection.  The ETR(s)
      at this destination site can obtain mappings by gleaning
      information from Map-Requests, Data-Probes, or encapsulated
      packets.

   Locator-Status-Bits (LSBs):  Locator status bits are present in the
      LISP header.  They are used by ITRs to inform ETRs about the up/
      down status of all ITRs ETRs at the local site.  These bits are used as
      a hint to convey up/down router status and not path reachability
      status.  The LSBs can be verified by use of one of the Locator
      Reachability Algoriths described in Section 6.3.

4.  Basic Overview

   One key concept of LISP is that end-systems (hosts) operate the same
   way they do today.  The IP addresses that hosts use for tracking
   sockets, connections, and for sending and receiving packets do not
   change.  In LISP terminology, these IP addresses are called Endpoint
   Identifiers (EIDs).

   Routers continue to forward packets based on IP destination
   addresses.  When a packet is LISP encapsulated, these addresses are
   referred to as Routing Locators (RLOCs).  Most routers along a path
   between two hosts will not change; they continue to perform routing/
   forwarding lookups on the destination addresses.  For routers between
   the source host and the ITR as well as routers from the ETR to the
   destination host, the destination address is an EID.  For the routers
   between the ITR and the ETR, the destination address is an RLOC.

   Another key LISP concept is the "Tunnel Router".  A tunnel router
   prepends LISP headers on host-originated packets and strip them prior
   to final delivery to their destination.  The IP addresses in this
   "outer header" are RLOCs.  During end-to-end packet exchange between
   two Internet hosts, an ITR prepends a new LISP header to each packet
   and an egress tunnel router strips the new header.  The ITR performs
   EID-to-RLOC lookups to determine the routing path to the ETR, which
   has the RLOC as one of its IP addresses.

   Some basic rules governing LISP are:

   o  End-systems (hosts) only send to addresses which are EIDs.  They
      don't know addresses are EIDs versus RLOCs but assume packets get
      to LISP routers, which in turn, deliver packets to the destination
      the end-system has specified.

   o  EIDs are always IP addresses assigned to hosts.

   o  LISP routers mostly deal with Routing Locator addresses.  See
      details later in Section 4.1 to clarify what is meant by "mostly".

   o  RLOCs are always IP addresses assigned to routers; preferably,
      topologically-oriented addresses from provider CIDR blocks.

   o  When a router originates packets it may use as a source address
      either an EID or RLOC.  When acting as a host (e.g. when
      terminating a transport session such as SSH, TELNET, or SNMP), it
      may use an EID that is explicitly assigned for that purpose.  An
      EID that identifies the router as a host MUST NOT be used as an
      RLOC; an EID is only routable within the scope of a site.  A
      typical BGP configuration might demonstrate this "hybrid" EID/RLOC
      usage where a router could use its "host-like" EID to terminate
      iBGP sessions to other routers in a site while at the same time
      using RLOCs to terminate eBGP sessions to routers outside the
      site.

   o  EIDs are not expected to be usable for global end-to-end
      communication in the absence of an EID-to-RLOC mapping operation.
      They are expected to be used locally for intra-site communication.

   o  EID prefixes are likely to be hierarchically assigned in a manner
      which is optimized for administrative convenience and to
      facilitate scaling of the EID-to-RLOC mapping database.  The
      hierarchy is based on a address allocation hierarchy which is
      independent of the network topology.

   o  EIDs may also be structured (subnetted) in a manner suitable for
      local routing within an autonomous system.

   An additional LISP header may be prepended to packets by a TE-ITR
   when re-routing of the path for a packet is desired.  An obvious
   instance of  A potential
   use-case for this would be an ISP router that needs to perform
   traffic engineering for packets flowing through its network.  In such
   a situation, termed Recursive Tunneling, an ISP transit acts as an
   additional ingress tunnel router and the RLOC it uses for the new
   prepended header would be either a TE-ETR within the ISP (along
   intra-ISP traffic engineered path) or a TE-ETR within another ISP (an
   inter-ISP traffic engineered path, where an agreement to build such a
   path exists).

   In order to avoid excessive packet overhead as well as possible
   encapsulation loops, this document mandates that a maximum of two
   LISP headers can be prepended to a packet.  It  For initial LISP
   deployments, it is believed assumed two headers is sufficient, where the first
   prepended header is used at a site for Location/Identity separation
   and second prepended header is used inside a service provider for
   Traffic Engineering purposes.

   Tunnel Routers can be placed fairly flexibly in a multi-AS topology.
   For example, the ITR for a particular end-to-end packet exchange
   might be the first-hop or default router within a site for the source
   host.  Similarly, the egress tunnel router might be the last-hop
   router directly-connected to the destination host.  Another example,
   perhaps for a VPN service out-sourced to an ISP by a site, the ITR
   could be the site's border router at the service provider attachment
   point.  Mixing and matching of site-operated, ISP-operated, and other
   tunnel routers is allowed for maximum flexibility.  See Section 8 for
   more details.

4.1.  Packet Flow Sequence

   This section provides an example of the unicast packet flow with the
   following conditions:

   o  Source host "host1.abc.com" is sending a packet to
      "host2.xyz.com", exactly what host1 would do if the site was not
      using LISP.

   o  Each site is multi-homed, so each tunnel router has an address
      (RLOC) assigned from the service provider address block for each
      provider to which that particular tunnel router is attached.

   o  The ITR(s) and ETR(s) are directly connected to the source and
      destination, respectively, but the source and destination can be
      located anywhere in LISP site.

   o  Map-Requests can be sent on the underlying routing system topology
      or over an alternative topology [ALT].

   o  Map-Replies are sent on the underlying routing system topology.

   Client host1.abc.com wants to communicate with server host2.xyz.com:

   1.  host1.abc.com wants to open a TCP connection to host2.xyz.com.
       It does a DNS lookup on host2.xyz.com.  An A/AAAA record is
       returned.  This address is the destination EID.  The locally-
       assigned address of host1.abc.com is used as the source EID.  An
       IPv4 or IPv6 packet is built and forwarded through the LISP site
       as a normal IP packet until it reaches a LISP ITR.

   2.  The LISP ITR must be able to map the EID destination to an RLOC
       of one of the ETRs at the destination site.  The specific method
       used to do this is not described in this example.  See [ALT] or
       [CONS] for possible solutions.

   3.  The ITR will send a LISP Map-Request.  Map-Requests SHOULD be
       rate-limited.

   4.  When an alternate mapping system is not in use, the Map-Request
       packet is routed through the underlying routing system.
       Otherwise, the Map-Request packet is routed on an alternate
       logical topology.  In either case, when the Map-Request arrives
       at one of the ETRs at the destination site, it will process the
       packet as a control message.

   5.  The ETR looks at the destination EID of the Map-Request and
       matches it against the prefixes in the ETR's configured EID-to-
       RLOC mapping database.  This is the list of EID-prefixes the ETR
       is supporting for the site it resides in.  If there is no match,
       the Map-Request is dropped.  Otherwise, a LISP Map-Reply is
       returned to the ITR.

   6.  The ITR receives the Map-Reply message, parses the message (to
       check for format validity) and stores the mapping information
       from the packet.  This information is stored in the ITR's EID-to-
       RLOC mapping cache.  Note that the map cache is an on-demand
       cache.  An ITR will manage its map cache in such a way that
       optimizes for its resource constraints.

   7.  Subsequent packets from host1.abc.com to host2.xyz.com will have
       a LISP header prepended by the ITR using the appropriate RLOC as
       the LISP header destination address learned from the ETR.  Note
       the packet may be sent to a different ETR than the one which
       returned the Map-Reply due to the source site's hashing policy or
       the destination site's locator-set policy.

   8.  The ETR receives these packets directly (since the destination
       address is one of its assigned IP addresses), strips the LISP
       header and forwards the packets to the attached destination host.

   In order to defer the need for a mapping lookup in the reverse
   direction, an ETR MAY create a cache entry that maps the source EID
   (inner header source IP address) to the source RLOC (outer header
   source IP address) in a received LISP packet.  Such a cache entry is
   termed a "gleaned" mapping and only contains a single RLOC for the
   EID in question.  More complete information about additional RLOCs
   SHOULD be verified by sending a LISP Map-Request for that EID.  Both
   ITR and the ETR may also influence the decision the other makes in
   selecting an RLOC.  See Section 6 for more details.

5.  LISP Encapsulation Details

   Since additional tunnel headers are prepended, the packet becomes
   larger and can exceed the MTU of any link traversed from the ITR to
   the ETR.  It is recommended in IPv4 that packets do not get
   fragmented as they are encapsulated by the ITR.  Instead, the packet
   is dropped and an ICMP Too Big message is returned to the source.

   This specification recommends that implementations support for one of
   the proposed fragmentation and reassembly schemes.  These two
   existing schemes are detailed in Section 5.4.

5.1.  LISP IPv4-in-IPv4 Header Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version|  IHL  |Type of Service|          Total Length         |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |         Identification        |Flags|      Fragment Offset    |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   OH  |  Time to Live | Protocol = 17 |         Header Checksum       |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                    Source Routing Locator                     |
    \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                 Destination Routing Locator                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4341        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L   |N|L|E|V|I|flags|            Nonce/Map-Version                  |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                 Instance ID/Locator Status Bits               |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version|  IHL  |Type of Service|          Total Length         |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |         Identification        |Flags|      Fragment Offset    |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   IH  |  Time to Live |    Protocol   |         Header Checksum       |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                           Source EID                          |
    \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                         Destination EID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2.  LISP IPv6-in-IPv6 Header Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version| Traffic Class |           Flow Label                  |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |   |         Payload Length        | Next Header=17|   Hop Limit   |
   v   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
   O   +                                                               +
   u   |                                                               |
   t   +                     Source Routing Locator                    +
   e   |                                                               |
   r   +                                                               +
       |                                                               |
   H   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   d   |                                                               |
   r   +                                                               +
       |                                                               |
   ^   +                  Destination Routing Locator                  +
   |   |                                                               |
    \  +                                                               +
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4341        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L   |N|L|E|V|I|flags|            Nonce/Map-Version                  |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                 Instance ID/Locator Status Bits               |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version| Traffic Class |           Flow Label                  |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /   |         Payload Length        |  Next Header  |   Hop Limit   |
   v   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
   I   +                                                               +
   n   |                                                               |
   n   +                          Source EID                           +
   e   |                                                               |
   r   +                                                               +
       |                                                               |
   H   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   d   |                                                               |
   r   +                                                               +
       |                                                               |
   ^   +                        Destination EID                        +
   \   |                                                               |
    \  +                                                               +
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.3.  Tunnel Header Field Descriptions

   Inner Header:  The inner header is the header on the datagram
      received from the originating host.  The source and destination IP
      addresses are EIDs.

   Outer Header:  The outer header is a new header prepended by an ITR.
      The address fields contain RLOCs obtained from the ingress
      router's EID-to-RLOC cache.  The IP protocol number is "UDP (17)"
      from [RFC0768].  The DF bit of the Flags field is set to 0 when
      the method in Section 5.4.1 is used and set to 1 when the method
      in Section 5.4.2 is used.

   UDP Header:  The UDP header contains a ITR selected source port when
      encapsulating a packet.  See Section 6.5 for details on the hash
      algorithm used to select a source port based on the 5-tuple of the
      inner header.  The destination port MUST be set to the well-known
      IANA assigned port value 4341.

   UDP Checksum:  The UDP checksum field SHOULD be transmitted as zero
      by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation
      [UDP-TUNNELS].  When a packet with a zero UDP checksum is received
      by an ETR, the ETR MUST accept the packet for decapsulation.  When
      an ITR transmits a non-zero value for the UDP checksum, it MUST
      send a correctly computed value in this field.  When an ETR
      receives a packet with a non-zero UDP checksum, it MAY choose to
      verify the checksum value.  If it chooses to perform such
      verification, and the verification fails, the packet MUST be
      silently dropped.  If the ETR chooses not to perform the
      verification, or performs the verification successfully, the
      packet MUST be accepted for decapsulation.  The handling of UDP
      checksums for all tunneling protocols, including LISP, is under
      active discussion within the IETF.  When that discussion
      concludes, any necessary changes will be made to align LISP with
      the outcome of the broader discussion.

   UDP Length:  The UDP length field is for an IPv4 encapsulated packet,
      the inner header Total Length plus the UDP and LISP header lengths
      are used.  For an IPv6 encapsulated packet, the inner header
      Payload Length plus the size of the IPv6 header (40 bytes) plus
      the size of the UDP and LISP headers are used.  The UDP header
      length is 8 bytes.

   N: The N bit is the nonce-present bit.  When this bit is set to 1,
      the low-order 24-bits of the first 32-bits of the LISP header
      contains a Nonce.  See Section 6.3.1 for details.  Both N and V
      bits MUST NOT be set in the same packet.  If they are, a
      decapsulating ETR MUST treat the "Nonce/Map-Version" field as
      having a Nonce value present.

   L: The L bit is the Locator-Status-Bits field enabled bit.  When this
      bit is set to 1, the Locator-Status-Bits in the second 32-bits of
      the LISP header are in use.

     x 1 x x 0 x x x
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|flags|            Nonce/Map-Version                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Locator Status Bits                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   E: The E bit is the echo-nonce-request bit.  When this bit is set to
      1, the N bit MUST be 1.  This bit SHOULD be ignored and has no
      meaning when the N bit is set to 0.  See Section 6.3.1 for
      details.

   V: The V bit is the Map-Version present bit.  When this bit is set to
      1, the N bit MUST be 0.  Refer to Section 6.6.3 for more details.
      This bit indicates that the first 4 bytes of the LISP header is
      encoded as:

     0 x 0 1 x x x x
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|flags|  Source Map-Version   |   Dest Map-Version    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Instance ID/Locator Status Bits               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   I: The I bit is the Instance ID bit.  See Section 5.5 for more
      details.  When this bit is set to 1, the Locator Status Bits field
      is reduced to 8-bits and the high-order 24-bits are used as an
      Instance ID.  If the L-bit is set to 0, then the low-order 8 bits
      are transmitted as zero and ignored on receipt.  The format of the
      last 4 bytes of the LISP header would look like:

     x x x x 1 x x x
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|flags|            Nonce/Map-Version                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Instance ID                   |     LSBs      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   flags:  The flags field is a 3-bit field is reserved for future flag
      use.  It is MUST be set to 0 on transmit and MUST be ignored on
      receipt.

   LISP Nonce:  The LISP nonce field is a 24-bit value that is randomly
      generated by an ITR when the N-bit is set to 1.  The nonce is also
      used when the E-bit is set to request the nonce value to be echoed
      by the other side when packets are returned.  When the E-bit is
      clear but the N-bit is set, a remote ITR is either echoing a
      previously requested echo-nonce or providing a random nonce.  See
      Section 6.3.1 for more details.

   LISP Locator Status Bits:  The locator status bits field in the LISP
      header is set by an ITR to indicate to an ETR the up/down status
      of the Locators in the source site.  Each RLOC in a Map-Reply is
      assigned an ordinal value from 0 to n-1 (when there are n RLOCs in
      a mapping entry).  The Locator Status Bits are numbered from 0 to
      n-1 from the least significant bit of field.  The field is 32-bits
      when the I-bit is set to 0 and is 8 bits when the I-bit is set to
      1.  When a Locator Status Bit is set to 1, the ITR is indicating
      to the ETR the RLOC associated with the bit ordinal has up status.
      See Section 6.3 for details on how an ITR can determine the status
      of other ITRs the ETRs at the same site.  When a site has multiple EID-
      prefixes which result in multiple mappings (where each could have
      a different locator-set), the Locator Status Bits setting in an
      encapsulated packet MUST reflect the mapping for the EID-prefix
      that the inner-header source EID address matches.  If the LSB for
      an anycast locator is set to 1, then there is at least one RLOC
      with that address that the ETR is considered 'up'.

   When doing ITR/PITR encapsulation:

   o  The outer header Time to Live field (or Hop Limit field, in case
      of IPv6) SHOULD be copied from the inner header Time to Live
      field.

   o  The outer header Type of Service field (or the Traffic Class
      field, in the case of IPv6) SHOULD be copied from the inner header
      Type of Service field (with one caveat, see below).

   When doing ETR/PETR decapsulation:

   o  The inner header Time to Live field (or Hop Limit field, in case
      of IPv6) SHOULD be copied from the outer header Time to Live
      field, when the Time to Live field of the outer header is less
      than the Time to Live of the inner header.  Failing to perform
      this check can cause the Time to Live of the inner header to
      increment across encapsulation/decapsulation cycle.  This check is
      also performed when doing initial encapsulation when a packet
      comes to an ITR or PITR destined for a LISP site.

   o  The inner header Type of Service field (or the Traffic Class
      field, in the case of IPv6) SHOULD be copied from the outer header
      Type of Service field (with one caveat, see below).

   Note if an ETR/PETR is also an ITR/PITR and choose to reencapsulate
   after decapsulating, the net effect of this is that the new outer
   header will carry the same Time to Live as the old outer header.

   Copying the TTL serves two purposes: first, it preserves the distance
   the host intended the packet to travel; second, and more importantly,
   it provides for suppression of looping packets in the event there is
   a loop of concatenated tunnels due to misconfiguration.  See
   Section 9.3 for TTL exception handling for traceroute packets.

   The ECN field occupies bits 6 and 7 of both the IPv4 Type of Service
   field and the IPv6 Traffic Class field [RFC3168].  The ECN field
   requires special treatment in order to avoid discarding indications
   of congestion [RFC3168].  ITR encapsulation MUST copy the 2-bit ECN
   field from the inner header to the outer header.  Re-encapsulation
   MUST copy the 2-bit ECN field from the stripped outer header to the
   new outer header.  If the ECN field contains a congestion indication
   codepoint (the value is '11', the Congestion Experienced (CE)
   codepoint), then ETR decapsulation MUST copy the 2-bit ECN field from
   the stripped outer header to the surviving inner header that is used
   to forward the packet beyond the ETR.  These requirements preserve
   Congestion Experienced (CE) indications when a packet that uses ECN
   traverses a LISP tunnel and becomes marked with a CE indication due
   to congestion between the tunnel endpoints.

5.4.  Dealing with Large Encapsulated Packets

   This section proposes two mechanisms to deal with packets that exceed
   the path MTU between the ITR and ETR.

   It is left to the implementor to decide if the stateless or stateful
   mechanism should be implemented.  Both or neither can be used since
   it is a local decision in the ITR regarding how to deal with MTU
   issues, and sites can interoperate with differing mechanisms.

   Both stateless and stateful mechanisms also apply to Reencapsulating
   and Recursive Tunneling.  So any actions below referring to an ITR
   also apply to an TE-ITR.

5.4.1.  A Stateless Solution to MTU Handling

   An ITR stateless solution to handle MTU issues is described as
   follows:

   1.  Define an architectural constant S for the maximum size of a
       packet, in bytes, an ITR would like to receive from a source
       inside of its site.

   2.  Define L to be the maximum size, in bytes, a packet of size S
       would be after the ITR prepends the LISP header, UDP header, and
       outer network layer header of size H.

   3.  Calculate: S + H = L.

   When an ITR receives a packet from a site-facing interface and adds H
   bytes worth of encapsulation to yield a packet size greater than L
   bytes, it resolves the MTU issue by first splitting the original
   packet into 2 equal-sized fragments.  A LISP header is then prepended
   to each fragment.  The size of the encapsulated fragments is then
   (S/2 + H), which is less than the ITR's estimate of the path MTU
   between the ITR and its correspondent ETR.

   When an ETR receives encapsulated fragments, it treats them as two
   individually encapsulated packets.  It strips the LISP headers then
   forwards each fragment to the destination host of the destination
   site.  The two fragments are reassembled at the destination host into
   the single IP datagram that was originated by the source host.

   This behavior is performed by the ITR when the source host originates
   a packet with the DF field of the IP header is set to 0.  When the DF
   field of the IP header is set to 1, or the packet is an IPv6 packet
   originated by the source host, the ITR will drop the packet when the
   size is greater than L, and sends an ICMP Too Big message to the
   source with a value of S, where S is (L - H).

   When the outer header encapsulation uses an IPv4 header, an
   implementation SHOULD set the DF bit to 1 so ETR fragment reassembly
   can be avoided.  An implementation MAY set the DF bit in such headers
   to 0 if it has good reason to believe there are unresolvable path MTU
   issues between the sending ITR and the receiving ETR.

   This specification recommends that L be defined as 1500.

5.4.2.  A Stateful Solution to MTU Handling

   An ITR stateful solution to handle MTU issues is described as follows
   and was first introduced in [OPENLISP]:

   1.  The ITR will keep state of the effective MTU for each locator per
       mapping cache entry.  The effective MTU is what the core network
       can deliver along the path between ITR and ETR.

   2.  When an IPv6 encapsulated packet or an IPv4 encapsulated packet
       with DF bit set to 1, exceeds what the core network can deliver,
       one of the intermediate routers on the path will send an ICMP Too
       Big message to the ITR.  The ITR will parse the ICMP message to
       determine which locator is affected by the effective MTU change
       and then record the new effective MTU value in the mapping cache
       entry.

   3.  When a packet is received by the ITR from a source inside of the
       site and the size of the packet is greater than the effective MTU
       stored with the mapping cache entry associated with the
       destination EID the packet is for, the ITR will send an ICMP Too
       Big message back to the source.  The packet size advertised by
       the ITR in the ICMP Too Big message is the effective MTU minus
       the LISP encapsulation length.

   Even though this mechanism is stateful, it has advantages over the
   stateless IP fragmentation mechanism, by not involving the
   destination host with reassembly of ITR fragmented packets.

5.5.  Using Virtualization and Segmentation with LISP

   When multiple organizations inside of a LISP site are using private
   addresses [RFC1918] as EID-prefixes, their address spaces MUST remain
   segregated due to possible address duplication.  An Instance ID in
   the address encoding can aid in making the entire AFI based address
   unique.  See IANA Considerations Section 14.1 for details for
   possible address encodings.

   An Instance ID can be carried in a LISP encapsulated packet.  An ITR
   that prepends a LISP header, will copy a 24-bit value, used by the
   LISP router to uniquely identify the address space.  The value is
   copied to the Instance ID field of the LISP header and the I-bit is
   set to 1.

   When an ETR decapsulates a packet, the Instance ID from the LISP
   header is used as a table identifier to locate the forwarding table
   to use for the inner destination EID lookup.

   For example, a 802.1Q VLAN tag or VPN identifier could be used as a
   24-bit Instance ID.

6.  EID-to-RLOC Mapping

6.1.  LISP IPv4 and IPv6 Control Plane Packet Formats

   The following new UDP packet types formats are used to retrieve EID-to-RLOC
   mappings: by the LISP control-plane.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Version|  IHL  |Type of Service|          Total Length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Identification        |Flags|      Fragment Offset    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Time to Live | Protocol = 17 |         Header Checksum       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Source Routing Locator                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Destination Routing Locator                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |           Source Port         |         Dest Port             |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                         LISP Message                          |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Version| Traffic Class |           Flow Label                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Payload Length        | Next Header=17|   Hop Limit   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                     Source Routing Locator                    +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                  Destination Routing Locator                  +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |           Source Port         |         Dest Port             |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                         LISP Message                          |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The LISP UDP-based messages are the Map-Request and Map-Reply
   messages.  When a UDP Map-Request is sent, the UDP source port is
   chosen by the sender and the destination UDP port number is set to
   4342.  When a UDP Map-Reply is sent, the source UDP port number is
   set to 4342 and the destination UDP port number is copied from the
   source port of either the Map-Request or the invoking data packet.
   Implementations MUST be prepared to accept packets when either the
   source port or destination UDP port is set to 4342 due to NATs
   changing port number values.

   The UDP Length field will reflect the length of the UDP header and
   the LISP Message payload.

   The UDP Checksum is computed and set to non-zero for Map-Request,
   Map-Reply, Map-Register and ECM control messages.  It MUST be checked
   on receipt and if the checksum fails, the packet MUST be dropped.

   LISP-CONS [CONS] uses TCP to send LISP control messages.  The format
   of control messages includes the UDP header so the checksum and
   length fields can be used to protect and delimit message boundaries.

   This main LISP specification is the authoritative source for message
   format definitions for the Map-Request and Map-Reply messages.

6.1.1.  LISP Packet Type Allocations

   This section will be the authoritative source for allocating LISP
   Type values.  Current allocations are:

       Reserved:                          0    b'0000'
       LISP Map-Request:                  1    b'0001'
       LISP Map-Reply:                    2    b'0010'
       LISP Map-Register:                 3    b'0011'
       LISP Map-Notify:                   4    b'0100'
       LISP Encapsulated Control Message: 8    b'1000'

6.1.2.  Map-Request Message Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=1 |A|M|P|S|p|s|    Reserved     |   IRC   | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Source-EID-AFI        |   Source EID Address  ...     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         ITR-RLOC-AFI 1        |    ITR-RLOC Address 1  ...    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         ITR-RLOC-AFI n        |    ITR-RLOC Address n  ...    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |   Reserved    | EID mask-len  |        EID-prefix-AFI         |
   Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                       EID-prefix  ...                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Map-Reply Record  ...                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Mapping Protocol Data                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet field descriptions:

   Type:   1 (Map-Request)

   A: This is an authoritative bit, which is set to 0 for UDP-based Map-
      Requests sent by an ITR.

   M: When set, it indicates a Map-Reply Record segment is included in
      the Map-Request.

   P: This is the probe-bit which indicates that a Map-Request SHOULD be
      treated as a locator reachability probe.  The receiver SHOULD
      respond with a Map-Reply with the probe-bit set, indicating the
      Map-Reply is a locator reachability probe reply, with the nonce
      copied from the Map-Request.  See Section 6.3.2 for more details.

   S: This is the SMR bit.  See Section 6.6.2 for details.

   p: This is the PITR bit.  This bit is set to 1 when a PITR sends a
      Map-Request.

   s: This is the SMR-invoked bit.  This bit is set to 1 when an xTR is
      sending a Map-Request in response to a received SMR-based Map-
      Request.

   Reserved:  Set  It MUST be set to 0 on transmission transmit and MUST be ignored on
      receipt.

   IRC:  This 5-bit field is the ITR-RLOC Count which encodes the
      additional number of (ITR-RLOC-AFI, ITR-RLOC Address) fields
      present in this message.  At least one (ITR-RLOC-AFI, ITR-RLOC-
      Address) pair must always be encoded.  Multiple ITR-RLOC Address
      fields are used so a Map-Replier can select which destination
      address to use for a Map-Reply.  The IRC value ranges from 0 to
      31, and for a value of 1, there are 2 ITR-RLOC addresses encoded
      and so on up to 31 which encodes a total of 32 ITR-RLOC addresses.

   Record Count:  The number of records in this Map-Request message.  A
      record is comprised of the portion of the packet that is labeled
      'Rec' above and occurs the number of times equal to Record Count.
      For this version of the protocol, a receiver MUST accept and
      process Map-Requests that contain one or more records, but a
      sender MUST only send Map-Requests containing one record.  Support
      for requesting multiple EIDs in a single Map-Request message will
      be specified in a future version of the protocol.

   Nonce:  An 8-byte random value created by the sender of the Map-
      Request.  This nonce will be returned in the Map-Reply.  The
      security of the LISP mapping protocol depends critically on the
      strength of the nonce in the Map-Request message.  The nonce
      SHOULD be generated by a properly seeded pseudo-random (or strong
      random) source.  See [RFC4086] for advice on generating security-
      sensitive random data.

   Source-EID-AFI:  Address family of the "Source EID Address" field.

   Source EID Address:  This is the EID of the source host which
      originated the packet which is invoking this Map-Request.  When
      Map-Requests are used for refreshing a map-cache entry or for
      RLOC-probing, an AFI value 0 is used and this field is of zero
      length.

   ITR-RLOC-AFI:  Address family of the "ITR-RLOC Address" field that
      follows this field.

   ITR-RLOC Address:  Used to give the ETR the option of selecting the
      destination address from any address family for the Map-Reply
      message.  This address MUST be a routable RLOC address of the
      sender of the Map-Request message.

   EID mask-len:  Mask length for EID prefix.

   EID-prefix-AFI:  Address family of EID-prefix according to [AFI]

   EID-prefix:  4 bytes if an IPv4 address-family, 16 bytes if an IPv6
      address-family.  When a Map-Request is sent by an ITR because a
      data packet is received for a destination where there is no
      mapping entry, the EID-prefix is set to the destination IP address
      of the data packet.  And the 'EID mask-len' is set to 32 or 128
      for IPv4 or IPv6, respectively.  When an xTR wants to query a site
      about the status of a mapping it already has cached, the EID-
      prefix used in the Map-Request has the same mask-length as the
      EID-prefix returned from the site when it sent a Map-Reply
      message.

   Map-Reply Record:  When the M bit is set, this field is the size of a
      single "Record" in the Map-Reply format.  This Map-Reply record
      contains the EID-to-RLOC mapping entry associated with the Source
      EID.  This allows the ETR which will receive this Map-Request to
      cache the data if it chooses to do so.

   Mapping Protocol Data:  See [CONS] for details.  This field is
      optional and present when the UDP length indicates there is enough
      space in the packet to include it.

6.1.3.  EID-to-RLOC UDP Map-Request Message

   A Map-Request is sent from an ITR when it needs a mapping for an EID,
   wants to test an RLOC for reachability, or wants to refresh a mapping
   before TTL expiration.  For the initial case, the destination IP
   address used for the Map-Request is the destination-EID from the
   packet which had a mapping cache lookup failure.  For the latter 2
   cases, the destination IP address used for the Map-Request is one of
   the RLOC addresses from the locator-set of the map cache entry.  The
   source address is either an IPv4 or IPv6 RLOC address depending if
   the Map-Request is using an IPv4 versus IPv6 header, respectively.
   In all cases, the UDP source port number for the Map-Request message
   is an ITR/PITR selected 16-bit value and the UDP destination port
   number is set to the well-known destination port number 4342.  A
   successful Map-Reply updates the cached set of RLOCs associated with
   the EID prefix range.

   One or more Map-Request (ITR-RLOC-AFI, ITR-RLOC-Address) fields MUST
   be filled in by the ITR.  The number of fields (minus 1) encoded MUST
   be placed in the IRC field.  The ITR MAY include all locally
   configured locators in this list or just provide one locator address
   from each address family it supports.  If the ITR erroneously
   provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map-
   Request.

   Map-Requests can also be LISP encapsulated using UDP destination port
   4342 with a LISP type value set to "Encapsulated Control Message",
   when sent from an ITR to a Map-Resolver.  Likewise, Map-Requests are
   LISP encapsulated the same way from a Map-Server to an ETR.  Details
   on encapsulated Map-Requests and Map-Resolvers can be found in
   [LISP-MS].

   Map-Requests MUST be rate-limited.  It is recommended that a Map-
   Request for the same EID-prefix be sent no more than once per second.

   An ITR that is configured with mapping database information (i.e. it
   is also an ETR) may optionally include those mappings in a Map-
   Request.  When an ETR configured to accept and verify such
   "piggybacked" mapping data receives such a Map-Request and it does
   not have this mapping in the map-cache, it may originate a "verifying
   Map-Request", addressed to the map-requesting ITR.  If the ETR has a
   map-cache entry that matches the "piggybacked" EID and the RLOC is in
   the locator-set for the entry, then it may send the "verifying Map-
   Request" directly to the originating Map-Request source.  If the RLOC
   is not in the locator-set, then the ETR MUST send the "verifying Map-
   Request" to the "piggybacked" EID.  Doing this forces the "verifying
   Map-Request" to go through the mapping database system to reach the
   authoritative source of information about that EID, guarding against
   RLOC-spoofing in in the "piggybacked" mapping data.

6.1.4.  Map-Reply Message Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=2 |P|E|S|          Reserved               | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   | Rsvd  |  Map-Version Number   |       EID-prefix-AFI          |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |        Unused Flags     |L|p|R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Mapping Protocol Data                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet field descriptions:

   Type:   2 (Map-Reply)

   P: This is the probe-bit which indicates that the Map-Reply is in
      response to a locator reachability probe Map-Request.  The nonce
      field MUST contain a copy of the nonce value from the original
      Map-Request.  See Section 6.3.2 for more details.

   E: Indicates that the ETR which sends this Map-Reply message is
      advertising that the site is enabled for the Echo-Nonce locator
      reachability algorithm.  See Section 6.3.1 for more details.

   S: This is the Security bit.  When set to 1 the field following the
      Mapping Protocol Data field will have the following format.  The
      detailed format of the Authentication Data Content field can be
      found in [LISP-SEC] when AD Type is equal to 1. for further
      study.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    AD Type    |       Authentication Data Content . . .       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reserved:  Set  It MUST be set to 0 on transmission transmit and MUST be ignored on
      receipt.

   Record Count:  The number of records in this reply message.  A record
      is comprised of that portion of the packet labeled 'Record' above
      and occurs the number of times equal to Record count.

   Nonce:  A 24-bit value set in a Data-Probe packet or a 64-bit value
      from the Map-Request is echoed in this Nonce field of the Map-
      Reply.

   Record TTL:  The time in minutes the recipient of the Map-Reply will
      store the mapping.  If the TTL is 0, the entry SHOULD be removed
      from the cache immediately.  If the value is 0xffffffff, the
      recipient can decide locally how long to store the mapping.

   Locator Count:  The number of Locator entries.  A locator entry
      comprises what is labeled above as 'Loc'.  The locator count can
      be 0 indicating there are no locators for the EID-prefix.

   EID mask-len:  Mask length for EID prefix.

   ACT:  This 3-bit field describes negative Map-Reply actions.  These
      bits are used only when the 'Locator Count' field is set to 0.
      The action bits are encoded only in Map-Reply messages.  The
      actions defined are used by an ITR or PTR when a destination EID
      matches a negative mapping cache entry.  Unassigned values should
      cause a map-cache entry to be created and, when packets match this
      negative cache entry, they will be dropped.  The current assigned
      values are:

      (0) No-Action:  The map-cache is kept alive and no packet
         encapsulation occurs.

      (1) Natively-Forward:  The packet is not encapsulated or dropped
         but natively forwarded.

      (2) Send-Map-Request:  The packet invokes sending a Map-Request.

      (3) Drop:  A packet that matches this map-cache entry is dropped.

   A: The Authoritative bit, when sent by a UDP-based message is always
      set to 1 by an ETR.  See [CONS] for TCP-based Map-Replies.  When a
      Map-Server is proxy Map-Replying [LISP-MS] for a LISP site, the
      Authoritative bit is set to 0.  This indicates to requesting ITRs
      that the Map-Reply was not originated by a LISP node managed at
      the site that owns the EID-prefix.

   Map-Version Number:  When this 12-bit value is non-zero the Map-Reply
      sender is informing the ITR what the version number is for the
      EID-record contained in the Map-Reply.  The ETR can allocate this
      number internally but MUST coordinate this value with other ETRs
      for the site.  When this value is 0, there is no versioning
      information conveyed.  The Map-Version Number can be included in
      Map-Request and Map-Register messages.  See Section 6.6.3 for more
      details.

   EID-prefix-AFI:  Address family of EID-prefix according to [AFI].

   EID-prefix:  4 bytes if an IPv4 address-family, 16 bytes if an IPv6
      address-family.

   Priority:  each RLOC is assigned a unicast priority.  Lower values
      are more preferable.  When multiple RLOCs have the same priority,
      they may be used in a load-split fashion.  A value of 255 means
      the RLOC MUST NOT be used for unicast forwarding.

   Weight:  when priorities are the same for multiple RLOCs, the weight
      indicates how to balance unicast traffic between them.  Weight is
      encoded as a relative weight of total unicast packets that match
      the mapping entry.  For example if there are 4 locators in a
      locator set, where the weights assigned are 30, 20, 20, and 10,
      the first locator will get 37.5% of the traffic, the 2nd and 3rd
      locators will get 25% of traffic and the 4th locator will get
      12.5% of the traffic.  If all weights for a locator-set are equal,
      receiver of the Map-Reply will decide how to load-split traffic.
      See Section 6.5 for a suggested hash algorithm to distribute load
      across locators with same priority and equal weight values.

   M Priority:  each RLOC is assigned a multicast priority used by an
      ETR in a receiver multicast site to select an ITR in a source
      multicast site for building multicast distribution trees.  A value
      of 255 means the RLOC MUST NOT be used for joining a multicast
      distribution tree.

   M Weight:  when priorities are the same for multiple RLOCs, the
      weight indicates how to balance building multicast distribution
      trees across multiple ITRs.  The weight is encoded as a relative
      weight (similar to the unicast Weights) of total number of trees
      built to the source site identified by the EID-prefix.  If all
      weights for a locator-set are equal, the receiver of the Map-Reply
      will decide how to distribute multicast state across ITRs.

   Unused Flags:  set to 0 when sending and ignored on receipt.

   L: when this bit is set, the locator is flagged as a local locator to
      the ETR that is sending the Map-Reply.  When a Map-Server is doing
      proxy Map-Replying [LISP-MS] for a LISP site, the L bit is set to
      0 for all locators in this locator-set.

   p: when this bit is set, an ETR informs the RLOC-probing ITR that the
      locator address, for which this bit is set, is the one being RLOC-
      probed and may be different from the source address of the Map-
      Reply.  An ITR that RLOC-probes a particular locator, MUST use
      this locator for retrieving the data structure used to store the
      fact that the locator is reachable.  The "p" bit is set for a
      single locator in the same locator set.  If an implementation sets
      more than one "p" bit erroneously, the receiver of the Map-Reply
      MUST select the first locator.  The "p" bit MUST NOT be set for
      locator-set records sent in Map-Request and Map-Register messages.

   R: set when the sender of a Map-Reply has a route to the locator in
      the locator data record.  This receiver may find this useful to
      know if the locator is up but not necessarily reachable from the
      receiver's point of view.  See also Section 6.4 for another way
      the R-bit may be used.

   Locator:  an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field)
      assigned to an ETR.  Note that the destination RLOC address MAY be
      an anycast address.  A source RLOC can be an anycast address as
      well.  The source or destination RLOC MUST NOT be the broadcast
      address (255.255.255.255 or any subnet broadcast address known to
      the router), and MUST NOT be a link-local multicast address.  The
      source RLOC MUST NOT be a multicast address.  The destination RLOC
      SHOULD be a multicast address if it is being mapped from a
      multicast destination EID.

   Mapping Protocol Data:  See [CONS] or [ALT] for details.  This field is
      optional and present when the UDP length indicates there is enough
      space in the packet to include it.  The Mapping Protocol Data is
      used when needed by the particular mapping system.

6.1.5.  EID-to-RLOC UDP Map-Reply Message

   A Map-Reply returns an EID-prefix with a prefix length that is less
   than or equal to the EID being requested.  The EID being requested is
   either from the destination field of an IP header of a Data-Probe or
   the EID record of a Map-Request.  The RLOCs in the Map-Reply are
   globally-routable IP addresses of all ETRs for the LISP site.  Each
   RLOC conveys status reachability but does not convey path
   reachability from a requesters perspective.  Separate testing of path
   reachability is required, See Section 6.3 for details.

   Note that a Map-Reply may contain different EID-prefix granularity
   (prefix + length) than the Map-Request which triggers it.  This might
   occur if a Map-Request were for a prefix that had been returned by an
   earlier Map-Reply.  In such a case, the requester updates its cache
   with the new prefix information and granularity.  For example, a
   requester with two cached EID-prefixes that are covered by a Map-
   Reply containing one, less-specific prefix, replaces the entry with
   the less-specific EID-prefix.  Note that the reverse, replacement of
   one less-specific prefix with multiple more-specific prefixes, can
   also occur but not by removing the less-specific prefix rather by
   adding the more-specific prefixes which during a lookup will override
   the less-specific prefix.

   When an ETR is configured with overlapping EID-prefixes, a Map-
   Request with an EID that longest matches any EID-prefix MUST be
   returned in a single Map-Reply message.  For instance, if an ETR had
   database mapping entries for EID-prefixes:

     10.0.0.0/8
     10.1.0.0/16
     10.1.1.0/24
     10.1.2.0/24

   A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record
   count of 1 to be returned with a mapping record EID-prefix of
   10.1.1.0/24.

   A Map-Request for EID 10.1.5.5, would cause a Map-Reply with a record
   count of 3 to be returned with mapping records for EID-prefixes
   10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24.

   Note that not all overlapping EID-prefixes need to be returned, only
   the more specifics (note in the second example above 10.0.0.0/8 was
   not returned for requesting EID 10.1.5.5) entries for the matching
   EID-prefix of the requesting EID.  When more than one EID-prefix is
   returned, all SHOULD use the same Time-to-Live value so they can all
   time out at the same time.  When a more specific EID-prefix is
   received later, its Time-to-Live value in the Map-Reply record can be
   stored even when other less specifics exist.  When a less specific
   EID-prefix is received later, its map-cache expiration time SHOULD be
   set to the minimum expiration time of any more specific EID-prefix in
   the map-cache.

   Map-Replies SHOULD be sent for an EID-prefix no more often than once
   per second to the same requesting router.  For scalability, it is
   expected that aggregation of EID addresses into EID-prefixes will
   allow one Map-Reply to satisfy a mapping for the EID addresses in the
   prefix range thereby reducing the number of Map-Request messages.

   Map-Reply records can have an empty locator-set.  A negative Map-
   Reply is a Map-Reply with an empty locator-set.  Negative Map-Replies
   convey special actions by the sender to the ITR or PTR which have
   solicited the Map-Reply.  There are two primary applications for
   Negative Map-Replies.  The first is for a Map-Resolver to instruct an
   ITR or PTR when a destination is for a LISP site versus a non-LISP
   site.  And the other is to source quench Map-Requests which are sent
   for non-allocated EIDs.

   For each Map-Reply record, the list of locators in a locator-set MUST
   appear in the same order for each ETR that originates a Map-Reply
   message.  The locator-set MUST be sorted in order of ascending IP
   address where an IPv4 locator address is considered numerically 'less
   than' an IPv6 locator address.

   When sending a Map-Reply message, the destination address is copied
   from the one of the ITR-RLOC fields from the Map-Request.  The ETR
   can choose a locator address from one of the address families it
   supports.  For Data-Probes, the destination address of the Map-Reply
   is copied from the source address of the Data-Probe message which is
   invoking the reply.  The source address of the Map-Reply is one of
   the local IP addresses chosen to allow uRPF checks to succeed in the
   upstream service provider.  The destination port of a Map-Reply
   message is copied from the source port of the Map-Request or Data-
   Probe and the source port of the Map-Reply message is set to the
   well-known UDP port 4342.

6.1.5.1.  Traffic Redirection with Coarse EID-Prefixes

   When an ETR is misconfigured or compromised, it could return coarse
   EID-prefixes in Map-Reply messages it sends.  The EID-prefix could
   cover EID-prefixes which are allocated to other sites redirecting
   their traffic to the locators of the compromised site.

   To solve this problem, there are two basic solutions that could be
   used.  The first is to have Map-Servers proxy-map-reply on behalf of
   ETRs so their registered EID-prefixes are the ones returned in Map-
   Replies.  Since the interaction between an ETR and Map-Server is
   secured with shared-keys, it is more difficult for an ETR to
   misbehave.  The second solution is to have ITRs and PTRs cache EID-
   prefixes with mask-lengths that are greater than or equal to a
   configured prefix length.  This limits the damage to a specific width
   of any EID-prefix advertised, but needs to be coordinated with the
   allocation of site prefixes.  These solutions can be used
   independently or at the same time.

   At the time of this writing, other approaches are being considered
   and researched.

6.1.6.  Map-Register Message Format

   The usage details of the Map-Register message can be found in
   specification [LISP-MS].  This section solely defines the message
   format.

   The message is sent in UDP with a destination UDP port of 4342 and a
   randomly selected UDP source port number.

   The Map-Register message format is:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=3 |P|            Reserved               |M| Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Key ID             |  Authentication Data Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                     Authentication Data                       ~
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   | Rsvd  |  Map-Version Number   |        EID-prefix-AFI         |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |        Unused Flags     |L|p|R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet field descriptions:

   Type:   3 (Map-Register)

   P: This is the proxy-map-reply bit, when set to 1 an ETR sends a Map-
      Register message requesting for the Map-Server to proxy Map-Reply.
      The Map-Server will send non-authoritative Map-Replies on behalf
      of the ETR.  Details on this usage will be provided in a future
      version of this draft.

   Reserved:  Set  It MUST be set to 0 on transmission transmit and MUST be ignored on
      receipt.

   M: This is the want-map-notify bit, when set to 1 an ETR is
      requesting for a Map-Notify message to be returned in response to
      sending a Map-Register message.  The Map-Notify message sent by a
      Map-Server is used to an acknowledge receipt of a Map-Register
      message.

   Record Count:  The number of records in this Map-Register message.  A
      record is comprised of that portion of the packet labeled 'Record'
      above and occurs the number of times equal to Record count.

   Nonce:  This 8-byte Nonce field is set to 0 in Map-Register messages.

   Key ID:  A configured ID to find the configured Message
      Authentication Code (MAC) algorithm and key value used for the
      authentication function.

   Authentication Data Length:  The length in bytes of the
      Authentication Data field that follows this field.  The length of
      the Authentication Data field is dependent on the Message
      Authentication Code (MAC) algorithm used.  The length field allows
      a device that doesn't know the MAC algorithm to correctly parse
      the packet.

   Authentication Data:  The message digest used from the output of the
      Message Authentication Code (MAC) algorithm.  The entire Map-
      Register payload is authenticated with this field preset to 0.
      After the MAC is computed, it is placed in this field.
      Implementations of this specification MUST include support for
      HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256 [RFC4634]
      is recommended.

   The definition of the rest of the Map-Register can be found in the
   Map-Reply section.

6.1.7.  Map-Notify Message Format

   The usage details of the Map-Notify message can be found in
   specification [LISP-MS].  This section solely defines the message
   format.

   The message is sent inside a UDP packet with a source UDP port equal
   to 4342 and a destination port equal to the source port from the Map-
   Register message this Map-Notify message is responding to.

   The Map-Notify message format is:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=4 |              Reserved                 | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Key ID             |  Authentication Data Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                     Authentication Data                       ~
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   | Rsvd  |  Map-Version Number   |         EID-prefix-AFI        |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |        Unused Flags     |L|p|R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet field descriptions:

   Type:   4 (Map-Notify)

   The Map-Notify message has the same contents as a Map-Register
   message.  See Map-Register section for field descriptions.

6.1.8.  Encapsulated Control Message Format

   An Encapsulated Control Message is used to encapsulate control
   packets sent between xTRs and the mapping database system described
   in [LISP-MS].

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |                       IPv4 or IPv6 Header                     |
   OH  |                      (uses RLOC addresses)                    |
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4342        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   LH  |Type=8 |S|                  Reserved                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |                       IPv4 or IPv6 Header                     |
   IH  |                  (uses RLOC or EID addresses)                 |
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = yyyy        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   LCM |                      LISP Control Message                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet header descriptions:

   OH:   The outer IPv4 or IPv6 header which uses RLOC addresses in the
      source and destination header address fields.

   UDP:   The outer UDP header with destination port 4342.  The source
      port is randomly allocated.  The checksum field MUST be non-zero.

   LH:   Type 8 is defined to be a "LISP Encapsulated Control Message"
      and what follows is either an IPv4 or IPv6 header as encoded by
      the first 4 bits after the reserved field.

   S:   This is the Security bit.  When set to 1 the field following the
      Reserved field will have the following format.  The detailed
      format of the Authentication Data Content field can be found in
      [LISP-SEC] when AD Type is equal to 1. for further study.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    AD Type    |       Authentication Data Content . . .       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IH:   The inner IPv4 or IPv6 header which can use either RLOC or EID
      addresses in the header address fields.  When a Map-Request is
      encapsulated in this packet format the destination address in this
      header is an EID.

   UDP:   The inner UDP header where the port assignments depends on the
      control packet being encapsulated.  When the control packet is a
      Map-Request or Map-Register, the source port is ITR/PITR selected
      and the destination port is 4342.  When the control packet is a
      Map-Reply, the source port is 4342 and the destination port is
      assigned from the source port of the invoking Map-Request.  Port
      number 4341 MUST NOT be assigned to either port.  The checksum
      field MUST be non-zero.

   LCM:   The format is one of the control message formats described in
      this section.  At this time, only Map-Request messages and PIM
      Join-Prune messages [MLISP] are allowed to be encapsulated.
      Encapsulating other types of LISP control messages are for further
      study.  When Map-Requests are sent for RLOC-probing purposes (i.e
      the probe-bit is set), they MUST NOT be sent inside Encapsulated
      Control Messages.

6.2.  Routing Locator Selection

   Both client-side and server-side may need control over the selection
   of RLOCs for conversations between them.  This control is achieved by
   manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply
   messages.  Alternatively, RLOC information may be gleaned from
   received tunneled packets or EID-to-RLOC Map-Request messages.

   The following enumerates different scenarios for choosing RLOCs and
   the controls that are available:

   o  Server-side returns one RLOC.  Client-side can only use one RLOC.
      Server-side has complete control of the selection.

   o  Server-side returns a list of RLOC where a subset of the list has
      the same best priority.  Client can only use the subset list
      according to the weighting assigned by the server-side.  In this
      case, the server-side controls both the subset list and load-
      splitting across its members.  The client-side can use RLOCs
      outside of the subset list if it determines that the subset list
      is unreachable (unless RLOCs are set to a Priority of 255).  Some
      sharing of control exists: the server-side determines the
      destination RLOC list and load distribution while the client-side
      has the option of using alternatives to this list if RLOCs in the
      list are unreachable.

   o  Server-side sets weight of 0 for the RLOC subset list.  In this
      case, the client-side can choose how the traffic load is spread
      across the subset list.  Control is shared by the server-side
      determining the list and the client determining load distribution.
      Again, the client can use alternative RLOCs if the server-provided
      list of RLOCs are unreachable.

   o  Either side (more likely on the server-side ETR) decides not to
      send a Map-Request.  For example, if the server-side ETR does not
      send Map-Requests, it gleans RLOCs from the client-side ITR,
      giving the client-side ITR responsibility for bidirectional RLOC
      reachability and preferability.  Server-side ETR gleaning of the
      client-side ITR RLOC is done by caching the inner header source
      EID and the outer header source RLOC of received packets.  The
      client-side ITR controls how traffic is returned and can alternate
      using an outer header source RLOC, which then can be added to the
      list the server-side ETR uses to return traffic.  Since no
      Priority or Weights are provided using this method, the server-
      side ETR MUST assume each client-side ITR RLOC uses the same best
      Priority with a Weight of zero.  In addition, since EID-prefix
      encoding cannot be conveyed in data packets, the EID-to-RLOC cache
      on tunnel routers can grow to be very large.

   o  A "gleaned" map-cache entry, one learned from the source RLOC of a
      received encapsulated packet, is only stored and used for a few
      seconds, pending verification.  Verification is performed by
      sending a Map-Request to the source EID (the inner header IP
      source address) of the received encapsulated packet.  A reply to
      this "verifying Map-Request" is used to fully populate the map-
      cache entry for the "gleaned" EID and is stored and used for the
      time indicated from the TTL field of a received Map-Reply.  When a
      verified map-cache entry is stored, data gleaning no longer occurs
      for subsequent packets which have a source EID that matches the
      EID-prefix of the verified entry.

   RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be
   reachable when the R-bit for the locator record is set to 1.  When
   the R-bit is set to 0, an ITR or PITR MUST not encapsulate to the
   RLOC.  Neither the information contained in a Map-Reply or that
   stored in the mapping database system provides reachability
   information for RLOCs.  Note that reachability is not part of the
   mapping system and is determined using one or more of the Routing
   Locator Reachability Algorithms described in the next section.

6.3.  Routing Locator Reachability

   Several mechanisms for determining RLOC reachability are currently
   defined:

   1.  An ETR may examine the Loc-Status-Bits in the LISP header of an
       encapsulated data packet received from an ITR.  If the ETR is
       also acting as an ITR and has traffic to return to the original
       ITR site, it can use this status information to help select an
       RLOC.

   2.  An ITR may receive an ICMP Network or ICMP Host Unreachable
       message for an RLOC it is using.  This indicates that the RLOC is
       likely down.

   3.  An ITR which participates in the global routing system can
       determine that an RLOC is down if no BGP RIB route exists that
       matches the RLOC IP address.

   4.  An ITR may receive an ICMP Port Unreachable message from a
       destination host.  This occurs if an ITR attempts to use
       interworking [INTERWORK] and LISP-encapsulated data is sent to a
       non-LISP-capable site.

   5.  An ITR may receive a Map-Reply from a ETR in response to a
       previously sent Map-Request.  The RLOC source of the Map-Reply is
       likely up since the ETR was able to send the Map-Reply to the
       ITR.

   6.  When an ETR receives an encapsulated packet from an ITR, the
       source RLOC from the outer header of the packet is likely up.

   7.  An ITR/ETR pair can use the Locator Reachability Algorithms
       described in this section, namely Echo-Noncing or RLOC-Probing.

   When determining Locator up/down reachability by examining the Loc-
   Status-Bits from the LISP encapsulated data packet, an ETR will
   receive up to date status from an encapsulating ITR about
   reachability for all ETRs at the site.  CE-based ITRs at the source
   site can determine reachability relative to each other using the site
   IGP as follows:

   o  Under normal circumstances, each ITR will advertise a default
      route into the site IGP.

   o  If an ITR fails or if the upstream link to its PE fails, its
      default route will either time-out or be withdrawn.

   Each ITR can thus observe the presence or lack of a default route
   originated by the others to determine the Locator Status Bits it sets
   for them.

   RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1.  The
   Loc-Status-Bits in a LISP encapsulated packet are numbered from 0 to
   n-1 starting with the least significant bit.  For example, if an RLOC
   listed in the 3rd position of the Map-Reply goes down (ordinal value
   2), then all ITRs at the site will clear the 3rd least significant
   bit (xxxx x0xx) of the Loc-Status-Bits field for the packets they
   encapsulate.

   When an ETR decapsulates a packet, it will check for any change in
   the Loc-Status-Bits field.  When a bit goes from 1 to 0, the ETR will
   refrain from encapsulating packets to an RLOC that is indicated as
   down.  It will only resume using that RLOC if the corresponding Loc-
   Status-Bit returns to a value of 1.  Loc-Status-Bits are associated
   with a locator-set per EID-prefix.  Therefore, when a locator becomes
   unreachable, the Loc-Status-Bit that corresponds to that locator's
   position in the list returned by the last Map-Reply will be set to
   zero for that particular EID-prefix.

   When ITRs at the site are not deployed in CE routers, the IGP can
   still be used to determine the reachability of Locators provided they
   are injected into the IGP.  This is typically done when a /32 address
   is configured on a loopback interface.

   When ITRs receive ICMP Network or Host Unreachable messages as a
   method to determine unreachability, they will refrain from using
   Locators which are described in Locator lists of Map-Replies.
   However, using this approach is unreliable because many network
   operators turn off generation of ICMP Unreachable messages.

   If an ITR does receive an ICMP Network or Host Unreachable message,
   it MAY originate its own ICMP Unreachable message destined for the
   host that originated the data packet the ITR encapsulated.

   Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a
   locator address from a locator-set in a mapping entry matches a
   prefix.  If it does not find one and BGP is running in the Default
   Free Zone (DFZ), it can decide to not use the locator even though the
   Loc-Status-Bits indicate the locator is up.  In this case, the path
   from the ITR to the ETR that is assigned the locator is not
   available.  More details are in [LOC-ID-ARCH].

   Optionally, an ITR can send a Map-Request to a Locator and if a Map-
   Reply is returned, reachability of the Locator has been determined.
   Obviously, sending such probes increases the number of control
   messages originated by tunnel routers for active flows, so Locators
   are assumed to be reachable when they are advertised.

   This assumption does create a dependency: Locator unreachability is
   detected by the receipt of ICMP Host Unreachable messages.  When an
   Locator has been determined to be unreachable, it is not used for
   active traffic; this is the same as if it were listed in a Map-Reply
   with priority 255.

   The ITR can test the reachability of the unreachable Locator by
   sending periodic Requests.  Both Requests and Replies MUST be rate-
   limited.  Locator reachability testing is never done with data
   packets since that increases the risk of packet loss for end-to-end
   sessions.

   When an ETR decapsulates a packet, it knows that it is reachable from
   the encapsulating ITR because that is how the packet arrived.  In
   most cases, the ETR can also reach the ITR but cannot assume this to
   be true due to the possibility of path asymmetry.  In the presence of
   unidirectional traffic flow from an ITR to an ETR, the ITR SHOULD NOT
   use the lack of return traffic as an indication that the ETR is
   unreachable.  Instead, it MUST use an alternate mechanisms to
   determine reachability.

6.3.1.  Echo Nonce Algorithm

   When data flows bidirectionally between locators from different
   sites, a data-plane mechanism called "nonce echoing" can be used to
   determine reachability between an ITR and ETR.  When an ITR wants to
   solicit a nonce echo, it sets the N and E bits and places a 24-bit
   nonce in the LISP header of the next encapsulated data packet.

   When this packet is received by the ETR, the encapsulated packet is
   forwarded as normal.  When the ETR next sends a data packet to the
   ITR, it includes the nonce received earlier with the N bit set and E
   bit cleared.  The ITR sees this "echoed nonce" and knows the path to
   and from the ETR is up.

   The ITR will set the E-bit and N-bit for every packet it sends while
   in echo-nonce-request state.  The time the ITR waits to process the
   echoed nonce before it determines the path is unreachable is variable
   and a choice left for the implementation.

   If the ITR is receiving packets from the ETR but does not see the
   nonce echoed while being in echo-nonce-request state, then the path
   to the ETR is unreachable.  This decision may be overridden by other
   locator reachability algorithms.  Once the ITR determines the path to
   the ETR is down it can switch to another locator for that EID-prefix.

   Note that "ITR" and "ETR" are relative terms here.  Both devices MUST
   be implementing both ITR and ETR functionality for the echo nonce
   mechanism to operate.

   The ITR and ETR may both go into echo-nonce-request state at the same
   time.  The number of packets sent or the time during which echo nonce
   requests are sent is an implementation specific setting.  However,
   when an ITR is in echo-nonce-request state, it can echo the ETR's
   nonce in the next set of packets that it encapsulates and then
   subsequently, continue sending echo-nonce-request packets.

   This mechanism does not completely solve the forward path
   reachability problem as traffic may be unidirectional.  That is, the
   ETR receiving traffic at a site may not be the same device as an ITR
   which transmits traffic from that site or the site to site traffic is
   unidirectional so there is no ITR returning traffic.

   The echo-nonce algorithm is bilateral.  That is, if one side sets the
   E-bit and the other side is not enabled for echo-noncing, then the
   echoing of the nonce does not occur and the requesting side may
   regard the locator unreachable erroneously.  An ITR SHOULD only set
   the E-bit in a encapsulated data packet when it knows the ETR is
   enabled for echo-noncing.  This is conveyed by the E-bit in the Map-
   Reply message.

   Note that other locator reachability mechanisms are being researched
   and can be used to compliment or even override the Echo Nonce
   Algorithm.  See next section for an example of control-plane probing.

6.3.2.  RLOC Probing Algorithm

   RLOC Probing is a method that an ITR or PTR can use to determine the
   reachability status of one or more locators that it has cached in a
   map-cache entry.  The probe-bit of the Map-Request and Map-Reply
   messages are used for RLOC Probing.

   RLOC probing is done in the control-plane on a timer basis where an
   ITR or PTR will originate a Map-Request destined to a locator address
   from one of its own locator addresses.  A Map-Request used as an
   RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or on the
   ALT like one would when soliciting mapping data.  The EID record
   encoded in the Map-Request is the EID-prefix of the map-cache entry
   cached by the ITR or PTR.  The ITR may include a mapping data record
   for its own database mapping information which contains the local
   EID-prefixes and RLOCs for its site.

   When an ETR receives a Map-Request message with the probe-bit set, it
   returns a Map-Reply with the probe-bit set.  The source address of
   the Map-Reply is set from the destination address of the Map-Request
   and the destination address of the Map-Reply is set from the source
   address of the Map-Request.  The Map-Reply SHOULD contain mapping
   data for the EID-prefix contained in the Map-Request.  This provides
   the opportunity for the ITR or PTR, which sent the RLOC-probe to get
   mapping updates if there were changes to the ETR's database mapping
   entries.

   There are advantages and disadvantages of RLOC Probing.  The greatest
   benefit of RLOC Probing is that it can handle many failure scenarios
   allowing the ITR to determine when the path to a specific locator is
   reachable or has become unreachable, thus providing a robust
   mechanism for switching to using another locator from the cached
   locator.  RLOC Probing can also provide rough RTT estimates between a
   pair of locators which can be useful for network management purposes
   as well as for selecting low delay paths.  The major disadvantage of
   RLOC Probing is in the number of control messages required and the
   amount of bandwidth used to obtain those benefits, especially if the
   requirement for failure detection times are very small.

   Continued research and testing will attempt to characterize the
   tradeoffs of failure detection times versus message overhead.

6.4.  EID Reachability within a LISP Site

   A site may be multihomed using two or more ETRs.  The hosts and
   infrastructure within a site will be addressed using one or more EID
   prefixes that are mapped to the RLOCs of the relevant ETRs in the
   mapping system.  One possible failure mode is for an ETR to lose
   reachability to one or more of the EID prefixes within its own site.
   When this occurs when the ETR sends Map-Replies, it can clear the
   R-bit associated with its own locator.  And when the ETR is also an
   ITR, it can clear its locator-status-bit in the encapsulation data
   header.

   It is recognized there are no simple solutions to the site
   partitioning problem because it is hard to know which part of the
   EID-prefix range is partitioned.  And which locators can reach any
   sub-ranges of the EID-prefixes.  This problem is under investigation
   with the expectation that experiments will tell us more.  Note, this
   is not a new problem introduced by the LISP architecture.  The
   problem exists today when a multi-homed site uses BGP to advertise
   its reachability upstream.

6.5.  Routing Locator Hashing

   When an ETR provides an EID-to-RLOC mapping in a Map-Reply message to
   a requesting ITR, the locator-set for the EID-prefix may contain
   different priority values for each locator address.  When more than
   one best priority locator exists, the ITR can decide how to load
   share traffic against the corresponding locators.

   The following hash algorithm may be used by an ITR to select a
   locator for a packet destined to an EID for the EID-to-RLOC mapping:

   1.  Either a source and destination address hash can be used or the
       traditional 5-tuple hash which includes the source and
       destination addresses, source and destination TCP, UDP, or SCTP
       port numbers and the IP protocol number field or IPv6 next-
       protocol fields of a packet a host originates from within a LISP
       site.  When a packet is not a TCP, UDP, or SCTP packet, the
       source and destination addresses only from the header are used to
       compute the hash.

   2.  Take the hash value and divide it by the number of locators
       stored in the locator-set for the EID-to-RLOC mapping.

   3.  The remainder will be yield a value of 0 to "number of locators
       minus 1".  Use the remainder to select the locator in the
       locator-set.

   Note that when a packet is LISP encapsulated, the source port number
   in the outer UDP header needs to be set.  Selecting a hashed value
   allows core routers which are attached to Link Aggregation Groups
   (LAGs) to load-split the encapsulated packets across member links of
   such LAGs.  Otherwise, core routers would see a single flow, since
   packets have a source address of the ITR, for packets which are
   originated by different EIDs at the source site.  A suggested setting
   for the source port number computed by an ITR is a 5-tuple hash
   function on the inner header, as described above.

   Many core router implementations use a 5-tuple hash to decide how to
   balance packet load across members of a LAG.  The 5-tuple hash
   includes the source and destination addresses of the packet and the
   source and destination ports when the protocol number in the packet
   is TCP or UDP.  For this reason, UDP encoding is used for LISP
   encapsulation.

6.6.  Changing the Contents of EID-to-RLOC Mappings

   Since the LISP architecture uses a caching scheme to retrieve and
   store EID-to-RLOC mappings, the only way an ITR can get a more up-to-
   date mapping is to re-request the mapping.  However, the ITRs do not
   know when the mappings change and the ETRs do not keep track of which
   ITRs requested its mappings.  For scalability reasons, we want to
   maintain this approach but need to provide a way for ETRs change
   their mappings and inform the sites that are currently communicating
   with the ETR site using such mappings.

   When adding a new locator record in lexiographic lexicographic order to the end of
   a locator-set, it is easy to update mappings.  We assume new mappings
   will maintain the same locator ordering as the old mapping but just
   have new locators appended to the end of the list.  So some ITRs can
   have a new mapping while other ITRs have only an old mapping that is
   used until they time out.  When an ITR has only an old mapping but
   detects bits set in the loc-status-bits that correspond to locators
   beyond the list it has cached, it simply ignores them.  However, this
   can only happen for locator addresses that are lexicographically
   greater than the locator addresses in the existing locator-set.

   When a locator record is inserted in the middle of a locator-set, to
   maintain lexiographic lexicographic order, the SMR procedure in Section 6.6.2 is
   used to inform ITRs and PTRs of the new locator-status-bit mappings.

   When a locator record is removed from a locator-set, ITRs that have
   the mapping cached will not use the removed locator because the xTRs
   will set the loc-status-bit to 0.  So even if the locator is in the
   list, it will not be used.  For new mapping requests, the xTRs can
   set the locator AFI to 0 (indicating an unspecified address), as well
   as setting the corresponding loc-status-bit to 0.  This forces ITRs
   with old or new mappings to avoid using the removed locator.

   If many changes occur to a mapping over a long period of time, one
   will find empty record slots in the middle of the locator-set and new
   records appended to the locator-set.  At some point, it would be
   useful to compact the locator-set so the loc-status-bit settings can
   be efficiently packed.

   We propose here three approaches for locator-set compaction, one
   operational and two protocol mechanisms.  The operational approach
   uses a clock sweep method.  The protocol approaches use the concept
   of Solicit-Map-Requests and Map-Versioning.

6.6.1.  Clock Sweep

   The clock sweep approach uses planning in advance and the use of
   count-down TTLs to time out mappings that have already been cached.
   The default setting for an EID-to-RLOC mapping TTL is 24 hours.  So
   there is a 24 hour window to time out old mappings.  The following
   clock sweep procedure is used:

   1.  24 hours before a mapping change is to take effect, a network
       administrator configures the ETRs at a site to start the clock
       sweep window.

   2.  During the clock sweep window, ETRs continue to send Map-Reply
       messages with the current (unchanged) mapping records.  The TTL
       for these mappings is set to 1 hour.

   3.  24 hours later, all previous cache entries will have timed out,
       and any active cache entries will time out within 1 hour.  During
       this 1 hour window the ETRs continue to send Map-Reply messages
       with the current (unchanged) mapping records with the TTL set to
       1 minute.

   4.  At the end of the 1 hour window, the ETRs will send Map-Reply
       messages with the new (changed) mapping records.  So any active
       caches can get the new mapping contents right away if not cached,
       or in 1 minute if they had the mapping cached.  The new mappings
       are cached with a time to live equal to the TTL in the Map-Reply.

6.6.2.  Solicit-Map-Request (SMR)

   Soliciting a Map-Request is a selective way for ETRs, at the site
   where mappings change, to control the rate they receive requests for
   Map-Reply messages.  SMRs are also used to tell remote ITRs to update
   the mappings they have cached.

   Since the ETRs don't keep track of remote ITRs that have cached their
   mappings, they do not know which ITRs need to have their mappings
   updated.  As a result, an ETR will solicit Map-Requests (called an
   SMR message) from those sites to which it has been sending
   encapsulated data to for the last minute.  In particular, an ETR will
   send an SMR an ITR to which it has recently sent encapsulated data.

   An SMR message is simply a bit set in a Map-Request message.  An ITR
   or PTR will send a Map-Request when they receive an SMR message.
   Both the SMR sender and the Map-Request responder MUST rate-limited
   these messages.  Rate-limiting can be implemented as a global rate-
   limiter or one rate-limiter per SMR destination.

   The following procedure shows how a SMR exchange occurs when a site
   is doing locator-set compaction for an EID-to-RLOC mapping:

   1.  When the database mappings in an ETR change, the ETRs at the site
       begin to send Map-Requests with the SMR bit set for each locator
       in each map-cache entry the ETR caches.

   2.  A remote ITR which receives the SMR message will schedule sending
       a Map-Request message to the source locator address of the SMR
       message or to the mapping database system.  A newly allocated
       random nonce is selected and the EID-prefix used is the one
       copied from the SMR message.  If the source locator is the only
       locator in the cached locator-set, the remote ITR SHOULD send a
       Map-Request to the database mapping system just in case the
       single locator has changed and may no longer be reachable to
       accept the Map-Request.

   3.  The remote ITR MUST rate-limit the Map-Request until it gets a
       Map-Reply while continuing to use the cached mapping.  When Map
       Versioning is used, described in Section 6.6.3, an SMR sender can
       detect if an ITR is using the most up to date database mapping.

   4.  The ETRs at the site with the changed mapping will reply to the
       Map-Request with a Map-Reply message that has a nonce from the
       SMR-invoked Map-Request.  The Map-Reply messages SHOULD be rate
       limited.  This is important to avoid Map-Reply implosion.

   5.  The ETRs, at the site with the changed mapping, record the fact
       that the site that sent the Map-Request has received the new
       mapping data in the mapping cache entry for the remote site so
       the loc-status-bits are reflective of the new mapping for packets
       going to the remote site.  The ETR then stops sending SMR
       messages.

   For security reasons an ITR MUST NOT process unsolicited Map-Replies.
   To avoid map-cache entry corruption by a third-party, a sender of an
   SMR-based Map-Request MUST be verified.  If an ITR receives an SMR-
   based Map-Request and the source is not in the locator-set for the
   stored map-cache entry, then the responding Map-Request MUST be sent
   with an EID destination to the mapping database system.  Since the
   mapping database system is more secure to reach an authoritative ETR,
   it will deliver the Map-Request to the authoritative source of the
   mapping data.

   When an ITR receives an SMR-based Map-Request for which it does not
   have a cached mapping for the EID in the SMR message, it MAY not send
   a SMR-invoked Map-Request.  This scenario can occur when an ETR sends
   SMR messages to all locators in the locator-set it has stored in its
   map-cache but the remote ITRs that receive the SMR may not be sending
   packets to the site.  There is no point in updating the ITRs until
   they need to send, in which case, they will send Map-Requests to
   obtain a map-cache entry.

6.6.3.  Database Map Versioning

   When there is unidirectional packet flow between an ITR and ETR, and
   the EID-to-RLOC mappings change on the ETR, it needs to inform the
   ITR so encapsulation can stop to a removed locator and start to a new
   locator in the locator-set.

   An ETR, when it sends Map-Reply messages, conveys its own Map-Version
   number.  This is known as the Destination Map-Version Number.  ITRs
   include the Destination Map-Version Number in packets they
   encapsulate to the site.  When an ETR decapsulates a packet and
   detects the Destination Map-Version Number is less than the current
   version for its mapping, the SMR procedure described in Section 6.6.2
   occurs.

   An ITR, when it encapsulates packets to ETRs, can convey its own Map-
   Version number.  This is known as the Source Map-Version Number.
   When an ETR decapsulates a packet and detects the Source Map-Version
   Number is greater than the last Map-Version Number sent in a Map-
   Reply from the ITR's site, the ETR will send a Map-Request to one of
   the ETRs for the source site.

   A Map-Version Number is used as a sequence number per EID-prefix.  So
   values that are greater, are considered to be more recent.  A value
   of 0 for the Source Map-Version Number or the Destination Map-Version
   Number conveys no versioning information and an ITR does no
   comparison with previously received Map-Version Numbers.

   A Map-Version Number can be included in Map-Register messages as
   well.  This is a good way for the Map-Server can assure that all ETRs
   for a site registering to it will be Map-Version number synchronized.

   See [VERSIONING] for a more detailed analysis and description of
   Database Map Versioning.

7.  Router Performance Considerations

   LISP is designed to be very hardware-based forwarding friendly.  A
   few implementation techniques can be used to incrementally implement
   LISP:

   o  When a tunnel encapsulated packet is received by an ETR, the outer
      destination address may not be the address of the router.  This
      makes it challenging for the control plane to get packets from the
      hardware.  This may be mitigated by creating special FIB entries
      for the EID-prefixes of EIDs served by the ETR (those for which
      the router provides an RLOC translation).  These FIB entries are
      marked with a flag indicating that control plane processing should
      be performed.  The forwarding logic of testing for particular IP
      protocol number value is not necessary.  There are a few proven
      cases where no changes to existing deployed hardware were needed
      to support the LISP data-plane.

   o  On an ITR, prepending a new IP header consists of adding more
      bytes to a MAC rewrite string and prepending the string as part of
      the outgoing encapsulation procedure.  Routers that support GRE
      tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already
      support this action.

   o  A packet's source address or interface the packet was received on
      can be used to select a VRF (Virtual Routing/Forwarding).  The
      VRF's routing table can be used to find EID-to-RLOC mappings.

8.  Deployment Scenarios

   This section will explore how and where ITRs and ETRs can be deployed
   and will discuss the pros and cons of each deployment scenario.  For
   a more detailed deployment recommendation, refer to [LISP-DEPLOY].

   There are two basic deployment trade-offs to consider: centralized
   versus distributed caches and flat, recursive, or re-encapsulating
   tunneling.  When deciding on centralized versus distributed caching,
   the following issues should be considered:

   o  Are the tunnel routers spread out so that the caches are spread
      across all the memories of each router?

   o  Should management "touch points" be minimized by choosing few
      tunnel routers, just enough for redundancy?

   o  In general, using more ITRs doesn't increase management load,
      since caches are built and stored dynamically.  On the other hand,
      more ETRs does require more management since EID-prefix-to-RLOC
      mappings need to be explicitly configured.

   When deciding on flat, recursive, or re-encapsulation tunneling, the
   following issues should be considered:

   o  Flat tunneling implements a single tunnel between source site and
      destination site.  This generally offers better paths between
      sources and destinations with a single tunnel path.

   o  Recursive tunneling is when tunneled traffic is again further
      encapsulated in another tunnel, either to implement VPNs or to
      perform Traffic Engineering.  When doing VPN-based tunneling, the
      site has some control since the site is prepending a new tunnel
      header.  In the case of TE-based tunneling, the site may have
      control if it is prepending a new tunnel header, but if the site's
      ISP is doing the TE, then the site has no control.  Recursive
      tunneling generally will result in suboptimal paths but at the
      benefit of steering traffic to resource available parts of the
      network.

   o  The technique of re-encapsulation ensures that packets only
      require one tunnel header.  So if a packet needs to be rerouted,
      it is first decapsulated by the ETR and then re-encapsulated with
      a new tunnel header using a new RLOC.

   The next sub-sections will survey where tunnel routers can reside in
   the network.

8.1.  First-hop/Last-hop Tunnel Routers

   By locating tunnel routers close to hosts, the EID-prefix set is at
   the granularity of an IP subnet.  So at the expense of more EID-
   prefix-to-RLOC sets for the site, the caches in each tunnel router
   can remain relatively small.  But caches always depend on the number
   of non-aggregated EID destination flows active through these tunnel
   routers.

   With more tunnel routers doing encapsulation, the increase in control
   traffic grows as well: since the EID-granularity is greater, more
   Map-Requests and Map-Replies are traveling between more routers.

   The advantage of placing the caches and databases at these stub
   routers is that the products deployed in this part of the network
   have better price-memory ratios then their core router counterparts.
   Memory is typically less expensive in these devices and fewer routes
   are stored (only IGP routes).  These devices tend to have excess
   capacity, both for forwarding and routing state.

   LISP functionality can also be deployed in edge switches.  These
   devices generally have layer-2 ports facing hosts and layer-3 ports
   facing the Internet.  Spare capacity is also often available in these
   devices as well.

8.2.  Border/Edge Tunnel Routers

   Using customer-edge (CE) routers for tunnel endpoints allows the EID
   space associated with a site to be reachable via a small set of RLOCs
   assigned to the CE routers for that site.  This is the default
   behavior envisioned in the rest of this specification.

   This offers the opposite benefit of the first-hop/last-hop tunnel
   router scenario: the number of mapping entries and network management
   touch points are reduced, allowing better scaling.

   One disadvantage is that less of the network's resources are used to
   reach host endpoints thereby centralizing the point-of-failure domain
   and creating network choke points at the CE router.

   Note that more than one CE router at a site can be configured with
   the same IP address.  In this case an RLOC is an anycast address.
   This allows resilience between the CE routers.  That is, if a CE
   router fails, traffic is automatically routed to the other routers
   using the same anycast address.  However, this comes with the
   disadvantage where the site cannot control the entrance point when
   the anycast route is advertised out from all border routers.  Another
   disadvantage of using anycast locators is the limited advertisement
   scope of /32 (or /128 for IPv6) routes.

8.3.  ISP Provider-Edge (PE) Tunnel Routers

   Use of ISP PE routers as tunnel endpoint routers is not the typical
   deployment scenario envisioned in the specification.  This section
   attempts to capture some of reasoning behind this preference of
   implementing LISP on CE routers.

   Use of ISP PE routers as tunnel endpoint routers gives an ISP, rather
   than a site, control over the location of the egress tunnel
   endpoints.  That is, the ISP can decide if the tunnel endpoints are
   in the destination site (in either CE routers or last-hop routers
   within a site) or at other PE edges.  The advantage of this case is
   that two tunnel headers can be avoided.  By having the PE be the
   first router on the path to encapsulate, it can choose a TE path
   first, and the ETR can decapsulate and re-encapsulate for a tunnel to
   the destination end site.

   An obvious disadvantage is that the end site has no control over
   where its packets flow or the RLOCs used.  Other disadvantages
   include the difficulty in synchronizing path liveness updates between
   CE and PE routers.

   As mentioned in earlier sections a combination of these scenarios is
   possible at the expense of extra packet header overhead, if both site
   and provider want control, then recursive or re-encapsulating tunnels
   are used.

8.4.  LISP Functionality with Conventional NATs

   LISP routers can be deployed behind Network Address Translator (NAT)
   devices to provide the same set of packet services hosts have today
   when they are addressed out of private address space.

   It is important to note that a locator address in any LISP control
   message MUST be a globally routable address and therefore SHOULD NOT
   contain [RFC1918] addresses.  If a LISP router is configured with
   private addresses, they MUST be used only in the outer IP header so
   the NAT device can translate properly.  Otherwise, EID addresses MUST
   be translated before encapsulation is performed.  Both NAT
   translation and LISP encapsulation functions could be co-located in
   the same device.

   More details on LISP address translation can be found in [INTERWORK].

8.5.  Packets Egressing a LISP Site

   When a LISP site is using two ITRs for redundancy, the failure of one
   ITR will likely shift outbound traffic to the second.  This second
   ITR's cache may not not be populated with the same EID-to-RLOC
   mapping entries as the first.  If this second ITR does not have these
   mappings, traffic will be dropped while the mappings are retrieved
   from the mapping system.  The retrieval of these messages may
   increase the load of requests being sent into the mapping system.
   While this is not anticipated this will be a problem, the deployment
   Deployment and experimentation will determine if there is an whether this issue requiring
   requires more attention.

9.  Traceroute Considerations

   When a source host in a LISP site initiates a traceroute to a
   destination host in another LISP site, it is highly desirable for it
   to see the entire path.  Since packets are encapsulated from ITR to
   ETR, the hop across the tunnel could be viewed as a single hop.
   However, LISP traceroute will provide the entire path so the user can
   see 3 distinct segments of the path from a source LISP host to a
   destination LISP host:

      Segment 1 (in source LISP site based on EIDs):

          source-host ---> first-hop ... next-hop ---> ITR

      Segment 2 (in the core network based on RLOCs):

          ITR ---> next-hop ... next-hop ---> ETR

      Segment 3 (in the destination LISP site based on EIDs):

          ETR ---> next-hop ... last-hop ---> destination-host

   For segment 1 of the path, ICMP Time Exceeded messages are returned
   in the normal matter as they are today.  The ITR performs a TTL
   decrement and test for 0 before encapsulating.  So the ITR hop is
   seen by the traceroute source has an EID address (the address of
   site-facing interface).

   For segment 2 of the path, ICMP Time Exceeded messages are returned
   to the ITR because the TTL decrement to 0 is done on the outer
   header, so the destination of the ICMP messages are to the ITR RLOC
   address, the source RLOC address of the encapsulated traceroute
   packet.  The ITR looks inside of the ICMP payload to inspect the
   traceroute source so it can return the ICMP message to the address of
   the traceroute client as well as retaining the core router IP address
   in the ICMP message.  This is so the traceroute client can display
   the core router address (the RLOC address) in the traceroute output.
   The ETR returns its RLOC address and responds to the TTL decrement to
   0 like the previous core routers did.

   For segment 3, the next-hop router downstream from the ETR will be
   decrementing the TTL for the packet that was encapsulated, sent into
   the core, decapsulated by the ETR, and forwarded because it isn't the
   final destination.  If the TTL is decremented to 0, any router on the
   path to the destination of the traceroute, including the next-hop
   router or destination, will send an ICMP Time Exceeded message to the
   source EID of the traceroute client.  The ICMP message will be
   encapsulated by the local ITR and sent back to the ETR in the
   originated traceroute source site, where the packet will be delivered
   to the host.

9.1.  IPv6 Traceroute

   IPv6 traceroute follows the procedure described above since the
   entire traceroute data packet is included in ICMP Time Exceeded
   message payload.  Therefore, only the ITR needs to pay special
   attention for forwarding ICMP messages back to the traceroute source.

9.2.  IPv4 Traceroute

   For IPv4 traceroute, we cannot follow the above procedure since IPv4
   ICMP Time Exceeded messages only include the invoking IP header and 8
   bytes that follow the IP header.  Therefore, when a core router sends
   an IPv4 Time Exceeded message to an ITR, all the ITR has in the ICMP
   payload is the encapsulated header it prepended followed by a UDP
   header.  The original invoking IP header, and therefore the identity
   of the traceroute source is lost.

   The solution we propose to solve this problem is to cache traceroute
   IPv4 headers in the ITR and to match them up with corresponding IPv4
   Time Exceeded messages received from core routers and the ETR.  The
   ITR will use a circular buffer for caching the IPv4 and UDP headers
   of traceroute packets.  It will select a 16-bit number as a key to
   find them later when the IPv4 Time Exceeded messages are received.
   When an ITR encapsulates an IPv4 traceroute packet, it will use the
   16-bit number as the UDP source port in the encapsulating header.
   When the ICMP Time Exceeded message is returned to the ITR, the UDP
   header of the encapsulating header is present in the ICMP payload
   thereby allowing the ITR to find the cached headers for the
   traceroute source.  The ITR puts the cached headers in the payload
   and sends the ICMP Time Exceeded message to the traceroute source
   retaining the source address of the original ICMP Time Exceeded
   message (a core router or the ETR of the site of the traceroute
   destination).

   The signature of a traceroute packet comes in two forms.  The first
   form is encoded as a UDP message where the destination port is
   inspected for a range of values.  The second form is encoded as an
   ICMP message where the IP identification field is inspected for a
   well-known value.

9.3.  Traceroute using Mixed Locators

   When either an IPv4 traceroute or IPv6 traceroute is originated and
   the ITR encapsulates it in the other address family header, you
   cannot get all 3 segments of the traceroute.  Segment 2 of the
   traceroute can not be conveyed to the traceroute source since it is
   expecting addresses from intermediate hops in the same address format
   for the type of traceroute it originated.  Therefore, in this case,
   segment 2 will make the tunnel look like one hop.  All the ITR has to
   do to make this work is to not copy the inner TTL to the outer,
   encapsulating header's TTL when a traceroute packet is encapsulated
   using an RLOC from a different address family.  This will cause no
   TTL decrement to 0 to occur in core routers between the ITR and ETR.

10.  Mobility Considerations

   There are several kinds of mobility of which only some might be of
   concern to LISP.  Essentially they are as follows.

10.1.  Site Mobility

   A site wishes to change its attachment points to the Internet, and
   its LISP Tunnel Routers will have new RLOCs when it changes upstream
   providers.  Changes in EID-RLOC mappings for sites are expected to be
   handled by configuration, outside of the LISP protocol.

10.2.  Slow Endpoint Mobility

   An individual endpoint wishes to move, but is not concerned about
   maintaining session continuity.  Renumbering is involved.  LISP can
   help with the issues surrounding renumbering [RFC4192] [LISA96] by
   decoupling the address space used by a site from the address spaces
   used by its ISPs.  [RFC4984]

10.3.  Fast Endpoint Mobility

   Fast endpoint mobility occurs when an endpoint moves relatively
   rapidly, changing its IP layer network attachment point.  Maintenance
   of session continuity is a goal.  This is where the Mobile IPv4
   [RFC3344bis] and Mobile IPv6 [RFC3775] [RFC4866] mechanisms are used,
   and primarily where interactions with LISP need to be explored.

   The problem is that as an endpoint moves, it may require changes to
   the mapping between its EID and a set of RLOCs for its new network
   location.  When this is added to the overhead of mobile IP binding
   updates, some packets might be delayed or dropped.

   In IPv4 mobility, when an endpoint is away from home, packets to it
   are encapsulated and forwarded via a home agent which resides in the
   home area the endpoint's address belongs to.  The home agent will
   encapsulate and forward packets either directly to the endpoint or to
   a foreign agent which resides where the endpoint has moved to.
   Packets from the endpoint may be sent directly to the correspondent
   node, may be sent via the foreign agent, or may be reverse-tunneled
   back to the home agent for delivery to the mobile node.  As the
   mobile node's EID or available RLOC changes, LISP EID-to-RLOC
   mappings are required for communication between the mobile node and
   the home agent, whether via foreign agent or not.  As a mobile
   endpoint changes networks, up to three LISP mapping changes may be
   required:

   o  The mobile node moves from an old location to a new visited
      network location and notifies its home agent that it has done so.
      The Mobile IPv4 control packets the mobile node sends pass through
      one of the new visited network's ITRs, which needs a EID-RLOC
      mapping for the home agent.

   o  The home agent might not have the EID-RLOC mappings for the mobile
      node's "care-of" address or its foreign agent in the new visited
      network, in which case it will need to acquire them.

   o  When packets are sent directly to the correspondent node, it may
      be that no traffic has been sent from the new visited network to
      the correspondent node's network, and the new visited network's
      ITR will need to obtain an EID-RLOC mapping for the correspondent
      node's site.

   In addition, if the IPv4 endpoint is sending packets from the new
   visited network using its original EID, then LISP will need to
   perform a route-returnability check on the new EID-RLOC mapping for
   that EID.

   In IPv6 mobility, packets can flow directly between the mobile node
   and the correspondent node in either direction.  The mobile node uses
   its "care-of" address (EID).  In this case, the route-returnability
   check would not be needed but one more LISP mapping lookup may be
   required instead:

   o  As above, three mapping changes may be needed for the mobile node
      to communicate with its home agent and to send packets to the
      correspondent node.

   o  In addition, another mapping will be needed in the correspondent
      node's ITR, in order for the correspondent node to send packets to
      the mobile node's "care-of" address (EID) at the new network
      location.

   When both endpoints are mobile the number of potential mapping
   lookups increases accordingly.

   As a mobile node moves there are not only mobility state changes in
   the mobile node, correspondent node, and home agent, but also state
   changes in the ITRs and ETRs for at least some EID-prefixes.

   The goal is to support rapid adaptation, with little delay or packet
   loss for the entire system.  Also IP mobility can be modified to
   require fewer mapping changes.  In order to increase overall system
   performance, there may be a need to reduce the optimization of one
   area in order to place fewer demands on another.

   In LISP, one possibility is to "glean" information.  When a packet
   arrives, the ETR could examine the EID-RLOC mapping and use that
   mapping for all outgoing traffic to that EID.  It can do this after
   performing a route-returnability check, to ensure that the new
   network location does have a internal route to that endpoint.
   However, this does not cover the case where an ITR (the node assigned
   the RLOC) at the mobile-node location has been compromised.

   Mobile IP packet exchange is designed for an environment in which all
   routing information is disseminated before packets can be forwarded.
   In order to allow the Internet to grow to support expected future
   use, we are moving to an environment where some information may have
   to be obtained after packets are in flight.  Modifications to IP
   mobility should be considered in order to optimize the behavior of
   the overall system.  Anything which decreases the number of new EID-
   RLOC mappings needed when a node moves, or maintains the validity of
   an EID-RLOC mapping for a longer time, is useful.

10.4.  Fast Network Mobility

   In addition to endpoints, a network can be mobile, possibly changing
   xTRs.  A "network" can be as small as a single router and as large as
   a whole site.  This is different from site mobility in that it is
   fast and possibly short-lived, but different from endpoint mobility
   in that a whole prefix is changing RLOCs.  However, the mechanisms
   are the same and there is no new overhead in LISP.  A map request for
   any endpoint will return a binding for the entire mobile prefix.

   If mobile networks become a more common occurrence, it may be useful
   to revisit the design of the mapping service and allow for dynamic
   updates of the database.

   The issue of interactions between mobility and LISP needs to be
   explored further.  Specific improvements to the entire system will
   depend on the details of mapping mechanisms.  Mapping mechanisms
   should be evaluated on how well they support session continuity for
   mobile nodes.

10.5.  LISP Mobile Node Mobility

   A mobile device can use the LISP infrastructure to achieve mobility
   by implementing the LISP encapsulation and decapsulation functions
   and acting as a simple ITR/ETR.  By doing this, such a "LISP mobile
   node" can use topologically-independent EID IP addresses that are not
   advertised into and do not impose a cost on the global routing
   system.  These EIDs are maintained at the edges of the mapping system
   (in LISP Map-Servers and Map-Resolvers) and are provided on demand to
   only the correspondents of the LISP mobile node.

   Refer to the LISP Mobility Architecture specification [LISP-MN] for
   more details.

11.  Multicast Considerations

   A multicast group address, as defined in the original Internet
   architecture is an identifier of a grouping of topologically
   independent receiver host locations.  The address encoding itself
   does not determine the location of the receiver(s).  The multicast
   routing protocol, and the network-based state the protocol creates,
   determines where the receivers are located.

   In the context of LISP, a multicast group address is both an EID and
   a Routing Locator.  Therefore, no specific semantic or action needs
   to be taken for a destination address, as it would appear in an IP
   header.  Therefore, a group address that appears in an inner IP
   header built by a source host will be used as the destination EID.
   The outer IP header (the destination Routing Locator address),
   prepended by a LISP router, will use the same group address as the
   destination Routing Locator.

   Having said that, only the source EID and source Routing Locator
   needs to be dealt with.  Therefore, an ITR merely needs to put its
   own IP address in the source Routing Locator field when prepending
   the outer IP header.  This source Routing Locator address, like any
   other Routing Locator address MUST be globally routable.

   Therefore, an EID-to-RLOC mapping does not need to be performed by an
   ITR when a received data packet is a multicast data packet or when
   processing a source-specific Join (either by IGMPv3 or PIM).  But the
   source Routing Locator is decided by the multicast routing protocol
   in a receiver site.  That is, an EID to Routing Locator translation
   is done at control-time.

   Another approach is to have the ITR not encapsulate a multicast
   packet and allow the host built packet to flow into the core even if
   the source address is allocated out of the EID namespace.  If the
   RPF-Vector TLV [RFC5496] is used by PIM in the core, then core
   routers can RPF to the ITR (the Locator address which is injected
   into core routing) rather than the host source address (the EID
   address which is not injected into core routing).

   To avoid any EID-based multicast state in the network core, the first
   approach is chosen for LISP-Multicast.  Details for LISP-Multicast
   and Interworking with non-LISP sites is described in specification
   [MLISP].

12.  Security Considerations

   It is believed that most of the security mechanisms will be part of
   the mapping database service when using control plane procedures for
   obtaining EID-to-RLOC mappings.  For data plane triggered mappings,
   as described in this specification, protection is provided against
   ETR spoofing by using Return- Routability mechanisms evidenced by the
   use of a 24-bit Nonce field in the LISP encapsulation header and a
   64-bit Nonce field in the LISP control message.  The nonce, coupled
   with the ITR accepting only solicited Map-Replies goes a long way
   toward providing decent authentication.

   LISP does not rely on a PKI infrastructure or a more heavy weight
   authentication system.  These systems challenge the scalability of
   LISP which was a primary design goal.

   DoS attack prevention will depend on implementations rate-limiting
   Map-Requests and Map-Replies to the control plane as well as rate-
   limiting the number of data-triggered Map-Replies.

   An incorrectly implemented or malicious ITR might choose to ignore
   the priority and weights provided by the ETR in its Map-Reply.  This
   traffic steering would be limited to the traffic that is sent by this
   ITR's site, and no more severe than if the site initiated a bandwidth
   DoS attack on (one of) the ETR's ingress links.  The ITR's site would
   typically gain no benefit from not respecting the weights, and would
   likely to receive better service by abiding by them.

   To deal with map-cache exhaustion attempts in an ITR/PTR, the
   implementation should consider putting a maximum cap on the number of
   entries stored with a reserve list for special or frequently accessed
   sites.  This should be a configuration policy control set by the
   network administrator who manages ITRs and PTRs.

   Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings,
   cache sizing and maintenance is an issue to be kept in mind during
   implementation.  It is a good idea to have instrumentation in place
   to detect thrashing of the cache.  Implementation experimentation
   will be used to determine which cache management strategies work
   best.  It should be noted that an undersized cache in an ITR/PTR not
   only causes adverse affect on the site or region they support, but
   may also cause increased Map-Request load on the mapping system.

   There is a potential security risk implicit in the fact that ETRs generate the
   EID prefix to which they are responding.  In theory, an  An ETR can claim a shorter
   prefix than it is actually responsible for.  Various mechanisms to
   ameliorate or resolve this issue will be examined in the future,
   [LISP-SEC].

   Spoofing of inner header addresses of LISP encapsulated packets is
   possible like with any tunneling mechanism.  ITRs MUST verify the
   source address of a packet to be an EID that belongs to the site's
   EID-prefix range prior to encapsulation.  ETRs MUST NOT decapsulate
   and forward packets into their site where the inner header
   destination EID does not belong to the ETR's EID-prefix range for the
   site.  If a LISP encapsulated packet arrives at an ETR, it MAY
   compare the inner header source EID address and the outer header
   source RLOC address with the mapping that exists in the mapping
   database.  Then when spoofing attacks occur, the outer header source
   RLOC address can be used to trace back the attack to the source site,
   using existing operational tools.

12.1.  IETF Security Area Statement

   This document represents the thinking of the LISP working group.  The
   Security Area of the IETF believes there is an open security issue
   how LISP interacts with BCP 107's guidance on experimental specification does not address automated key
   management.  This and other issues would need to be resolved before
   standardization of LISP.  Accounting for these concerns may change
   management (AKM).  BCP 107 provides guidance in this area.  In
   addition, at the underlying design time of LISP.  It this writing, substantial work is important that deferring these
   discussions in order being
   undertaken to publish an experimental protocol sooner not
   restrict a standardized solution that balances concerns of all areas improve security of the IETF. routing system [KARP], [RPKI],
   [BGP-SEC], [LISP-SEC], Future work on LISP should address BCP-107 as
   well as other open security considerations, which may require changes
   to this specification.

13.  Network Management Considerations

   Considerations for Network Management tools exist so the LISP
   protocol suite can be operationally managed.  The mechanisms can be
   found in [LISP-MIB] and [LISP-LIG].

14.  IANA Considerations

   This section provides guidance to the Internet Assigned Numbers
   Authority (IANA) regarding registration of values related to the LISP
   specification, in accordance with BCP 26 and RFC 5226 [RFC5226].

   There are two name spaces in LISP that require registration:

   o  LISP IANA registry allocations should not be made for purposes
      unrelated to LISP routing or transport protocols.

   o  The following policies are used here with the meanings defined in
      BCP 26: "Specification Required", "IETF Consensus", "Experimental
      Use", "First Come First Served".

14.1.  LISP Address Type Codes

   Instance ID type codes have a range from 0 to 15, of which 0 and 1
   have been allocated [LCAF].  New Type Codes MUST be allocated
   starting at 2.  Type Codes 2 - 10 are to be assigned by IETF Review.
   Type Codes 11 - 15 are available on a First Come First Served policy.

   The following codes have been allocated:

   Type 0:  Null Body Type

   Type 1:  AFI List Type

   See [LCAF] for details for other possible unapproved address
   encodings.  The unapproved LCAF encodings are an area for further
   study and experimentation.

14.2.  LISP UDP Port Numbers

   The IANA registry has allocated UDP port numbers 4341 and 4342 for
   LISP data-plane and control-plane operation, respectively.

15.  References

15.1.  Normative References

   [BGP-SEC]  Lepinski, M., "An Overview of BGPSEC",
              draft-lepinski-bgpsec-overview-00.txt (work in progress),
              March 2011.

   [KARP]     Lebovitz, G. and M. Bhatia, "Keying and Authentication for
              Routing Protocols (KARP)Design Guidelines",
              draft-ietf-karp-design-guide-02.txt (work in progress),
              March 2011.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1700]  Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
              October 1994.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2404]  Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
              ESP and AH", RFC 2404, November 1998.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.

   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, September 2001.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

   [RFC4632]  Fuller, V. and T. Li, "Classless Inter-domain Routing
              (CIDR): The Internet Address Assignment and Aggregation
              Plan", BCP 122, RFC 4632, August 2006.

   [RFC4634]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and HMAC-SHA)", RFC 4634, July 2006.

   [RFC4866]  Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
              Optimization for Mobile IPv6", RFC 4866, May 2007.

   [RFC4984]  Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
              Workshop on Routing and Addressing", RFC 4984,
              September 2007.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5496]  Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
              Forwarding (RPF) Vector TLV", RFC 5496, March 2009.

   [RPKI]     Lepinski, M., "An Infrastructure to Support Secure
              Internet Routing", draft-ietf-sidr-arch-12.txt (work in
              progress), February 2011.

   [UDP-TUNNELS]
              Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled
              Packets"",
              Packets", draft-eubanks-chimento-6man-01.txt (work in
              progress), October 2010.

15.2.  Informative References

   [AFI]      IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
              NUMBERS http://www.iana.org/.../address-family-numbers,
              Febuary 2007.
              http://www.iana.org/assignments/address-family-numbers,
              January 2011.

   [AFI-REGISTRY]
              IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
              NUMBER registry http://www.iana.org/assignments/
              address-family-numbers/
              address-family-numbers.xml#address-family-numbers-1,
              January 2011.

   [ALT]      Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
              Alternative Topology (LISP-ALT)",
              draft-ietf-lisp-alt-06.txt
              draft-ietf-lisp-alt-07.txt (work in progress), March June 2011.

   [CHIAPPA]  Chiappa, J., "Endpoints and Endpoint names: A Proposed
              Enhancement to the Internet Architecture", Internet-
              Draft http://www.chiappa.net/~jnc/tech/endpoints.txt,
              1999.

   [CONS]     Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A
              Content distribution Overlay Network  Service for LISP",
              draft-meyer-lisp-cons-03.txt (work in progress),
              November 2007.

   [EMACS]    Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID
              Mappings Multicast Across Cooperating Systems for LISP",
              draft-curran-lisp-emacs-00.txt (work in progress),
              November 2007.

   [INTERWORK]
              Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
              "Interworking LISP with IPv4 and IPv6",
              draft-ietf-lisp-interworking-02.txt (work in progress),
              March
              June 2011.

   [LCAF]     Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
              Address Format", draft-farinacci-lisp-lcaf-04.txt (work in
              progress), October 2010.

   [LISA96]   Lear, E., Katinsky, J., Coffin, J., and D. Tharp,
              "Renumbering: Threat or Menace?", Usenix , September 1996.

   [LISP-DEPLOY]
              Jakab, L., Coras, F., Domingo-Pascual, J., and D. Lewis,
              "LISP Network Element Deployment Considerations",
              draft-jakab-lisp-deployment-02.txt (work in progress),
              February 2011.

   [LISP-LIG]
              Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)",
              draft-ietf-lisp-lig-01.txt (work in progress),
              October 2010.

   [LISP-MAIN]
              Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-farinacci-lisp-12.txt (work in progress),
              March 2009.

   [LISP-MIB]
              Schudel, G., Jain, A., and V. Moreno, "LISP MIB",
              draft-ietf-lisp-mib-01.txt (work in progress), March 2011.

   [LISP-MN]  Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP
              Mobility Architecture", draft-meyer-lisp-mn-04.txt (work
              in progress), October 2010.

   [LISP-MS]  Farinacci, D. and V. Fuller, "LISP Map Server",
              draft-ietf-lisp-ms-07.txt
              draft-ietf-lisp-ms-09.txt (work in progress), March June 2011.

   [LISP-SEC]
              Maino, F., Ermagon, V., Cabellos, A., Sausez, D., and O.
              Bonaventure, "LISP-Security (LISP-SEC)",
              draft-maino-lisp-sec-00.txt
              draft-ietf-lisp-sec-00.txt (work in progress),
              February June 2011.

   [LOC-ID-ARCH]
              Meyer, D. and D. Lewis, "Architectural Implications of
              Locator/ID  Separation",
              draft-meyer-loc-id-implications-01.txt (work in progress),
              Januaryr 2009.

   [MLISP]    Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
              "LISP for Multicast Environments",
              draft-ietf-lisp-multicast-05.txt
              draft-ietf-lisp-multicast-06.txt (work in progress),
              April
              June 2011.

   [NERD]     Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
              draft-lear-lisp-nerd-08.txt (work in progress),
              March 2010.

   [OPENLISP]
              Iannone, L. and O. Bonaventure, "OpenLISP Implementation
              Report", draft-iannone-openlisp-implementation-01.txt
              (work in progress), July 2008.

   [RADIR]    Narten, T., "Routing and Addressing Problem Statement",
              draft-narten-radir-problem-statement-00.txt (work in
              progress), July 2007.

   [RFC3344bis]
              Perkins, C., "IP Mobility Support for IPv4, revised",
              draft-ietf-mip4-rfc3344bis-05 (work in progress),
              July 2007.

   [RFC4192]  Baker, F., Lear, E., and R. Droms, "Procedures for
              Renumbering an IPv6 Network without a Flag Day", RFC 4192,
              September 2005.

   [RPMD]     Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol
              for Routing Protocol Meta-data  Dissemination",
              draft-handley-p2ppush-unpublished-2007726.txt (work in
              progress), July 2007.

   [VERSIONING]
              Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping
              Versioning", draft-ietf-lisp-map-versioning-01.txt (work
              in progress), March 2011.

Appendix A.  Acknowledgments

   An initial thank you goes to Dave Oran for planting the seeds for the
   initial ideas for LISP.  His consultation continues to provide value
   to the LISP authors.

   A special and appreciative thank you goes to Noel Chiappa for
   providing architectural impetus over the past decades on separation
   of location and identity, as well as detailed review of the LISP
   architecture and documents, coupled with enthusiasm for making LISP a
   practical and incremental transition for the Internet.

   The authors would like to gratefully acknowledge many people who have
   contributed discussion and ideas to the making of this proposal.
   They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller,
   Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston,
   David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley,
   Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler,
   Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi
   Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Terry
   Manderson, Roger Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van
   Beijnum, Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien
   Saucez, Damian Lezama, Attilla De Groot, Parantap Lahiri, David
   Black, Roque Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin,
   Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari
   Arkko, Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu,
   Dhirendra Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri
   Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina
   Ermagan, Albert Cabellos, Fabio Maino, Victor Moreno, Chris White,
   Clarence Filsfils, and Alia Atlas.

   This work originated in the Routing Research Group (RRG) of the IRTF.
   The individual submission [LISP-MAIN] was converted into this IETF
   LISP working group draft.

Appendix B.  Document Change Log

B.1.  Changes to draft-ietf-lisp-13.txt

   o  Posted June 2011 to complete working group last call.

   o  Tracker item 87.  Put Yakov suggested wording in the EID-prefix
      definition section to reference [INTERWORK] and [LISP-DEPLOY]
      about discussion on transition and access mechanisms.

   o  Change "ITRs" to "ETRs" in the Locator Status Bit definition
      section and data packet description section per Damien's comment.

   o  Remove the normative reference to [LISP-SEC] when describing the
      S-bit in the ECM and Map-Reply headers.

   o  Tracker item 54.  Added text from John Scudder in the "Packets
      Egressing a LISP Site" section.

   o  Add sentence to the "Reencapsulating Tunnel" definition about how
      reencapsulation loops can occur when not coordinating among
      multiple mapping database systems.

   o  Remove "In theory" from a sentence in the Security Considerations
      section.

   o  Remove Security Area Statement title and reword section with
      Eliot's provided text.  The text was agreed upon by LISP-WG chairs
      and Security ADs.

   o  Remove word "potential" from the over-claiming paragraph of the
      Security Considerations section per Stephen's request.

   o  Wordsmithing and other editorial comments from Alia.

B.2.  Changes to draft-ietf-lisp-12.txt

   o  Posted April 2011.

   o  Tracker item 87.  Provided rewording how an EID-prefix can be
      resued in the definition section of "EID-prefix".

   o  Tracker item 95.  Change "eliminate" to "defer" in section 4.1.

   o  Tracker item 110.  Added that the Mapping Protocol Data field in
      the Map-Reply message is only used when needed by the particular
      Mapping Database System.

   o  Tracker item 111.  Indicate that if an LSB that is assocaited with
      an anycast address, that there is at least one RLOC that is up.

   o  Tracker item 108.  Make clear the R-bit does not define RLOC path
      reachability.

   o  Tracker item 107.  Indicate that weights are relative to each
      other versus requiring an addition of up to 100%.

   o  Tracker item 46.  Add a sentence how LISP products should be sized
      for the appropriate demand so cache thrashing is avoided.

   o  Change some references of RFC 5226 to [AFI] per Luigi.

   o  Per Luigi, make reference to "EID-AFI" consistent to "EID-prefix-
      AFI".

   o  Tracker item 66.  Indicate that appending locators to a locator-
      set is done when the added locators are lexiographically lexicographically greater
      than the previous ones in the set.

   o  Tracker item 87.  Once again reword the definition of the EID-
      prefix to reflect recent comments.

   o  Tracker item 70.  Added text to security section on what the
      implications could be if an ITR does not obey priority and weights
      from a Map-Reply message.

   o  Tracker item 54.  Added text to the new section titled "Packets
      Egressing a LISP Site" to describe the implications when two or
      more ITRs exist at a site where only one ITR is used for egress
      traffic and when there is a shift of traffic to the others, how
      the map-cache will need to be populated in those new egress ITRs.

   o  Tracker item 33.  Make more clear in the Routing Locator Selection
      section what an ITR should do when it sees an R-bit of 0 in a
      locator-record of a Map-Reply.

   o  Tracker item 33.  Add paragraph to the EID Reachability section
      indicating that site parittioning is under investigation.

   o  Tracker item 58.  Added last paragraph of Security Considerations
      section about how to protect inner header EID address spoofing
      attacks.

   o  Add suggested Sam text to indicate that all security concerns need
      not be addressed for moving document to Experimental RFC status.
      Put this in a subsection of the Secuirty Considerations section.

B.2.

B.3.  Changes to draft-ietf-lisp-11.txt

   o  Posted March 30, 2011.

   o  Change IANA URL.  The URL we had pointed to a general protocol
      numbers page.

   o  Added the "s" bit to the Map-Request to allow SMR-invoked Map-
      Requests to be sent to a MN ETR via the map-server.

   o  Generalize text for the defintion of Reencapsuatling tunnels.

   o  Add pargraph suggested by Joel to explain how implementation
      experimentation will be used to determine the proper cache
      management techniques.

   o  Add Yakov provided text for the definition of "EID-to-RLOC
      "Database".

   o  Add reference in Section 8, Deployment Scenarios, to the
      draft-jakab-lisp-deploy-02.txt draft.

   o  Clarify sentence about no hardware changes needed to support LISP
      encapsulation.

   o  Add paragraph about what is the procedure when a locator is
      inserted in the middle of a locator-set.

   o  Add a definition for Locator-Status-Bits so we can emphasize they
      are used as a hint for router up/down status and not path
      reachability.

   o  Change "BGP RIB" to "RIB" per Clarence's comment.

   o  Fixed complaints by IDnits.

   o  Add subsection to Security Considerations section indicating how
      EID-prefix overclaiming in Map-Replies is for further study and
      add a reference to LISP-SEC.

B.3.

B.4.  Changes to draft-ietf-lisp-10.txt

   o  Posted March 2011.

   o  Add p-bit to Map-Request so there is documentary reasons to know
      when a PITR has sent a Map-Request to an ETR.

   o  Add Map-Notify message which is used to acknowledge a Map-Register
      message sent to a Map-Server.

   o  Add M-bit to the Map-Register message so an ETR that wants an
      acknowledgment for the Map-Register can request one.

   o  Add S-bit to the ECM and Map-Reply messages to describe security
      data that can be present in each message.  Then refer to
      [LISP-SEC] for expansive details.

   o  Add Network Management Considerations section and point to the MIB
      and LIG drafts.

   o  Remove the word "simple" per Yakov's comments.

B.4.

B.5.  Changes to draft-ietf-lisp-09.txt

   o  Posted October 2010.

   o  Add to IANA Consideration section about the use of LCAF Type
      values that accepted and maintained by the IANA registry and not
      the LCAF specification.

   o  Indicate that implementations should be able to receive LISP
      control messages when either UDP port is 4342, so they can be
      robust in the face of intervening NAT boxes.

   o  Add paragraph to SMR section to indicate that an ITR does not need
      to respond to an SMR-based Map-Request when it has no map-cache
      entry for the SMR source's EID-prefix.

B.5.

B.6.  Changes to draft-ietf-lisp-08.txt

   o  Posted August 2010.

   o  In section 6.1.6, remove statement about setting TTL to 0 in Map-
      Register messages.

   o  Clarify language in section 6.1.5 about Map-Replying to Data-
      Probes or Map-Requests.

   o  Indicate that outer TTL should only be copied to inner TTL when it
      is less than inner TTL.

   o  Indicate a source-EID for RLOC-probes are encoded with an AFI
      value of 0.

   o  Indicate that SMRs can have a global or per SMR destination rate-
      limiter.

   o  Add clarifications to the SMR procedures.

   o  Add definitions for "client-side" and 'server-side" terms used in
      this specification.

   o  Clear up language in section 6.4, last paragraph.

   o  Change ACT of value 0 to "no-action".  This is so we can RLOC-
      probe a PETR and have it return a Map-Reply with a locator-set of
      size 0.  The way it is spec'ed the map-cache entry has action
      "dropped".  Drop-action is set to 3.

   o  Add statement about normalizing locator weights.

   o  Clarify R-bit definition in the Map-Reply locator record.

   o  Add section on EID Reachability within a LISP site.

   o  Clarify another disadvantage of using anycast locators.

   o  Reworded Abstract.

   o  Change section 2.0 Introduction to remove obsolete information
      such as the LISP variant definitions.

   o  Change section 5 title from "Tunneling Details" to "LISP
      Encapsulation Details".

   o  Changes to section 5 to include results of network deployment
      experience with MTU.  Recommend that implementations use either
      the stateful or stateless handling.

   o  Make clarification wordsmithing to Section 7 and 8.

   o  Identify that if there is one locator in the locator-set of a map-
      cache entry, that an SMR from that locator should be responded to
      by sending the the SMR-invoked Map-Request to the database mapping
      system rather than to the RLOC itself (which may be unreachable).

   o  When describing Unicast and Multicast Weights indicate the the
      values are relative weights rather than percentages.  So it
      doesn't imply the sum of all locator weights in the locator-set
      need to be 100.

   o  Do some wordsmithing on copying TTL and TOS fields.

   o  Numerous wordsmithing changes from Dave Meyer.  He fine toothed
      combed the spec.

   o  Removed Section 14 "Prototype Plans and Status".  We felt this
      type of section is no longer appropriate for a protocol
      specification.

   o  Add clarification text for the IRC description per Damien's
      commentary.

   o  Remove text on copying nonce from SMR to SMR-invoked Map- Request
      per Vina's comment about a possible DoS vector.

   o  Clarify (S/2 + H) in the stateless MTU section.

   o  Add text to reflect Damien's comment about the description of the
      "ITR-RLOC Address" field in the Map-Request. that the list of RLOC
      addresses are local addresses of the Map-Requester.

B.6.

B.7.  Changes to draft-ietf-lisp-07.txt

   o  Posted April 2010.

   o  Added I-bit to data header so LSB field can also be used as an
      Instance ID field.  When this occurs, the LSB field is reduced to
      8-bits (from 32-bits).

   o  Added V-bit to the data header so the 24-bit nonce field can also
      be used for source and destination version numbers.

   o  Added Map-Version 12-bit value to the EID-record to be used in all
      of Map-Request, Map-Reply, and Map-Register messages.

   o  Added multiple ITR-RLOC fields to the Map-Request packet so an ETR
      can decide what address to select for the destination of a Map-
      Reply.

   o  Added L-bit (Local RLOC bit) and p-bit (Probe-Reply RLOC bit) to
      the Locator-Set record of an EID-record for a Map-Reply message.
      The L-bit indicates which RLOCs in the locator-set are local to
      the sender of the message.  The P-bit indicates which RLOC is the
      source of a RLOC-probe Reply (Map-Reply) message.

   o  Add reference to the LISP Canonical Address Format [LCAF] draft.

   o  Made editorial and clarification changes based on comments from
      Dhirendra Trivedi.

   o  Added wordsmithing comments from Joel Halpern on DF=1 setting.

   o  Add John Zwiebel clarification to Echo Nonce Algorithm section
      6.3.1.

   o  Add John Zwiebel comment about expanding on proxy-map-reply bit
      for Map-Register messages.

   o  Add NAT section per Ron Bonica comments.

   o  Fix IDnits issues per Ron Bonica.

   o  Added section on Virtualization and Segmentation to explain the
      use if the Instance ID field in the data header.

   o  There are too many P-bits, keep their scope to the packet format
      description and refer to them by name every where else in the
      spec.

   o  Scanned all occurrences of "should", "should not", "must" and
      "must not" and uppercased them.

   o  John Zwiebel offered text for section 4.1 to modernize the
      example.  Thanks Z!

   o  Make it more clear in the definition of "EID-to-RLOC Database"
      that all ETRs need to have the same database mapping.  This
      reflects a comment from John Scudder.

   o  Add a definition "Route-returnability" to the Definition of Terms
      section.

   o  In section 9.2, add text to describe what the signature of
      traceroute packets can look like.

   o  Removed references to Data Probe for introductory example.  Data-
      probes are still part of the LISP design but not encouraged.

   o  Added the definition for "LISP site" to the Definition of Terms"
      section.

B.7.

B.8.  Changes to draft-ietf-lisp-06.txt

   Editorial based changes:

   o  Posted December 2009.

   o  Fix typo for flags in LISP data header.  Changed from "4" to "5".

   o  Add text to indicate that Map-Register messages must contain a
      computed UDP checksum.

   o  Add definitions for PITR and PETR.

   o  Indicate an AFI value of 0 is an unspecified address.

   o  Indicate that the TTL field of a Map-Register is not used and set
      to 0 by the sender.  This change makes this spec consistent with
      [LISP-MS].

   o  Change "... yield a packet size of L bytes" to "... yield a packet
      size greater than L bytes".

   o  Clarify section 6.1.5 on what addresses and ports are used in Map-
      Reply messages.

   o  Clarify that LSBs that go beyond the number of locators do not to
      be SMRed when the locator addresses are greater lexicographically
      than the locator in the existing locator-set.

   o  Add Gregg, Srini, and Amit to acknowledgment section.

   o  Clarify in the definition of a LISP header what is following the
      UDP header.

   o  Clarify "verifying Map-Request" text in section 6.1.3.

   o  Add Xu Xiaohu to the acknowledgment section for introducing the
      problem of overlapping EID-prefixes among multiple sites in an RRG
      email message.

   Design based changes:

   o  Use stronger language to have the outer IPv4 header set DF=1 so we
      can avoid fragment reassembly in an ETR or PETR.  This will also
      make IPv4 and IPv6 encapsulation have consistent behavior.

   o  Map-Requests should not be sent in ECM with the Probe bit is set.
      These type of Map-Requests are used as RLOC-probes and are sent
      directly to locator addresses in the underlying network.

   o  Add text in section 6.1.5 about returning all EID-prefixes in a
      Map-Reply sent by an ETR when there are overlapping EID-prefixes
      configure.

   o  Add text in a new subsection of section 6.1.5 about dealing with
      Map-Replies with coarse EID-prefixes.

B.8.

B.9.  Changes to draft-ietf-lisp-05.txt

   o  Posted September 2009.

   o  Added this Document Change Log appendix.

   o  Added section indicating that encapsulated Map-Requests must use
      destination UDP port 4342.

   o  Don't use AH in Map-Registers.  Put key-id, auth-length, and auth-
      data in Map-Register payload.

   o  Added Jari to acknowledgment section.

   o  State the source-EID is set to 0 when using Map-Requests to
      refresh or RLOC-probe.

   o  Make more clear what source-RLOC should be for a Map-Request.

   o  The LISP-CONS authors thought that the Type definitions for CONS
      should be removed from this specification.

   o  Removed nonce from Map-Register message, it wasn't used so no need
      for it.

   o  Clarify what to do for unspecified Action bits for negative Map-
      Replies.  Since No Action is a drop, make value 0 Drop.

B.9.

B.10.  Changes to draft-ietf-lisp-04.txt

   o  Posted September 2009.

   o  How do deal with record count greater than 1 for a Map-Request.
      Damien and Joel comment.  Joel suggests: 1) Specify that senders
      compliant with the current document will always set the count to
      1, and note that the count is included for future extensibility.
      2) Specify what a receiver compliant with the draft should do if
      it receives a request with a count greater than 1.  Presumably, it
      should send some error back?

   o  Add Fred Templin in acknowledgment section.

   o  Add Margaret and Sam to the acknowledgment section for their great
      comments.

   o  Say more about LAGs in the UDP section per Sam Hartman's comment.

   o  Sam wants to use MAY instead of SHOULD for ignoring checksums on
      ETR.  From the mailing list: "You'd need to word it as an ITR MAY
      send a zero checksum, an ETR MUST accept a 0 checksum and MAY
      ignore the checksum completely.  And of course we'd need to
      confirm that can actually be implemented.  In particular, hardware
      that verifies UDP checksums on receive needs to be checked to make
      sure it permits 0 checksums."

   o  Margaret wants a reference to
      http://www.ietf.org/id/draft-eubanks-chimento-6man-00.txt.

   o  Fix description in Map-Request section.  Where we describe Map-
      Reply Record, change "R-bit" to "M-bit".

   o  Add the mobility bit to Map-Replies.  So PTRs don't probe so often
      for MNs but often enough to get mapping updates.

   o  Indicate SHA1 can be used as well for Map-Registers.

   o  More Fred comments on MTU handling.

   o  Isidor comment about spec'ing better periodic Map-Registers.  Will
      be fixed in draft-ietf-lisp-ms-02.txt.

   o  Margaret's comment on gleaning: "The current specification does
      not make it clear how long gleaned map entries should be retained
      in the cache, nor does it make it clear how/ when they will be
      validated.  The LISP spec should, at the very least, include a
      (short) default lifetime for gleaned entries, require that they be
      validated within a short period of time, and state that a new
      gleaned entry should never overwrite an entry that was obtained
      from the mapping system.  The security implications of storing
      "gleaned" entries should also be explored in detail."

   o  Add section on RLOC-probing per working group feedback.

   o  Change "loc-reach-bits" to "loc-status-bits" per comment from
      Noel.

   o  Remove SMR-bit from data-plane.  Dino prefers to have it in the
      control plane only.

   o  Change LISP header to allow a "Research Bit" so the Nonce and LSB
      fields can be turned off and used for another future purpose.  For
      Luigi et al versioning convergence.

   o  Add a N-bit to the data header suggested by Noel.  Then the nonce
      field could be used when N is not 1.

   o  Clarify that when E-bit is 0, the nonce field can be an echoed
      nonce or a random nonce.  Comment from Jesper.

   o  Indicate when doing data-gleaning that a verifying Map-Request is
      sent to the source-EID of the gleaned data packet so we can avoid
      map-cache corruption by a 3rd party.  Comment from Pedro.

   o  Indicate that a verifying Map-Request, for accepting mapping data,
      should be sent over the ALT (or to the EID).

   o  Reference IPsec RFC 4302.  Comment from Sam and Brian Weis.

   o  Put E-bit in Map-Reply to tell ITRs that the ETR supports echo-
      noncing.  Comment by Pedro and Dino.

   o  Jesper made a comment to loosen the language about requiring the
      copy of inner TTL to outer TTL since the text to get mixed-AF
      traceroute to work would violate the "MUST" clause.  Changed from
      MUST to SHOULD in section 5.3.

B.10.

B.11.  Changes to draft-ietf-lisp-03.txt

   o  Posted July 2009.

   o  Removed loc-reach-bits longword from control packets per Damien
      comment.

   o  Clarifications in MTU text from Roque.

   o  Added text to indicate that the locator-set be sorted by locator
      address from Isidor.

   o  Clarification text from John Zwiebel in Echo-Nonce section.

B.11.

B.12.  Changes to draft-ietf-lisp-02.txt

   o  Posted July 2009.

   o  Encapsulation packet format change to add E-bit and make loc-
      reach-bits 32-bits in length.

   o  Added Echo-Nonce Algorithm section.

   o  Clarification how ECN bits are copied.

   o  Moved S-bit in Map-Request.

   o  Added P-bit in Map-Request and Map-Reply messages to anticipate
      RLOC-Probe Algorithm.

   o  Added to Mobility section to reference [LISP-MN].

B.12.

B.13.  Changes to draft-ietf-lisp-01.txt

   o  Posted 2 days after draft-ietf-lisp-00.txt in May 2009.

   o  Defined LEID to be a "LISP EID".

   o  Indicate encapsulation use IPv4 DF=0.

   o  Added negative Map-Reply messages with drop, native-forward, and
      send-map-request actions.

   o  Added Proxy-Map-Reply bit to Map-Register.

B.13.

B.14.  Changes to draft-ietf-lisp-00.txt

   o  Posted May 2009.

   o  Rename of draft-farinacci-lisp-12.txt.

   o  Acknowledgment to RRG.

Authors' Addresses

   Dino Farinacci
   cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: dino@cisco.com

   Vince Fuller
   cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: vaf@cisco.com

   Dave Meyer
   cisco Systems
   170 Tasman Drive
   San Jose, CA
   USA

   Email: dmm@cisco.com

   Darrel Lewis
   cisco Systems
   170 Tasman Drive
   San Jose, CA
   USA

   Email: darlewis@cisco.com
--Apple-Mail-3--328112272 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-3--328112272 Content-Disposition: attachment; filename=draft-ietf-lisp-13.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-13.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Experimental D. Meyer Expires: December 23, 2011 D. Lewis cisco Systems June 21, 2011 Locator/ID Separation Protocol (LISP) draft-ietf-lisp-13 Abstract This draft describes a network-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. LISP can be incrementally deployed, without a "flag day", and offers traffic engineering, multi-homing, and mobility benefits even to early adopters, when there are relatively few LISP- capable sites. Design and development of LISP was largely motivated by the problem statement produced by the October, 2006 IAB Routing and Addressing Workshop. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 23, 2011. Farinacci, et al. Expires December 23, 2011 [Page 1] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 Copyright Notice Copyright (c) 2011 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 BSD License. Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 7 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14 5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . . 16 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 17 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 17 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 19 5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 22 5.4.1. A Stateless Solution to MTU Handling . . . . . . . . . 23 5.4.2. A Stateful Solution to MTU Handling . . . . . . . . . 24 5.5. Using Virtualization and Segmentation with LISP . . . . . 24 6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 26 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 26 6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 28 6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 28 6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 31 6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 32 6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 36 6.1.6. Map-Register Message Format . . . . . . . . . . . . . 38 6.1.7. Map-Notify Message Format . . . . . . . . . . . . . . 40 6.1.8. Encapsulated Control Message Format . . . . . . . . . 41 6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 43 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 45 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 47 6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 48 6.4. EID Reachability within a LISP Site . . . . . . . . . . . 49 6.5. Routing Locator Hashing . . . . . . . . . . . . . . . . . 50 6.6. Changing the Contents of EID-to-RLOC Mappings . . . . . . 50 Farinacci, et al. Expires December 23, 2011 [Page 2] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 6.6.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 51 6.6.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 52 6.6.3. Database Map Versioning . . . . . . . . . . . . . . . 54 7. Router Performance Considerations . . . . . . . . . . . . . . 55 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 56 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 57 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 57 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 58 8.4. LISP Functionality with Conventional NATs . . . . . . . . 58 8.5. Packets Egressing a LISP Site . . . . . . . . . . . . . . 59 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 60 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 61 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 61 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 61 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 63 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 63 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 63 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 63 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 65 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 65 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 67 12. Security Considerations . . . . . . . . . . . . . . . . . . . 68 13. Network Management Considerations . . . . . . . . . . . . . . 70 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 14.1. LISP Address Type Codes . . . . . . . . . . . . . . . . . 71 14.2. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . . 71 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72 15.1. Normative References . . . . . . . . . . . . . . . . . . . 72 15.2. Informative References . . . . . . . . . . . . . . . . . . 73 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 77 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 78 B.1. Changes to draft-ietf-lisp-13.txt . . . . . . . . . . . . 78 B.2. Changes to draft-ietf-lisp-12.txt . . . . . . . . . . . . 78 B.3. Changes to draft-ietf-lisp-11.txt . . . . . . . . . . . . 80 B.4. Changes to draft-ietf-lisp-10.txt . . . . . . . . . . . . 80 B.5. Changes to draft-ietf-lisp-09.txt . . . . . . . . . . . . 81 B.6. Changes to draft-ietf-lisp-08.txt . . . . . . . . . . . . 81 B.7. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 83 B.8. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 85 B.9. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 86 B.10. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 86 B.11. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 88 B.12. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 88 B.13. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 89 B.14. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 90 Farinacci, et al. Expires December 23, 2011 [Page 3] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Farinacci, et al. Expires December 23, 2011 [Page 4] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 2. Introduction This document describes the Locator/Identifier Separation Protocol (LISP), which provides a set of functions for routers to exchange information used to map from non-routeable Endpoint Identifiers (EIDs) to routeable Routing Locators (RLOCs). It also defines a mechanism for these LISP routers to encapsulate IP packets addressed with EIDs for transmission across an Internet that uses RLOCs for routing and forwarding. Creation of LISP was initially motivated by discussions during the IAB-sponsored Routing and Addressing Workshop held in Amsterdam in October, 2006 (see [RFC4984]). A key conclusion of the workshop was that the Internet routing and addressing system was not scaling well in the face of the explosive growth of new sites; one reason for this poor scaling is the increasing number of multi-homed and other sites that cannot be addressed as part of topologically- or provider-based aggregated prefixes. Additional work that more completely described the problem statement may be found in [RADIR]. A basic observation, made many years ago in early networking research such as that documented in [CHIAPPA] and [RFC4984], is that using a single address field for both identifying a device and for determining where it is topologically located in the network requires optimization along two conflicting axes: for routing to be efficient, the address must be assigned topologically; for collections of devices to be easily and effectively managed, without the need for renumbering in response to topological change (such as that caused by adding or removing attachment points to the network or by mobility events), the address must explicitly not be tied to the topology. The approach that LISP takes to solving the routing scalability problem is to replace IP addresses with two new types of numbers: Routing Locators (RLOCs), which are topologically assigned to network attachment points (and are therefore amenable to aggregation) and used for routing and forwarding of packets through the network; and Endpoint Identifiers (EIDs), which are assigned independently from the network topology, are used for numbering devices, and are aggregated along administrative boundaries. LISP then defines functions for mapping between the two numbering spaces and for encapsulating traffic originated by devices using non-routeable EIDs for transport across a network infrastructure that routes and forwards using RLOCs. Both RLOCs and EIDs are syntactically- identical to IP addresses; it is the semantics of how they are used that differs. This document describes the protocol that implements these functions. The database which stores the mappings between EIDs and RLOCs is Farinacci, et al. Expires December 23, 2011 [Page 5] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 explicitly a separate "module" to facilitate experimentation with a variety of approaches. One database design that is being developed and prototyped as part of the LISP working group work is [ALT]. Others that have been described but not implemented include [CONS], [EMACS], [RPMD], [NERD]. Finally, [LISP-MS], documents a general- purpose service interface for accessing a mapping database; this interface is intended to make the mapping database modular so that different approaches can be tried without the need to modify installed xTRs. This experimental specification does not address automated key management. Addressing automated key management is necessary for Internet standards. See Section 12 for further security details. Farinacci, et al. Expires December 23, 2011 [Page 6] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 3. Definition of Terms Provider Independent (PI) Addresses: PI addresses are an address block assigned from a pool where blocks are not associated with any particular location in the network (e.g. from a particular service provider), and is therefore not topologically aggregatable in the routing system. Provider Assigned (PA) Addresses: PA addresses are an a address block assigned to a site by each service provider to which a site connects. Typically, each block is sub-block of a service provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and is aggregated into the larger block before being advertised into the global Internet. Traditionally, IP multihoming has been implemented by each multi-homed site acquiring its own, globally- visible prefix. LISP uses only topologically-assigned and aggregatable address blocks for RLOCs, eliminating this demonstrably non-scalable practice. Routing Locator (RLOC): A RLOC is an IPv4 or IPv6 address of an egress tunnel router (ETR). A RLOC is the output of a EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically-aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as PA addresses. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site. Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. The host obtains a destination EID the same way it obtains an destination address today, for example through a Domain Name System (DNS) [RFC1034] lookup or Session Invitation Protocol (SIP) [RFC3261] exchange. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID is allocated to a host from an EID-prefix block associated with the site where the host is located. An EID can be used by a host to refer to other hosts. EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be assigned in a hierarchical manner, independent of the network topology, to facilitate scaling of the mapping database. In addition, an EID block assigned to a site may have site-local structure (subnetting) for routing within the site; this structure is not visible to the global routing system. When used in discussions with other Locator/ID separation proposals, a LISP EID will be called a "LEID". Throughout this document, any references to "EID" refers to an LEID. Farinacci, et al. Expires December 23, 2011 [Page 7] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 EID-prefix: An EID-prefix is a power-of-two block of EIDs which are allocated to a site by an address allocation authority. EID- prefixes are associated with a set of RLOC addresses which make up a "database mapping". EID-prefix allocations can be broken up into smaller blocks when an RLOC set is to be associated with the smaller EID-prefix. A globally routed address block (whether PI or PA) is not inherently an EID-prefix. A globally routed address block may be used by its assignee as an EID block. The converse is not supported. That is, a site which receives an explicitly allocated EID-prefix may not use that EID-prefix as a globally prefix. This would require coordination and cooperation with the entities managing the mapping infrastructure. Once this has been done, that block could be removed from the globally routed IP system, if other suitable transition and access mechanisms are in place. Discussion of such transition and access mechanisms can be found in [INTERWORK] and [LISP-DEPLOY]. End-system: An end-system is an IPv4 or IPv6 device that originates packets with a single IPv4 or IPv6 header. The end-system supplies an EID value for the destination address field of the IP header when communicating globally (i.e. outside of its routing domain). An end-system can be a host computer, a switch or router device, or any network appliance. Ingress Tunnel Router (ITR): An ITR is a router which accepts an IP packet with a single IP header (more precisely, an IP packet that does not contain a LISP header). The router treats this "inner" IP destination address as an EID and performs an EID-to-RLOC mapping lookup. The router then prepends an "outer" IP header with one of its globally-routable RLOCs in the source address field and the result of the mapping lookup in the destination address field. Note that this destination RLOC may be an intermediate, proxy device that has better knowledge of the EID- to-RLOC mapping closer to the destination EID. In general, an ITR receives IP packets from site end-systems on one side and sends LISP-encapsulated IP packets toward the Internet on the other side. Specifically, when a service provider prepends a LISP header for Traffic Engineering purposes, the router that does this is also regarded as an ITR. The outer RLOC the ISP ITR uses can be based on the outer destination address (the originating ITR's supplied RLOC) or the inner destination address (the originating hosts supplied EID). Farinacci, et al. Expires December 23, 2011 [Page 8] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 TE-ITR: A TE-ITR is an ITR that is deployed in a service provider network that prepends an additional LISP header for Traffic Engineering purposes. Egress Tunnel Router (ETR): An ETR is a router that accepts an IP packet where the destination address in the "outer" IP header is one of its own RLOCs. The router strips the "outer" header and forwards the packet based on the next IP header found. In general, an ETR receives LISP-encapsulated IP packets from the Internet on one side and sends decapsulated IP packets to site end-systems on the other side. ETR functionality does not have to be limited to a router device. A server host can be the endpoint of a LISP tunnel as well. TE-ETR: A TE-ETR is an ETR that is deployed in a service provider network that strips an outer LISP header for Traffic Engineering purposes. xTR: A xTR is a reference to an ITR or ETR when direction of data flow is not part of the context description. xTR refers to the router that is the tunnel endpoint. Used synonymously with the term "Tunnel Router". For example, "An xTR can be located at the Customer Edge (CE) router", meaning both ITR and ETR functionality is at the CE router. EID-to-RLOC Cache: The EID-to-RLOC cache is a short-lived, on- demand table in an ITR that stores, tracks, and is responsible for timing-out and otherwise validating EID-to-RLOC mappings. This cache is distinct from the full "database" of EID-to-RLOC mappings, it is dynamic, local to the ITR(s), and relatively small while the database is distributed, relatively static, and much more global in scope. EID-to-RLOC Database: The EID-to-RLOC database is a global distributed database that contains all known EID-prefix to RLOC mappings. Each potential ETR typically contains a small piece of the database: the EID-to-RLOC mappings for the EID prefixes "behind" the router. These map to one of the router's own, globally-visible, IP addresses. The same database mapping entries MUST be configured on all ETRs for a given site. In a steady state the EID-prefixes for the site and the locator-set for each EID-prefix MUST be the same on all ETRs. Procedures to enforce and/or verify this are outside the scope of this document. Note that there may be transient conditions when the EID-prefix for the site and locator-set for each EID-prefix may not be the same on all ETRs. This has no negative implications. Farinacci, et al. Expires December 23, 2011 [Page 9] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 Recursive Tunneling: Recursive tunneling occurs when a packet has more than one LISP IP header. Additional layers of tunneling may be employed to implement traffic engineering or other re-routing as needed. When this is done, an additional "outer" LISP header is added and the original RLOCs are preserved in the "inner" header. Any references to tunnels in this specification refers to dynamic encapsulating tunnels and never are they statically configured. Reencapsulating Tunnels: Reencapsulating tunneling occurs when an ETR removes a LISP header, then acts as an ITR to prepend another LISP header. Doing this allows a packet to be re-routed by the re-encapsulating router without adding the overhead of additional tunnel headers. Any references to tunnels in this specification refers to dynamic encapsulating tunnels and never are they statically configured. When using multiple mapping database systems, care must be taken to not create reencapsulation loops. LISP Header: a term used in this document to refer to the outer IPv4 or IPv6 header, a UDP header, and a LISP-specific 8-byte header that follows the UDP header, an ITR prepends or an ETR strips. Address Family Identifier (AFI): a term used to describe an address encoding in a packet. An address family currently pertains to an IPv4 or IPv6 address. See [AFI]/[AFI-REGISTRY] and [RFC1700] for details. An AFI value of 0 used in this specification indicates an unspecified encoded address where the length of the address is 0 bytes following the 16-bit AFI value of 0. Negative Mapping Entry: A negative mapping entry, also known as a negative cache entry, is an EID-to-RLOC entry where an EID-prefix is advertised or stored with no RLOCs. That is, the locator-set for the EID-to-RLOC entry is empty or has an encoded locator count of 0. This type of entry could be used to describe a prefix from a non-LISP site, which is explicitly not in the mapping database. There are a set of well defined actions that are encoded in a Negative Map-Reply. Data Probe: A data-probe is a LISP-encapsulated data packet where the inner header destination address equals the outer header destination address used to trigger a Map-Reply by a decapsulating ETR. In addition, the original packet is decapsulated and delivered to the destination host. A Data Probe is used in some of the mapping database designs to "probe" or request a Map-Reply from an ETR; in other cases, Map-Requests are used. See each mapping database design for details. Farinacci, et al. Expires December 23, 2011 [Page 10] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 Proxy ITR (PITR): A PITR is also known as a PTR is defined and described in [INTERWORK], a PITR acts like an ITR but does so on behalf of non-LISP sites which send packets to destinations at LISP sites. Proxy ETR (PETR): A PETR is defined and described in [INTERWORK], a PETR acts like an ETR but does so on behalf of LISP sites which send packets to destinations at non-LISP sites. Route-returnability: is an assumption that the underlying routing system will deliver packets to the destination. When combined with a nonce that is provided by a sender and returned by a receiver limits off-path data insertion. LISP site: is a set of routers in an edge network that are under a single technical administration. LISP routers which reside in the edge network are the demarcation points to separate the edge network from the core network. Client-side: a term used in this document to indicate a connection initiation attempt by an EID. The ITR(s) at the LISP site are the first to get involved in obtaining database map cache entries by sending Map-Request messages. Server-side: a term used in this document to indicate a connection initiation attempt is being accepted for a destination EID. The ETR(s) at the destination LISP site are the first to send Map- Replies to the source site initiating the connection. The ETR(s) at this destination site can obtain mappings by gleaning information from Map-Requests, Data-Probes, or encapsulated packets. Locator-Status-Bits (LSBs): Locator status bits are present in the LISP header. They are used by ITRs to inform ETRs about the up/ down status of all ETRs at the local site. These bits are used as a hint to convey up/down router status and not path reachability status. The LSBs can be verified by use of one of the Locator Reachability Algoriths described in Section 6.3. Farinacci, et al. Expires December 23, 2011 [Page 11] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 4. Basic Overview One key concept of LISP is that end-systems (hosts) operate the same way they do today. The IP addresses that hosts use for tracking sockets, connections, and for sending and receiving packets do not change. In LISP terminology, these IP addresses are called Endpoint Identifiers (EIDs). Routers continue to forward packets based on IP destination addresses. When a packet is LISP encapsulated, these addresses are referred to as Routing Locators (RLOCs). Most routers along a path between two hosts will not change; they continue to perform routing/ forwarding lookups on the destination addresses. For routers between the source host and the ITR as well as routers from the ETR to the destination host, the destination address is an EID. For the routers between the ITR and the ETR, the destination address is an RLOC. Another key LISP concept is the "Tunnel Router". A tunnel router prepends LISP headers on host-originated packets and strip them prior to final delivery to their destination. The IP addresses in this "outer header" are RLOCs. During end-to-end packet exchange between two Internet hosts, an ITR prepends a new LISP header to each packet and an egress tunnel router strips the new header. The ITR performs EID-to-RLOC lookups to determine the routing path to the ETR, which has the RLOC as one of its IP addresses. Some basic rules governing LISP are: o End-systems (hosts) only send to addresses which are EIDs. They don't know addresses are EIDs versus RLOCs but assume packets get to LISP routers, which in turn, deliver packets to the destination the end-system has specified. o EIDs are always IP addresses assigned to hosts. o LISP routers mostly deal with Routing Locator addresses. See details later in Section 4.1 to clarify what is meant by "mostly". o RLOCs are always IP addresses assigned to routers; preferably, topologically-oriented addresses from provider CIDR blocks. o When a router originates packets it may use as a source address either an EID or RLOC. When acting as a host (e.g. when terminating a transport session such as SSH, TELNET, or SNMP), it may use an EID that is explicitly assigned for that purpose. An EID that identifies the router as a host MUST NOT be used as an RLOC; an EID is only routable within the scope of a site. A typical BGP configuration might demonstrate this "hybrid" EID/RLOC Farinacci, et al. Expires December 23, 2011 [Page 12] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 usage where a router could use its "host-like" EID to terminate iBGP sessions to other routers in a site while at the same time using RLOCs to terminate eBGP sessions to routers outside the site. o EIDs are not expected to be usable for global end-to-end communication in the absence of an EID-to-RLOC mapping operation. They are expected to be used locally for intra-site communication. o EID prefixes are likely to be hierarchically assigned in a manner which is optimized for administrative convenience and to facilitate scaling of the EID-to-RLOC mapping database. The hierarchy is based on a address allocation hierarchy which is independent of the network topology. o EIDs may also be structured (subnetted) in a manner suitable for local routing within an autonomous system. An additional LISP header may be prepended to packets by a TE-ITR when re-routing of the path for a packet is desired. A potential use-case for this would be an ISP router that needs to perform traffic engineering for packets flowing through its network. In such a situation, termed Recursive Tunneling, an ISP transit acts as an additional ingress tunnel router and the RLOC it uses for the new prepended header would be either a TE-ETR within the ISP (along intra-ISP traffic engineered path) or a TE-ETR within another ISP (an inter-ISP traffic engineered path, where an agreement to build such a path exists). In order to avoid excessive packet overhead as well as possible encapsulation loops, this document mandates that a maximum of two LISP headers can be prepended to a packet. For initial LISP deployments, it is assumed two headers is sufficient, where the first prepended header is used at a site for Location/Identity separation and second prepended header is used inside a service provider for Traffic Engineering purposes. Tunnel Routers can be placed fairly flexibly in a multi-AS topology. For example, the ITR for a particular end-to-end packet exchange might be the first-hop or default router within a site for the source host. Similarly, the egress tunnel router might be the last-hop router directly-connected to the destination host. Another example, perhaps for a VPN service out-sourced to an ISP by a site, the ITR could be the site's border router at the service provider attachment point. Mixing and matching of site-operated, ISP-operated, and other tunnel routers is allowed for maximum flexibility. See Section 8 for more details. Farinacci, et al. Expires December 23, 2011 [Page 13] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 4.1. Packet Flow Sequence This section provides an example of the unicast packet flow with the following conditions: o Source host "host1.abc.com" is sending a packet to "host2.xyz.com", exactly what host1 would do if the site was not using LISP. o Each site is multi-homed, so each tunnel router has an address (RLOC) assigned from the service provider address block for each provider to which that particular tunnel router is attached. o The ITR(s) and ETR(s) are directly connected to the source and destination, respectively, but the source and destination can be located anywhere in LISP site. o Map-Requests can be sent on the underlying routing system topology or over an alternative topology [ALT]. o Map-Replies are sent on the underlying routing system topology. Client host1.abc.com wants to communicate with server host2.xyz.com: 1. host1.abc.com wants to open a TCP connection to host2.xyz.com. It does a DNS lookup on host2.xyz.com. An A/AAAA record is returned. This address is the destination EID. The locally- assigned address of host1.abc.com is used as the source EID. An IPv4 or IPv6 packet is built and forwarded through the LISP site as a normal IP packet until it reaches a LISP ITR. 2. The LISP ITR must be able to map the EID destination to an RLOC of one of the ETRs at the destination site. The specific method used to do this is not described in this example. See [ALT] or [CONS] for possible solutions. 3. The ITR will send a LISP Map-Request. Map-Requests SHOULD be rate-limited. 4. When an alternate mapping system is not in use, the Map-Request packet is routed through the underlying routing system. Otherwise, the Map-Request packet is routed on an alternate logical topology. In either case, when the Map-Request arrives at one of the ETRs at the destination site, it will process the packet as a control message. 5. The ETR looks at the destination EID of the Map-Request and matches it against the prefixes in the ETR's configured EID-to- Farinacci, et al. Expires December 23, 2011 [Page 14] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 RLOC mapping database. This is the list of EID-prefixes the ETR is supporting for the site it resides in. If there is no match, the Map-Request is dropped. Otherwise, a LISP Map-Reply is returned to the ITR. 6. The ITR receives the Map-Reply message, parses the message (to check for format validity) and stores the mapping information from the packet. This information is stored in the ITR's EID-to- RLOC mapping cache. Note that the map cache is an on-demand cache. An ITR will manage its map cache in such a way that optimizes for its resource constraints. 7. Subsequent packets from host1.abc.com to host2.xyz.com will have a LISP header prepended by the ITR using the appropriate RLOC as the LISP header destination address learned from the ETR. Note the packet may be sent to a different ETR than the one which returned the Map-Reply due to the source site's hashing policy or the destination site's locator-set policy. 8. The ETR receives these packets directly (since the destination address is one of its assigned IP addresses), strips the LISP header and forwards the packets to the attached destination host. In order to defer the need for a mapping lookup in the reverse direction, an ETR MAY create a cache entry that maps the source EID (inner header source IP address) to the source RLOC (outer header source IP address) in a received LISP packet. Such a cache entry is termed a "gleaned" mapping and only contains a single RLOC for the EID in question. More complete information about additional RLOCs SHOULD be verified by sending a LISP Map-Request for that EID. Both ITR and the ETR may also influence the decision the other makes in selecting an RLOC. See Section 6 for more details. Farinacci, et al. Expires December 23, 2011 [Page 15] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 5. LISP Encapsulation Details Since additional tunnel headers are prepended, the packet becomes larger and can exceed the MTU of any link traversed from the ITR to the ETR. It is recommended in IPv4 that packets do not get fragmented as they are encapsulated by the ITR. Instead, the packet is dropped and an ICMP Too Big message is returned to the source. This specification recommends that implementations support for one of the proposed fragmentation and reassembly schemes. These two existing schemes are detailed in Section 5.4. Farinacci, et al. Expires December 23, 2011 [Page 16] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 5.1. LISP IPv4-in-IPv4 Header Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| IHL |Type of Service| Total Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identification |Flags| Fragment Offset | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OH | Time to Live | Protocol =3D 17 | Header Checksum = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source Routing Locator | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E|V|I|flags| Nonce/Map-Version | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | Instance ID/Locator Status Bits | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| IHL |Type of Service| Total Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identification |Flags| Fragment Offset | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IH | Time to Live | Protocol | Header Checksum | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source EID | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination EID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2. LISP IPv6-in-IPv6 Header Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| Traffic Class | Flow Label | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires December 23, 2011 [Page 17] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 | | Payload Length | Next Header=3D17| Hop Limit = | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | O + + u | | t + Source Routing Locator + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | ^ + Destination Routing Locator + | | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E|V|I|flags| Nonce/Map-Version | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | Instance ID/Locator Status Bits | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| Traffic Class | Flow Label | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Payload Length | Next Header | Hop Limit | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | I + + n | | n + Source EID + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | ^ + Destination EID + \ | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires December 23, 2011 [Page 18] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 5.3. Tunnel Header Field Descriptions Inner Header: The inner header is the header on the datagram received from the originating host. The source and destination IP addresses are EIDs. Outer Header: The outer header is a new header prepended by an ITR. The address fields contain RLOCs obtained from the ingress router's EID-to-RLOC cache. The IP protocol number is "UDP (17)" from [RFC0768]. The DF bit of the Flags field is set to 0 when the method in Section 5.4.1 is used and set to 1 when the method in Section 5.4.2 is used. UDP Header: The UDP header contains a ITR selected source port when encapsulating a packet. See Section 6.5 for details on the hash algorithm used to select a source port based on the 5-tuple of the inner header. The destination port MUST be set to the well-known IANA assigned port value 4341. UDP Checksum: The UDP checksum field SHOULD be transmitted as zero by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS]. When a packet with a zero UDP checksum is received by an ETR, the ETR MUST accept the packet for decapsulation. When an ITR transmits a non-zero value for the UDP checksum, it MUST send a correctly computed value in this field. When an ETR receives a packet with a non-zero UDP checksum, it MAY choose to verify the checksum value. If it chooses to perform such verification, and the verification fails, the packet MUST be silently dropped. If the ETR chooses not to perform the verification, or performs the verification successfully, the packet MUST be accepted for decapsulation. The handling of UDP checksums for all tunneling protocols, including LISP, is under active discussion within the IETF. When that discussion concludes, any necessary changes will be made to align LISP with the outcome of the broader discussion. UDP Length: The UDP length field is for an IPv4 encapsulated packet, the inner header Total Length plus the UDP and LISP header lengths are used. For an IPv6 encapsulated packet, the inner header Payload Length plus the size of the IPv6 header (40 bytes) plus the size of the UDP and LISP headers are used. The UDP header length is 8 bytes. N: The N bit is the nonce-present bit. When this bit is set to 1, the low-order 24-bits of the first 32-bits of the LISP header contains a Nonce. See Section 6.3.1 for details. Both N and V bits MUST NOT be set in the same packet. If they are, a decapsulating ETR MUST treat the "Nonce/Map-Version" field as Farinacci, et al. Expires December 23, 2011 [Page 19] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 having a Nonce value present. L: The L bit is the Locator-Status-Bits field enabled bit. When this bit is set to 1, the Locator-Status-Bits in the second 32-bits of the LISP header are in use. x 1 x x 0 x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|flags| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator Status Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E: The E bit is the echo-nonce-request bit. When this bit is set to 1, the N bit MUST be 1. This bit SHOULD be ignored and has no meaning when the N bit is set to 0. See Section 6.3.1 for details. V: The V bit is the Map-Version present bit. When this bit is set to 1, the N bit MUST be 0. Refer to Section 6.6.3 for more details. This bit indicates that the first 4 bytes of the LISP header is encoded as: 0 x 0 1 x x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|flags| Source Map-Version | Dest Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator Status Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I: The I bit is the Instance ID bit. See Section 5.5 for more details. When this bit is set to 1, the Locator Status Bits field is reduced to 8-bits and the high-order 24-bits are used as an Instance ID. If the L-bit is set to 0, then the low-order 8 bits are transmitted as zero and ignored on receipt. The format of the last 4 bytes of the LISP header would look like: Farinacci, et al. Expires December 23, 2011 [Page 20] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 x x x x 1 x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|flags| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID | LSBs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ flags: The flags field is a 3-bit field is reserved for future flag use. It MUST be set to 0 on transmit and MUST be ignored on receipt. LISP Nonce: The LISP nonce field is a 24-bit value that is randomly generated by an ITR when the N-bit is set to 1. The nonce is also used when the E-bit is set to request the nonce value to be echoed by the other side when packets are returned. When the E-bit is clear but the N-bit is set, a remote ITR is either echoing a previously requested echo-nonce or providing a random nonce. See Section 6.3.1 for more details. LISP Locator Status Bits: The locator status bits field in the LISP header is set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. Each RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator Status Bits are numbered from 0 to n-1 from the least significant bit of field. The field is 32-bits when the I-bit is set to 0 and is 8 bits when the I-bit is set to 1. When a Locator Status Bit is set to 1, the ITR is indicating to the ETR the RLOC associated with the bit ordinal has up status. See Section 6.3 for details on how an ITR can determine the status of the ETRs at the same site. When a site has multiple EID- prefixes which result in multiple mappings (where each could have a different locator-set), the Locator Status Bits setting in an encapsulated packet MUST reflect the mapping for the EID-prefix that the inner-header source EID address matches. If the LSB for an anycast locator is set to 1, then there is at least one RLOC with that address the ETR is considered 'up'. When doing ITR/PITR encapsulation: o The outer header Time to Live field (or Hop Limit field, in case of IPv6) SHOULD be copied from the inner header Time to Live field. o The outer header Type of Service field (or the Traffic Class field, in the case of IPv6) SHOULD be copied from the inner header Type of Service field (with one caveat, see below). When doing ETR/PETR decapsulation: Farinacci, et al. Expires December 23, 2011 [Page 21] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 o The inner header Time to Live field (or Hop Limit field, in case of IPv6) SHOULD be copied from the outer header Time to Live field, when the Time to Live field of the outer header is less than the Time to Live of the inner header. Failing to perform this check can cause the Time to Live of the inner header to increment across encapsulation/decapsulation cycle. This check is also performed when doing initial encapsulation when a packet comes to an ITR or PITR destined for a LISP site. o The inner header Type of Service field (or the Traffic Class field, in the case of IPv6) SHOULD be copied from the outer header Type of Service field (with one caveat, see below). Note if an ETR/PETR is also an ITR/PITR and choose to reencapsulate after decapsulating, the net effect of this is that the new outer header will carry the same Time to Live as the old outer header. Copying the TTL serves two purposes: first, it preserves the distance the host intended the packet to travel; second, and more importantly, it provides for suppression of looping packets in the event there is a loop of concatenated tunnels due to misconfiguration. See Section 9.3 for TTL exception handling for traceroute packets. The ECN field occupies bits 6 and 7 of both the IPv4 Type of Service field and the IPv6 Traffic Class field [RFC3168]. The ECN field requires special treatment in order to avoid discarding indications of congestion [RFC3168]. ITR encapsulation MUST copy the 2-bit ECN field from the inner header to the outer header. Re-encapsulation MUST copy the 2-bit ECN field from the stripped outer header to the new outer header. If the ECN field contains a congestion indication codepoint (the value is '11', the Congestion Experienced (CE) codepoint), then ETR decapsulation MUST copy the 2-bit ECN field from the stripped outer header to the surviving inner header that is used to forward the packet beyond the ETR. These requirements preserve Congestion Experienced (CE) indications when a packet that uses ECN traverses a LISP tunnel and becomes marked with a CE indication due to congestion between the tunnel endpoints. 5.4. Dealing with Large Encapsulated Packets This section proposes two mechanisms to deal with packets that exceed the path MTU between the ITR and ETR. It is left to the implementor to decide if the stateless or stateful mechanism should be implemented. Both or neither can be used since it is a local decision in the ITR regarding how to deal with MTU issues, and sites can interoperate with differing mechanisms. Farinacci, et al. Expires December 23, 2011 [Page 22] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 Both stateless and stateful mechanisms also apply to Reencapsulating and Recursive Tunneling. So any actions below referring to an ITR also apply to an TE-ITR. 5.4.1. A Stateless Solution to MTU Handling An ITR stateless solution to handle MTU issues is described as follows: 1. Define an architectural constant S for the maximum size of a packet, in bytes, an ITR would like to receive from a source inside of its site. 2. Define L to be the maximum size, in bytes, a packet of size S would be after the ITR prepends the LISP header, UDP header, and outer network layer header of size H. 3. Calculate: S + H =3D L. When an ITR receives a packet from a site-facing interface and adds H bytes worth of encapsulation to yield a packet size greater than L bytes, it resolves the MTU issue by first splitting the original packet into 2 equal-sized fragments. A LISP header is then prepended to each fragment. The size of the encapsulated fragments is then (S/2 + H), which is less than the ITR's estimate of the path MTU between the ITR and its correspondent ETR. When an ETR receives encapsulated fragments, it treats them as two individually encapsulated packets. It strips the LISP headers then forwards each fragment to the destination host of the destination site. The two fragments are reassembled at the destination host into the single IP datagram that was originated by the source host. This behavior is performed by the ITR when the source host originates a packet with the DF field of the IP header is set to 0. When the DF field of the IP header is set to 1, or the packet is an IPv6 packet originated by the source host, the ITR will drop the packet when the size is greater than L, and sends an ICMP Too Big message to the source with a value of S, where S is (L - H). When the outer header encapsulation uses an IPv4 header, an implementation SHOULD set the DF bit to 1 so ETR fragment reassembly can be avoided. An implementation MAY set the DF bit in such headers to 0 if it has good reason to believe there are unresolvable path MTU issues between the sending ITR and the receiving ETR. This specification recommends that L be defined as 1500. Farinacci, et al. Expires December 23, 2011 [Page 23] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 5.4.2. A Stateful Solution to MTU Handling An ITR stateful solution to handle MTU issues is described as follows and was first introduced in [OPENLISP]: 1. The ITR will keep state of the effective MTU for each locator per mapping cache entry. The effective MTU is what the core network can deliver along the path between ITR and ETR. 2. When an IPv6 encapsulated packet or an IPv4 encapsulated packet with DF bit set to 1, exceeds what the core network can deliver, one of the intermediate routers on the path will send an ICMP Too Big message to the ITR. The ITR will parse the ICMP message to determine which locator is affected by the effective MTU change and then record the new effective MTU value in the mapping cache entry. 3. When a packet is received by the ITR from a source inside of the site and the size of the packet is greater than the effective MTU stored with the mapping cache entry associated with the destination EID the packet is for, the ITR will send an ICMP Too Big message back to the source. The packet size advertised by the ITR in the ICMP Too Big message is the effective MTU minus the LISP encapsulation length. Even though this mechanism is stateful, it has advantages over the stateless IP fragmentation mechanism, by not involving the destination host with reassembly of ITR fragmented packets. 5.5. Using Virtualization and Segmentation with LISP When multiple organizations inside of a LISP site are using private addresses [RFC1918] as EID-prefixes, their address spaces MUST remain segregated due to possible address duplication. An Instance ID in the address encoding can aid in making the entire AFI based address unique. See IANA Considerations Section 14.1 for details for possible address encodings. An Instance ID can be carried in a LISP encapsulated packet. An ITR that prepends a LISP header, will copy a 24-bit value, used by the LISP router to uniquely identify the address space. The value is copied to the Instance ID field of the LISP header and the I-bit is set to 1. When an ETR decapsulates a packet, the Instance ID from the LISP header is used as a table identifier to locate the forwarding table to use for the inner destination EID lookup. Farinacci, et al. Expires December 23, 2011 [Page 24] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 For example, a 802.1Q VLAN tag or VPN identifier could be used as a 24-bit Instance ID. Farinacci, et al. Expires December 23, 2011 [Page 25] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 6. EID-to-RLOC Mapping 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats The following UDP packet formats are used by the LISP control-plane. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol =3D 17 | Header Checksum = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port | Dest Port | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | LISP Message | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header=3D17| Hop Limit = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Routing Locator + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | Farinacci, et al. Expires December 23, 2011 [Page 26] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 + Destination Routing Locator + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port | Dest Port | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | LISP Message | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LISP UDP-based messages are the Map-Request and Map-Reply messages. When a UDP Map-Request is sent, the UDP source port is chosen by the sender and the destination UDP port number is set to 4342. When a UDP Map-Reply is sent, the source UDP port number is set to 4342 and the destination UDP port number is copied from the source port of either the Map-Request or the invoking data packet. Implementations MUST be prepared to accept packets when either the source port or destination UDP port is set to 4342 due to NATs changing port number values. The UDP Length field will reflect the length of the UDP header and the LISP Message payload. The UDP Checksum is computed and set to non-zero for Map-Request, Map-Reply, Map-Register and ECM control messages. It MUST be checked on receipt and if the checksum fails, the packet MUST be dropped. LISP-CONS [CONS] uses TCP to send LISP control messages. The format of control messages includes the UDP header so the checksum and length fields can be used to protect and delimit message boundaries. This main LISP specification is the authoritative source for message format definitions for the Map-Request and Map-Reply messages. Farinacci, et al. Expires December 23, 2011 [Page 27] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 6.1.1. LISP Packet Type Allocations This section will be the authoritative source for allocating LISP Type values. Current allocations are: Reserved: 0 b'0000' LISP Map-Request: 1 b'0001' LISP Map-Reply: 2 b'0010' LISP Map-Register: 3 b'0011' LISP Map-Notify: 4 b'0100' LISP Encapsulated Control Message: 8 b'1000' 6.1.2. Map-Request Message Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=3D1 |A|M|P|S|p|s| Reserved | IRC | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source-EID-AFI | Source EID Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ITR-RLOC-AFI n | ITR-RLOC Address n ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Reserved | EID mask-len | EID-prefix-AFI | Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | EID-prefix ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Map-Reply Record ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mapping Protocol Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet field descriptions: Farinacci, et al. Expires December 23, 2011 [Page 28] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 Type: 1 (Map-Request) A: This is an authoritative bit, which is set to 0 for UDP-based Map- Requests sent by an ITR. M: When set, it indicates a Map-Reply Record segment is included in the Map-Request. P: This is the probe-bit which indicates that a Map-Request SHOULD be treated as a locator reachability probe. The receiver SHOULD respond with a Map-Reply with the probe-bit set, indicating the Map-Reply is a locator reachability probe reply, with the nonce copied from the Map-Request. See Section 6.3.2 for more details. S: This is the SMR bit. See Section 6.6.2 for details. p: This is the PITR bit. This bit is set to 1 when a PITR sends a Map-Request. s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is sending a Map-Request in response to a received SMR-based Map- Request. Reserved: It MUST be set to 0 on transmit and MUST be ignored on receipt. IRC: This 5-bit field is the ITR-RLOC Count which encodes the additional number of (ITR-RLOC-AFI, ITR-RLOC Address) fields present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC- Address) pair must always be encoded. Multiple ITR-RLOC Address fields are used so a Map-Replier can select which destination address to use for a Map-Reply. The IRC value ranges from 0 to 31, and for a value of 1, there are 2 ITR-RLOC addresses encoded and so on up to 31 which encodes a total of 32 ITR-RLOC addresses. Record Count: The number of records in this Map-Request message. A record is comprised of the portion of the packet that is labeled 'Rec' above and occurs the number of times equal to Record Count. For this version of the protocol, a receiver MUST accept and process Map-Requests that contain one or more records, but a sender MUST only send Map-Requests containing one record. Support for requesting multiple EIDs in a single Map-Request message will be specified in a future version of the protocol. Nonce: An 8-byte random value created by the sender of the Map- Request. This nonce will be returned in the Map-Reply. The security of the LISP mapping protocol depends critically on the strength of the nonce in the Map-Request message. The nonce Farinacci, et al. Expires December 23, 2011 [Page 29] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 SHOULD be generated by a properly seeded pseudo-random (or strong random) source. See [RFC4086] for advice on generating security- sensitive random data. Source-EID-AFI: Address family of the "Source EID Address" field. Source EID Address: This is the EID of the source host which originated the packet which is invoking this Map-Request. When Map-Requests are used for refreshing a map-cache entry or for RLOC-probing, an AFI value 0 is used and this field is of zero length. ITR-RLOC-AFI: Address family of the "ITR-RLOC Address" field that follows this field. ITR-RLOC Address: Used to give the ETR the option of selecting the destination address from any address family for the Map-Reply message. This address MUST be a routable RLOC address of the sender of the Map-Request message. EID mask-len: Mask length for EID prefix. EID-prefix-AFI: Address family of EID-prefix according to [AFI] EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 address-family. When a Map-Request is sent by an ITR because a data packet is received for a destination where there is no mapping entry, the EID-prefix is set to the destination IP address of the data packet. And the 'EID mask-len' is set to 32 or 128 for IPv4 or IPv6, respectively. When an xTR wants to query a site about the status of a mapping it already has cached, the EID- prefix used in the Map-Request has the same mask-length as the EID-prefix returned from the site when it sent a Map-Reply message. Map-Reply Record: When the M bit is set, this field is the size of a single "Record" in the Map-Reply format. This Map-Reply record contains the EID-to-RLOC mapping entry associated with the Source EID. This allows the ETR which will receive this Map-Request to cache the data if it chooses to do so. Mapping Protocol Data: See [CONS] for details. This field is optional and present when the UDP length indicates there is enough space in the packet to include it. Farinacci, et al. Expires December 23, 2011 [Page 30] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 6.1.3. EID-to-RLOC UDP Map-Request Message A Map-Request is sent from an ITR when it needs a mapping for an EID, wants to test an RLOC for reachability, or wants to refresh a mapping before TTL expiration. For the initial case, the destination IP address used for the Map-Request is the destination-EID from the packet which had a mapping cache lookup failure. For the latter 2 cases, the destination IP address used for the Map-Request is one of the RLOC addresses from the locator-set of the map cache entry. The source address is either an IPv4 or IPv6 RLOC address depending if the Map-Request is using an IPv4 versus IPv6 header, respectively. In all cases, the UDP source port number for the Map-Request message is an ITR/PITR selected 16-bit value and the UDP destination port number is set to the well-known destination port number 4342. A successful Map-Reply updates the cached set of RLOCs associated with the EID prefix range. One or more Map-Request (ITR-RLOC-AFI, ITR-RLOC-Address) fields MUST be filled in by the ITR. The number of fields (minus 1) encoded MUST be placed in the IRC field. The ITR MAY include all locally configured locators in this list or just provide one locator address from each address family it supports. If the ITR erroneously provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map- Request. Map-Requests can also be LISP encapsulated using UDP destination port 4342 with a LISP type value set to "Encapsulated Control Message", when sent from an ITR to a Map-Resolver. Likewise, Map-Requests are LISP encapsulated the same way from a Map-Server to an ETR. Details on encapsulated Map-Requests and Map-Resolvers can be found in [LISP-MS]. Map-Requests MUST be rate-limited. It is recommended that a Map- Request for the same EID-prefix be sent no more than once per second. An ITR that is configured with mapping database information (i.e. it is also an ETR) may optionally include those mappings in a Map- Request. When an ETR configured to accept and verify such "piggybacked" mapping data receives such a Map-Request and it does not have this mapping in the map-cache, it may originate a "verifying Map-Request", addressed to the map-requesting ITR. If the ETR has a map-cache entry that matches the "piggybacked" EID and the RLOC is in the locator-set for the entry, then it may send the "verifying Map- Request" directly to the originating Map-Request source. If the RLOC is not in the locator-set, then the ETR MUST send the "verifying Map- Request" to the "piggybacked" EID. Doing this forces the "verifying Map-Request" to go through the mapping database system to reach the authoritative source of information about that EID, guarding against Farinacci, et al. Expires December 23, 2011 [Page 31] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 RLOC-spoofing in in the "piggybacked" mapping data. 6.1.4. Map-Reply Message Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=3D2 |P|E|S| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | ACT |A| Reserved | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c | Rsvd | Map-Version Number | EID-prefix-AFI | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | EID-prefix | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| Priority | Weight | M Priority | M Weight | | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o | Unused Flags |L|p|R| Loc-AFI | | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| Locator | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mapping Protocol Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet field descriptions: Type: 2 (Map-Reply) P: This is the probe-bit which indicates that the Map-Reply is in response to a locator reachability probe Map-Request. The nonce field MUST contain a copy of the nonce value from the original Map-Request. See Section 6.3.2 for more details. E: Indicates that the ETR which sends this Map-Reply message is advertising that the site is enabled for the Echo-Nonce locator reachability algorithm. See Section 6.3.1 for more details. Farinacci, et al. Expires December 23, 2011 [Page 32] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 S: This is the Security bit. When set to 1 the field following the Mapping Protocol Data field will have the following format. The detailed format of the Authentication Data Content is for further study. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AD Type | Authentication Data Content . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved: It MUST be set to 0 on transmit and MUST be ignored on receipt. Record Count: The number of records in this reply message. A record is comprised of that portion of the packet labeled 'Record' above and occurs the number of times equal to Record count. Nonce: A 24-bit value set in a Data-Probe packet or a 64-bit value from the Map-Request is echoed in this Nonce field of the Map- Reply. Record TTL: The time in minutes the recipient of the Map-Reply will store the mapping. If the TTL is 0, the entry SHOULD be removed from the cache immediately. If the value is 0xffffffff, the recipient can decide locally how long to store the mapping. Locator Count: The number of Locator entries. A locator entry comprises what is labeled above as 'Loc'. The locator count can be 0 indicating there are no locators for the EID-prefix. EID mask-len: Mask length for EID prefix. ACT: This 3-bit field describes negative Map-Reply actions. These bits are used only when the 'Locator Count' field is set to 0. The action bits are encoded only in Map-Reply messages. The actions defined are used by an ITR or PTR when a destination EID matches a negative mapping cache entry. Unassigned values should cause a map-cache entry to be created and, when packets match this negative cache entry, they will be dropped. The current assigned values are: Farinacci, et al. Expires December 23, 2011 [Page 33] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 (0) No-Action: The map-cache is kept alive and no packet encapsulation occurs. (1) Natively-Forward: The packet is not encapsulated or dropped but natively forwarded. (2) Send-Map-Request: The packet invokes sending a Map-Request. (3) Drop: A packet that matches this map-cache entry is dropped. A: The Authoritative bit, when sent by a UDP-based message is always set to 1 by an ETR. See [CONS] for TCP-based Map-Replies. When a Map-Server is proxy Map-Replying [LISP-MS] for a LISP site, the Authoritative bit is set to 0. This indicates to requesting ITRs that the Map-Reply was not originated by a LISP node managed at the site that owns the EID-prefix. Map-Version Number: When this 12-bit value is non-zero the Map-Reply sender is informing the ITR what the version number is for the EID-record contained in the Map-Reply. The ETR can allocate this number internally but MUST coordinate this value with other ETRs for the site. When this value is 0, there is no versioning information conveyed. The Map-Version Number can be included in Map-Request and Map-Register messages. See Section 6.6.3 for more details. EID-prefix-AFI: Address family of EID-prefix according to [AFI]. EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 address-family. Priority: each RLOC is assigned a unicast priority. Lower values are more preferable. When multiple RLOCs have the same priority, they may be used in a load-split fashion. A value of 255 means the RLOC MUST NOT be used for unicast forwarding. Weight: when priorities are the same for multiple RLOCs, the weight indicates how to balance unicast traffic between them. Weight is encoded as a relative weight of total unicast packets that match the mapping entry. For example if there are 4 locators in a locator set, where the weights assigned are 30, 20, 20, and 10, the first locator will get 37.5% of the traffic, the 2nd and 3rd locators will get 25% of traffic and the 4th locator will get 12.5% of the traffic. If all weights for a locator-set are equal, receiver of the Map-Reply will decide how to load-split traffic. See Section 6.5 for a suggested hash algorithm to distribute load across locators with same priority and equal weight values. Farinacci, et al. Expires December 23, 2011 [Page 34] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 M Priority: each RLOC is assigned a multicast priority used by an ETR in a receiver multicast site to select an ITR in a source multicast site for building multicast distribution trees. A value of 255 means the RLOC MUST NOT be used for joining a multicast distribution tree. M Weight: when priorities are the same for multiple RLOCs, the weight indicates how to balance building multicast distribution trees across multiple ITRs. The weight is encoded as a relative weight (similar to the unicast Weights) of total number of trees built to the source site identified by the EID-prefix. If all weights for a locator-set are equal, the receiver of the Map-Reply will decide how to distribute multicast state across ITRs. Unused Flags: set to 0 when sending and ignored on receipt. L: when this bit is set, the locator is flagged as a local locator to the ETR that is sending the Map-Reply. When a Map-Server is doing proxy Map-Replying [LISP-MS] for a LISP site, the L bit is set to 0 for all locators in this locator-set. p: when this bit is set, an ETR informs the RLOC-probing ITR that the locator address, for which this bit is set, is the one being RLOC- probed and may be different from the source address of the Map- Reply. An ITR that RLOC-probes a particular locator, MUST use this locator for retrieving the data structure used to store the fact that the locator is reachable. The "p" bit is set for a single locator in the same locator set. If an implementation sets more than one "p" bit erroneously, the receiver of the Map-Reply MUST select the first locator. The "p" bit MUST NOT be set for locator-set records sent in Map-Request and Map-Register messages. R: set when the sender of a Map-Reply has a route to the locator in the locator data record. This receiver may find this useful to know if the locator is up but not necessarily reachable from the receiver's point of view. See also Section 6.4 for another way the R-bit may be used. Locator: an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field) assigned to an ETR. Note that the destination RLOC address MAY be an anycast address. A source RLOC can be an anycast address as well. The source or destination RLOC MUST NOT be the broadcast address (255.255.255.255 or any subnet broadcast address known to the router), and MUST NOT be a link-local multicast address. The source RLOC MUST NOT be a multicast address. The destination RLOC SHOULD be a multicast address if it is being mapped from a multicast destination EID. Farinacci, et al. Expires December 23, 2011 [Page 35] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 Mapping Protocol Data: See [CONS] for details. This field is optional and present when the UDP length indicates there is enough space in the packet to include it. The Mapping Protocol Data is used when needed by the particular mapping system. 6.1.5. EID-to-RLOC UDP Map-Reply Message A Map-Reply returns an EID-prefix with a prefix length that is less than or equal to the EID being requested. The EID being requested is either from the destination field of an IP header of a Data-Probe or the EID record of a Map-Request. The RLOCs in the Map-Reply are globally-routable IP addresses of all ETRs for the LISP site. Each RLOC conveys status reachability but does not convey path reachability from a requesters perspective. Separate testing of path reachability is required, See Section 6.3 for details. Note that a Map-Reply may contain different EID-prefix granularity (prefix + length) than the Map-Request which triggers it. This might occur if a Map-Request were for a prefix that had been returned by an earlier Map-Reply. In such a case, the requester updates its cache with the new prefix information and granularity. For example, a requester with two cached EID-prefixes that are covered by a Map- Reply containing one, less-specific prefix, replaces the entry with the less-specific EID-prefix. Note that the reverse, replacement of one less-specific prefix with multiple more-specific prefixes, can also occur but not by removing the less-specific prefix rather by adding the more-specific prefixes which during a lookup will override the less-specific prefix. When an ETR is configured with overlapping EID-prefixes, a Map- Request with an EID that longest matches any EID-prefix MUST be returned in a single Map-Reply message. For instance, if an ETR had database mapping entries for EID-prefixes: 10.0.0.0/8 10.1.0.0/16 10.1.1.0/24 10.1.2.0/24 A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record count of 1 to be returned with a mapping record EID-prefix of 10.1.1.0/24. A Map-Request for EID 10.1.5.5, would cause a Map-Reply with a record count of 3 to be returned with mapping records for EID-prefixes 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24. Note that not all overlapping EID-prefixes need to be returned, only Farinacci, et al. Expires December 23, 2011 [Page 36] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 the more specifics (note in the second example above 10.0.0.0/8 was not returned for requesting EID 10.1.5.5) entries for the matching EID-prefix of the requesting EID. When more than one EID-prefix is returned, all SHOULD use the same Time-to-Live value so they can all time out at the same time. When a more specific EID-prefix is received later, its Time-to-Live value in the Map-Reply record can be stored even when other less specifics exist. When a less specific EID-prefix is received later, its map-cache expiration time SHOULD be set to the minimum expiration time of any more specific EID-prefix in the map-cache. Map-Replies SHOULD be sent for an EID-prefix no more often than once per second to the same requesting router. For scalability, it is expected that aggregation of EID addresses into EID-prefixes will allow one Map-Reply to satisfy a mapping for the EID addresses in the prefix range thereby reducing the number of Map-Request messages. Map-Reply records can have an empty locator-set. A negative Map- Reply is a Map-Reply with an empty locator-set. Negative Map-Replies convey special actions by the sender to the ITR or PTR which have solicited the Map-Reply. There are two primary applications for Negative Map-Replies. The first is for a Map-Resolver to instruct an ITR or PTR when a destination is for a LISP site versus a non-LISP site. And the other is to source quench Map-Requests which are sent for non-allocated EIDs. For each Map-Reply record, the list of locators in a locator-set MUST appear in the same order for each ETR that originates a Map-Reply message. The locator-set MUST be sorted in order of ascending IP address where an IPv4 locator address is considered numerically 'less than' an IPv6 locator address. When sending a Map-Reply message, the destination address is copied from the one of the ITR-RLOC fields from the Map-Request. The ETR can choose a locator address from one of the address families it supports. For Data-Probes, the destination address of the Map-Reply is copied from the source address of the Data-Probe message which is invoking the reply. The source address of the Map-Reply is one of the local IP addresses chosen to allow uRPF checks to succeed in the upstream service provider. The destination port of a Map-Reply message is copied from the source port of the Map-Request or Data- Probe and the source port of the Map-Reply message is set to the well-known UDP port 4342. 6.1.5.1. Traffic Redirection with Coarse EID-Prefixes When an ETR is misconfigured or compromised, it could return coarse EID-prefixes in Map-Reply messages it sends. The EID-prefix could Farinacci, et al. Expires December 23, 2011 [Page 37] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 cover EID-prefixes which are allocated to other sites redirecting their traffic to the locators of the compromised site. To solve this problem, there are two basic solutions that could be used. The first is to have Map-Servers proxy-map-reply on behalf of ETRs so their registered EID-prefixes are the ones returned in Map- Replies. Since the interaction between an ETR and Map-Server is secured with shared-keys, it is more difficult for an ETR to misbehave. The second solution is to have ITRs and PTRs cache EID- prefixes with mask-lengths that are greater than or equal to a configured prefix length. This limits the damage to a specific width of any EID-prefix advertised, but needs to be coordinated with the allocation of site prefixes. These solutions can be used independently or at the same time. At the time of this writing, other approaches are being considered and researched. 6.1.6. Map-Register Message Format The usage details of the Map-Register message can be found in specification [LISP-MS]. This section solely defines the message format. The message is sent in UDP with a destination UDP port of 4342 and a randomly selected UDP source port number. The Map-Register message format is: Farinacci, et al. Expires December 23, 2011 [Page 38] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=3D3 |P| Reserved |M| Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key ID | Authentication Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Authentication Data ~ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | ACT |A| Reserved | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c | Rsvd | Map-Version Number | EID-prefix-AFI | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | EID-prefix | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| Priority | Weight | M Priority | M Weight | | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o | Unused Flags |L|p|R| Loc-AFI | | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| Locator | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet field descriptions: Type: 3 (Map-Register) P: This is the proxy-map-reply bit, when set to 1 an ETR sends a Map- Register message requesting for the Map-Server to proxy Map-Reply. The Map-Server will send non-authoritative Map-Replies on behalf of the ETR. Details on this usage will be provided in a future version of this draft. Reserved: It MUST be set to 0 on transmit and MUST be ignored on receipt. M: This is the want-map-notify bit, when set to 1 an ETR is requesting for a Map-Notify message to be returned in response to sending a Map-Register message. The Map-Notify message sent by a Map-Server is used to an acknowledge receipt of a Map-Register message. Farinacci, et al. Expires December 23, 2011 [Page 39] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 Record Count: The number of records in this Map-Register message. A record is comprised of that portion of the packet labeled 'Record' above and occurs the number of times equal to Record count. Nonce: This 8-byte Nonce field is set to 0 in Map-Register messages. Key ID: A configured ID to find the configured Message Authentication Code (MAC) algorithm and key value used for the authentication function. Authentication Data Length: The length in bytes of the Authentication Data field that follows this field. The length of the Authentication Data field is dependent on the Message Authentication Code (MAC) algorithm used. The length field allows a device that doesn't know the MAC algorithm to correctly parse the packet. Authentication Data: The message digest used from the output of the Message Authentication Code (MAC) algorithm. The entire Map- Register payload is authenticated with this field preset to 0. After the MAC is computed, it is placed in this field. Implementations of this specification MUST include support for HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256 [RFC4634] is recommended. The definition of the rest of the Map-Register can be found in the Map-Reply section. 6.1.7. Map-Notify Message Format The usage details of the Map-Notify message can be found in specification [LISP-MS]. This section solely defines the message format. The message is sent inside a UDP packet with a source UDP port equal to 4342 and a destination port equal to the source port from the Map- Register message this Map-Notify message is responding to. The Map-Notify message format is: Farinacci, et al. Expires December 23, 2011 [Page 40] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=3D4 | Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key ID | Authentication Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Authentication Data ~ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | ACT |A| Reserved | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c | Rsvd | Map-Version Number | EID-prefix-AFI | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | EID-prefix | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| Priority | Weight | M Priority | M Weight | | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o | Unused Flags |L|p|R| Loc-AFI | | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| Locator | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet field descriptions: Type: 4 (Map-Notify) The Map-Notify message has the same contents as a Map-Register message. See Map-Register section for field descriptions. 6.1.8. Encapsulated Control Message Format An Encapsulated Control Message is used to encapsulate control packets sent between xTRs and the mapping database system described in [LISP-MS]. Farinacci, et al. Expires December 23, 2011 [Page 41] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | IPv4 or IPv6 Header | OH | (uses RLOC addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4342 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LH |Type=3D8 |S| Reserved = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | IPv4 or IPv6 Header | IH | (uses RLOC or EID addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D yyyy = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LCM | LISP Control Message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet header descriptions: OH: The outer IPv4 or IPv6 header which uses RLOC addresses in the source and destination header address fields. UDP: The outer UDP header with destination port 4342. The source port is randomly allocated. The checksum field MUST be non-zero. LH: Type 8 is defined to be a "LISP Encapsulated Control Message" and what follows is either an IPv4 or IPv6 header as encoded by the first 4 bits after the reserved field. S: This is the Security bit. When set to 1 the field following the Reserved field will have the following format. The detailed format of the Authentication Data Content is for further study. Farinacci, et al. Expires December 23, 2011 [Page 42] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AD Type | Authentication Data Content . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IH: The inner IPv4 or IPv6 header which can use either RLOC or EID addresses in the header address fields. When a Map-Request is encapsulated in this packet format the destination address in this header is an EID. UDP: The inner UDP header where the port assignments depends on the control packet being encapsulated. When the control packet is a Map-Request or Map-Register, the source port is ITR/PITR selected and the destination port is 4342. When the control packet is a Map-Reply, the source port is 4342 and the destination port is assigned from the source port of the invoking Map-Request. Port number 4341 MUST NOT be assigned to either port. The checksum field MUST be non-zero. LCM: The format is one of the control message formats described in this section. At this time, only Map-Request messages and PIM Join-Prune messages [MLISP] are allowed to be encapsulated. Encapsulating other types of LISP control messages are for further study. When Map-Requests are sent for RLOC-probing purposes (i.e the probe-bit is set), they MUST NOT be sent inside Encapsulated Control Messages. 6.2. Routing Locator Selection Both client-side and server-side may need control over the selection of RLOCs for conversations between them. This control is achieved by manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply messages. Alternatively, RLOC information may be gleaned from received tunneled packets or EID-to-RLOC Map-Request messages. The following enumerates different scenarios for choosing RLOCs and the controls that are available: o Server-side returns one RLOC. Client-side can only use one RLOC. Server-side has complete control of the selection. o Server-side returns a list of RLOC where a subset of the list has the same best priority. Client can only use the subset list according to the weighting assigned by the server-side. In this case, the server-side controls both the subset list and load- splitting across its members. The client-side can use RLOCs outside of the subset list if it determines that the subset list Farinacci, et al. Expires December 23, 2011 [Page 43] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 is unreachable (unless RLOCs are set to a Priority of 255). Some sharing of control exists: the server-side determines the destination RLOC list and load distribution while the client-side has the option of using alternatives to this list if RLOCs in the list are unreachable. o Server-side sets weight of 0 for the RLOC subset list. In this case, the client-side can choose how the traffic load is spread across the subset list. Control is shared by the server-side determining the list and the client determining load distribution. Again, the client can use alternative RLOCs if the server-provided list of RLOCs are unreachable. o Either side (more likely on the server-side ETR) decides not to send a Map-Request. For example, if the server-side ETR does not send Map-Requests, it gleans RLOCs from the client-side ITR, giving the client-side ITR responsibility for bidirectional RLOC reachability and preferability. Server-side ETR gleaning of the client-side ITR RLOC is done by caching the inner header source EID and the outer header source RLOC of received packets. The client-side ITR controls how traffic is returned and can alternate using an outer header source RLOC, which then can be added to the list the server-side ETR uses to return traffic. Since no Priority or Weights are provided using this method, the server- side ETR MUST assume each client-side ITR RLOC uses the same best Priority with a Weight of zero. In addition, since EID-prefix encoding cannot be conveyed in data packets, the EID-to-RLOC cache on tunnel routers can grow to be very large. o A "gleaned" map-cache entry, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner header IP source address) of the received encapsulated packet. A reply to this "verifying Map-Request" is used to fully populate the map- cache entry for the "gleaned" EID and is stored and used for the time indicated from the TTL field of a received Map-Reply. When a verified map-cache entry is stored, data gleaning no longer occurs for subsequent packets which have a source EID that matches the EID-prefix of the verified entry. RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be reachable when the R-bit for the locator record is set to 1. When the R-bit is set to 0, an ITR or PITR MUST not encapsulate to the RLOC. Neither the information contained in a Map-Reply or that stored in the mapping database system provides reachability information for RLOCs. Note that reachability is not part of the mapping system and is determined using one or more of the Routing Farinacci, et al. Expires December 23, 2011 [Page 44] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 Locator Reachability Algorithms described in the next section. 6.3. Routing Locator Reachability Several mechanisms for determining RLOC reachability are currently defined: 1. An ETR may examine the Loc-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC. 2. An ITR may receive an ICMP Network or ICMP Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. 3. An ITR which participates in the global routing system can determine that an RLOC is down if no BGP RIB route exists that matches the RLOC IP address. 4. An ITR may receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [INTERWORK] and LISP-encapsulated data is sent to a non-LISP-capable site. 5. An ITR may receive a Map-Reply from a ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up since the ETR was able to send the Map-Reply to the ITR. 6. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up. 7. An ITR/ETR pair can use the Locator Reachability Algorithms described in this section, namely Echo-Noncing or RLOC-Probing. When determining Locator up/down reachability by examining the Loc- Status-Bits from the LISP encapsulated data packet, an ETR will receive up to date status from an encapsulating ITR about reachability for all ETRs at the site. CE-based ITRs at the source site can determine reachability relative to each other using the site IGP as follows: o Under normal circumstances, each ITR will advertise a default route into the site IGP. Farinacci, et al. Expires December 23, 2011 [Page 45] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 o If an ITR fails or if the upstream link to its PE fails, its default route will either time-out or be withdrawn. Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator Status Bits it sets for them. RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The Loc-Status-Bits in a LISP encapsulated packet are numbered from 0 to n-1 starting with the least significant bit. For example, if an RLOC listed in the 3rd position of the Map-Reply goes down (ordinal value 2), then all ITRs at the site will clear the 3rd least significant bit (xxxx x0xx) of the Loc-Status-Bits field for the packets they encapsulate. When an ETR decapsulates a packet, it will check for any change in the Loc-Status-Bits field. When a bit goes from 1 to 0, the ETR will refrain from encapsulating packets to an RLOC that is indicated as down. It will only resume using that RLOC if the corresponding Loc- Status-Bit returns to a value of 1. Loc-Status-Bits are associated with a locator-set per EID-prefix. Therefore, when a locator becomes unreachable, the Loc-Status-Bit that corresponds to that locator's position in the list returned by the last Map-Reply will be set to zero for that particular EID-prefix. When ITRs at the site are not deployed in CE routers, the IGP can still be used to determine the reachability of Locators provided they are injected into the IGP. This is typically done when a /32 address is configured on a loopback interface. When ITRs receive ICMP Network or Host Unreachable messages as a method to determine unreachability, they will refrain from using Locators which are described in Locator lists of Map-Replies. However, using this approach is unreliable because many network operators turn off generation of ICMP Unreachable messages. If an ITR does receive an ICMP Network or Host Unreachable message, it MAY originate its own ICMP Unreachable message destined for the host that originated the data packet the ITR encapsulated. Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a locator address from a locator-set in a mapping entry matches a prefix. If it does not find one and BGP is running in the Default Free Zone (DFZ), it can decide to not use the locator even though the Loc-Status-Bits indicate the locator is up. In this case, the path from the ITR to the ETR that is assigned the locator is not available. More details are in [LOC-ID-ARCH]. Farinacci, et al. Expires December 23, 2011 [Page 46] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 Optionally, an ITR can send a Map-Request to a Locator and if a Map- Reply is returned, reachability of the Locator has been determined. Obviously, sending such probes increases the number of control messages originated by tunnel routers for active flows, so Locators are assumed to be reachable when they are advertised. This assumption does create a dependency: Locator unreachability is detected by the receipt of ICMP Host Unreachable messages. When an Locator has been determined to be unreachable, it is not used for active traffic; this is the same as if it were listed in a Map-Reply with priority 255. The ITR can test the reachability of the unreachable Locator by sending periodic Requests. Both Requests and Replies MUST be rate- limited. Locator reachability testing is never done with data packets since that increases the risk of packet loss for end-to-end sessions. When an ETR decapsulates a packet, it knows that it is reachable from the encapsulating ITR because that is how the packet arrived. In most cases, the ETR can also reach the ITR but cannot assume this to be true due to the possibility of path asymmetry. In the presence of unidirectional traffic flow from an ITR to an ETR, the ITR SHOULD NOT use the lack of return traffic as an indication that the ETR is unreachable. Instead, it MUST use an alternate mechanisms to determine reachability. 6.3.1. Echo Nonce Algorithm When data flows bidirectionally between locators from different sites, a data-plane mechanism called "nonce echoing" can be used to determine reachability between an ITR and ETR. When an ITR wants to solicit a nonce echo, it sets the N and E bits and places a 24-bit nonce in the LISP header of the next encapsulated data packet. When this packet is received by the ETR, the encapsulated packet is forwarded as normal. When the ETR next sends a data packet to the ITR, it includes the nonce received earlier with the N bit set and E bit cleared. The ITR sees this "echoed nonce" and knows the path to and from the ETR is up. The ITR will set the E-bit and N-bit for every packet it sends while in echo-nonce-request state. The time the ITR waits to process the echoed nonce before it determines the path is unreachable is variable and a choice left for the implementation. If the ITR is receiving packets from the ETR but does not see the nonce echoed while being in echo-nonce-request state, then the path Farinacci, et al. Expires December 23, 2011 [Page 47] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 to the ETR is unreachable. This decision may be overridden by other locator reachability algorithms. Once the ITR determines the path to the ETR is down it can switch to another locator for that EID-prefix. Note that "ITR" and "ETR" are relative terms here. Both devices MUST be implementing both ITR and ETR functionality for the echo nonce mechanism to operate. The ITR and ETR may both go into echo-nonce-request state at the same time. The number of packets sent or the time during which echo nonce requests are sent is an implementation specific setting. However, when an ITR is in echo-nonce-request state, it can echo the ETR's nonce in the next set of packets that it encapsulates and then subsequently, continue sending echo-nonce-request packets. This mechanism does not completely solve the forward path reachability problem as traffic may be unidirectional. That is, the ETR receiving traffic at a site may not be the same device as an ITR which transmits traffic from that site or the site to site traffic is unidirectional so there is no ITR returning traffic. The echo-nonce algorithm is bilateral. That is, if one side sets the E-bit and the other side is not enabled for echo-noncing, then the echoing of the nonce does not occur and the requesting side may regard the locator unreachable erroneously. An ITR SHOULD only set the E-bit in a encapsulated data packet when it knows the ETR is enabled for echo-noncing. This is conveyed by the E-bit in the Map- Reply message. Note that other locator reachability mechanisms are being researched and can be used to compliment or even override the Echo Nonce Algorithm. See next section for an example of control-plane probing. 6.3.2. RLOC Probing Algorithm RLOC Probing is a method that an ITR or PTR can use to determine the reachability status of one or more locators that it has cached in a map-cache entry. The probe-bit of the Map-Request and Map-Reply messages are used for RLOC Probing. RLOC probing is done in the control-plane on a timer basis where an ITR or PTR will originate a Map-Request destined to a locator address from one of its own locator addresses. A Map-Request used as an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or on the ALT like one would when soliciting mapping data. The EID record encoded in the Map-Request is the EID-prefix of the map-cache entry cached by the ITR or PTR. The ITR may include a mapping data record for its own database mapping information which contains the local Farinacci, et al. Expires December 23, 2011 [Page 48] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 EID-prefixes and RLOCs for its site. When an ETR receives a Map-Request message with the probe-bit set, it returns a Map-Reply with the probe-bit set. The source address of the Map-Reply is set from the destination address of the Map-Request and the destination address of the Map-Reply is set from the source address of the Map-Request. The Map-Reply SHOULD contain mapping data for the EID-prefix contained in the Map-Request. This provides the opportunity for the ITR or PTR, which sent the RLOC-probe to get mapping updates if there were changes to the ETR's database mapping entries. There are advantages and disadvantages of RLOC Probing. The greatest benefit of RLOC Probing is that it can handle many failure scenarios allowing the ITR to determine when the path to a specific locator is reachable or has become unreachable, thus providing a robust mechanism for switching to using another locator from the cached locator. RLOC Probing can also provide rough RTT estimates between a pair of locators which can be useful for network management purposes as well as for selecting low delay paths. The major disadvantage of RLOC Probing is in the number of control messages required and the amount of bandwidth used to obtain those benefits, especially if the requirement for failure detection times are very small. Continued research and testing will attempt to characterize the tradeoffs of failure detection times versus message overhead. 6.4. EID Reachability within a LISP Site A site may be multihomed using two or more ETRs. The hosts and infrastructure within a site will be addressed using one or more EID prefixes that are mapped to the RLOCs of the relevant ETRs in the mapping system. One possible failure mode is for an ETR to lose reachability to one or more of the EID prefixes within its own site. When this occurs when the ETR sends Map-Replies, it can clear the R-bit associated with its own locator. And when the ETR is also an ITR, it can clear its locator-status-bit in the encapsulation data header. It is recognized there are no simple solutions to the site partitioning problem because it is hard to know which part of the EID-prefix range is partitioned. And which locators can reach any sub-ranges of the EID-prefixes. This problem is under investigation with the expectation that experiments will tell us more. Note, this is not a new problem introduced by the LISP architecture. The problem exists today when a multi-homed site uses BGP to advertise its reachability upstream. Farinacci, et al. Expires December 23, 2011 [Page 49] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 6.5. Routing Locator Hashing When an ETR provides an EID-to-RLOC mapping in a Map-Reply message to a requesting ITR, the locator-set for the EID-prefix may contain different priority values for each locator address. When more than one best priority locator exists, the ITR can decide how to load share traffic against the corresponding locators. The following hash algorithm may be used by an ITR to select a locator for a packet destined to an EID for the EID-to-RLOC mapping: 1. Either a source and destination address hash can be used or the traditional 5-tuple hash which includes the source and destination addresses, source and destination TCP, UDP, or SCTP port numbers and the IP protocol number field or IPv6 next- protocol fields of a packet a host originates from within a LISP site. When a packet is not a TCP, UDP, or SCTP packet, the source and destination addresses only from the header are used to compute the hash. 2. Take the hash value and divide it by the number of locators stored in the locator-set for the EID-to-RLOC mapping. 3. The remainder will be yield a value of 0 to "number of locators minus 1". Use the remainder to select the locator in the locator-set. Note that when a packet is LISP encapsulated, the source port number in the outer UDP header needs to be set. Selecting a hashed value allows core routers which are attached to Link Aggregation Groups (LAGs) to load-split the encapsulated packets across member links of such LAGs. Otherwise, core routers would see a single flow, since packets have a source address of the ITR, for packets which are originated by different EIDs at the source site. A suggested setting for the source port number computed by an ITR is a 5-tuple hash function on the inner header, as described above. Many core router implementations use a 5-tuple hash to decide how to balance packet load across members of a LAG. The 5-tuple hash includes the source and destination addresses of the packet and the source and destination ports when the protocol number in the packet is TCP or UDP. For this reason, UDP encoding is used for LISP encapsulation. 6.6. Changing the Contents of EID-to-RLOC Mappings Since the LISP architecture uses a caching scheme to retrieve and store EID-to-RLOC mappings, the only way an ITR can get a more up-to- Farinacci, et al. Expires December 23, 2011 [Page 50] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 date mapping is to re-request the mapping. However, the ITRs do not know when the mappings change and the ETRs do not keep track of which ITRs requested its mappings. For scalability reasons, we want to maintain this approach but need to provide a way for ETRs change their mappings and inform the sites that are currently communicating with the ETR site using such mappings. When adding a new locator record in lexicographic order to the end of a locator-set, it is easy to update mappings. We assume new mappings will maintain the same locator ordering as the old mapping but just have new locators appended to the end of the list. So some ITRs can have a new mapping while other ITRs have only an old mapping that is used until they time out. When an ITR has only an old mapping but detects bits set in the loc-status-bits that correspond to locators beyond the list it has cached, it simply ignores them. However, this can only happen for locator addresses that are lexicographically greater than the locator addresses in the existing locator-set. When a locator record is inserted in the middle of a locator-set, to maintain lexicographic order, the SMR procedure in Section 6.6.2 is used to inform ITRs and PTRs of the new locator-status-bit mappings. When a locator record is removed from a locator-set, ITRs that have the mapping cached will not use the removed locator because the xTRs will set the loc-status-bit to 0. So even if the locator is in the list, it will not be used. For new mapping requests, the xTRs can set the locator AFI to 0 (indicating an unspecified address), as well as setting the corresponding loc-status-bit to 0. This forces ITRs with old or new mappings to avoid using the removed locator. If many changes occur to a mapping over a long period of time, one will find empty record slots in the middle of the locator-set and new records appended to the locator-set. At some point, it would be useful to compact the locator-set so the loc-status-bit settings can be efficiently packed. We propose here three approaches for locator-set compaction, one operational and two protocol mechanisms. The operational approach uses a clock sweep method. The protocol approaches use the concept of Solicit-Map-Requests and Map-Versioning. 6.6.1. Clock Sweep The clock sweep approach uses planning in advance and the use of count-down TTLs to time out mappings that have already been cached. The default setting for an EID-to-RLOC mapping TTL is 24 hours. So there is a 24 hour window to time out old mappings. The following clock sweep procedure is used: Farinacci, et al. Expires December 23, 2011 [Page 51] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 1. 24 hours before a mapping change is to take effect, a network administrator configures the ETRs at a site to start the clock sweep window. 2. During the clock sweep window, ETRs continue to send Map-Reply messages with the current (unchanged) mapping records. The TTL for these mappings is set to 1 hour. 3. 24 hours later, all previous cache entries will have timed out, and any active cache entries will time out within 1 hour. During this 1 hour window the ETRs continue to send Map-Reply messages with the current (unchanged) mapping records with the TTL set to 1 minute. 4. At the end of the 1 hour window, the ETRs will send Map-Reply messages with the new (changed) mapping records. So any active caches can get the new mapping contents right away if not cached, or in 1 minute if they had the mapping cached. The new mappings are cached with a time to live equal to the TTL in the Map-Reply. 6.6.2. Solicit-Map-Request (SMR) Soliciting a Map-Request is a selective way for ETRs, at the site where mappings change, to control the rate they receive requests for Map-Reply messages. SMRs are also used to tell remote ITRs to update the mappings they have cached. Since the ETRs don't keep track of remote ITRs that have cached their mappings, they do not know which ITRs need to have their mappings updated. As a result, an ETR will solicit Map-Requests (called an SMR message) from those sites to which it has been sending encapsulated data to for the last minute. In particular, an ETR will send an SMR an ITR to which it has recently sent encapsulated data. An SMR message is simply a bit set in a Map-Request message. An ITR or PTR will send a Map-Request when they receive an SMR message. Both the SMR sender and the Map-Request responder MUST rate-limited these messages. Rate-limiting can be implemented as a global rate- limiter or one rate-limiter per SMR destination. The following procedure shows how a SMR exchange occurs when a site is doing locator-set compaction for an EID-to-RLOC mapping: 1. When the database mappings in an ETR change, the ETRs at the site begin to send Map-Requests with the SMR bit set for each locator in each map-cache entry the ETR caches. Farinacci, et al. Expires December 23, 2011 [Page 52] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 2. A remote ITR which receives the SMR message will schedule sending a Map-Request message to the source locator address of the SMR message or to the mapping database system. A newly allocated random nonce is selected and the EID-prefix used is the one copied from the SMR message. If the source locator is the only locator in the cached locator-set, the remote ITR SHOULD send a Map-Request to the database mapping system just in case the single locator has changed and may no longer be reachable to accept the Map-Request. 3. The remote ITR MUST rate-limit the Map-Request until it gets a Map-Reply while continuing to use the cached mapping. When Map Versioning is used, described in Section 6.6.3, an SMR sender can detect if an ITR is using the most up to date database mapping. 4. The ETRs at the site with the changed mapping will reply to the Map-Request with a Map-Reply message that has a nonce from the SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate limited. This is important to avoid Map-Reply implosion. 5. The ETRs, at the site with the changed mapping, record the fact that the site that sent the Map-Request has received the new mapping data in the mapping cache entry for the remote site so the loc-status-bits are reflective of the new mapping for packets going to the remote site. The ETR then stops sending SMR messages. For security reasons an ITR MUST NOT process unsolicited Map-Replies. To avoid map-cache entry corruption by a third-party, a sender of an SMR-based Map-Request MUST be verified. If an ITR receives an SMR- based Map-Request and the source is not in the locator-set for the stored map-cache entry, then the responding Map-Request MUST be sent with an EID destination to the mapping database system. Since the mapping database system is more secure to reach an authoritative ETR, it will deliver the Map-Request to the authoritative source of the mapping data. When an ITR receives an SMR-based Map-Request for which it does not have a cached mapping for the EID in the SMR message, it MAY not send a SMR-invoked Map-Request. This scenario can occur when an ETR sends SMR messages to all locators in the locator-set it has stored in its map-cache but the remote ITRs that receive the SMR may not be sending packets to the site. There is no point in updating the ITRs until they need to send, in which case, they will send Map-Requests to obtain a map-cache entry. Farinacci, et al. Expires December 23, 2011 [Page 53] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 6.6.3. Database Map Versioning When there is unidirectional packet flow between an ITR and ETR, and the EID-to-RLOC mappings change on the ETR, it needs to inform the ITR so encapsulation can stop to a removed locator and start to a new locator in the locator-set. An ETR, when it sends Map-Reply messages, conveys its own Map-Version number. This is known as the Destination Map-Version Number. ITRs include the Destination Map-Version Number in packets they encapsulate to the site. When an ETR decapsulates a packet and detects the Destination Map-Version Number is less than the current version for its mapping, the SMR procedure described in Section 6.6.2 occurs. An ITR, when it encapsulates packets to ETRs, can convey its own Map- Version number. This is known as the Source Map-Version Number. When an ETR decapsulates a packet and detects the Source Map-Version Number is greater than the last Map-Version Number sent in a Map- Reply from the ITR's site, the ETR will send a Map-Request to one of the ETRs for the source site. A Map-Version Number is used as a sequence number per EID-prefix. So values that are greater, are considered to be more recent. A value of 0 for the Source Map-Version Number or the Destination Map-Version Number conveys no versioning information and an ITR does no comparison with previously received Map-Version Numbers. A Map-Version Number can be included in Map-Register messages as well. This is a good way for the Map-Server can assure that all ETRs for a site registering to it will be Map-Version number synchronized. See [VERSIONING] for a more detailed analysis and description of Database Map Versioning. Farinacci, et al. Expires December 23, 2011 [Page 54] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 7. Router Performance Considerations LISP is designed to be very hardware-based forwarding friendly. A few implementation techniques can be used to incrementally implement LISP: o When a tunnel encapsulated packet is received by an ETR, the outer destination address may not be the address of the router. This makes it challenging for the control plane to get packets from the hardware. This may be mitigated by creating special FIB entries for the EID-prefixes of EIDs served by the ETR (those for which the router provides an RLOC translation). These FIB entries are marked with a flag indicating that control plane processing should be performed. The forwarding logic of testing for particular IP protocol number value is not necessary. There are a few proven cases where no changes to existing deployed hardware were needed to support the LISP data-plane. o On an ITR, prepending a new IP header consists of adding more bytes to a MAC rewrite string and prepending the string as part of the outgoing encapsulation procedure. Routers that support GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already support this action. o A packet's source address or interface the packet was received on can be used to select a VRF (Virtual Routing/Forwarding). The VRF's routing table can be used to find EID-to-RLOC mappings. Farinacci, et al. Expires December 23, 2011 [Page 55] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 8. Deployment Scenarios This section will explore how and where ITRs and ETRs can be deployed and will discuss the pros and cons of each deployment scenario. For a more detailed deployment recommendation, refer to [LISP-DEPLOY]. There are two basic deployment trade-offs to consider: centralized versus distributed caches and flat, recursive, or re-encapsulating tunneling. When deciding on centralized versus distributed caching, the following issues should be considered: o Are the tunnel routers spread out so that the caches are spread across all the memories of each router? o Should management "touch points" be minimized by choosing few tunnel routers, just enough for redundancy? o In general, using more ITRs doesn't increase management load, since caches are built and stored dynamically. On the other hand, more ETRs does require more management since EID-prefix-to-RLOC mappings need to be explicitly configured. When deciding on flat, recursive, or re-encapsulation tunneling, the following issues should be considered: o Flat tunneling implements a single tunnel between source site and destination site. This generally offers better paths between sources and destinations with a single tunnel path. o Recursive tunneling is when tunneled traffic is again further encapsulated in another tunnel, either to implement VPNs or to perform Traffic Engineering. When doing VPN-based tunneling, the site has some control since the site is prepending a new tunnel header. In the case of TE-based tunneling, the site may have control if it is prepending a new tunnel header, but if the site's ISP is doing the TE, then the site has no control. Recursive tunneling generally will result in suboptimal paths but at the benefit of steering traffic to resource available parts of the network. o The technique of re-encapsulation ensures that packets only require one tunnel header. So if a packet needs to be rerouted, it is first decapsulated by the ETR and then re-encapsulated with a new tunnel header using a new RLOC. The next sub-sections will survey where tunnel routers can reside in the network. Farinacci, et al. Expires December 23, 2011 [Page 56] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 8.1. First-hop/Last-hop Tunnel Routers By locating tunnel routers close to hosts, the EID-prefix set is at the granularity of an IP subnet. So at the expense of more EID- prefix-to-RLOC sets for the site, the caches in each tunnel router can remain relatively small. But caches always depend on the number of non-aggregated EID destination flows active through these tunnel routers. With more tunnel routers doing encapsulation, the increase in control traffic grows as well: since the EID-granularity is greater, more Map-Requests and Map-Replies are traveling between more routers. The advantage of placing the caches and databases at these stub routers is that the products deployed in this part of the network have better price-memory ratios then their core router counterparts. Memory is typically less expensive in these devices and fewer routes are stored (only IGP routes). These devices tend to have excess capacity, both for forwarding and routing state. LISP functionality can also be deployed in edge switches. These devices generally have layer-2 ports facing hosts and layer-3 ports facing the Internet. Spare capacity is also often available in these devices as well. 8.2. Border/Edge Tunnel Routers Using customer-edge (CE) routers for tunnel endpoints allows the EID space associated with a site to be reachable via a small set of RLOCs assigned to the CE routers for that site. This is the default behavior envisioned in the rest of this specification. This offers the opposite benefit of the first-hop/last-hop tunnel router scenario: the number of mapping entries and network management touch points are reduced, allowing better scaling. One disadvantage is that less of the network's resources are used to reach host endpoints thereby centralizing the point-of-failure domain and creating network choke points at the CE router. Note that more than one CE router at a site can be configured with the same IP address. In this case an RLOC is an anycast address. This allows resilience between the CE routers. That is, if a CE router fails, traffic is automatically routed to the other routers using the same anycast address. However, this comes with the disadvantage where the site cannot control the entrance point when the anycast route is advertised out from all border routers. Another disadvantage of using anycast locators is the limited advertisement Farinacci, et al. Expires December 23, 2011 [Page 57] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 scope of /32 (or /128 for IPv6) routes. 8.3. ISP Provider-Edge (PE) Tunnel Routers Use of ISP PE routers as tunnel endpoint routers is not the typical deployment scenario envisioned in the specification. This section attempts to capture some of reasoning behind this preference of implementing LISP on CE routers. Use of ISP PE routers as tunnel endpoint routers gives an ISP, rather than a site, control over the location of the egress tunnel endpoints. That is, the ISP can decide if the tunnel endpoints are in the destination site (in either CE routers or last-hop routers within a site) or at other PE edges. The advantage of this case is that two tunnel headers can be avoided. By having the PE be the first router on the path to encapsulate, it can choose a TE path first, and the ETR can decapsulate and re-encapsulate for a tunnel to the destination end site. An obvious disadvantage is that the end site has no control over where its packets flow or the RLOCs used. Other disadvantages include the difficulty in synchronizing path liveness updates between CE and PE routers. As mentioned in earlier sections a combination of these scenarios is possible at the expense of extra packet header overhead, if both site and provider want control, then recursive or re-encapsulating tunnels are used. 8.4. LISP Functionality with Conventional NATs LISP routers can be deployed behind Network Address Translator (NAT) devices to provide the same set of packet services hosts have today when they are addressed out of private address space. It is important to note that a locator address in any LISP control message MUST be a globally routable address and therefore SHOULD NOT contain [RFC1918] addresses. If a LISP router is configured with private addresses, they MUST be used only in the outer IP header so the NAT device can translate properly. Otherwise, EID addresses MUST be translated before encapsulation is performed. Both NAT translation and LISP encapsulation functions could be co-located in the same device. More details on LISP address translation can be found in [INTERWORK]. Farinacci, et al. Expires December 23, 2011 [Page 58] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 8.5. Packets Egressing a LISP Site When a LISP site is using two ITRs for redundancy, the failure of one ITR will likely shift outbound traffic to the second. This second ITR's cache may not not be populated with the same EID-to-RLOC mapping entries as the first. If this second ITR does not have these mappings, traffic will be dropped while the mappings are retrieved from the mapping system. The retrieval of these messages may increase the load of requests being sent into the mapping system. Deployment and experimentation will determine whether this issue requires more attention. Farinacci, et al. Expires December 23, 2011 [Page 59] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 9. Traceroute Considerations When a source host in a LISP site initiates a traceroute to a destination host in another LISP site, it is highly desirable for it to see the entire path. Since packets are encapsulated from ITR to ETR, the hop across the tunnel could be viewed as a single hop. However, LISP traceroute will provide the entire path so the user can see 3 distinct segments of the path from a source LISP host to a destination LISP host: Segment 1 (in source LISP site based on EIDs): source-host ---> first-hop ... next-hop ---> ITR Segment 2 (in the core network based on RLOCs): ITR ---> next-hop ... next-hop ---> ETR Segment 3 (in the destination LISP site based on EIDs): ETR ---> next-hop ... last-hop ---> destination-host For segment 1 of the path, ICMP Time Exceeded messages are returned in the normal matter as they are today. The ITR performs a TTL decrement and test for 0 before encapsulating. So the ITR hop is seen by the traceroute source has an EID address (the address of site-facing interface). For segment 2 of the path, ICMP Time Exceeded messages are returned to the ITR because the TTL decrement to 0 is done on the outer header, so the destination of the ICMP messages are to the ITR RLOC address, the source RLOC address of the encapsulated traceroute packet. The ITR looks inside of the ICMP payload to inspect the traceroute source so it can return the ICMP message to the address of the traceroute client as well as retaining the core router IP address in the ICMP message. This is so the traceroute client can display the core router address (the RLOC address) in the traceroute output. The ETR returns its RLOC address and responds to the TTL decrement to 0 like the previous core routers did. For segment 3, the next-hop router downstream from the ETR will be decrementing the TTL for the packet that was encapsulated, sent into the core, decapsulated by the ETR, and forwarded because it isn't the final destination. If the TTL is decremented to 0, any router on the path to the destination of the traceroute, including the next-hop router or destination, will send an ICMP Time Exceeded message to the source EID of the traceroute client. The ICMP message will be Farinacci, et al. Expires December 23, 2011 [Page 60] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 encapsulated by the local ITR and sent back to the ETR in the originated traceroute source site, where the packet will be delivered to the host. 9.1. IPv6 Traceroute IPv6 traceroute follows the procedure described above since the entire traceroute data packet is included in ICMP Time Exceeded message payload. Therefore, only the ITR needs to pay special attention for forwarding ICMP messages back to the traceroute source. 9.2. IPv4 Traceroute For IPv4 traceroute, we cannot follow the above procedure since IPv4 ICMP Time Exceeded messages only include the invoking IP header and 8 bytes that follow the IP header. Therefore, when a core router sends an IPv4 Time Exceeded message to an ITR, all the ITR has in the ICMP payload is the encapsulated header it prepended followed by a UDP header. The original invoking IP header, and therefore the identity of the traceroute source is lost. The solution we propose to solve this problem is to cache traceroute IPv4 headers in the ITR and to match them up with corresponding IPv4 Time Exceeded messages received from core routers and the ETR. The ITR will use a circular buffer for caching the IPv4 and UDP headers of traceroute packets. It will select a 16-bit number as a key to find them later when the IPv4 Time Exceeded messages are received. When an ITR encapsulates an IPv4 traceroute packet, it will use the 16-bit number as the UDP source port in the encapsulating header. When the ICMP Time Exceeded message is returned to the ITR, the UDP header of the encapsulating header is present in the ICMP payload thereby allowing the ITR to find the cached headers for the traceroute source. The ITR puts the cached headers in the payload and sends the ICMP Time Exceeded message to the traceroute source retaining the source address of the original ICMP Time Exceeded message (a core router or the ETR of the site of the traceroute destination). The signature of a traceroute packet comes in two forms. The first form is encoded as a UDP message where the destination port is inspected for a range of values. The second form is encoded as an ICMP message where the IP identification field is inspected for a well-known value. 9.3. Traceroute using Mixed Locators When either an IPv4 traceroute or IPv6 traceroute is originated and the ITR encapsulates it in the other address family header, you Farinacci, et al. Expires December 23, 2011 [Page 61] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 cannot get all 3 segments of the traceroute. Segment 2 of the traceroute can not be conveyed to the traceroute source since it is expecting addresses from intermediate hops in the same address format for the type of traceroute it originated. Therefore, in this case, segment 2 will make the tunnel look like one hop. All the ITR has to do to make this work is to not copy the inner TTL to the outer, encapsulating header's TTL when a traceroute packet is encapsulated using an RLOC from a different address family. This will cause no TTL decrement to 0 to occur in core routers between the ITR and ETR. Farinacci, et al. Expires December 23, 2011 [Page 62] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 10. Mobility Considerations There are several kinds of mobility of which only some might be of concern to LISP. Essentially they are as follows. 10.1. Site Mobility A site wishes to change its attachment points to the Internet, and its LISP Tunnel Routers will have new RLOCs when it changes upstream providers. Changes in EID-RLOC mappings for sites are expected to be handled by configuration, outside of the LISP protocol. 10.2. Slow Endpoint Mobility An individual endpoint wishes to move, but is not concerned about maintaining session continuity. Renumbering is involved. LISP can help with the issues surrounding renumbering [RFC4192] [LISA96] by decoupling the address space used by a site from the address spaces used by its ISPs. [RFC4984] 10.3. Fast Endpoint Mobility Fast endpoint mobility occurs when an endpoint moves relatively rapidly, changing its IP layer network attachment point. Maintenance of session continuity is a goal. This is where the Mobile IPv4 [RFC3344bis] and Mobile IPv6 [RFC3775] [RFC4866] mechanisms are used, and primarily where interactions with LISP need to be explored. The problem is that as an endpoint moves, it may require changes to the mapping between its EID and a set of RLOCs for its new network location. When this is added to the overhead of mobile IP binding updates, some packets might be delayed or dropped. In IPv4 mobility, when an endpoint is away from home, packets to it are encapsulated and forwarded via a home agent which resides in the home area the endpoint's address belongs to. The home agent will encapsulate and forward packets either directly to the endpoint or to a foreign agent which resides where the endpoint has moved to. Packets from the endpoint may be sent directly to the correspondent node, may be sent via the foreign agent, or may be reverse-tunneled back to the home agent for delivery to the mobile node. As the mobile node's EID or available RLOC changes, LISP EID-to-RLOC mappings are required for communication between the mobile node and the home agent, whether via foreign agent or not. As a mobile endpoint changes networks, up to three LISP mapping changes may be required: Farinacci, et al. Expires December 23, 2011 [Page 63] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 o The mobile node moves from an old location to a new visited network location and notifies its home agent that it has done so. The Mobile IPv4 control packets the mobile node sends pass through one of the new visited network's ITRs, which needs a EID-RLOC mapping for the home agent. o The home agent might not have the EID-RLOC mappings for the mobile node's "care-of" address or its foreign agent in the new visited network, in which case it will need to acquire them. o When packets are sent directly to the correspondent node, it may be that no traffic has been sent from the new visited network to the correspondent node's network, and the new visited network's ITR will need to obtain an EID-RLOC mapping for the correspondent node's site. In addition, if the IPv4 endpoint is sending packets from the new visited network using its original EID, then LISP will need to perform a route-returnability check on the new EID-RLOC mapping for that EID. In IPv6 mobility, packets can flow directly between the mobile node and the correspondent node in either direction. The mobile node uses its "care-of" address (EID). In this case, the route-returnability check would not be needed but one more LISP mapping lookup may be required instead: o As above, three mapping changes may be needed for the mobile node to communicate with its home agent and to send packets to the correspondent node. o In addition, another mapping will be needed in the correspondent node's ITR, in order for the correspondent node to send packets to the mobile node's "care-of" address (EID) at the new network location. When both endpoints are mobile the number of potential mapping lookups increases accordingly. As a mobile node moves there are not only mobility state changes in the mobile node, correspondent node, and home agent, but also state changes in the ITRs and ETRs for at least some EID-prefixes. The goal is to support rapid adaptation, with little delay or packet loss for the entire system. Also IP mobility can be modified to require fewer mapping changes. In order to increase overall system performance, there may be a need to reduce the optimization of one area in order to place fewer demands on another. Farinacci, et al. Expires December 23, 2011 [Page 64] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 In LISP, one possibility is to "glean" information. When a packet arrives, the ETR could examine the EID-RLOC mapping and use that mapping for all outgoing traffic to that EID. It can do this after performing a route-returnability check, to ensure that the new network location does have a internal route to that endpoint. However, this does not cover the case where an ITR (the node assigned the RLOC) at the mobile-node location has been compromised. Mobile IP packet exchange is designed for an environment in which all routing information is disseminated before packets can be forwarded. In order to allow the Internet to grow to support expected future use, we are moving to an environment where some information may have to be obtained after packets are in flight. Modifications to IP mobility should be considered in order to optimize the behavior of the overall system. Anything which decreases the number of new EID- RLOC mappings needed when a node moves, or maintains the validity of an EID-RLOC mapping for a longer time, is useful. 10.4. Fast Network Mobility In addition to endpoints, a network can be mobile, possibly changing xTRs. A "network" can be as small as a single router and as large as a whole site. This is different from site mobility in that it is fast and possibly short-lived, but different from endpoint mobility in that a whole prefix is changing RLOCs. However, the mechanisms are the same and there is no new overhead in LISP. A map request for any endpoint will return a binding for the entire mobile prefix. If mobile networks become a more common occurrence, it may be useful to revisit the design of the mapping service and allow for dynamic updates of the database. The issue of interactions between mobility and LISP needs to be explored further. Specific improvements to the entire system will depend on the details of mapping mechanisms. Mapping mechanisms should be evaluated on how well they support session continuity for mobile nodes. 10.5. LISP Mobile Node Mobility A mobile device can use the LISP infrastructure to achieve mobility by implementing the LISP encapsulation and decapsulation functions and acting as a simple ITR/ETR. By doing this, such a "LISP mobile node" can use topologically-independent EID IP addresses that are not advertised into and do not impose a cost on the global routing system. These EIDs are maintained at the edges of the mapping system (in LISP Map-Servers and Map-Resolvers) and are provided on demand to only the correspondents of the LISP mobile node. Farinacci, et al. Expires December 23, 2011 [Page 65] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 Refer to the LISP Mobility Architecture specification [LISP-MN] for more details. Farinacci, et al. Expires December 23, 2011 [Page 66] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 11. Multicast Considerations A multicast group address, as defined in the original Internet architecture is an identifier of a grouping of topologically independent receiver host locations. The address encoding itself does not determine the location of the receiver(s). The multicast routing protocol, and the network-based state the protocol creates, determines where the receivers are located. In the context of LISP, a multicast group address is both an EID and a Routing Locator. Therefore, no specific semantic or action needs to be taken for a destination address, as it would appear in an IP header. Therefore, a group address that appears in an inner IP header built by a source host will be used as the destination EID. The outer IP header (the destination Routing Locator address), prepended by a LISP router, will use the same group address as the destination Routing Locator. Having said that, only the source EID and source Routing Locator needs to be dealt with. Therefore, an ITR merely needs to put its own IP address in the source Routing Locator field when prepending the outer IP header. This source Routing Locator address, like any other Routing Locator address MUST be globally routable. Therefore, an EID-to-RLOC mapping does not need to be performed by an ITR when a received data packet is a multicast data packet or when processing a source-specific Join (either by IGMPv3 or PIM). But the source Routing Locator is decided by the multicast routing protocol in a receiver site. That is, an EID to Routing Locator translation is done at control-time. Another approach is to have the ITR not encapsulate a multicast packet and allow the host built packet to flow into the core even if the source address is allocated out of the EID namespace. If the RPF-Vector TLV [RFC5496] is used by PIM in the core, then core routers can RPF to the ITR (the Locator address which is injected into core routing) rather than the host source address (the EID address which is not injected into core routing). To avoid any EID-based multicast state in the network core, the first approach is chosen for LISP-Multicast. Details for LISP-Multicast and Interworking with non-LISP sites is described in specification [MLISP]. Farinacci, et al. Expires December 23, 2011 [Page 67] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 12. Security Considerations It is believed that most of the security mechanisms will be part of the mapping database service when using control plane procedures for obtaining EID-to-RLOC mappings. For data plane triggered mappings, as described in this specification, protection is provided against ETR spoofing by using Return- Routability mechanisms evidenced by the use of a 24-bit Nonce field in the LISP encapsulation header and a 64-bit Nonce field in the LISP control message. The nonce, coupled with the ITR accepting only solicited Map-Replies goes a long way toward providing decent authentication. LISP does not rely on a PKI infrastructure or a more heavy weight authentication system. These systems challenge the scalability of LISP which was a primary design goal. DoS attack prevention will depend on implementations rate-limiting Map-Requests and Map-Replies to the control plane as well as rate- limiting the number of data-triggered Map-Replies. An incorrectly implemented or malicious ITR might choose to ignore the priority and weights provided by the ETR in its Map-Reply. This traffic steering would be limited to the traffic that is sent by this ITR's site, and no more severe than if the site initiated a bandwidth DoS attack on (one of) the ETR's ingress links. The ITR's site would typically gain no benefit from not respecting the weights, and would likely to receive better service by abiding by them. To deal with map-cache exhaustion attempts in an ITR/PTR, the implementation should consider putting a maximum cap on the number of entries stored with a reserve list for special or frequently accessed sites. This should be a configuration policy control set by the network administrator who manages ITRs and PTRs. Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings, cache sizing and maintenance is an issue to be kept in mind during implementation. It is a good idea to have instrumentation in place to detect thrashing of the cache. Implementation experimentation will be used to determine which cache management strategies work best. It should be noted that an undersized cache in an ITR/PTR not only causes adverse affect on the site or region they support, but may also cause increased Map-Request load on the mapping system. There is a security risk implicit in the fact that ETRs generate the EID prefix to which they are responding. An ETR can claim a shorter prefix than it is actually responsible for. Various mechanisms to ameliorate or resolve this issue will be examined in the future, [LISP-SEC]. Farinacci, et al. Expires December 23, 2011 [Page 68] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 Spoofing of inner header addresses of LISP encapsulated packets is possible like with any tunneling mechanism. ITRs MUST verify the source address of a packet to be an EID that belongs to the site's EID-prefix range prior to encapsulation. ETRs MUST NOT decapsulate and forward packets into their site where the inner header destination EID does not belong to the ETR's EID-prefix range for the site. If a LISP encapsulated packet arrives at an ETR, it MAY compare the inner header source EID address and the outer header source RLOC address with the mapping that exists in the mapping database. Then when spoofing attacks occur, the outer header source RLOC address can be used to trace back the attack to the source site, using existing operational tools. This experimental specification does not address automated key management (AKM). BCP 107 provides guidance in this area. In addition, at the time of this writing, substantial work is being undertaken to improve security of the routing system [KARP], [RPKI], [BGP-SEC], [LISP-SEC], Future work on LISP should address BCP-107 as well as other open security considerations, which may require changes to this specification. Farinacci, et al. Expires December 23, 2011 [Page 69] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 13. Network Management Considerations Considerations for Network Management tools exist so the LISP protocol suite can be operationally managed. The mechanisms can be found in [LISP-MIB] and [LISP-LIG]. Farinacci, et al. Expires December 23, 2011 [Page 70] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 14. IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the LISP specification, in accordance with BCP 26 and RFC 5226 [RFC5226]. There are two name spaces in LISP that require registration: o LISP IANA registry allocations should not be made for purposes unrelated to LISP routing or transport protocols. o The following policies are used here with the meanings defined in BCP 26: "Specification Required", "IETF Consensus", "Experimental Use", "First Come First Served". 14.1. LISP Address Type Codes Instance ID type codes have a range from 0 to 15, of which 0 and 1 have been allocated [LCAF]. New Type Codes MUST be allocated starting at 2. Type Codes 2 - 10 are to be assigned by IETF Review. Type Codes 11 - 15 are available on a First Come First Served policy. The following codes have been allocated: Type 0: Null Body Type Type 1: AFI List Type See [LCAF] for details for other possible unapproved address encodings. The unapproved LCAF encodings are an area for further study and experimentation. 14.2. LISP UDP Port Numbers The IANA registry has allocated UDP port numbers 4341 and 4342 for LISP data-plane and control-plane operation, respectively. Farinacci, et al. Expires December 23, 2011 [Page 71] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 15. References 15.1. Normative References [BGP-SEC] Lepinski, M., "An Overview of BGPSEC", draft-lepinski-bgpsec-overview-00.txt (work in progress), March 2011. [KARP] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP)Design Guidelines", draft-ietf-karp-design-guide-02.txt (work in progress), March 2011. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. Farinacci, et al. Expires December 23, 2011 [Page 72] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006. [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006. [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, May 2007. [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, March 2009. [RPKI] Lepinski, M., "An Infrastructure to Support Secure Internet Routing", draft-ietf-sidr-arch-12.txt (work in progress), February 2011. [UDP-TUNNELS] Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled Packets", draft-eubanks-chimento-6man-01.txt (work in progress), October 2010. 15.2. Informative References [AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY NUMBERS http://www.iana.org/assignments/address-family-numbers, January 2011. [AFI-REGISTRY] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY NUMBER registry http://www.iana.org/assignments/ address-family-numbers/ address-family-numbers.xml#address-family-numbers-1, Farinacci, et al. Expires December 23, 2011 [Page 73] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 January 2011. [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP Alternative Topology (LISP-ALT)", draft-ietf-lisp-alt-07.txt (work in progress), June 2011. [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed Enhancement to the Internet Architecture", Internet- Draft http://www.chiappa.net/~jnc/tech/endpoints.txt, 1999. [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A Content distribution Overlay Network Service for LISP", draft-meyer-lisp-cons-03.txt (work in progress), November 2007. [EMACS] Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID Mappings Multicast Across Cooperating Systems for LISP", draft-curran-lisp-emacs-00.txt (work in progress), November 2007. [INTERWORK] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking LISP with IPv4 and IPv6", draft-ietf-lisp-interworking-02.txt (work in progress), June 2011. [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format", draft-farinacci-lisp-lcaf-04.txt (work in progress), October 2010. [LISA96] Lear, E., Katinsky, J., Coffin, J., and D. Tharp, "Renumbering: Threat or Menace?", Usenix , September 1996. [LISP-DEPLOY] Jakab, L., Coras, F., Domingo-Pascual, J., and D. Lewis, "LISP Network Element Deployment Considerations", draft-jakab-lisp-deployment-02.txt (work in progress), February 2011. [LISP-LIG] Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)", draft-ietf-lisp-lig-01.txt (work in progress), October 2010. [LISP-MAIN] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", Farinacci, et al. Expires December 23, 2011 [Page 74] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 draft-farinacci-lisp-12.txt (work in progress), March 2009. [LISP-MIB] Schudel, G., Jain, A., and V. Moreno, "LISP MIB", draft-ietf-lisp-mib-01.txt (work in progress), March 2011. [LISP-MN] Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP Mobility Architecture", draft-meyer-lisp-mn-04.txt (work in progress), October 2010. [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", draft-ietf-lisp-ms-09.txt (work in progress), June 2011. [LISP-SEC] Maino, F., Ermagon, V., Cabellos, A., Sausez, D., and O. Bonaventure, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-00.txt (work in progress), June 2011. [LOC-ID-ARCH] Meyer, D. and D. Lewis, "Architectural Implications of Locator/ID Separation", draft-meyer-loc-id-implications-01.txt (work in progress), Januaryr 2009. [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "LISP for Multicast Environments", draft-ietf-lisp-multicast-06.txt (work in progress), June 2011. [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", draft-lear-lisp-nerd-08.txt (work in progress), March 2010. [OPENLISP] Iannone, L. and O. Bonaventure, "OpenLISP Implementation Report", draft-iannone-openlisp-implementation-01.txt (work in progress), July 2008. [RADIR] Narten, T., "Routing and Addressing Problem Statement", draft-narten-radir-problem-statement-00.txt (work in progress), July 2007. [RFC3344bis] Perkins, C., "IP Mobility Support for IPv4, revised", draft-ietf-mip4-rfc3344bis-05 (work in progress), July 2007. Farinacci, et al. Expires December 23, 2011 [Page 75] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005. [RPMD] Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol for Routing Protocol Meta-data Dissemination", draft-handley-p2ppush-unpublished-2007726.txt (work in progress), July 2007. [VERSIONING] Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping Versioning", draft-ietf-lisp-map-versioning-01.txt (work in progress), March 2011. Farinacci, et al. Expires December 23, 2011 [Page 76] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 Appendix A. Acknowledgments An initial thank you goes to Dave Oran for planting the seeds for the initial ideas for LISP. His consultation continues to provide value to the LISP authors. A special and appreciative thank you goes to Noel Chiappa for providing architectural impetus over the past decades on separation of location and identity, as well as detailed review of the LISP architecture and documents, coupled with enthusiasm for making LISP a practical and incremental transition for the Internet. The authors would like to gratefully acknowledge many people who have contributed discussion and ideas to the making of this proposal. They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller, Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston, David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Terry Manderson, Roger Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari Arkko, Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu, Dhirendra Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina Ermagan, Albert Cabellos, Fabio Maino, Victor Moreno, Chris White, Clarence Filsfils, and Alia Atlas. This work originated in the Routing Research Group (RRG) of the IRTF. The individual submission [LISP-MAIN] was converted into this IETF LISP working group draft. Farinacci, et al. Expires December 23, 2011 [Page 77] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 Appendix B. Document Change Log B.1. Changes to draft-ietf-lisp-13.txt o Posted June 2011 to complete working group last call. o Tracker item 87. Put Yakov suggested wording in the EID-prefix definition section to reference [INTERWORK] and [LISP-DEPLOY] about discussion on transition and access mechanisms. o Change "ITRs" to "ETRs" in the Locator Status Bit definition section and data packet description section per Damien's comment. o Remove the normative reference to [LISP-SEC] when describing the S-bit in the ECM and Map-Reply headers. o Tracker item 54. Added text from John Scudder in the "Packets Egressing a LISP Site" section. o Add sentence to the "Reencapsulating Tunnel" definition about how reencapsulation loops can occur when not coordinating among multiple mapping database systems. o Remove "In theory" from a sentence in the Security Considerations section. o Remove Security Area Statement title and reword section with Eliot's provided text. The text was agreed upon by LISP-WG chairs and Security ADs. o Remove word "potential" from the over-claiming paragraph of the Security Considerations section per Stephen's request. o Wordsmithing and other editorial comments from Alia. B.2. Changes to draft-ietf-lisp-12.txt o Posted April 2011. o Tracker item 87. Provided rewording how an EID-prefix can be resued in the definition section of "EID-prefix". o Tracker item 95. Change "eliminate" to "defer" in section 4.1. o Tracker item 110. Added that the Mapping Protocol Data field in the Map-Reply message is only used when needed by the particular Mapping Database System. Farinacci, et al. Expires December 23, 2011 [Page 78] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 o Tracker item 111. Indicate that if an LSB that is assocaited with an anycast address, that there is at least one RLOC that is up. o Tracker item 108. Make clear the R-bit does not define RLOC path reachability. o Tracker item 107. Indicate that weights are relative to each other versus requiring an addition of up to 100%. o Tracker item 46. Add a sentence how LISP products should be sized for the appropriate demand so cache thrashing is avoided. o Change some references of RFC 5226 to [AFI] per Luigi. o Per Luigi, make reference to "EID-AFI" consistent to "EID-prefix- AFI". o Tracker item 66. Indicate that appending locators to a locator- set is done when the added locators are lexicographically greater than the previous ones in the set. o Tracker item 87. Once again reword the definition of the EID- prefix to reflect recent comments. o Tracker item 70. Added text to security section on what the implications could be if an ITR does not obey priority and weights from a Map-Reply message. o Tracker item 54. Added text to the new section titled "Packets Egressing a LISP Site" to describe the implications when two or more ITRs exist at a site where only one ITR is used for egress traffic and when there is a shift of traffic to the others, how the map-cache will need to be populated in those new egress ITRs. o Tracker item 33. Make more clear in the Routing Locator Selection section what an ITR should do when it sees an R-bit of 0 in a locator-record of a Map-Reply. o Tracker item 33. Add paragraph to the EID Reachability section indicating that site parittioning is under investigation. o Tracker item 58. Added last paragraph of Security Considerations section about how to protect inner header EID address spoofing attacks. o Add suggested Sam text to indicate that all security concerns need not be addressed for moving document to Experimental RFC status. Put this in a subsection of the Secuirty Considerations section. Farinacci, et al. Expires December 23, 2011 [Page 79] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 B.3. Changes to draft-ietf-lisp-11.txt o Posted March 30, 2011. o Change IANA URL. The URL we had pointed to a general protocol numbers page. o Added the "s" bit to the Map-Request to allow SMR-invoked Map- Requests to be sent to a MN ETR via the map-server. o Generalize text for the defintion of Reencapsuatling tunnels. o Add pargraph suggested by Joel to explain how implementation experimentation will be used to determine the proper cache management techniques. o Add Yakov provided text for the definition of "EID-to-RLOC "Database". o Add reference in Section 8, Deployment Scenarios, to the draft-jakab-lisp-deploy-02.txt draft. o Clarify sentence about no hardware changes needed to support LISP encapsulation. o Add paragraph about what is the procedure when a locator is inserted in the middle of a locator-set. o Add a definition for Locator-Status-Bits so we can emphasize they are used as a hint for router up/down status and not path reachability. o Change "BGP RIB" to "RIB" per Clarence's comment. o Fixed complaints by IDnits. o Add subsection to Security Considerations section indicating how EID-prefix overclaiming in Map-Replies is for further study and add a reference to LISP-SEC. B.4. Changes to draft-ietf-lisp-10.txt o Posted March 2011. o Add p-bit to Map-Request so there is documentary reasons to know when a PITR has sent a Map-Request to an ETR. Farinacci, et al. Expires December 23, 2011 [Page 80] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 o Add Map-Notify message which is used to acknowledge a Map-Register message sent to a Map-Server. o Add M-bit to the Map-Register message so an ETR that wants an acknowledgment for the Map-Register can request one. o Add S-bit to the ECM and Map-Reply messages to describe security data that can be present in each message. Then refer to [LISP-SEC] for expansive details. o Add Network Management Considerations section and point to the MIB and LIG drafts. o Remove the word "simple" per Yakov's comments. B.5. Changes to draft-ietf-lisp-09.txt o Posted October 2010. o Add to IANA Consideration section about the use of LCAF Type values that accepted and maintained by the IANA registry and not the LCAF specification. o Indicate that implementations should be able to receive LISP control messages when either UDP port is 4342, so they can be robust in the face of intervening NAT boxes. o Add paragraph to SMR section to indicate that an ITR does not need to respond to an SMR-based Map-Request when it has no map-cache entry for the SMR source's EID-prefix. B.6. Changes to draft-ietf-lisp-08.txt o Posted August 2010. o In section 6.1.6, remove statement about setting TTL to 0 in Map- Register messages. o Clarify language in section 6.1.5 about Map-Replying to Data- Probes or Map-Requests. o Indicate that outer TTL should only be copied to inner TTL when it is less than inner TTL. o Indicate a source-EID for RLOC-probes are encoded with an AFI value of 0. Farinacci, et al. Expires December 23, 2011 [Page 81] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 o Indicate that SMRs can have a global or per SMR destination rate- limiter. o Add clarifications to the SMR procedures. o Add definitions for "client-side" and 'server-side" terms used in this specification. o Clear up language in section 6.4, last paragraph. o Change ACT of value 0 to "no-action". This is so we can RLOC- probe a PETR and have it return a Map-Reply with a locator-set of size 0. The way it is spec'ed the map-cache entry has action "dropped". Drop-action is set to 3. o Add statement about normalizing locator weights. o Clarify R-bit definition in the Map-Reply locator record. o Add section on EID Reachability within a LISP site. o Clarify another disadvantage of using anycast locators. o Reworded Abstract. o Change section 2.0 Introduction to remove obsolete information such as the LISP variant definitions. o Change section 5 title from "Tunneling Details" to "LISP Encapsulation Details". o Changes to section 5 to include results of network deployment experience with MTU. Recommend that implementations use either the stateful or stateless handling. o Make clarification wordsmithing to Section 7 and 8. o Identify that if there is one locator in the locator-set of a map- cache entry, that an SMR from that locator should be responded to by sending the the SMR-invoked Map-Request to the database mapping system rather than to the RLOC itself (which may be unreachable). o When describing Unicast and Multicast Weights indicate the the values are relative weights rather than percentages. So it doesn't imply the sum of all locator weights in the locator-set need to be 100. Farinacci, et al. Expires December 23, 2011 [Page 82] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 o Do some wordsmithing on copying TTL and TOS fields. o Numerous wordsmithing changes from Dave Meyer. He fine toothed combed the spec. o Removed Section 14 "Prototype Plans and Status". We felt this type of section is no longer appropriate for a protocol specification. o Add clarification text for the IRC description per Damien's commentary. o Remove text on copying nonce from SMR to SMR-invoked Map- Request per Vina's comment about a possible DoS vector. o Clarify (S/2 + H) in the stateless MTU section. o Add text to reflect Damien's comment about the description of the "ITR-RLOC Address" field in the Map-Request. that the list of RLOC addresses are local addresses of the Map-Requester. B.7. Changes to draft-ietf-lisp-07.txt o Posted April 2010. o Added I-bit to data header so LSB field can also be used as an Instance ID field. When this occurs, the LSB field is reduced to 8-bits (from 32-bits). o Added V-bit to the data header so the 24-bit nonce field can also be used for source and destination version numbers. o Added Map-Version 12-bit value to the EID-record to be used in all of Map-Request, Map-Reply, and Map-Register messages. o Added multiple ITR-RLOC fields to the Map-Request packet so an ETR can decide what address to select for the destination of a Map- Reply. o Added L-bit (Local RLOC bit) and p-bit (Probe-Reply RLOC bit) to the Locator-Set record of an EID-record for a Map-Reply message. The L-bit indicates which RLOCs in the locator-set are local to the sender of the message. The P-bit indicates which RLOC is the source of a RLOC-probe Reply (Map-Reply) message. o Add reference to the LISP Canonical Address Format [LCAF] draft. Farinacci, et al. Expires December 23, 2011 [Page 83] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 o Made editorial and clarification changes based on comments from Dhirendra Trivedi. o Added wordsmithing comments from Joel Halpern on DF=3D1 setting. o Add John Zwiebel clarification to Echo Nonce Algorithm section 6.3.1. o Add John Zwiebel comment about expanding on proxy-map-reply bit for Map-Register messages. o Add NAT section per Ron Bonica comments. o Fix IDnits issues per Ron Bonica. o Added section on Virtualization and Segmentation to explain the use if the Instance ID field in the data header. o There are too many P-bits, keep their scope to the packet format description and refer to them by name every where else in the spec. o Scanned all occurrences of "should", "should not", "must" and "must not" and uppercased them. o John Zwiebel offered text for section 4.1 to modernize the example. Thanks Z! o Make it more clear in the definition of "EID-to-RLOC Database" that all ETRs need to have the same database mapping. This reflects a comment from John Scudder. o Add a definition "Route-returnability" to the Definition of Terms section. o In section 9.2, add text to describe what the signature of traceroute packets can look like. o Removed references to Data Probe for introductory example. Data- probes are still part of the LISP design but not encouraged. o Added the definition for "LISP site" to the Definition of Terms" section. Farinacci, et al. Expires December 23, 2011 [Page 84] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 B.8. Changes to draft-ietf-lisp-06.txt Editorial based changes: o Posted December 2009. o Fix typo for flags in LISP data header. Changed from "4" to "5". o Add text to indicate that Map-Register messages must contain a computed UDP checksum. o Add definitions for PITR and PETR. o Indicate an AFI value of 0 is an unspecified address. o Indicate that the TTL field of a Map-Register is not used and set to 0 by the sender. This change makes this spec consistent with [LISP-MS]. o Change "... yield a packet size of L bytes" to "... yield a packet size greater than L bytes". o Clarify section 6.1.5 on what addresses and ports are used in Map- Reply messages. o Clarify that LSBs that go beyond the number of locators do not to be SMRed when the locator addresses are greater lexicographically than the locator in the existing locator-set. o Add Gregg, Srini, and Amit to acknowledgment section. o Clarify in the definition of a LISP header what is following the UDP header. o Clarify "verifying Map-Request" text in section 6.1.3. o Add Xu Xiaohu to the acknowledgment section for introducing the problem of overlapping EID-prefixes among multiple sites in an RRG email message. Design based changes: o Use stronger language to have the outer IPv4 header set DF=3D1 so = we can avoid fragment reassembly in an ETR or PETR. This will also make IPv4 and IPv6 encapsulation have consistent behavior. o Map-Requests should not be sent in ECM with the Probe bit is set. These type of Map-Requests are used as RLOC-probes and are sent Farinacci, et al. Expires December 23, 2011 [Page 85] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 directly to locator addresses in the underlying network. o Add text in section 6.1.5 about returning all EID-prefixes in a Map-Reply sent by an ETR when there are overlapping EID-prefixes configure. o Add text in a new subsection of section 6.1.5 about dealing with Map-Replies with coarse EID-prefixes. B.9. Changes to draft-ietf-lisp-05.txt o Posted September 2009. o Added this Document Change Log appendix. o Added section indicating that encapsulated Map-Requests must use destination UDP port 4342. o Don't use AH in Map-Registers. Put key-id, auth-length, and auth- data in Map-Register payload. o Added Jari to acknowledgment section. o State the source-EID is set to 0 when using Map-Requests to refresh or RLOC-probe. o Make more clear what source-RLOC should be for a Map-Request. o The LISP-CONS authors thought that the Type definitions for CONS should be removed from this specification. o Removed nonce from Map-Register message, it wasn't used so no need for it. o Clarify what to do for unspecified Action bits for negative Map- Replies. Since No Action is a drop, make value 0 Drop. B.10. Changes to draft-ietf-lisp-04.txt o Posted September 2009. o How do deal with record count greater than 1 for a Map-Request. Damien and Joel comment. Joel suggests: 1) Specify that senders compliant with the current document will always set the count to 1, and note that the count is included for future extensibility. 2) Specify what a receiver compliant with the draft should do if it receives a request with a count greater than 1. Presumably, it should send some error back? Farinacci, et al. Expires December 23, 2011 [Page 86] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 o Add Fred Templin in acknowledgment section. o Add Margaret and Sam to the acknowledgment section for their great comments. o Say more about LAGs in the UDP section per Sam Hartman's comment. o Sam wants to use MAY instead of SHOULD for ignoring checksums on ETR. =46rom the mailing list: "You'd need to word it as an ITR = MAY send a zero checksum, an ETR MUST accept a 0 checksum and MAY ignore the checksum completely. And of course we'd need to confirm that can actually be implemented. In particular, hardware that verifies UDP checksums on receive needs to be checked to make sure it permits 0 checksums." o Margaret wants a reference to http://www.ietf.org/id/draft-eubanks-chimento-6man-00.txt. o Fix description in Map-Request section. Where we describe Map- Reply Record, change "R-bit" to "M-bit". o Add the mobility bit to Map-Replies. So PTRs don't probe so often for MNs but often enough to get mapping updates. o Indicate SHA1 can be used as well for Map-Registers. o More Fred comments on MTU handling. o Isidor comment about spec'ing better periodic Map-Registers. Will be fixed in draft-ietf-lisp-ms-02.txt. o Margaret's comment on gleaning: "The current specification does not make it clear how long gleaned map entries should be retained in the cache, nor does it make it clear how/ when they will be validated. The LISP spec should, at the very least, include a (short) default lifetime for gleaned entries, require that they be validated within a short period of time, and state that a new gleaned entry should never overwrite an entry that was obtained from the mapping system. The security implications of storing "gleaned" entries should also be explored in detail." o Add section on RLOC-probing per working group feedback. o Change "loc-reach-bits" to "loc-status-bits" per comment from Noel. o Remove SMR-bit from data-plane. Dino prefers to have it in the control plane only. Farinacci, et al. Expires December 23, 2011 [Page 87] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 o Change LISP header to allow a "Research Bit" so the Nonce and LSB fields can be turned off and used for another future purpose. For Luigi et al versioning convergence. o Add a N-bit to the data header suggested by Noel. Then the nonce field could be used when N is not 1. o Clarify that when E-bit is 0, the nonce field can be an echoed nonce or a random nonce. Comment from Jesper. o Indicate when doing data-gleaning that a verifying Map-Request is sent to the source-EID of the gleaned data packet so we can avoid map-cache corruption by a 3rd party. Comment from Pedro. o Indicate that a verifying Map-Request, for accepting mapping data, should be sent over the ALT (or to the EID). o Reference IPsec RFC 4302. Comment from Sam and Brian Weis. o Put E-bit in Map-Reply to tell ITRs that the ETR supports echo- noncing. Comment by Pedro and Dino. o Jesper made a comment to loosen the language about requiring the copy of inner TTL to outer TTL since the text to get mixed-AF traceroute to work would violate the "MUST" clause. Changed from MUST to SHOULD in section 5.3. B.11. Changes to draft-ietf-lisp-03.txt o Posted July 2009. o Removed loc-reach-bits longword from control packets per Damien comment. o Clarifications in MTU text from Roque. o Added text to indicate that the locator-set be sorted by locator address from Isidor. o Clarification text from John Zwiebel in Echo-Nonce section. B.12. Changes to draft-ietf-lisp-02.txt o Posted July 2009. o Encapsulation packet format change to add E-bit and make loc- reach-bits 32-bits in length. Farinacci, et al. Expires December 23, 2011 [Page 88] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 o Added Echo-Nonce Algorithm section. o Clarification how ECN bits are copied. o Moved S-bit in Map-Request. o Added P-bit in Map-Request and Map-Reply messages to anticipate RLOC-Probe Algorithm. o Added to Mobility section to reference [LISP-MN]. B.13. Changes to draft-ietf-lisp-01.txt o Posted 2 days after draft-ietf-lisp-00.txt in May 2009. o Defined LEID to be a "LISP EID". o Indicate encapsulation use IPv4 DF=3D0. o Added negative Map-Reply messages with drop, native-forward, and send-map-request actions. o Added Proxy-Map-Reply bit to Map-Register. B.14. Changes to draft-ietf-lisp-00.txt o Posted May 2009. o Rename of draft-farinacci-lisp-12.txt. o Acknowledgment to RRG. Farinacci, et al. Expires December 23, 2011 [Page 89] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 Authors' Addresses Dino Farinacci cisco Systems Tasman Drive San Jose, CA 95134 USA Email: dino@cisco.com Vince Fuller cisco Systems Tasman Drive San Jose, CA 95134 USA Email: vaf@cisco.com Dave Meyer cisco Systems 170 Tasman Drive San Jose, CA USA Email: dmm@cisco.com Darrel Lewis cisco Systems 170 Tasman Drive San Jose, CA USA Email: darlewis@cisco.com Farinacci, et al. Expires December 23, 2011 [Page 90] =0C --Apple-Mail-3--328112272 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-3--328112272 Content-Disposition: attachment; filename=rfcdiff-lisp-multicast-05-to-06.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-lisp-multicast-05-to-06.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-multicast-05.txt draft-ietf-lisp-multicast-06.txt 
Network Working Group                                       D. Farinacci
Internet-Draft                                                  D. Meyer
Intended status: Experimental                                 J. Zwiebel
Expires: October 7, December 22, 2011                                     S. Venaas
                                                           cisco Systems
                                                           April 5,
                                                           June 20, 2011

                    LISP for Multicast Environments
                      draft-ietf-lisp-multicast-05
                      draft-ietf-lisp-multicast-06

Abstract

   This draft describes how inter-domain multicast routing will function
   in an environment where Locator/ID Separation is deployed using the
   LISP architecture.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 7, December 22, 2011.

Copyright Notice

   Copyright (c) 2011 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 BSD License.

Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  7
   4.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 10
   5.  Source Addresses versus Group Addresses  . . . . . . . . . . . 13
   6.  Locator Reachability Implications on LISP-Multicast  . . . . . 14
   7.  Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 15
   8.  LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 17
     8.1.  ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 17
       8.1.1.  Multiple RLOCs for an ITR  . . . . . . . . . . . . . . 17
       8.1.2.  Multiple ITRs for a LISP Source Site . . . . . . . . . 18
     8.2.  ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 18
     8.3.  Replication Locations  . . . . . . . . . . . . . . . . . . 18 19
   9.  LISP-Multicast Interworking  . . . . . . . . . . . . . . . . . 20
     9.1.  LISP and non-LISP Mixed Sites  . . . . . . . . . . . . . . 20
       9.1.1.  LISP Source Site to non-LISP Receiver Sites  . . . . . 21
       9.1.2.  Non-LISP Source Site to non-LISP Receiver  Sites . . . 22
       9.1.3.  Non-LISP Source Site to Any Receiver Site  . . . . . . 23
       9.1.4.  Unicast LISP Source Site to Any Receiver Sites . . . . 24
       9.1.5.  LISP Source Site to Any Receiver Sites . . . . . . . . 24
     9.2.  LISP Sites with Mixed Address Families . . . . . . . . . . 25
     9.3.  Making a Multicast Interworking Decision . . . . . . . . . 27
   10. Considerations when RP Addresses are Embedded in Group
       Addresses  . . . . . . . . . . . . . . . . . . . . . . . . . . 28
   11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 29
   12. Mtrace Considerations  . . . . . . . . . . . . . . . . . . . . 30
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 31
   14. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 32
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 33
     15.2. Informative References . . . . . . . . . . . . . . . . . . 33
   Appendix A.  Document Change Log . . . . . . . . . . . . . . . . . 35
     A.1.  Changes to draft-ietf-lisp-multicast-05.txt draft-ietf-lisp-multicast-06.txt  . . . . . . . 35
     A.2.  Changes to draft-ietf-lisp-multicast-04.txt draft-ietf-lisp-multicast-05.txt  . . . . . . . 35
     A.3.  Changes to draft-ietf-lisp-multicast-03.txt draft-ietf-lisp-multicast-04.txt  . . . . . . . 35
     A.4.  Changes to draft-ietf-lisp-multicast-02.txt draft-ietf-lisp-multicast-03.txt  . . . . . . . 35
     A.5.  Changes to draft-ietf-lisp-multicast-01.txt draft-ietf-lisp-multicast-02.txt  . . . . . . . 36
     A.6.  Changes to draft-ietf-lisp-multicast-01.txt  . . . . . . . 36
     A.7.  Changes to draft-ietf-lisp-multicast-00.txt  . . . . . . . 36
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37

1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   The Locator/ID Separation Architecture [LISP] provides a mechanism to
   separate out Identification and Location semantics from the current
   definition of an IP address.  By creating two namespaces, an EID
   namespace used by sites and a Locator (RLOC) namespace used by core
   routing, the core routing infrastructure can scale by doing
   topological aggregation of routing information.

   Since LISP creates a new namespace, a mapping function must exist to
   map a site's EID prefixes to its associated locators.  For unicast
   packets, both the source address and destination address must be
   mapped.  For multicast packets, only the source address needs to be
   mapped.  The destination group address doesn't need to be mapped
   because the semantics of an IPv4 or IPv6 group address are logical in
   nature and not topology-dependent.  Therefore, this specifications
   focuses on to map a source EID address of a multicast flow during
   distribution tree setup and packet delivery.

   This specification will address the following scenarios:

   1.  How a multicast source host in a LISP site sends multicast
       packets to receivers inside of its site as well as to receivers
       in other sites that are LISP enabled.

   2.  How inter-domain (or between LISP sites) multicast distribution
       trees are built and how forwarding of multicast packets leaving a
       source site toward receivers sites is performed.

   3.  What protocols are affected and what changes are required to such
       multicast protocols.

   4.  How ASM-mode, SSM-mode, and Bidir-mode service models will
       operate.

   5.  How multicast packet flow will occur for multiple combinations of
       LISP and non-LISP capable source and receiver sites, for example:

       A.  How multicast packets from a source host in a LISP site are
           sent to receivers in other sites when they are all non-LISP
           sites.

       B.  How multicast packets from a source host in a LISP site are
           sent to receivers in both LISP-enabled sites and non-LISP
           sites.

       C.  How multicast packets from a source host in a non-LISP site
           are sent to receivers in other sites when they are all LISP-
           enabled sites.

       D.  How multicast packets from a source host in a non-LISP site
           are sent to receivers in both LISP-enabled sites and non-LISP
           sites.

   This specification focuses on what changes are needed to the
   multicast routing protocols to support LISP-Multicast as well as
   other protocols used for inter-domain multicast, such as Multi-
   protocol BGP (MBGP) [RFC4760].  The approach proposed in this
   specification requires no changes to the multicast infrastructure
   inside of a site when all sources and receivers reside in that site,
   even when the site is LISP enabled.  That is, internal operation of
   multicast is unchanged regardless of whether or not the site is LISP
   enabled or whether or not receivers exist in other sites which are
   LISP-enabled.

   Therefore, we see changes only to PIM-ASM [RFC4601], MSDP [RFC3618],
   and PIM-SSM [RFC4607].  Bidir-PIM [RFC5015], which typically does not
   run in an inter-domain environment is not addressed in depth in this
   version of the specification.

   Also, the current version of this specification does not describe
   multicast-based Traffic Engineering relative to the TE-ITR and TE-ETR
   descriptions in [LISP].

3.  Definition of Terms

   The terminology in this section is consistent with the definitions in
   [LISP] but is extended specifically to deal with the application of
   the terminology to multicast routing.

   LISP-Multicast:   a reference to the design in this specification.
      That is, when any site that is participating in multicast
      communication has been upgraded to be a LISP site, the operation
      of control-plane and data-plane protocols is considered part of
      the LISP-Multicast architecture.

   Endpoint ID (EID):   a 32-bit (for IPv4) or 128-bit (for IPv6) value
      used in the source address field of the first (most inner) LISP
      header of a multicast packet.  The host obtains a destination
      group address the same way it obtains one today, as it would when
      it is a non-LISP site.  The source EID is obtained via existing
      mechanisms used to set a host's "local" IP address.  An EID is
      allocated to a host from an EID prefix block associated with the
      site the host is located in.  An EID can be used by a host to
      refer to another host, as when it joins an SSM (S-EID,G) route
      using IGMP version 3 [RFC4604].  LISP uses Provider Independent
      (PI) blocks for EIDs; such EIDs MUST NOT be used as LISP RLOCs.
      Note that EID blocks may be assigned in a hierarchical manner,
      independent of the network topology, to facilitate scaling of the
      mapping database.  In addition, an EID block assigned to a site
      may have site-local structure (subnetting) for routing within the
      site; this structure is not visible to the global routing system.

   Routing Locator (RLOC):   the IPv4 or IPv6 address of an ingress
      tunnel router (ITR), the router in the multicast source host's
      site that encapsulates multicast packets.  It is the output of a
      EID-to-RLOC mapping lookup.  An EID maps to one or more RLOCs.
      Typically, RLOCs are numbered from topologically-aggregatable
      blocks that are assigned to a site at each point to which it
      attaches to the global Internet; where the topology is defined by
      the connectivity of provider networks, RLOCs can be thought of as
      Provider Assigned (PA) addresses.  Multiple RLOCs can be assigned
      to the same ITR device or to multiple ITR devices at a site.

   Ingress Tunnel Router (ITR):   a router which accepts an IP multicast
      packet with a single IP header (more precisely, an IP packet that
      does not contain a LISP header).  The router treats this "inner"
      IP destination multicast address opaquely so it doesn't need to
      perform a map lookup on the group address because it is
      topologically insignificant.  The router then prepends an "outer"
      IP header with one of its globally-routable RLOCs as the source
      address field.  This RLOC is known to other multicast receiver
      sites which have used the mapping database to join a multicast
      tree for which the ITR is the root.  In general, an ITR receives
      IP packets from site end systems on one side and sends LISP-
      encapsulated multicast IP packets out all external interfaces
      which have been joined.

      An ITR would receive a multicast packet from a source inside of
      its site when 1) it is on the path from the multicast source to
      internally joined receivers, or 2) when it is on the path from the
      multicast source to externally joined receivers.

   Egress Tunnel Router (ETR):   a router that is on the path from a
      multicast source host in another site to a multicast receiver in
      its own site.  An ETR accepts a PIM Join/Prune message from a site
      internal PIM router destined for the source's EID in the multicast
      source site.  The ETR maps the source EID in the Join/Prune
      message to an RLOC address based on the EID-to-RLOC mapping.  This
      sets up the ETR to accept multicast encapsulated packets from the
      ITR in the source multicast site.  A multicast ETR decapsulates
      multicast encapsulated packets and replicates them on interfaces
      leading to internal receivers.

   xTR:   is a reference to an ITR or ETR when direction of data flow is
      not part of the context description. xTR refers to the router that
      is the tunnel endpoint.  Used synonymously with the term "Tunnel
      Router".  For example, "An xTR can be located at the Customer Edge
      (CE) router", meaning both ITR and ETR functionality can be at the
      CE router.

   LISP Header:   a term used in this document to refer to the outer
      IPv4 or IPv6 header, a UDP header, and a LISP header.  An ITR
      prepends headers and an ETR strips headers.  A LISP encapsulated
      multicast packet will have an "inner" header with the source EID
      in the source field; an "outer" header with the source RLOC in the
      source field: and the same globally unique group address in the
      destination field of both the inner and outer header.

   (S,G) State:   the formal definition is in the PIM Sparse Mode
      [RFC4601] specification.  For this specification, the term is used
      generally to refer to multicast state.  Based on its topological
      location, the (S,G) state resides in routers can be either
      (S-EID,G) state (at a location where the (S,G) state resides) or
      (S-RLOC,G) state (in the Internet core).

   (S-EID,G) State:   refers to multicast state in multicast source and
      receiver sites where S-EID is the IP address of the multicast
      source host (its EID).  An S-EID can appear in an IGMPv3 report,
      an MSDP SA message or a PIM Join/Prune message that travels inside
      of a site.

   (S-RLOC,G) State:   refers to multicast state in the core where S is
      a source locator (the IP address of a multicast ITR) of a site
      with a multicast source.  The (S-RLOC,G) is mapped from (S-EID,G)
      entry by doing a mapping database lookup for the EID prefix that
      S-EID maps to.  An S-RLOC can appear in a PIM Join/Prune message
      when it travels from an ETR to an ITR over the Internet core.

   uLISP Site:   a unicast only LISP site according to [LISP] which has
      not deployed the procedures of this specification and therefore,
      for multicast purposes, follows the procedures from Section 9.

   mPETR:   this is a multicast proxy-ETR that is responsible for
      advertising a very coarse EID prefix which non-LISP and uLISP
      sites can target their (S-EID,G) PIM Join/Prune message to. mPETRs
      are used so LISP source multicast sites can send multicast packets
      using source addresses from the EID namespace. mPETRs act as Proxy
      ETRs for supporting multicast routing in a LISP infrastructure.
      It is likely an uPITR [INTWORK] and a mPETR will be co-loacted co-located
      since the single device advertises a coarse EID-prefix in the
      underlying unicast routing system.

   Mixed Locator-Sets:   this is a locator-set for a LISP database
      mapping entry where the RLOC addresses in the locator-set are in
      both IPv4 and IPv6 format.

   Unicast Encapsulated PIM Join/Prune Message:   this is a standard PIM
      Join/Prune message (encapsulated in a LISP Encapsulated Control
      Message with destination UDP port 4342) which is sent by ETRs at
      multicast receiver sites to an ITR at a multicast source site.
      This message is sent periodically as long as there are interfaces
      in the oif-list for the (S-EID,G) entry the ETR is joining for.

4.  Basic Overview

   LISP, when used for unicast routing, increases the site's ability to
   control ingress traffic flows.  Egress traffic flows are controlled
   by the IGP in the source site.  For multicast, the IGP coupled with
   PIM can decide which path multicast packets ingress.  By using the
   traffic engineering features of LISP, a multicast source site can
   control the egress of its multicast traffic.  By controlling the
   priorities of locators from a mapping database entry, a source
   multicast site can control which way multicast receiver sites join to
   the source site.

   At this point in time, we don't see a requirement for different
   locator-sets, priority, and weight policies for multicast than we
   have for unicast.  However, when traffic engineering policies are
   different for unicast versus multicast flows, it will be desirable to
   use multicast-based priority and weight values in Map-Reply messages.

   The fundamental multicast forwarding model is to encapsulate a
   multicast packet into another multicast packet.  An ITR will
   encapsulate multicast packets received from sources that it serves in
   another LISP multicast header.  The destination group address from
   the inner header is copied to the destination address of the outer
   header.  The inner source address is the EID of the multicast source
   host and the outer source address is the RLOC of the encapsulating
   ITR.

   The LISP-Multicast architecture will follow this high-level protocol
   and operational sequence:

   1.  Receiver hosts in multicast sites will join multicast content the
       way they do today, they use IGMP.  When they use IGMPv3 where
       they specify source addresses, they use source EIDs, that is they
       join (S-EID,G).  If the multicast source is external to this
       receiver site, the PIM Join/Prune message flows toward the ETRs,
       finding the shortest exit (that is the closest exit for the Join/
       Prune message and the closest entrance for the multicast packet
       to the receiver).

   2.  The ETR does a mapping database lookup for S-EID.  If the mapping
       is cached from a previous lookup (from either a previous Join/
       Prune for the source multicast site or a unicast packet that went
       to the site), it will use the RLOC information from the mapping.
       The ETR will use the same priority and weighting mechanism as for
       unicast.  So the source site can decide which way multicast
       packets egress.

   3.  The ETR will build two PIM Join/Prune messages, one that contains
       a (S-EID,G) entry that is unicast to the ITR that matches the
       RLOC the ETR selects, and the other which contains a (S-RLOC,G)
       entry so the core network can create multicast state from this
       ETR to the ITR.

   4.  When the ITR gets the unicast Join/Prune message (see Section 3
       for formal definition), it will process (S-EID,G) entries in the
       message and propagate them inside of the site where it has
       explicit routing information for EIDs via the IGP.  When the ITR
       receives the (S-RLOC,G) PIM Join/Prune message it will process it
       like any other join it would get in today's Internet.  The S-RLOC
       address is the IP address of this ITR.

   5.  At this point there is (S-EID,G) state from the joining host in
       the receiver multicast site to the ETR of the receiver multicast
       site.  There is (S-RLOC,G) state across the core network from the
       ETR of the multicast receiver site to the ITR in the multicast
       source site and (S-EID,G) state in the source multicast site.
       Note, the (S-EID,G) state is the same S-EID in each multicast
       site.  As other ETRs join the same multicast tree, they can join
       through the same ITR (in which case the packet replication is
       done in the core) or a different ITR (in which case the packet
       replication is done at the source site).

   6.  When a packet is originated by the multicast host in the source
       site, it will flow to one or more ITRs which will prepend a LISP
       header by copying the group address to the outer destination
       address field and insert its own locator address in the outer
       source address field.  The ITR will look at its (S-RLOC,G) state,
       where S-RLOC is its own locator address, and replicate the packet
       on each interface a (S-RLOC,G) joined was received on.  The core
       has (S-RLOC,G) so where fanout occurs to multiple sites, a core
       router will do packet replication.

   7.  When either the source site or the core replicates the packet,
       the ETR will receive a LISP packet with a destination group
       address.  It will decapsulate packets because it has receivers
       for the group.  Otherwise, it would have not received the packets
       because it would not have joined.  The ETR decapsulates and does
       a (S-EID,G) lookup in its multicast FIB to forward packets out
       one or more interfaces to forward the packet to internal
       receivers.

   This architecture is consistent and scalable with the architecture
   presented in [LISP] where multicast state in the core operates on
   locators and multicast state at the sites operates on EIDs.

   Alternatively, [LISP] also has a mechanism where (S-EID,G) state can
   reside in the core through the use of RPF-vectors [RPFV] in PIM Join/
   Prune messages.  However, few PIM implementations support RPF vectors
   and LISP should avoid S-EID state in the core.  See Section 5 for
   details.

   However, we have some observations on the algorithm above.  We can
   scale the control plane but at the expense of sending data to sites
   which may have not joined the distribution tree where the
   encapsulated data is being delivered.  For example, one site joins
   (S-EID1,G) and another site joins (S-EID2,G).  Both EIDs are in the
   same multicast source site.  Both multicast receiver sites join to
   the same ITR with state (S-RLOC,G) where S-RLOC is the RLOC for the
   ITR.  The ITR joins both (S-EID1,G) and (S-EID2,G) inside of the
   site.  The ITR receives (S-RLOC,G) joins and populates the oif-list
   state for it.  Since both (S-EID1,G) and (S-EID2, G) map to the one
   (S-RLOC,G) packets will be delivered by the core to both multicast
   receiver sites even though each have joined a single source-based
   distribution tree.  This behavior is a consequence of the many-to-one
   mapping between S-EIDs and a S-RLOC.

   There is a possible solution to this problem which reduces the number
   of many-to-one occurrences of (S-EID,G) entries aggregating into a
   single (S-RLOC,G) entry.  If a physical ITR can be assigned multiple
   RLOC addresses and these addresses are advertised in mapping database
   entries, then ETRs at receiver sites have more RLOC address options
   and therefore can join different (RLOC,G) entries for each (S-EID,G)
   entry joined at the receiver site.  It would not scale to have a one-
   to-one relationship between the number of S-EID sources at a source
   site and the number of RLOCs assigned to all ITRs at the site, but we
   can reduce the "n" to a smaller number in the "n-to-1" relationship.
   And in turn, reduce the opportunity for data packets to be delivered
   to sites for groups not joined.

5.  Source Addresses versus Group Addresses

   Multicast group addresses don't have to be associated with either the
   EID or RLOC namespace.  They actually are a namespace of their own
   that can be treated as logical with relatively opaque allocation.
   So, by their nature, they don't detract from an incremental
   deployment of LISP-Multicast.

   As for source addresses, as in the unicast LISP scenario, there is a
   decoupling of identification from location.  In a LISP site, packets
   are originated from hosts using their allocated EIDs, those addresses
   are used to identify the host as well as where in the site's topology
   the host resides but not how and where it is attached to the
   Internet.

   Therefore, when multicast distribution tree state is created anywhere
   in the network on the path from any multicast receiver to a multicast
   source, EID state is maintained at the source and receiver multicast
   sites, and RLOC state is maintained in the core.  That is, a
   multicast distribution tree will be represented as a 3-tuple of
   {(S-EID,G) (S-RLOC,G) (S-EID,G)} where the first element of the
   3-tuple is the state stored in routers from the source to one or more
   ITRs in the source multicast site, the second element of the 3-tuple
   is the state stored in routers downstream of the ITR, in the core, to
   all LISP receiver multicast sites, and the third element in the
   3-tuple is the state stored in the routers downstream of each ETR, in
   each receiver multicast site, reaching each receiver.  Note that
   (S-EID,G) is the same in both the source and receiver multicast
   sites.

   The concatenation/mapping from the first element to the second
   element of the 3-tuples is done by the ITR and from the second
   element to the third element is done at the ETRs.

6.  Locator Reachability Implications on LISP-Multicast

   Multicast state as it is stored in the core is always (S,G) state as
   it exists today or (S-RLOC,G) state as it will exist when LISP sites
   are deployed.  The core routers cannot distinguish one from the
   other.  They don't need to because it is state that RPFs against the
   core routing tables in the RLOC namespace.  The difference is where
   the root of the distribution tree for a particular source is.  In the
   traditional multicast core, the source S is the source host's IP
   address.  For LISP-Multicast the source S is a single ITR of the
   multicast source site.

   An ITR is selected based on the LISP EID-to-RLOC mapping used when an
   ETR propagates a PIM Join/Prune message out of a receiver multicast
   site.  The selection is based on the same algorithm an ITR would use
   to select an ETR when sending a unicast packet to the site.  In the
   unicast case, the ITR can change on a per-packet basis depending on
   the reachability of the ETR.  So an ITR can change relatively easily
   using local reachability state.  However, in the multicast case, when
   an ITR goes unreachable, new distribution tree state must be built
   because the encapsulating root has changed.  This is more significant
   than an RPF-change event, where any router would typically locally
   change its RPF-interface for its existing tree state.  But when an
   encapsulating LISP-Multicast ITR goes unreachable, new distribution
   state must be rebuilt and reflect the new encapsulator.  Therefore,
   when an ITR goes unreachable, all ETRs that are currently joined to
   that ITR will have to trigger a new Join/Prune message for (S-RLOC,G)
   to the new ITR as well as send a unicast encapsulated Join/Prune
   message telling the new ITR which (S-EID,G) is being joined.

   This issue can be mitigated by using anycast addressing for the ITRs
   so the problem does reduce to an RPF change in the core, but still
   requires a unicast encapsulated Join/Prune message to tell the new
   ITR about (S-EID,G).  The problem with this approach is that the ETR
   really doesn't know when the ITR has changed so the new anycast ITR
   will get the (S-EID,G) state only when the ETR sends it the next time
   during its periodic sending procedures.

7.  Multicast Protocol Changes

   A number of protocols are used today for inter-domain multicast
   routing:

   IGMPv1-v3, MLDv1-v2:   These protocols do not require any changes for
      LISP-Multicast for two reasons.  One being that they are link-
      local and not used over site boundaries and second they advertise
      group addresses that don't need translation.  Where source
      addresses are supplied in IGMPv3 and MLDv2 messages, they are
      semantically regarded as EIDs and don't need to be converted to
      RLOCs until the multicast tree-building protocol, such as PIM, is
      received by the ETR at the site boundary.  Addresses used for IGMP
      and MLD come out of the source site's allocated addresses which
      are therefore from the EID namespace.

   MBGP:   Even though MBGP is not a multicast routing protocol, it is
      used to find multicast sources when the unicast BGP peering
      topology and the multicast MBGP peering topology are not
      congruent.  When MBGP is used in a LISP-Multicast environment, the
      prefixes which are advertised are from the RLOC namespace.  This
      allows receiver multicast sites to find a path to the source
      multicast site's ITRs.  MBGP peering addresses will be from the
      RLOC namespace.

   MSDP:   MSDP is used to announce active multicast sources to other
      routing domains (or LISP sites).  The announcements come from the
      PIM Rendezvous Points (RPs) from sites where there are active
      multicast sources sending to various groups.  In the context of
      LISP-Multicast, the source addresses advertised in MSDP will
      semantically be from the EID namespace since they describe the
      identity of a source multicast host.  It will be true that the
      state stored in MSDP caches from core routers will be from the EID
      namespace.  An RP address inside of site will be from the EID
      namespace so it can be advertised and reached by internal unicast
      routing mechanism.  However, for MSDP peer-RPF checking to work
      properly across sites, the RP addresses must be converted or
      mapped into a routable address that is advertised and maintained
      in the BGP routing tables in the core.  MSDP peering addresses can
      come out of either the EID or a routable address namespace.  And
      the choice can be made unilaterally because the ITR at the site
      will determine which namespace the destination peer address is out
      of by looking in the mapping database service.

   PIM-SSM:   In the simplest form of distribution tree building, when
      PIM operates in SSM mode, a source distribution tree is built and
      maintained across site boundaries.  In this case, there is a small
      modification to the operation of the PIM protocol (but not to any
      message format) to support taking a Join/Prune message originated
      inside of a LISP site with embedded addresses from the EID
      namespace and converting them to addresses from the RLOC namespace
      when the Join/Prune message crosses a site boundary.  This is
      similar to the requirements documented in [MNAT].

   PIM-Bidir:   Bidirectional PIM is typically run inside of a routing
      domain, but if deployed in an inter-domain environment, one would
      have to decide if the RP address of the shared-tree would be from
      the EID namespace or the RLOC namespace.  If the RP resides in a
      site-based router, then the RP address is from the EID namespace.
      If the RP resides in the core where RLOC addresses are routed,
      then the RP address is from the RLOC namespace.  This could be
      easily distinguishable if the EID address were well-known address
      allocation block from the RLOC namespace.  Also, when using
      Embedded-RP for RP determination [RFC3956], the format of the
      group address could indicate the namespace the RP address is from.
      However, refer to Section 10 for considerations core routers need
      to make when using Embedded-RP IPv6 group addresses.  When using
      Bidir-PIM for inter-domain multicast routing, it is recommended to
      use staticly configured RPs so core routers think the Bidir group
      is associated with an ITR's RLOC as the RP address and site
      routers think the Bidir group is associated with the site resident
      RP with an EID address.  With respect to DF-election in Bidir PIM,
      no changes are required since all messaging and addressing is
      link-local.

   PIM-ASM:   The ASM mode of PIM, the most popular form of PIM, is
      deployed in the Internet today is by having shared-trees within a
      site and using source-trees across sites.  By the use of MSDP and
      PIM-SSM techniques described above, we can get multicast
      connectivity across LISP sites.  Having said that, that means
      there are no special actions required for processing (*,G) or
      (S,G,R) Join/Prune messages since they all operate against the
      shared-tree which is site resident.  Just like with ASM, there is
      no (*,G) in the core when LISP-Multicast is in use.  This is also
      true for the RP-mapping mechanisms Auto-RP and BSR.

   Based on the protocol description above, the conclusion is that there
   are no protocol message format changes, just a translation function
   performed at the control-plane.  This will make for an easier and
   faster transition for LISP since fewer components in the network have
   to change.

   It should also be stated just like it is in [LISP] that no host
   changes, whatsoever, are required to have a multicast source host
   send multicast packets and for a multicast receiver host to receive
   multicast packets.

8.  LISP-Multicast Data-Plane Architecture

   The LISP-Multicast data-plane operation conforms to the operation and
   packet formats specified in [LISP].  However, encapsulating a
   multicast packet from an ITR is a much simpler process.  The process
   is simply to copy the inner group address to the outer destination
   address.  And to have the ITR use its own IP address (its RLOC), and
   as the source address.  The process is simpler for multicast because
   there is no EID-to-RLOC mapping lookup performed during packet
   forwarding.

   In the decapsulation case, the ETR simply removes the outer header
   and performs a multicast routing table lookup on the inner header
   (S-EID,G) addresses.  Then the oif-list for the (S-EID,G) entry is
   used to replicate the packet on site-facing interfaces leading to
   multicast receiver hosts.

   There is no Data-Probe logic for ETRs as there can be in the unicast
   forwarding case.

8.1.  ITR Forwarding Procedure

   The following procedure is used by an ITR, when it receives a
   multicast packet from a source inside of its site:

   1.  A multicast data packet sent by a host in a LISP site will have
       the source address equal to the host's EID and the destination
       address equal to the group address of the multicast group.  It is
       assumed the group information is obtained by current methods.
       The same is true for a multicast receiver to obtain the source
       and group address of a multicast flow.

   2.  When the ITR receives a multicast packet, it will have both S-EID
       state and S-RLOC state stored.  Since the packet was received on
       a site-facing interface, the RPF lookup is based on the S-EID
       state.  If the RPF check succeeds, then the oif-list contains
       interfaces that are site-facing and external-facing.  For the
       site-facing interfaces, no LISP header is prepended.  For the
       external-facing interfaces a LISP header is prepended.  When the
       ITR prepends a LISP header, it uses its own RLOC address as the
       source address and copies the group address supplied by the IP
       header the host built as the outer destination address.

8.1.1.  Multiple RLOCs for an ITR

   Typically, an ITR will have a single RLOC address but in some cases
   there could be multiple RLOC addresses assigned from either the same
   or different service providers.  In this case when (S-RLOC,G) Join/
   Prune messages are received for each RLOC, there is a oif-list
   merging action that must take place.  Therefore, when a packet is
   received from a site-facing interface that matches on a (S-EID,G)
   entry, the interfaces of the oif-list from all (RLOC,G) entries
   joined to the ITR as well as the site-facing oif-list joined for
   (S-EID,G) must be part be included in packet replication.  In
   addition to replicating for all types of oif-lists, each oif entry
   must be tagged with the RLOC address, so encapsulation uses the outer
   source address for the RLOC joined.

8.1.2.  Multiple ITRs for a LISP Source Site

   Note when ETRs from different multicast receiver sites receive
   (S-EID,G) joins, they may select a different S-RLOC for a multicast
   source site due to policy (the multicast ITR can return different
   multicast priority and weight values per ETR Map-Request).  In this
   case, the same (S-EID,G) is being realized by different (S-RLOC,G)
   state in the core.  This will not result in duplicate packets because
   each ITR in the multicast source site will choose their own RLOC for
   the source address for encapsulated multicast traffic.  The RLOC
   addresses are the ones joined by remote multicast ETRs.

   When different (S-EID,G) traffic is combined into a single (RLOC,G)
   core distribution tree, this may cause traffic to go to a receiver
   multicast site when it does not need to.  This happens when one
   receiver multicast site joins (S1-EID,Gi) through a core distribution
   tree of (RLOC1,Gi) and another multicast receiver site joins (S2-
   EID,Gi) through the same core distribution tree of (RLOC1,Gi).  When
   ETRs decapsulate such traffic, they should know from their local
   (S-EID,G) state if the packet should be forwarded.  If there is no
   (S-EID,G) state that matches the inner packet header, the packet is
   discarded.

8.2.  ETR Forwarding Procedure

   The following procedure is used by an ETR, when it receives a
   multicast packet from a source outside of its site:

   1.  When a multicast data packet is received by an ETR on an
       external-facing interface, it will do an RPF lookup on the S-RLOC
       state it has stored.  If the RPF check succeeds, the interfaces
       from the oif-list are used for replication to interfaces that are
       site-facing as well as interfaces that are external-facing (this
       ETR can also be a transit multicast router for receivers outside
       of its site).  When the packet is to be replicated for an
       external-facing interface, the LISP encapsulation header are not
       stripped.  When the packet is replicated for a site-facing
       interface, the encapsulation header is stripped.

   2.  The packet without a LISP header is now forwarded down the
       (S-EID,G) distribution tree in the receiver multicast site.

8.3.  Replication Locations

   Multicast packet replication can happen in the following topological
   locations:

   o  In an IGP multicast router inside a site which operates on S-EIDs.

   o  In a transit multicast router inside of the core which operates on
      S-RLOCs.

   o  At one or more ETR routers depending on the path a Join/Prune
      message exits a receiver multicast site.

   o  At one or more ITR routers in a source multicast site depending on
      what priorities are returned in a Map-Reply to receiver multicast
      sites.

   In the last case the source multicast site can do replication rather
   than having a single exit from the site.  But this only can occur
   when the priorities in the Map-Reply are modified for different
   receiver multicast site so that the PIM Join/Prune messages arrive at
   different ITRs.

   This policy technique, also used in [ALT] for unicast, is useful for
   multicast to mitigate the problems of changing distribution tree
   state as discussed in Section 6.

9.  LISP-Multicast Interworking

   This section will describe the multicast corollary to [INTWORK] which
   describes the interworking of multicast routing among LISP and non-
   LISP sites.

9.1.  LISP and non-LISP Mixed Sites

   Since multicast communication can involve more than two entities to
   communicate together, the combinations of interworking scenarios are
   more involved.  However, the state maintained for distribution trees
   at the sites is the same regardless of whether or not the site is
   LISP enabled or not.  So most of the implications are in the core
   with respect to storing routable EID prefixes from either PA or PI
   blocks.

   Before we enumerate the multicast interworking scenarios, we must
   define 3 deployment states of a site:

   o  A non-LISP site which will run PIM-SSM or PIM-ASM with MSDP as it
      does today.  The addresses for the site are globally routable.

   o  A site that deploys LISP for unicast routing.  The addresses for
      the site are not globally routable.  Let's define the name for
      this type of site as a uLISP site.

   o  A site that deploys LISP for both unicast and multicast routing.
      The addresses for the site are not globally routable.  Let's
      define the name for this type of site as a LISP-Multicast site.

   We will not consider a LISP site enabled for multicast purposes only
   but do consider a uLISP site as documented in [INTWORK].  In this
   section we don't discuss how a LISP site sends multicast packets when
   all receiver sites are LISP-Multicast enabled; that has been
   discussed in previous sections.

   The following scenarios exist to make LISP-Multicast sites interwork
   with non-LISP-Multicast sites:

   1.  A LISP site must be able to send multicast packets to receiver
       sites which are a mix of non-LISP sites and uLISP sites.

   2.  A non-LISP site must be able to send multicast packets to
       receiver sites which are a mix of non-LISP sites and uLISP sites.

   3.  A non-LISP site must be able to send multicast packets to
       receiver sites which are a mix of LISP sites, uLISP sites, and
       non-LISP sites.

   4.  A uLISP site must be able to send multicast packets to receiver
       sites which are a mix of LISP sites, uLISP sites, and non-LISP
       sites.

   5.  A LISP site must be able to send multicast packets to receiver
       sites which are a mix of LISP sites, uLISP sites, and non-LISP
       sites.

9.1.1.  LISP Source Site to non-LISP Receiver Sites

   In the first scenario, a site is LISP capable for both unicast and
   multicast traffic and as such operates on EIDs.  Therefore there is a
   possibility that the EID prefix block is not routable in the core.
   For LISP receiver multicast sites this isn't a problem but for non-
   LISP or uLISP receiver multicast sites, when a PIM Join/Prune message
   is received by the edge router, it has no route to propagate the
   Join/Prune message out of the site.  This is no different than the
   unicast case that LISP-NAT in [INTWORK] solves.

   LISP-NAT allows a unicast packet that exits a LISP site to get its
   source address mapped to a globally routable address before the ITR
   realizes that it should not encapsulate the packet destined to a non-
   LISP site.  For a multicast packet to leave a LISP site, distribution
   tree state needs to be built so the ITR can know where to send the
   packet.  So the receiver multicast sites need to know about the
   multicast source host by its routable address and not its EID
   address.  When this is the case, the routable address is the
   (S-RLOC,G) state that is stored and maintained in the core routers.
   It is important to note that the routable address for the host cannot
   be the same as an RLOC for the site.  Because site because we want the ITRs to
   process a received PIM Join/Prune message from an external-facing
   interface to be propagated inside of the site so the site-part of the
   distribution tree is built.

   Using a globally routable source address allows non-LISP and uLISP
   multicast receiver to join, create, and maintain a multicast
   distribution tree.  However, the LISP multicast receiver site will
   want to perform an EID-to-RLOC mapping table lookup when a PIM Join/
   Prune message is received on a site-facing interface.  It does this
   because it wants to find a (S-RLOC,G) entry to Join in the core.  So
   we have a conflict of behavior between the two types of sites.

   The solution to this problem is the same as when an ITR wants to send
   a unicast packet to a destination site but needs determine if the
   site is LISP capable or not.  When it is not LISP capable, the ITR
   does not encapsulate the packet.  So for the multicast case, when ETR
   receives a PIM Join/Prune message for (S-EID,G) state, it will do a
   mapping table lookup on S-EID.  In this case, S-EID is not in the
   mapping database because the source multicast site is using a
   routable address and not an EID prefix address.  So the ETR knows to
   simply propagate the PIM Join/Prune message to a external-facing
   interface without converting the (S-EID,G) because it is an (S,G)
   where S is routable and reachable via core routing tables.

   Now that the multicast distribution tree is built and maintained from
   any non-LISP or uLISP receiver multicast site, the way packet
   forwarding model is performed can be explained.

   Since the ITR in the source multicast site has never received a
   unicast encapsulated PIM Join/Prune message from any ETR in a
   receiver multicast site, it knows there are no LISP-Multicast
   receiver sites.  Therefore, there is no need for the ITR to
   encapsulate data.  Since it will know a priori (via configuration)
   that its site's EIDs are not routable, routable (and not registered to the
   mapping database system), it assumes that the multicast packets from
   the source host are sent by a routable address.  That is, it is the
   responsibility of the multicast source host's system administrator to
   ensure that the source host sends multicast traffic using a routable
   source address.  When this happens, the ITR acts simply as a router
   and forwards the multicast packet like an ordinary multicast router.

   There is an alternative to using a LISP-NAT scheme just like there is
   for unicast [INTWORK] forwarding by using Proxy Tunnel Routers
   (PxTRs).  This can work the same way for multicast routing as well,
   but the difference is that non-LISP and uLISP sites will send PIM
   Join/Prune messages for (S-EID,G) which make their way in the core to
   multicast PxTRs.  Let's call this use of a PxTR as a "Multicast
   Proxy-ETR" (or mPETR).  Since the mPETRs advertise very coarse EID
   prefixes, they draw the PIM Join/Prune control traffic making them
   the target of the distribution tree.  To get multicast packets from
   the LISP source multicast sites, the tree needs to be built on the
   path from the mPETR to the LISP source multicast site.  To make this
   happen the mPETR acts as a "Proxy ETR" (where in unicast it acts as a
   "Proxy ITR", or an uPITR). uPITR [INTWORK]).

   The existence of mPETRs in the core allows source multicast site ITRs
   to encapsulate multicast packets according to (S-RLOC,G) state.  The
   (S-RLOC,G) state is built from the mPETRs to the multicast ITRs.  The
   encapsulated multicast packets are decapsulated by mPETRs and then
   forwarded according to (S-EID,G) state.  The (S-EID,G) state is built
   from the non-LISP and uLISP receiver multicast sites to the mPETRs.

9.1.2.  Non-LISP Source Site to non-LISP Receiver  Sites

   Clearly non-LISP multicast sites can send multicast packets to non-
   LISP receiver multicast sites.  That is what they do today.  However,
   discussion is required to show how non-LISP multicast sites send
   multicast packets to uLISP receiver multicast sites.

   Since uLISP receiver multicast sites are not targets of any (S,G)
   state, they simply send (S,G) PIM Join/Prune messages toward the non-
   LISP source multicast site.  Since the source multicast site, in this
   case has not been upgraded to LISP, all multicast source host
   addresses are routable.  So this case is simplified to where a uLISP
   receiver multicast site looks to the source multicast site as a non-
   LISP receiver multicast site.

9.1.3.  Non-LISP Source Site to Any Receiver Site

   When a non-LISP source multicast site has receivers in either a non-
   LISP/uLISP site or a LISP site, one needs to decide how the LISP
   receiver multicast site will attach to the distribution tree.  We
   know from Section 9.1.2 that non-LISP and uLISP receiver multicast
   sites can join the distribution tree, but a LISP receiver multicast
   site ETR will need to know if the source address of the multicast
   source host is routable or not.  We showed in Section 9.1.1 that an
   ETR, before it sends a PIM Join/Prune message on an external-facing
   interface, does a EID-to-RLOC mapping lookup to determine if it
   should convert the (S,G) state from a PIM Join/Prune message received
   on a site-facing interface to a (S-RLOC,G).  If the lookup fails, the
   ETR can conclude the source multicast site is a non-LISP site so it
   simply forwards the Join/Prune message (it also doesn't need to send
   a unicast encapsulated Join/Prune message because there is no ITR in
   a non-LISP site and there is namespace continuity between the ETR and
   source).

   For a non-LISP source multicast site, (S-EID,G) state could be
   limited to the edges of the network with the use of multicast proxy-
   ITRs (mPITRs).  The mPITRs can take native, unencapsulated multicast
   packets from non-LISP source multicast and uLISP sites and
   encapsulate them to ETRs in receiver multicast sites or to mPETRs
   that can decapsulate for non-LISP receiver multicast or uLISP sites.
   The mPITRs are responsible for sending (S-EID,G) joins to the non-
   LISP source multicast site.  To connect the distribution trees
   together, multicast ETRs will need to be configured with the mPITR's
   RLOC addresses so they can send both (S-RLOC,G) joins to build a
   distribution tree to the mPITR as well as for sending unicast oins joins
   to mPITRs so they can propogate (S-EID,G) joins into source multicast
   sites.  The use of mPITRs is undergoing more study and is work in
   progress.

9.1.4.  Unicast LISP Source Site to Any Receiver Sites

   In the last section, it was explained how an ETR in a multicast
   receiver site can determine if a source multicast site is LISP-
   enabled by looking into the mapping database.  When the source
   multicast site is a uLISP site, it is LISP enabled but the ITR, by
   definition is not capable of doing multicast encapsulation.  So for
   the purposes of multicast routing, the uLISP source multicast site is
   treated as non-LISP source multicast site.

   Non-LISP receiver multicast sites can join distribution trees to a
   uLISP source multicast site since the source site behaves, from a
   forwarding perspective, as a non-LISP source site.  This is also the
   case for a uLISP receiver multicast site since the ETR does not have
   multicast functionality built-in or enabled.

   Special considerations are required for LISP receiver multicast sites
   since they think the source multicast site is LISP capable, the ETR
   cannot know if ITR is LISP-Multicast capable.  To solve this problem,
   each mapping database entry will have a multicast 2-tuple (Mpriority,
   Mweight) per RLOC.  When the Mpriority is set to 255, the site is
   considered not multicast capable.  So an ETR in a LISP receiver
   multicast site can distinguish whether a LISP source multicast site
   is LISP-Multicast site from a uLISP site.

9.1.5.  LISP Source Site to Any Receiver Sites

   When a LISP source multicast site has receivers in LISP, non-LISP,
   and uLISP receiver multicast sites, it has a conflict about how it
   sends multicast packets.  The ITR can either encapsulate or natively
   forward multicast packets.  Since the receiver multicast sites are
   heterogeneous in their behavior, one packet forwarding mechanism
   cannot satisfy both.  However, if a LISP receiver multicast site acts
   like a uLISP site then it could receive packets like a non-LISP
   receiver multicast site making all receiver multicast sites have
   homogeneous behavior.  However, this poses the following issues:

   o  LISP-NAT techniques with routable addresses would be required in
      all cases.

   o  Or alternatively, mPETR deployment would be required forcing
      coarse EID prefix advertisement in the core.

   o  But what is most disturbing is that when all sites that
      participate are LISP-Multicast sites but then a non-LISP or uLISP
      site joins the distribution tree, then the existing joined LISP
      receiver multicast sites would have to change their behavior.
      This would create too much dynamic tree-building churn to be a
      viable alternative.

   So the solution space options are:

   1.  Make the LISP ITR in the source multicast site send two packets,
       one that is encapsulated with (S-RLOC,G) to reach LISP receiver
       multicast sites and another that is not encapsulated with
       (S-EID,G) to reach non-LISP and uLISP receiver multicast sites.

   2.  Make the LISP ITR always encapsulate packets with (S-RLOC,G) to
       reach LISP-Multicast sites and to reach mPETRs that can
       decapsulate and forward (S-EID,G) packets to non-LISP and uLISP
       receiver multicast sites.

9.2.  LISP Sites with Mixed Address Families

   A LISP database mapping entry that describes the locator-set,
   Mpriority and Mweight per locator address (RLOC), for an EID prefix
   associated with a site could have RLOC addresses in either IPv4 or
   IPv6 format.  When a mapping entry has a mix of RLOC formatted
   addresses, it is an implicit advertisement by the site that it is a
   dual-stack site.  That is, the site can receive IPv4 or IPv6 unicast
   packets.

   To distinguish if the site can receive dual-stack unicast packets as
   well as dual-stack multicast packets, the Mpriority value setting
   will be relative to an IPv4 or IPv6 RLOC See [LISP] for packet format
   details.

   If you consider the combinations of LISP, non-LISP, and uLISP sites
   sharing the same distribution tree and considering the capabilities
   of supporting IPv4, IPv6, or dual-stack, the number of total
   combinations grows beyond comprehension.

   Using some combinatorial math, we have the following profiles of a
   site and the combinations that can occur:

   1.  LISP-Multicast IPv4 Site

   2.  LISP-Multicast IPv6 Site

   3.  LISP-Multicast Dual-Stack Site

   4.  uLISP IPv4 Site

   5.  uLISP IPv6 Site
   6.  uLISP Dual-Stack Site

   7.  non-LISP IPv4 Site

   8.  non-LISP IPv6 Site

   9.  non-LISP Dual-Stack Site

   Lets define (m n) = m!/(n!*(m-n)!), pronounced "m choose n" to
   illustrate some combinatorial math below.

   When 1 site talks to another site, the combinatorial is (9 2), when 1
   site talks to another 2 sites, the combinatorial is (9 3).  If sum
   this up to (9 9), we have:

   (9 2) + (9 3) + (9 4) + (9 5) + (9 6) + (9 7) + (9 8) + (9 9) =

     36  +   84  +  126  +  126  +   84  +   36  +   9   +   1

   Which results in the total number of cases to be considered at 502.

   This combinatorial gets even worse when you consider a site using one
   address family inside of the site and the xTRs use the other address
   family (as in using IPv4 EIDs with IPv6 RLOCs or IPv6 EIDs with IPv4
   RLOCs).

   To rationalize this combinatorial nightmare, there are some
   guidelines which need to be put in place:

   o  Each distribution tree shared between sites will either be an IPv4
      distribution tree or an IPv6 distribution tree.  Therefore, we can
      avoid head-end replication by building and sending packets on each
      address family based distribution tree.  Even though there might
      be an urge to do multicast packet translation from one address
      family format to the other, it is a non-viable over-complicated
      urge.  Multicast ITRs will only encapsulate packets where the
      inner and outer headers are from the same address family.

   o  All LISP sites on a multicast distribution tree must share a
      common address family which is determined by the source site's
      locator-set in its LISP database mapping entry.  All receiver
      multicast sites will use the best RLOC priority controlled by the
      source multicast site.  This is true when the source site is
      either LISP-Multicast or uLISP capable.  This means that priority-
      based policy modification is prohibited.  When a receiver
      multicast site ETR receives a (S-EID,G) join, it must select a
      S-RLOC for the same address family as S-EID.

   o  A mixed multicast locator-set with the best multicast priority
      values MUST not NOT be configured on multicast ITRs.  A mixed locator-
      set can exist (for unicast use), but the multicast priorities MUST
      be the set for the same address family locators.

   o  When the source site is not LISP capable, it is up to how
      receivers find the source and group information for a multicast
      flow.  That mechanism decides the address family for the flow.

9.3.  Making a Multicast Interworking Decision

   This Multicast Interworking section has shown all combinations of
   multicast connectivity that could occur.  As you might have already
   concluded, this can be quite complicated and if the design is too
   ambitious, the dynamics of the protocol could cause a lot of
   instability.

   The trade-off decisions are hard to make and we want the same single
   solution to work for both IPv4 and IPv6 multicast.  It is imperative
   to have an incrementally deployable solution for all of IPv4 unicast
   and multicast and IPv6 unicast and multicast while minimizing (or
   eliminating) both unicast and multicast EID namespace state.

   Therefore the design decision to go with uPITRs [INTWORK] for unicast
   routing and mPETRs for multicast routing seems to be the sweet spot
   in the solution space so we can optimize state requirements and avoid head-
   end
   head-end data replication at ITRs.

10.  Considerations when RP Addresses are Embedded in Group Addresses

   When ASM and PIM-Bidir is used in an IPv6 inter-domain environment, a
   technique exists to embed the unicast address of an RP in a IPv6
   group address [RFC3956].  When routers in end sites process a PIM
   Join/Prune message which contain an embedded-RP group address, they
   extract the RP address from the group address and treat it from the
   EID namespace.  However, core routers do not have state for the EID
   namespace, need to extract an RP address from the RLOC namespace.

   Therefore, it is the responsibility of ETRs in multicast receiver
   sites to map the group address into a group address where the
   embedded-RP address is from the RLOC namespace.  The mapped RP-
   address is obtained from a EID-to-RLOC mapping database lookup.  The
   ETR will also send a unicast (*,G) Join/Prune message to the ITR so
   the branch of the distribution tree from the source site resident RP
   to the ITR is created.

   This technique is no different than the techniques described in this
   specification for translating (S,G) state and propagating Join/Prune
   messages into the core.  The only difference is that the (*,G) state
   in Join/Prune messages are mapped because they contain unicast
   addresses encoded in an Embedded-RP group address.

11.  Taking Advantage of Upgrades in the Core

   If the core routers are upgraded to support [RPFV] and [RFC5496],
   then we can pass EID specific data through the core without,
   possibly, having to store the state in the core.

   By doing this we can eliminate the ETR from unicast encapsulating PIM
   Join/Prune messages to the source site's ITR.

   However, this solution is restricted to a small set of workable cases
   which would not be good for general use of LISP-Multicast.  In
   addition due to slow convergence properties, it is not being
   recommended for LISP-Multicast.

12.  Mtrace Considerations

   Mtrace functionality must be consistent with unicast traceroute
   functionality where all hops from multicast receiver to multicast
   source are visible.

   The design for mtrace for use in LISP-Multicast environments is to be
   determined but should build upon the mtrace version 2 specified in
   [MTRACE].

13.  Security Considerations

   Refer to the [LISP] specification.

14.  Acknowledgments

   The authors would like to gratefully acknowledge the people who have
   contributed discussion, ideas, and commentary to the making of this
   proposal and specification.  People who provided expert review were
   Scott Brim, Greg Shepherd, and Dave Oran.  Other commentary from
   discussions at Summer 2008 Dublin IETF were Toerless Eckert and
   Ijsbrand Wijnands.

   We would also like to thank the MBONED working group for constructive
   and civil verbal feedback when this draft was presented at the Fall
   2008 IETF in Minneapolis.  In particular, good commentary came from
   Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou,
   Ron Bonica, and Lenny Guardino. Guardino, Alia Atlas, and Jesus Arango.

   An expert review of this specification was done by Yiqun Cai and
   Liming Wei. We thank them for their detailed comments.

   This work originated in the Routing Research Group (RRG) of the IRTF.
   The individual submission [MLISP] was converted into this IETF LISP
   working group draft.

15.  References

15.1.  Normative References

   [LISP]     Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-13.txt (work in progress), June 2011.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3618]  Fenner, B. and D. Meyer, "Multicast Source Discovery
              Protocol (MSDP)", RFC 3618, October 2003.

   [RFC3956]  Savola, P. and B. Haberman, "Embedding the Rendezvous
              Point (RP) Address in an IPv6 Multicast Address",
              RFC 3956, November 2004.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC4604]  Holbrook, H., Cain, B., and B. Haberman, "Using Internet
              Group Management Protocol Version 3 (IGMPv3) and Multicast
              Listener Discovery Protocol Version 2 (MLDv2) for Source-
              Specific Multicast", RFC 4604, August 2006.

   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, August 2006.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              January 2007.

   [RFC5015]  Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
              "Bidirectional Protocol Independent Multicast (BIDIR-
              PIM)", RFC 5015, October 2007.

   [RFC5496]  Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
              Forwarding (RPF) Vector TLV", RFC 5496, March 2009.

15.2.  Informative References

   [ALT]      Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative
              Topology (LISP-ALT)", draft-ietf-lisp-alt-06.txt (work in
              progress), March 2011.

   [INTWORK]  Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP
              with IPv4 and IPv6", draft-ietf-lisp-interworking-01.txt draft-ietf-lisp-interworking-02.txt
              (work in progress), March 2010.

   [LISP]     Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-12.txt (work in progress), April 2011.

   [MLISP]    Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
              "LISP for Multicast Environments",
              draft-farinacci-lisp-multicast-01.txt (work in progress),
              November 2008.

   [MNAT]     Wing, D. and T. Eckert, "Multicast Requirements for a
              Network Address (and  port) Translator (NAT)",
              draft-ietf-behave-multicast-07.txt (work in progress),
              June 2007.

   [MTRACE]   Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace
              Version 2: Traceroute Facility for IP Multicast",
              draft-ietf-mboned-mtrace-v2-03.txt (work in progress),
              March 2009.

   [RPFV]     Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector
              TLV", draft-ietf-pim-rpf-vector-06.txt (work in progress),
              February 2008.

Appendix A.  Document Change Log

A.1.  Changes to draft-ietf-lisp-multicast-06.txt

   o  Posted June 2011 to complete working group last call.

   o  Added paragraph to section 8.1.2 based on Jesus comment about
      making it more clear what happens when two (S-EID,G) trees use the
      same (RLOC,G) tree.

   o  Make more references to [INTWORK] when mentioning uPITRs and
      uPETRs.

   o  Made many changes based on editorial and wordsmithing comments
      from Alia.

A.2.  Changes to draft-ietf-lisp-multicast-05.txt

   o  Posted April 2011 to reset expiration timer.

   o  Updated references.

A.2.

A.3.  Changes to draft-ietf-lisp-multicast-04.txt

   o  Posted October 2010 to reset expiration timer.

   o  Updated references.

A.3.

A.4.  Changes to draft-ietf-lisp-multicast-03.txt

   o  Posted April 2010.

   o  Added section 8.1.2 to address Joel Halpern's comment about
      receiver sites joining the same source site via 2 different RLOCs,
      each being a separate ITR.

   o  Change all occurences of "mPTR" to "mPETR" to become more
      consistent with uPITRs and uPETRs described in [INTWORK].  That
      is, an mPETR is a LISP multicast router that decapsulates
      multicast packets that are encapsulated to it by ITRs in multicast
      source sites.

   o  Add clarifications in section 9 about how homogeneous multicast
      encapsulation should occur.  As well as describing in this
      section, how to deal with mixed-locator sets to avoid
      heterogeneous encapsulation.

   o  Introduce concept of mPITRs to help reduce (S-EID,G) to the edges
      of LISP global multicast network.

A.4.

A.5.  Changes to draft-ietf-lisp-multicast-02.txt

   o  Posted September 2009.

   o  Added Document Change Log appendix.

   o  Specify that the LISP Encapsulated Control Message be used for
      unicasting PIM Join/Prune messages from ETRs to ITRs.

A.5.

A.6.  Changes to draft-ietf-lisp-multicast-01.txt

   o  Posted November 2008.

   o  Specified that PIM Join/Prune unicast messages that get sent from
      ETRs to ITRs of a source multicast site get LISP encapsulated in
      destination UDP port 4342.

   o  Add multiple RLOCs per ITR per Yiqun's comments.

   o  Indicate how static RPs can be used when LISP is run using Bidir-
      PIM in the core.

   o  Editorial changes per Liming comments.

   o  Add Mttrace Considersations section.

A.6.

A.7.  Changes to draft-ietf-lisp-multicast-00.txt

   o  Posted April 2008.

   o  Renamed from draft-farinacci-lisp-multicast-01.txt.

Authors' Addresses

   Dino Farinacci
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: dino@cisco.com

   Dave Meyer
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: dmm@cisco.com

   John Zwiebel
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: jzwiebel@cisco.com

   Stig Venaas
   cisco Systems
   Tasman Drive
   San Jose, CA
   USA

   Email: stig@cisco.com
--Apple-Mail-3--328112272 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-3--328112272 Content-Disposition: attachment; filename=draft-ietf-lisp-multicast-06.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-multicast-06.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft D. Meyer Intended status: Experimental J. Zwiebel Expires: December 22, 2011 S. Venaas cisco Systems June 20, 2011 LISP for Multicast Environments draft-ietf-lisp-multicast-06 Abstract This draft describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the LISP architecture. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 22, 2011. Copyright Notice Copyright (c) 2011 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 Farinacci, et al. Expires December 22, 2011 [Page 1] =0C Internet-Draft LISP for Multicast Environments June 2011 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 BSD License. Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 7 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Source Addresses versus Group Addresses . . . . . . . . . . . 13 6. Locator Reachability Implications on LISP-Multicast . . . . . 14 7. Multicast Protocol Changes . . . . . . . . . . . . . . . . . . 15 8. LISP-Multicast Data-Plane Architecture . . . . . . . . . . . . 17 8.1. ITR Forwarding Procedure . . . . . . . . . . . . . . . . . 17 8.1.1. Multiple RLOCs for an ITR . . . . . . . . . . . . . . 17 8.1.2. Multiple ITRs for a LISP Source Site . . . . . . . . . 18 8.2. ETR Forwarding Procedure . . . . . . . . . . . . . . . . . 18 8.3. Replication Locations . . . . . . . . . . . . . . . . . . 19 9. LISP-Multicast Interworking . . . . . . . . . . . . . . . . . 20 9.1. LISP and non-LISP Mixed Sites . . . . . . . . . . . . . . 20 9.1.1. LISP Source Site to non-LISP Receiver Sites . . . . . 21 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites . . . 22 9.1.3. Non-LISP Source Site to Any Receiver Site . . . . . . 23 9.1.4. Unicast LISP Source Site to Any Receiver Sites . . . . 24 9.1.5. LISP Source Site to Any Receiver Sites . . . . . . . . 24 9.2. LISP Sites with Mixed Address Families . . . . . . . . . . 25 9.3. Making a Multicast Interworking Decision . . . . . . . . . 27 10. Considerations when RP Addresses are Embedded in Group Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 28 11. Taking Advantage of Upgrades in the Core . . . . . . . . . . . 29 12. Mtrace Considerations . . . . . . . . . . . . . . . . . . . . 30 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 15.1. Normative References . . . . . . . . . . . . . . . . . . . 33 15.2. Informative References . . . . . . . . . . . . . . . . . . 33 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 35 A.1. Changes to draft-ietf-lisp-multicast-06.txt . . . . . . . 35 A.2. Changes to draft-ietf-lisp-multicast-05.txt . . . . . . . 35 A.3. Changes to draft-ietf-lisp-multicast-04.txt . . . . . . . 35 A.4. Changes to draft-ietf-lisp-multicast-03.txt . . . . . . . 35 A.5. Changes to draft-ietf-lisp-multicast-02.txt . . . . . . . 36 A.6. Changes to draft-ietf-lisp-multicast-01.txt . . . . . . . 36 Farinacci, et al. Expires December 22, 2011 [Page 2] =0C Internet-Draft LISP for Multicast Environments June 2011 A.7. Changes to draft-ietf-lisp-multicast-00.txt . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 Farinacci, et al. Expires December 22, 2011 [Page 3] =0C Internet-Draft LISP for Multicast Environments June 2011 1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Farinacci, et al. Expires December 22, 2011 [Page 4] =0C Internet-Draft LISP for Multicast Environments June 2011 2. Introduction The Locator/ID Separation Architecture [LISP] provides a mechanism to separate out Identification and Location semantics from the current definition of an IP address. By creating two namespaces, an EID namespace used by sites and a Locator (RLOC) namespace used by core routing, the core routing infrastructure can scale by doing topological aggregation of routing information. Since LISP creates a new namespace, a mapping function must exist to map a site's EID prefixes to its associated locators. For unicast packets, both the source address and destination address must be mapped. For multicast packets, only the source address needs to be mapped. The destination group address doesn't need to be mapped because the semantics of an IPv4 or IPv6 group address are logical in nature and not topology-dependent. Therefore, this specifications focuses on to map a source EID address of a multicast flow during distribution tree setup and packet delivery. This specification will address the following scenarios: 1. How a multicast source host in a LISP site sends multicast packets to receivers inside of its site as well as to receivers in other sites that are LISP enabled. 2. How inter-domain (or between LISP sites) multicast distribution trees are built and how forwarding of multicast packets leaving a source site toward receivers sites is performed. 3. What protocols are affected and what changes are required to such multicast protocols. 4. How ASM-mode, SSM-mode, and Bidir-mode service models will operate. 5. How multicast packet flow will occur for multiple combinations of LISP and non-LISP capable source and receiver sites, for example: A. How multicast packets from a source host in a LISP site are sent to receivers in other sites when they are all non-LISP sites. B. How multicast packets from a source host in a LISP site are sent to receivers in both LISP-enabled sites and non-LISP sites. C. How multicast packets from a source host in a non-LISP site are sent to receivers in other sites when they are all LISP- Farinacci, et al. Expires December 22, 2011 [Page 5] =0C Internet-Draft LISP for Multicast Environments June 2011 enabled sites. D. How multicast packets from a source host in a non-LISP site are sent to receivers in both LISP-enabled sites and non-LISP sites. This specification focuses on what changes are needed to the multicast routing protocols to support LISP-Multicast as well as other protocols used for inter-domain multicast, such as Multi- protocol BGP (MBGP) [RFC4760]. The approach proposed in this specification requires no changes to the multicast infrastructure inside of a site when all sources and receivers reside in that site, even when the site is LISP enabled. That is, internal operation of multicast is unchanged regardless of whether or not the site is LISP enabled or whether or not receivers exist in other sites which are LISP-enabled. Therefore, we see changes only to PIM-ASM [RFC4601], MSDP [RFC3618], and PIM-SSM [RFC4607]. Bidir-PIM [RFC5015], which typically does not run in an inter-domain environment is not addressed in depth in this version of the specification. Also, the current version of this specification does not describe multicast-based Traffic Engineering relative to the TE-ITR and TE-ETR descriptions in [LISP]. Farinacci, et al. Expires December 22, 2011 [Page 6] =0C Internet-Draft LISP for Multicast Environments June 2011 3. Definition of Terms The terminology in this section is consistent with the definitions in [LISP] but is extended specifically to deal with the application of the terminology to multicast routing. LISP-Multicast: a reference to the design in this specification. That is, when any site that is participating in multicast communication has been upgraded to be a LISP site, the operation of control-plane and data-plane protocols is considered part of the LISP-Multicast architecture. Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source address field of the first (most inner) LISP header of a multicast packet. The host obtains a destination group address the same way it obtains one today, as it would when it is a non-LISP site. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID is allocated to a host from an EID prefix block associated with the site the host is located in. An EID can be used by a host to refer to another host, as when it joins an SSM (S-EID,G) route using IGMP version 3 [RFC4604]. LISP uses Provider Independent (PI) blocks for EIDs; such EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be assigned in a hierarchical manner, independent of the network topology, to facilitate scaling of the mapping database. In addition, an EID block assigned to a site may have site-local structure (subnetting) for routing within the site; this structure is not visible to the global routing system. Routing Locator (RLOC): the IPv4 or IPv6 address of an ingress tunnel router (ITR), the router in the multicast source host's site that encapsulates multicast packets. It is the output of a EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically-aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as Provider Assigned (PA) addresses. Multiple RLOCs can be assigned to the same ITR device or to multiple ITR devices at a site. Ingress Tunnel Router (ITR): a router which accepts an IP multicast packet with a single IP header (more precisely, an IP packet that does not contain a LISP header). The router treats this "inner" IP destination multicast address opaquely so it doesn't need to perform a map lookup on the group address because it is topologically insignificant. The router then prepends an "outer" IP header with one of its globally-routable RLOCs as the source address field. This RLOC is known to other multicast receiver Farinacci, et al. Expires December 22, 2011 [Page 7] =0C Internet-Draft LISP for Multicast Environments June 2011 sites which have used the mapping database to join a multicast tree for which the ITR is the root. In general, an ITR receives IP packets from site end systems on one side and sends LISP- encapsulated multicast IP packets out all external interfaces which have been joined. An ITR would receive a multicast packet from a source inside of its site when 1) it is on the path from the multicast source to internally joined receivers, or 2) when it is on the path from the multicast source to externally joined receivers. Egress Tunnel Router (ETR): a router that is on the path from a multicast source host in another site to a multicast receiver in its own site. An ETR accepts a PIM Join/Prune message from a site internal PIM router destined for the source's EID in the multicast source site. The ETR maps the source EID in the Join/Prune message to an RLOC address based on the EID-to-RLOC mapping. This sets up the ETR to accept multicast encapsulated packets from the ITR in the source multicast site. A multicast ETR decapsulates multicast encapsulated packets and replicates them on interfaces leading to internal receivers. xTR: is a reference to an ITR or ETR when direction of data flow is not part of the context description. xTR refers to the router that is the tunnel endpoint. Used synonymously with the term "Tunnel Router". For example, "An xTR can be located at the Customer Edge (CE) router", meaning both ITR and ETR functionality can be at the CE router. LISP Header: a term used in this document to refer to the outer IPv4 or IPv6 header, a UDP header, and a LISP header. An ITR prepends headers and an ETR strips headers. A LISP encapsulated multicast packet will have an "inner" header with the source EID in the source field; an "outer" header with the source RLOC in the source field: and the same globally unique group address in the destination field of both the inner and outer header. (S,G) State: the formal definition is in the PIM Sparse Mode [RFC4601] specification. For this specification, the term is used generally to refer to multicast state. Based on its topological location, the (S,G) state resides in routers can be either (S-EID,G) state (at a location where the (S,G) state resides) or (S-RLOC,G) state (in the Internet core). (S-EID,G) State: refers to multicast state in multicast source and receiver sites where S-EID is the IP address of the multicast source host (its EID). An S-EID can appear in an IGMPv3 report, an MSDP SA message or a PIM Join/Prune message that travels inside Farinacci, et al. Expires December 22, 2011 [Page 8] =0C Internet-Draft LISP for Multicast Environments June 2011 of a site. (S-RLOC,G) State: refers to multicast state in the core where S is a source locator (the IP address of a multicast ITR) of a site with a multicast source. The (S-RLOC,G) is mapped from (S-EID,G) entry by doing a mapping database lookup for the EID prefix that S-EID maps to. An S-RLOC can appear in a PIM Join/Prune message when it travels from an ETR to an ITR over the Internet core. uLISP Site: a unicast only LISP site according to [LISP] which has not deployed the procedures of this specification and therefore, for multicast purposes, follows the procedures from Section 9. mPETR: this is a multicast proxy-ETR that is responsible for advertising a very coarse EID prefix which non-LISP and uLISP sites can target their (S-EID,G) PIM Join/Prune message to. mPETRs are used so LISP source multicast sites can send multicast packets using source addresses from the EID namespace. mPETRs act as Proxy ETRs for supporting multicast routing in a LISP infrastructure. It is likely an uPITR [INTWORK] and a mPETR will be co-located since the single device advertises a coarse EID-prefix in the underlying unicast routing system. Mixed Locator-Sets: this is a locator-set for a LISP database mapping entry where the RLOC addresses in the locator-set are in both IPv4 and IPv6 format. Unicast Encapsulated PIM Join/Prune Message: this is a standard PIM Join/Prune message (encapsulated in a LISP Encapsulated Control Message with destination UDP port 4342) which is sent by ETRs at multicast receiver sites to an ITR at a multicast source site. This message is sent periodically as long as there are interfaces in the oif-list for the (S-EID,G) entry the ETR is joining for. Farinacci, et al. Expires December 22, 2011 [Page 9] =0C Internet-Draft LISP for Multicast Environments June 2011 4. Basic Overview LISP, when used for unicast routing, increases the site's ability to control ingress traffic flows. Egress traffic flows are controlled by the IGP in the source site. For multicast, the IGP coupled with PIM can decide which path multicast packets ingress. By using the traffic engineering features of LISP, a multicast source site can control the egress of its multicast traffic. By controlling the priorities of locators from a mapping database entry, a source multicast site can control which way multicast receiver sites join to the source site. At this point in time, we don't see a requirement for different locator-sets, priority, and weight policies for multicast than we have for unicast. However, when traffic engineering policies are different for unicast versus multicast flows, it will be desirable to use multicast-based priority and weight values in Map-Reply messages. The fundamental multicast forwarding model is to encapsulate a multicast packet into another multicast packet. An ITR will encapsulate multicast packets received from sources that it serves in another LISP multicast header. The destination group address from the inner header is copied to the destination address of the outer header. The inner source address is the EID of the multicast source host and the outer source address is the RLOC of the encapsulating ITR. The LISP-Multicast architecture will follow this high-level protocol and operational sequence: 1. Receiver hosts in multicast sites will join multicast content the way they do today, they use IGMP. When they use IGMPv3 where they specify source addresses, they use source EIDs, that is they join (S-EID,G). If the multicast source is external to this receiver site, the PIM Join/Prune message flows toward the ETRs, finding the shortest exit (that is the closest exit for the Join/ Prune message and the closest entrance for the multicast packet to the receiver). 2. The ETR does a mapping database lookup for S-EID. If the mapping is cached from a previous lookup (from either a previous Join/ Prune for the source multicast site or a unicast packet that went to the site), it will use the RLOC information from the mapping. The ETR will use the same priority and weighting mechanism as for unicast. So the source site can decide which way multicast packets egress. Farinacci, et al. Expires December 22, 2011 [Page 10] =0C Internet-Draft LISP for Multicast Environments June 2011 3. The ETR will build two PIM Join/Prune messages, one that contains a (S-EID,G) entry that is unicast to the ITR that matches the RLOC the ETR selects, and the other which contains a (S-RLOC,G) entry so the core network can create multicast state from this ETR to the ITR. 4. When the ITR gets the unicast Join/Prune message (see Section 3 for formal definition), it will process (S-EID,G) entries in the message and propagate them inside of the site where it has explicit routing information for EIDs via the IGP. When the ITR receives the (S-RLOC,G) PIM Join/Prune message it will process it like any other join it would get in today's Internet. The S-RLOC address is the IP address of this ITR. 5. At this point there is (S-EID,G) state from the joining host in the receiver multicast site to the ETR of the receiver multicast site. There is (S-RLOC,G) state across the core network from the ETR of the multicast receiver site to the ITR in the multicast source site and (S-EID,G) state in the source multicast site. Note, the (S-EID,G) state is the same S-EID in each multicast site. As other ETRs join the same multicast tree, they can join through the same ITR (in which case the packet replication is done in the core) or a different ITR (in which case the packet replication is done at the source site). 6. When a packet is originated by the multicast host in the source site, it will flow to one or more ITRs which will prepend a LISP header by copying the group address to the outer destination address field and insert its own locator address in the outer source address field. The ITR will look at its (S-RLOC,G) state, where S-RLOC is its own locator address, and replicate the packet on each interface a (S-RLOC,G) joined was received on. The core has (S-RLOC,G) so where fanout occurs to multiple sites, a core router will do packet replication. 7. When either the source site or the core replicates the packet, the ETR will receive a LISP packet with a destination group address. It will decapsulate packets because it has receivers for the group. Otherwise, it would have not received the packets because it would not have joined. The ETR decapsulates and does a (S-EID,G) lookup in its multicast FIB to forward packets out one or more interfaces to forward the packet to internal receivers. This architecture is consistent and scalable with the architecture presented in [LISP] where multicast state in the core operates on locators and multicast state at the sites operates on EIDs. Farinacci, et al. Expires December 22, 2011 [Page 11] =0C Internet-Draft LISP for Multicast Environments June 2011 Alternatively, [LISP] also has a mechanism where (S-EID,G) state can reside in the core through the use of RPF-vectors [RPFV] in PIM Join/ Prune messages. However, few PIM implementations support RPF vectors and LISP should avoid S-EID state in the core. See Section 5 for details. However, we have some observations on the algorithm above. We can scale the control plane but at the expense of sending data to sites which may have not joined the distribution tree where the encapsulated data is being delivered. For example, one site joins (S-EID1,G) and another site joins (S-EID2,G). Both EIDs are in the same multicast source site. Both multicast receiver sites join to the same ITR with state (S-RLOC,G) where S-RLOC is the RLOC for the ITR. The ITR joins both (S-EID1,G) and (S-EID2,G) inside of the site. The ITR receives (S-RLOC,G) joins and populates the oif-list state for it. Since both (S-EID1,G) and (S-EID2, G) map to the one (S-RLOC,G) packets will be delivered by the core to both multicast receiver sites even though each have joined a single source-based distribution tree. This behavior is a consequence of the many-to-one mapping between S-EIDs and a S-RLOC. There is a possible solution to this problem which reduces the number of many-to-one occurrences of (S-EID,G) entries aggregating into a single (S-RLOC,G) entry. If a physical ITR can be assigned multiple RLOC addresses and these addresses are advertised in mapping database entries, then ETRs at receiver sites have more RLOC address options and therefore can join different (RLOC,G) entries for each (S-EID,G) entry joined at the receiver site. It would not scale to have a one- to-one relationship between the number of S-EID sources at a source site and the number of RLOCs assigned to all ITRs at the site, but we can reduce the "n" to a smaller number in the "n-to-1" relationship. And in turn, reduce the opportunity for data packets to be delivered to sites for groups not joined. Farinacci, et al. Expires December 22, 2011 [Page 12] =0C Internet-Draft LISP for Multicast Environments June 2011 5. Source Addresses versus Group Addresses Multicast group addresses don't have to be associated with either the EID or RLOC namespace. They actually are a namespace of their own that can be treated as logical with relatively opaque allocation. So, by their nature, they don't detract from an incremental deployment of LISP-Multicast. As for source addresses, as in the unicast LISP scenario, there is a decoupling of identification from location. In a LISP site, packets are originated from hosts using their allocated EIDs, those addresses are used to identify the host as well as where in the site's topology the host resides but not how and where it is attached to the Internet. Therefore, when multicast distribution tree state is created anywhere in the network on the path from any multicast receiver to a multicast source, EID state is maintained at the source and receiver multicast sites, and RLOC state is maintained in the core. That is, a multicast distribution tree will be represented as a 3-tuple of {(S-EID,G) (S-RLOC,G) (S-EID,G)} where the first element of the 3-tuple is the state stored in routers from the source to one or more ITRs in the source multicast site, the second element of the 3-tuple is the state stored in routers downstream of the ITR, in the core, to all LISP receiver multicast sites, and the third element in the 3-tuple is the state stored in the routers downstream of each ETR, in each receiver multicast site, reaching each receiver. Note that (S-EID,G) is the same in both the source and receiver multicast sites. The concatenation/mapping from the first element to the second element of the 3-tuples is done by the ITR and from the second element to the third element is done at the ETRs. Farinacci, et al. Expires December 22, 2011 [Page 13] =0C Internet-Draft LISP for Multicast Environments June 2011 6. Locator Reachability Implications on LISP-Multicast Multicast state as it is stored in the core is always (S,G) state as it exists today or (S-RLOC,G) state as it will exist when LISP sites are deployed. The core routers cannot distinguish one from the other. They don't need to because it is state that RPFs against the core routing tables in the RLOC namespace. The difference is where the root of the distribution tree for a particular source is. In the traditional multicast core, the source S is the source host's IP address. For LISP-Multicast the source S is a single ITR of the multicast source site. An ITR is selected based on the LISP EID-to-RLOC mapping used when an ETR propagates a PIM Join/Prune message out of a receiver multicast site. The selection is based on the same algorithm an ITR would use to select an ETR when sending a unicast packet to the site. In the unicast case, the ITR can change on a per-packet basis depending on the reachability of the ETR. So an ITR can change relatively easily using local reachability state. However, in the multicast case, when an ITR goes unreachable, new distribution tree state must be built because the encapsulating root has changed. This is more significant than an RPF-change event, where any router would typically locally change its RPF-interface for its existing tree state. But when an encapsulating LISP-Multicast ITR goes unreachable, new distribution state must be rebuilt and reflect the new encapsulator. Therefore, when an ITR goes unreachable, all ETRs that are currently joined to that ITR will have to trigger a new Join/Prune message for (S-RLOC,G) to the new ITR as well as send a unicast encapsulated Join/Prune message telling the new ITR which (S-EID,G) is being joined. This issue can be mitigated by using anycast addressing for the ITRs so the problem does reduce to an RPF change in the core, but still requires a unicast encapsulated Join/Prune message to tell the new ITR about (S-EID,G). The problem with this approach is that the ETR really doesn't know when the ITR has changed so the new anycast ITR will get the (S-EID,G) state only when the ETR sends it the next time during its periodic sending procedures. Farinacci, et al. Expires December 22, 2011 [Page 14] =0C Internet-Draft LISP for Multicast Environments June 2011 7. Multicast Protocol Changes A number of protocols are used today for inter-domain multicast routing: IGMPv1-v3, MLDv1-v2: These protocols do not require any changes for LISP-Multicast for two reasons. One being that they are link- local and not used over site boundaries and second they advertise group addresses that don't need translation. Where source addresses are supplied in IGMPv3 and MLDv2 messages, they are semantically regarded as EIDs and don't need to be converted to RLOCs until the multicast tree-building protocol, such as PIM, is received by the ETR at the site boundary. Addresses used for IGMP and MLD come out of the source site's allocated addresses which are therefore from the EID namespace. MBGP: Even though MBGP is not a multicast routing protocol, it is used to find multicast sources when the unicast BGP peering topology and the multicast MBGP peering topology are not congruent. When MBGP is used in a LISP-Multicast environment, the prefixes which are advertised are from the RLOC namespace. This allows receiver multicast sites to find a path to the source multicast site's ITRs. MBGP peering addresses will be from the RLOC namespace. MSDP: MSDP is used to announce active multicast sources to other routing domains (or LISP sites). The announcements come from the PIM Rendezvous Points (RPs) from sites where there are active multicast sources sending to various groups. In the context of LISP-Multicast, the source addresses advertised in MSDP will semantically be from the EID namespace since they describe the identity of a source multicast host. It will be true that the state stored in MSDP caches from core routers will be from the EID namespace. An RP address inside of site will be from the EID namespace so it can be advertised and reached by internal unicast routing mechanism. However, for MSDP peer-RPF checking to work properly across sites, the RP addresses must be converted or mapped into a routable address that is advertised and maintained in the BGP routing tables in the core. MSDP peering addresses can come out of either the EID or a routable address namespace. And the choice can be made unilaterally because the ITR at the site will determine which namespace the destination peer address is out of by looking in the mapping database service. PIM-SSM: In the simplest form of distribution tree building, when PIM operates in SSM mode, a source distribution tree is built and maintained across site boundaries. In this case, there is a small modification to the operation of the PIM protocol (but not to any Farinacci, et al. Expires December 22, 2011 [Page 15] =0C Internet-Draft LISP for Multicast Environments June 2011 message format) to support taking a Join/Prune message originated inside of a LISP site with embedded addresses from the EID namespace and converting them to addresses from the RLOC namespace when the Join/Prune message crosses a site boundary. This is similar to the requirements documented in [MNAT]. PIM-Bidir: Bidirectional PIM is typically run inside of a routing domain, but if deployed in an inter-domain environment, one would have to decide if the RP address of the shared-tree would be from the EID namespace or the RLOC namespace. If the RP resides in a site-based router, then the RP address is from the EID namespace. If the RP resides in the core where RLOC addresses are routed, then the RP address is from the RLOC namespace. This could be easily distinguishable if the EID address were well-known address allocation block from the RLOC namespace. Also, when using Embedded-RP for RP determination [RFC3956], the format of the group address could indicate the namespace the RP address is from. However, refer to Section 10 for considerations core routers need to make when using Embedded-RP IPv6 group addresses. When using Bidir-PIM for inter-domain multicast routing, it is recommended to use staticly configured RPs so core routers think the Bidir group is associated with an ITR's RLOC as the RP address and site routers think the Bidir group is associated with the site resident RP with an EID address. With respect to DF-election in Bidir PIM, no changes are required since all messaging and addressing is link-local. PIM-ASM: The ASM mode of PIM, the most popular form of PIM, is deployed in the Internet today is by having shared-trees within a site and using source-trees across sites. By the use of MSDP and PIM-SSM techniques described above, we can get multicast connectivity across LISP sites. Having said that, that means there are no special actions required for processing (*,G) or (S,G,R) Join/Prune messages since they all operate against the shared-tree which is site resident. Just like with ASM, there is no (*,G) in the core when LISP-Multicast is in use. This is also true for the RP-mapping mechanisms Auto-RP and BSR. Based on the protocol description above, the conclusion is that there are no protocol message format changes, just a translation function performed at the control-plane. This will make for an easier and faster transition for LISP since fewer components in the network have to change. It should also be stated just like it is in [LISP] that no host changes, whatsoever, are required to have a multicast source host send multicast packets and for a multicast receiver host to receive multicast packets. Farinacci, et al. Expires December 22, 2011 [Page 16] =0C Internet-Draft LISP for Multicast Environments June 2011 8. LISP-Multicast Data-Plane Architecture The LISP-Multicast data-plane operation conforms to the operation and packet formats specified in [LISP]. However, encapsulating a multicast packet from an ITR is a much simpler process. The process is simply to copy the inner group address to the outer destination address. And to have the ITR use its own IP address (its RLOC), and as the source address. The process is simpler for multicast because there is no EID-to-RLOC mapping lookup performed during packet forwarding. In the decapsulation case, the ETR simply removes the outer header and performs a multicast routing table lookup on the inner header (S-EID,G) addresses. Then the oif-list for the (S-EID,G) entry is used to replicate the packet on site-facing interfaces leading to multicast receiver hosts. There is no Data-Probe logic for ETRs as there can be in the unicast forwarding case. 8.1. ITR Forwarding Procedure The following procedure is used by an ITR, when it receives a multicast packet from a source inside of its site: 1. A multicast data packet sent by a host in a LISP site will have the source address equal to the host's EID and the destination address equal to the group address of the multicast group. It is assumed the group information is obtained by current methods. The same is true for a multicast receiver to obtain the source and group address of a multicast flow. 2. When the ITR receives a multicast packet, it will have both S-EID state and S-RLOC state stored. Since the packet was received on a site-facing interface, the RPF lookup is based on the S-EID state. If the RPF check succeeds, then the oif-list contains interfaces that are site-facing and external-facing. For the site-facing interfaces, no LISP header is prepended. For the external-facing interfaces a LISP header is prepended. When the ITR prepends a LISP header, it uses its own RLOC address as the source address and copies the group address supplied by the IP header the host built as the outer destination address. 8.1.1. Multiple RLOCs for an ITR Typically, an ITR will have a single RLOC address but in some cases there could be multiple RLOC addresses assigned from either the same or different service providers. In this case when (S-RLOC,G) Join/ Farinacci, et al. Expires December 22, 2011 [Page 17] =0C Internet-Draft LISP for Multicast Environments June 2011 Prune messages are received for each RLOC, there is a oif-list merging action that must take place. Therefore, when a packet is received from a site-facing interface that matches on a (S-EID,G) entry, the interfaces of the oif-list from all (RLOC,G) entries joined to the ITR as well as the site-facing oif-list joined for (S-EID,G) must be part be included in packet replication. In addition to replicating for all types of oif-lists, each oif entry must be tagged with the RLOC address, so encapsulation uses the outer source address for the RLOC joined. 8.1.2. Multiple ITRs for a LISP Source Site Note when ETRs from different multicast receiver sites receive (S-EID,G) joins, they may select a different S-RLOC for a multicast source site due to policy (the multicast ITR can return different multicast priority and weight values per ETR Map-Request). In this case, the same (S-EID,G) is being realized by different (S-RLOC,G) state in the core. This will not result in duplicate packets because each ITR in the multicast source site will choose their own RLOC for the source address for encapsulated multicast traffic. The RLOC addresses are the ones joined by remote multicast ETRs. When different (S-EID,G) traffic is combined into a single (RLOC,G) core distribution tree, this may cause traffic to go to a receiver multicast site when it does not need to. This happens when one receiver multicast site joins (S1-EID,Gi) through a core distribution tree of (RLOC1,Gi) and another multicast receiver site joins (S2- EID,Gi) through the same core distribution tree of (RLOC1,Gi). When ETRs decapsulate such traffic, they should know from their local (S-EID,G) state if the packet should be forwarded. If there is no (S-EID,G) state that matches the inner packet header, the packet is discarded. 8.2. ETR Forwarding Procedure The following procedure is used by an ETR, when it receives a multicast packet from a source outside of its site: 1. When a multicast data packet is received by an ETR on an external-facing interface, it will do an RPF lookup on the S-RLOC state it has stored. If the RPF check succeeds, the interfaces from the oif-list are used for replication to interfaces that are site-facing as well as interfaces that are external-facing (this ETR can also be a transit multicast router for receivers outside of its site). When the packet is to be replicated for an external-facing interface, the LISP encapsulation header are not stripped. When the packet is replicated for a site-facing interface, the encapsulation header is stripped. Farinacci, et al. Expires December 22, 2011 [Page 18] =0C Internet-Draft LISP for Multicast Environments June 2011 2. The packet without a LISP header is now forwarded down the (S-EID,G) distribution tree in the receiver multicast site. 8.3. Replication Locations Multicast packet replication can happen in the following topological locations: o In an IGP multicast router inside a site which operates on S-EIDs. o In a transit multicast router inside of the core which operates on S-RLOCs. o At one or more ETR routers depending on the path a Join/Prune message exits a receiver multicast site. o At one or more ITR routers in a source multicast site depending on what priorities are returned in a Map-Reply to receiver multicast sites. In the last case the source multicast site can do replication rather than having a single exit from the site. But this only can occur when the priorities in the Map-Reply are modified for different receiver multicast site so that the PIM Join/Prune messages arrive at different ITRs. This policy technique, also used in [ALT] for unicast, is useful for multicast to mitigate the problems of changing distribution tree state as discussed in Section 6. Farinacci, et al. Expires December 22, 2011 [Page 19] =0C Internet-Draft LISP for Multicast Environments June 2011 9. LISP-Multicast Interworking This section will describe the multicast corollary to [INTWORK] which describes the interworking of multicast routing among LISP and non- LISP sites. 9.1. LISP and non-LISP Mixed Sites Since multicast communication can involve more than two entities to communicate together, the combinations of interworking scenarios are more involved. However, the state maintained for distribution trees at the sites is the same regardless of whether or not the site is LISP enabled or not. So most of the implications are in the core with respect to storing routable EID prefixes from either PA or PI blocks. Before we enumerate the multicast interworking scenarios, we must define 3 deployment states of a site: o A non-LISP site which will run PIM-SSM or PIM-ASM with MSDP as it does today. The addresses for the site are globally routable. o A site that deploys LISP for unicast routing. The addresses for the site are not globally routable. Let's define the name for this type of site as a uLISP site. o A site that deploys LISP for both unicast and multicast routing. The addresses for the site are not globally routable. Let's define the name for this type of site as a LISP-Multicast site. We will not consider a LISP site enabled for multicast purposes only but do consider a uLISP site as documented in [INTWORK]. In this section we don't discuss how a LISP site sends multicast packets when all receiver sites are LISP-Multicast enabled; that has been discussed in previous sections. The following scenarios exist to make LISP-Multicast sites interwork with non-LISP-Multicast sites: 1. A LISP site must be able to send multicast packets to receiver sites which are a mix of non-LISP sites and uLISP sites. 2. A non-LISP site must be able to send multicast packets to receiver sites which are a mix of non-LISP sites and uLISP sites. 3. A non-LISP site must be able to send multicast packets to receiver sites which are a mix of LISP sites, uLISP sites, and non-LISP sites. Farinacci, et al. Expires December 22, 2011 [Page 20] =0C Internet-Draft LISP for Multicast Environments June 2011 4. A uLISP site must be able to send multicast packets to receiver sites which are a mix of LISP sites, uLISP sites, and non-LISP sites. 5. A LISP site must be able to send multicast packets to receiver sites which are a mix of LISP sites, uLISP sites, and non-LISP sites. 9.1.1. LISP Source Site to non-LISP Receiver Sites In the first scenario, a site is LISP capable for both unicast and multicast traffic and as such operates on EIDs. Therefore there is a possibility that the EID prefix block is not routable in the core. For LISP receiver multicast sites this isn't a problem but for non- LISP or uLISP receiver multicast sites, when a PIM Join/Prune message is received by the edge router, it has no route to propagate the Join/Prune message out of the site. This is no different than the unicast case that LISP-NAT in [INTWORK] solves. LISP-NAT allows a unicast packet that exits a LISP site to get its source address mapped to a globally routable address before the ITR realizes that it should not encapsulate the packet destined to a non- LISP site. For a multicast packet to leave a LISP site, distribution tree state needs to be built so the ITR can know where to send the packet. So the receiver multicast sites need to know about the multicast source host by its routable address and not its EID address. When this is the case, the routable address is the (S-RLOC,G) state that is stored and maintained in the core routers. It is important to note that the routable address for the host cannot be the same as an RLOC for the site because we want the ITRs to process a received PIM Join/Prune message from an external-facing interface to be propagated inside of the site so the site-part of the distribution tree is built. Using a globally routable source address allows non-LISP and uLISP multicast receiver to join, create, and maintain a multicast distribution tree. However, the LISP multicast receiver site will want to perform an EID-to-RLOC mapping table lookup when a PIM Join/ Prune message is received on a site-facing interface. It does this because it wants to find a (S-RLOC,G) entry to Join in the core. So we have a conflict of behavior between the two types of sites. The solution to this problem is the same as when an ITR wants to send a unicast packet to a destination site but needs determine if the site is LISP capable or not. When it is not LISP capable, the ITR does not encapsulate the packet. So for the multicast case, when ETR receives a PIM Join/Prune message for (S-EID,G) state, it will do a mapping table lookup on S-EID. In this case, S-EID is not in the Farinacci, et al. Expires December 22, 2011 [Page 21] =0C Internet-Draft LISP for Multicast Environments June 2011 mapping database because the source multicast site is using a routable address and not an EID prefix address. So the ETR knows to simply propagate the PIM Join/Prune message to a external-facing interface without converting the (S-EID,G) because it is an (S,G) where S is routable and reachable via core routing tables. Now that the multicast distribution tree is built and maintained from any non-LISP or uLISP receiver multicast site, the way packet forwarding model is performed can be explained. Since the ITR in the source multicast site has never received a unicast encapsulated PIM Join/Prune message from any ETR in a receiver multicast site, it knows there are no LISP-Multicast receiver sites. Therefore, there is no need for the ITR to encapsulate data. Since it will know a priori (via configuration) that its site's EIDs are not routable (and not registered to the mapping database system), it assumes that the multicast packets from the source host are sent by a routable address. That is, it is the responsibility of the multicast source host's system administrator to ensure that the source host sends multicast traffic using a routable source address. When this happens, the ITR acts simply as a router and forwards the multicast packet like an ordinary multicast router. There is an alternative to using a LISP-NAT scheme just like there is for unicast [INTWORK] forwarding by using Proxy Tunnel Routers (PxTRs). This can work the same way for multicast routing as well, but the difference is that non-LISP and uLISP sites will send PIM Join/Prune messages for (S-EID,G) which make their way in the core to multicast PxTRs. Let's call this use of a PxTR as a "Multicast Proxy-ETR" (or mPETR). Since the mPETRs advertise very coarse EID prefixes, they draw the PIM Join/Prune control traffic making them the target of the distribution tree. To get multicast packets from the LISP source multicast sites, the tree needs to be built on the path from the mPETR to the LISP source multicast site. To make this happen the mPETR acts as a "Proxy ETR" (where in unicast it acts as a "Proxy ITR", or an uPITR [INTWORK]). The existence of mPETRs in the core allows source multicast site ITRs to encapsulate multicast packets according to (S-RLOC,G) state. The (S-RLOC,G) state is built from the mPETRs to the multicast ITRs. The encapsulated multicast packets are decapsulated by mPETRs and then forwarded according to (S-EID,G) state. The (S-EID,G) state is built from the non-LISP and uLISP receiver multicast sites to the mPETRs. 9.1.2. Non-LISP Source Site to non-LISP Receiver Sites Clearly non-LISP multicast sites can send multicast packets to non- LISP receiver multicast sites. That is what they do today. However, Farinacci, et al. Expires December 22, 2011 [Page 22] =0C Internet-Draft LISP for Multicast Environments June 2011 discussion is required to show how non-LISP multicast sites send multicast packets to uLISP receiver multicast sites. Since uLISP receiver multicast sites are not targets of any (S,G) state, they simply send (S,G) PIM Join/Prune messages toward the non- LISP source multicast site. Since the source multicast site, in this case has not been upgraded to LISP, all multicast source host addresses are routable. So this case is simplified to where a uLISP receiver multicast site looks to the source multicast site as a non- LISP receiver multicast site. 9.1.3. Non-LISP Source Site to Any Receiver Site When a non-LISP source multicast site has receivers in either a non- LISP/uLISP site or a LISP site, one needs to decide how the LISP receiver multicast site will attach to the distribution tree. We know from Section 9.1.2 that non-LISP and uLISP receiver multicast sites can join the distribution tree, but a LISP receiver multicast site ETR will need to know if the source address of the multicast source host is routable or not. We showed in Section 9.1.1 that an ETR, before it sends a PIM Join/Prune message on an external-facing interface, does a EID-to-RLOC mapping lookup to determine if it should convert the (S,G) state from a PIM Join/Prune message received on a site-facing interface to a (S-RLOC,G). If the lookup fails, the ETR can conclude the source multicast site is a non-LISP site so it simply forwards the Join/Prune message (it also doesn't need to send a unicast encapsulated Join/Prune message because there is no ITR in a non-LISP site and there is namespace continuity between the ETR and source). For a non-LISP source multicast site, (S-EID,G) state could be limited to the edges of the network with the use of multicast proxy- ITRs (mPITRs). The mPITRs can take native, unencapsulated multicast packets from non-LISP source multicast and uLISP sites and encapsulate them to ETRs in receiver multicast sites or to mPETRs that can decapsulate for non-LISP receiver multicast or uLISP sites. The mPITRs are responsible for sending (S-EID,G) joins to the non- LISP source multicast site. To connect the distribution trees together, multicast ETRs will need to be configured with the mPITR's RLOC addresses so they can send both (S-RLOC,G) joins to build a distribution tree to the mPITR as well as for sending unicast joins to mPITRs so they can propogate (S-EID,G) joins into source multicast sites. The use of mPITRs is undergoing more study and is work in progress. Farinacci, et al. Expires December 22, 2011 [Page 23] =0C Internet-Draft LISP for Multicast Environments June 2011 9.1.4. Unicast LISP Source Site to Any Receiver Sites In the last section, it was explained how an ETR in a multicast receiver site can determine if a source multicast site is LISP- enabled by looking into the mapping database. When the source multicast site is a uLISP site, it is LISP enabled but the ITR, by definition is not capable of doing multicast encapsulation. So for the purposes of multicast routing, the uLISP source multicast site is treated as non-LISP source multicast site. Non-LISP receiver multicast sites can join distribution trees to a uLISP source multicast site since the source site behaves, from a forwarding perspective, as a non-LISP source site. This is also the case for a uLISP receiver multicast site since the ETR does not have multicast functionality built-in or enabled. Special considerations are required for LISP receiver multicast sites since they think the source multicast site is LISP capable, the ETR cannot know if ITR is LISP-Multicast capable. To solve this problem, each mapping database entry will have a multicast 2-tuple (Mpriority, Mweight) per RLOC. When the Mpriority is set to 255, the site is considered not multicast capable. So an ETR in a LISP receiver multicast site can distinguish whether a LISP source multicast site is LISP-Multicast site from a uLISP site. 9.1.5. LISP Source Site to Any Receiver Sites When a LISP source multicast site has receivers in LISP, non-LISP, and uLISP receiver multicast sites, it has a conflict about how it sends multicast packets. The ITR can either encapsulate or natively forward multicast packets. Since the receiver multicast sites are heterogeneous in their behavior, one packet forwarding mechanism cannot satisfy both. However, if a LISP receiver multicast site acts like a uLISP site then it could receive packets like a non-LISP receiver multicast site making all receiver multicast sites have homogeneous behavior. However, this poses the following issues: o LISP-NAT techniques with routable addresses would be required in all cases. o Or alternatively, mPETR deployment would be required forcing coarse EID prefix advertisement in the core. o But what is most disturbing is that when all sites that participate are LISP-Multicast sites but then a non-LISP or uLISP site joins the distribution tree, then the existing joined LISP receiver multicast sites would have to change their behavior. This would create too much dynamic tree-building churn to be a Farinacci, et al. Expires December 22, 2011 [Page 24] =0C Internet-Draft LISP for Multicast Environments June 2011 viable alternative. So the solution space options are: 1. Make the LISP ITR in the source multicast site send two packets, one that is encapsulated with (S-RLOC,G) to reach LISP receiver multicast sites and another that is not encapsulated with (S-EID,G) to reach non-LISP and uLISP receiver multicast sites. 2. Make the LISP ITR always encapsulate packets with (S-RLOC,G) to reach LISP-Multicast sites and to reach mPETRs that can decapsulate and forward (S-EID,G) packets to non-LISP and uLISP receiver multicast sites. 9.2. LISP Sites with Mixed Address Families A LISP database mapping entry that describes the locator-set, Mpriority and Mweight per locator address (RLOC), for an EID prefix associated with a site could have RLOC addresses in either IPv4 or IPv6 format. When a mapping entry has a mix of RLOC formatted addresses, it is an implicit advertisement by the site that it is a dual-stack site. That is, the site can receive IPv4 or IPv6 unicast packets. To distinguish if the site can receive dual-stack unicast packets as well as dual-stack multicast packets, the Mpriority value setting will be relative to an IPv4 or IPv6 RLOC See [LISP] for packet format details. If you consider the combinations of LISP, non-LISP, and uLISP sites sharing the same distribution tree and considering the capabilities of supporting IPv4, IPv6, or dual-stack, the number of total combinations grows beyond comprehension. Using some combinatorial math, we have the following profiles of a site and the combinations that can occur: 1. LISP-Multicast IPv4 Site 2. LISP-Multicast IPv6 Site 3. LISP-Multicast Dual-Stack Site 4. uLISP IPv4 Site 5. uLISP IPv6 Site Farinacci, et al. Expires December 22, 2011 [Page 25] =0C Internet-Draft LISP for Multicast Environments June 2011 6. uLISP Dual-Stack Site 7. non-LISP IPv4 Site 8. non-LISP IPv6 Site 9. non-LISP Dual-Stack Site Lets define (m n) =3D m!/(n!*(m-n)!), pronounced "m choose n" to illustrate some combinatorial math below. When 1 site talks to another site, the combinatorial is (9 2), when 1 site talks to another 2 sites, the combinatorial is (9 3). If sum this up to (9 9), we have: (9 2) + (9 3) + (9 4) + (9 5) + (9 6) + (9 7) + (9 8) + (9 9) =3D 36 + 84 + 126 + 126 + 84 + 36 + 9 + 1 Which results in the total number of cases to be considered at 502. This combinatorial gets even worse when you consider a site using one address family inside of the site and the xTRs use the other address family (as in using IPv4 EIDs with IPv6 RLOCs or IPv6 EIDs with IPv4 RLOCs). To rationalize this combinatorial nightmare, there are some guidelines which need to be put in place: o Each distribution tree shared between sites will either be an IPv4 distribution tree or an IPv6 distribution tree. Therefore, we can avoid head-end replication by building and sending packets on each address family based distribution tree. Even though there might be an urge to do multicast packet translation from one address family format to the other, it is a non-viable over-complicated urge. Multicast ITRs will only encapsulate packets where the inner and outer headers are from the same address family. o All LISP sites on a multicast distribution tree must share a common address family which is determined by the source site's locator-set in its LISP database mapping entry. All receiver multicast sites will use the best RLOC priority controlled by the source multicast site. This is true when the source site is either LISP-Multicast or uLISP capable. This means that priority- based policy modification is prohibited. When a receiver multicast site ETR receives a (S-EID,G) join, it must select a S-RLOC for the same address family as S-EID. Farinacci, et al. Expires December 22, 2011 [Page 26] =0C Internet-Draft LISP for Multicast Environments June 2011 o A mixed multicast locator-set with the best multicast priority values MUST NOT be configured on multicast ITRs. A mixed locator- set can exist (for unicast use), but the multicast priorities MUST be the set for the same address family locators. o When the source site is not LISP capable, it is up to how receivers find the source and group information for a multicast flow. That mechanism decides the address family for the flow. 9.3. Making a Multicast Interworking Decision This Multicast Interworking section has shown all combinations of multicast connectivity that could occur. As you might have already concluded, this can be quite complicated and if the design is too ambitious, the dynamics of the protocol could cause a lot of instability. The trade-off decisions are hard to make and we want the same single solution to work for both IPv4 and IPv6 multicast. It is imperative to have an incrementally deployable solution for all of IPv4 unicast and multicast and IPv6 unicast and multicast while minimizing (or eliminating) both unicast and multicast EID namespace state. Therefore the design decision to go with uPITRs [INTWORK] for unicast routing and mPETRs for multicast routing seems to be the sweet spot in the solution space so we can optimize state requirements and avoid head-end data replication at ITRs. Farinacci, et al. Expires December 22, 2011 [Page 27] =0C Internet-Draft LISP for Multicast Environments June 2011 10. Considerations when RP Addresses are Embedded in Group Addresses When ASM and PIM-Bidir is used in an IPv6 inter-domain environment, a technique exists to embed the unicast address of an RP in a IPv6 group address [RFC3956]. When routers in end sites process a PIM Join/Prune message which contain an embedded-RP group address, they extract the RP address from the group address and treat it from the EID namespace. However, core routers do not have state for the EID namespace, need to extract an RP address from the RLOC namespace. Therefore, it is the responsibility of ETRs in multicast receiver sites to map the group address into a group address where the embedded-RP address is from the RLOC namespace. The mapped RP- address is obtained from a EID-to-RLOC mapping database lookup. The ETR will also send a unicast (*,G) Join/Prune message to the ITR so the branch of the distribution tree from the source site resident RP to the ITR is created. This technique is no different than the techniques described in this specification for translating (S,G) state and propagating Join/Prune messages into the core. The only difference is that the (*,G) state in Join/Prune messages are mapped because they contain unicast addresses encoded in an Embedded-RP group address. Farinacci, et al. Expires December 22, 2011 [Page 28] =0C Internet-Draft LISP for Multicast Environments June 2011 11. Taking Advantage of Upgrades in the Core If the core routers are upgraded to support [RPFV] and [RFC5496], then we can pass EID specific data through the core without, possibly, having to store the state in the core. By doing this we can eliminate the ETR from unicast encapsulating PIM Join/Prune messages to the source site's ITR. However, this solution is restricted to a small set of workable cases which would not be good for general use of LISP-Multicast. In addition due to slow convergence properties, it is not being recommended for LISP-Multicast. Farinacci, et al. Expires December 22, 2011 [Page 29] =0C Internet-Draft LISP for Multicast Environments June 2011 12. Mtrace Considerations Mtrace functionality must be consistent with unicast traceroute functionality where all hops from multicast receiver to multicast source are visible. The design for mtrace for use in LISP-Multicast environments is to be determined but should build upon the mtrace version 2 specified in [MTRACE]. Farinacci, et al. Expires December 22, 2011 [Page 30] =0C Internet-Draft LISP for Multicast Environments June 2011 13. Security Considerations Refer to the [LISP] specification. Farinacci, et al. Expires December 22, 2011 [Page 31] =0C Internet-Draft LISP for Multicast Environments June 2011 14. Acknowledgments The authors would like to gratefully acknowledge the people who have contributed discussion, ideas, and commentary to the making of this proposal and specification. People who provided expert review were Scott Brim, Greg Shepherd, and Dave Oran. Other commentary from discussions at Summer 2008 Dublin IETF were Toerless Eckert and Ijsbrand Wijnands. We would also like to thank the MBONED working group for constructive and civil verbal feedback when this draft was presented at the Fall 2008 IETF in Minneapolis. In particular, good commentary came from Tom Pusateri, Steve Casner, Marshall Eubanks, Dimitri Papadimitriou, Ron Bonica, Lenny Guardino, Alia Atlas, and Jesus Arango. An expert review of this specification was done by Yiqun Cai and Liming Wei. We thank them for their detailed comments. This work originated in the Routing Research Group (RRG) of the IRTF. The individual submission [MLISP] was converted into this IETF LISP working group draft. Farinacci, et al. Expires December 22, 2011 [Page 32] =0C Internet-Draft LISP for Multicast Environments June 2011 15. References 15.1. Normative References [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-13.txt (work in progress), June 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source- Specific Multicast", RFC 4604, August 2006. [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR- PIM)", RFC 5015, October 2007. [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, March 2009. 15.2. Informative References [ALT] Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative Topology (LISP-ALT)", draft-ietf-lisp-alt-06.txt (work in progress), March 2011. [INTWORK] Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP Farinacci, et al. Expires December 22, 2011 [Page 33] =0C Internet-Draft LISP for Multicast Environments June 2011 with IPv4 and IPv6", draft-ietf-lisp-interworking-02.txt (work in progress), March 2011. [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "LISP for Multicast Environments", draft-farinacci-lisp-multicast-01.txt (work in progress), November 2008. [MNAT] Wing, D. and T. Eckert, "Multicast Requirements for a Network Address (and port) Translator (NAT)", draft-ietf-behave-multicast-07.txt (work in progress), June 2007. [MTRACE] Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace Version 2: Traceroute Facility for IP Multicast", draft-ietf-mboned-mtrace-v2-03.txt (work in progress), March 2009. [RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector TLV", draft-ietf-pim-rpf-vector-06.txt (work in progress), February 2008. Farinacci, et al. Expires December 22, 2011 [Page 34] =0C Internet-Draft LISP for Multicast Environments June 2011 Appendix A. Document Change Log A.1. Changes to draft-ietf-lisp-multicast-06.txt o Posted June 2011 to complete working group last call. o Added paragraph to section 8.1.2 based on Jesus comment about making it more clear what happens when two (S-EID,G) trees use the same (RLOC,G) tree. o Make more references to [INTWORK] when mentioning uPITRs and uPETRs. o Made many changes based on editorial and wordsmithing comments from Alia. A.2. Changes to draft-ietf-lisp-multicast-05.txt o Posted April 2011 to reset expiration timer. o Updated references. A.3. Changes to draft-ietf-lisp-multicast-04.txt o Posted October 2010 to reset expiration timer. o Updated references. A.4. Changes to draft-ietf-lisp-multicast-03.txt o Posted April 2010. o Added section 8.1.2 to address Joel Halpern's comment about receiver sites joining the same source site via 2 different RLOCs, each being a separate ITR. o Change all occurences of "mPTR" to "mPETR" to become more consistent with uPITRs and uPETRs described in [INTWORK]. That is, an mPETR is a LISP multicast router that decapsulates multicast packets that are encapsulated to it by ITRs in multicast source sites. o Add clarifications in section 9 about how homogeneous multicast encapsulation should occur. As well as describing in this section, how to deal with mixed-locator sets to avoid heterogeneous encapsulation. Farinacci, et al. Expires December 22, 2011 [Page 35] =0C Internet-Draft LISP for Multicast Environments June 2011 o Introduce concept of mPITRs to help reduce (S-EID,G) to the edges of LISP global multicast network. A.5. Changes to draft-ietf-lisp-multicast-02.txt o Posted September 2009. o Added Document Change Log appendix. o Specify that the LISP Encapsulated Control Message be used for unicasting PIM Join/Prune messages from ETRs to ITRs. A.6. Changes to draft-ietf-lisp-multicast-01.txt o Posted November 2008. o Specified that PIM Join/Prune unicast messages that get sent from ETRs to ITRs of a source multicast site get LISP encapsulated in destination UDP port 4342. o Add multiple RLOCs per ITR per Yiqun's comments. o Indicate how static RPs can be used when LISP is run using Bidir- PIM in the core. o Editorial changes per Liming comments. o Add Mttrace Considersations section. A.7. Changes to draft-ietf-lisp-multicast-00.txt o Posted April 2008. o Renamed from draft-farinacci-lisp-multicast-01.txt. Farinacci, et al. Expires December 22, 2011 [Page 36] =0C Internet-Draft LISP for Multicast Environments June 2011 Authors' Addresses Dino Farinacci cisco Systems Tasman Drive San Jose, CA USA Email: dino@cisco.com Dave Meyer cisco Systems Tasman Drive San Jose, CA USA Email: dmm@cisco.com John Zwiebel cisco Systems Tasman Drive San Jose, CA USA Email: jzwiebel@cisco.com Stig Venaas cisco Systems Tasman Drive San Jose, CA USA Email: stig@cisco.com Farinacci, et al. Expires December 22, 2011 [Page 37] =0C --Apple-Mail-3--328112272 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-3--328112272-- From akatlas@gmail.com Wed Jun 22 12:51:25 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF6C11E809C for ; Wed, 22 Jun 2011 12:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCl0-OUQuEAs for ; Wed, 22 Jun 2011 12:51:23 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB4711E8073 for ; Wed, 22 Jun 2011 12:51:22 -0700 (PDT) Received: by ewy19 with SMTP id 19so433054ewy.31 for ; Wed, 22 Jun 2011 12:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eMrm6o4pRL5jneTQLzCY79p5Fm7HqNPZVtLyNZfu0HU=; b=Kg7MpPSzHbXYjlf23VgPpXdYIEVemJMMTxcECSb/SaohLipt4HayRcm11rYeU/mgu+ VV3qRKnUOFKyahRHaZxY3AM3nq93MkIECVkE/uVuQ65kR/1uEsVUuO+QxTFek5pIyVw+ Xglw42D1usbpSwS7/q9rLNlxddNmimOOZ7gV8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YVAJwrtBPpvRS/6H6cxJ6mBGyvmw9o8YvJf9wPdDUDBMofV//XnNLI6YVr9Mykkwvz ahZkOQOWUyB0ptvqadsyad7YLQOGwdT3um9J5LJU6z+TRtffAXfcAkwbXCKoc+5IhWix +XF6q0UQcuZbgaHHLEBAIT6AZdfIzyVoBAv+U= MIME-Version: 1.0 Received: by 10.14.119.8 with SMTP id m8mr817797eeh.48.1308772280932; Wed, 22 Jun 2011 12:51:20 -0700 (PDT) Received: by 10.14.189.3 with HTTP; Wed, 22 Jun 2011 12:51:20 -0700 (PDT) In-Reply-To: <9ACA6751-3A26-47CB-9126-72863469F4D2@cisco.com> References: <4099FE40-80F6-4E32-848C-C33990DB1343@cisco.com> <9ACA6751-3A26-47CB-9126-72863469F4D2@cisco.com> Date: Wed, 22 Jun 2011 15:51:20 -0400 Message-ID: From: Alia Atlas To: Dino Farinacci Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Stig Venaas , Jesus Arango , lisp@ietf.org, David Meyer Subject: Re: [lisp] Proposed changes for draft-ietf-lisp-multicast-06.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2011 19:51:25 -0000 Dino, Yet more comments in-line. Alia On Mon, Jun 20, 2011 at 2:51 PM, Dino Farinacci wrote: >> Dino, >> >> Comments are in-line > > Thanks for the comments. See responses inline. > >> On Mon, May 30, 2011 at 11:50 PM, Dino Farinacci wrote: >> >>> Alia comments: >>> >>>> What I most want to see in this draft is a clear description of what >>>> needs to implemented and how. =A0It gives a good survey of the >>>> architectural possibilities and even makes suggestions at the end - >>>> but not quite sufficient to be clear in the details of what needs to >>>> be implemented for interoperability and what is for future >>>> experimentation. >>> >>> Everything in the spec needs to be implemented. Why would you think >>> differently? >> >> There are places in the text where the phrasing is very unclear - for ju= st >> the >> first instance, there is the last paragraph in Sec 4: >> >> "There is a possible solution to this problem which reduces the number >> =A0of many-to-one occurrences of (S-EID,G) entries aggregating into a >> =A0single (S-RLOC,G) entry. =A0If a physical ITR can be assigned multipl= e >> =A0RLOC addresses and these addresses are advertised in mapping database >> =A0entries, then ETRs at receiver sites have more RLOC address options >> =A0and therefore can join different (RLOC,G) entries for each (S-EID,G) >> =A0entry joined at the receiver site. =A0It would not scale to have a on= e- >> =A0to-one relationship between the number of S-EID sources at a source >> =A0site and the number of RLOCs assigned to all ITRs at the site, but we >> =A0can reduce the "n" to a smaller number in the "n-to-1" relationship. >> =A0And in turn, reduce the opportunity for data packets to be delivered >> =A0to sites for groups not joined." >> >> This doesn't give a way to force all receiver sites to select the same >> (RLOC,G) for a given (S-EID,G) as you replied was necessary to Jesus' >> comments. > > The above paragraph is showing a tradeoff between one-to-one state betwee= n > (S-EID,G) and (S-RLOC,G). If you want good trees at the expense of core > state, you go with this option. If you want to reduce core state, you use > aggregate trees in the core which combine many (S-EID,G) entries into one > (S-RLOC,G) entry. > > Jesus made a lot of comments, so I don't know how this paragraph relates = to > which comment. > > If you want to make this thread productive so we can proceed, you need to= be > very detailed in your commentary or there is nothing I can do to decide o= n > how to deal with the comments. I am referring to the following question and your response in the first message of this thread. Jesus comments: 1. Cross-talk duplication of multicast flows when using multiple RLOCS: Consider two receiver sites A and B with the following mappings: Site A: (S1, G) --> (RLOC1, G) (S2, G) --> (RLOC2, G) Site B: (S1, G) --> (RLOC2, G) This would cause Site A to receive duplicate packets for (S1,G). One co= py would be encapsulated with source RLOC1 while the second copy will be All sites are suppose to hash to the same RLOC for a given (S-EID,G). So Site B would use (RLOC1,G) as would Site A. >> I can go through the draft again for each example - but phrasing of >> "it is possible", >> "a potential solution", "one approach", etc. do not indicate a >> requirement to implement >> for interoperability. > > I am going to repeat. This draft is experimental. And there are a lot of > potential solutions we have not thought about yet. The ones are presented > make it obvious and convincing that the currently documented potential > solutions should be considered by the implementation, allowing us to leav= e > room for the implementation to create its own solution for experimentatio= n > and interoperability. > > If you think we have all the answers, and want us to document them, then = we > would be lieing. We don't want to lie. =A0;-) =A0And I know you are not a= sking > us to do that. Of course not - but I'm looking for enough clarity to understand what the b= ase is to inter-operate & what is trying to address open questions to be investigated during experimentation. >>>> b) Sec 4, second paragraph: "At this point in time, we don't see a >>>> requirement for different locator-sets, priority, and weight policies >>>> for multicast than we have for unicast." =A0but there is an M Priority >>>> and M Weight in the [LISP] draft. =A0Clarification as to why would be >>>> useful... (I know it is to get the RLOCs of the ITRs which shouldn't >>>> be used for unicast traffic.) >>> >>> I added a sentence. >>> >>>> I don't see a mechanism other than the M Priority to obtain the RLOCs >>>> associated with an ITR - since only ETR RLOCs would normally be >>>> included. >>> >>> I don't understand the comment. There is one locator-set, and the RLOCs >>> for >>> encapsulating unicast packets to and the RLOCs for sending multicast jo= in >>> messages to can be a different set within the locator-set. >> >> Ok - let me clarify. =A0The set of RLOCs in a locator-set, until this >> draft, are for the ETR. =A0For multicast, the set of RLOCs required must > > Well, correction, they are for xTRs at the site. And the encoding allows = you > to list ITRs as well even though you would not use them as targets of > encapsulation. You achieve this either by setting the priority to 255 or > setting the corresponding R-bit/LSB bit to 0. OK - but this is not stated anywhere in the set of drafts - i.e. either tha= t one should/may include ITRs with a priority of 255 and/or corresponding R-bit t= o 0. My assumption from what the text says is that those RLOCs shouldn't be used for unicast forwarding. I have seen nothing about what they should be used= for (except R-bit =3D 0 addressing the concerns of removing existing locators). Can you please write this assumption into the draft(s) - both on the includ= ing ITRs and on what assumptions the multicast draft may make about it? >> be for the ITR. IF the ITR and ETR are different, there must be a way >> of telling which RLOCs belong to an ITR and which belong to an ETR. > > This is how you encode them in a Map-Reply, as an example of unicast ITRs= A > and B, and multicast ITRs C and D: > > locator-set-count:4 > > A, up: 1, uw: 50, mp: 255, mw: 0 > B, up: 1, uw: 50, mp: 255, mw: 0 > C, up: 255, uw: 0, mp: 1, mw: 50 > D, up: 255, uw: 0, mp: 1, mw: 50 > > This describes a site that is doing active-active multihoming for unicast > traffic by having ITRs, which received this Map-Reply, to load-split unic= ast > flows across encapsulations to A and B. ITRs do not use C and D because t= he > unicast priority is set to 255. > > A and B are not used for unicast Joins since the multicast priority is se= t > to 255. > > When ETRs at a receiver site want to join an (EID,G), they will use C and= D > and load-split different (S-EID,G) entries across C and D in a active-act= ive > fashion. I agree with this example. My point is that it relies on having the M Prio= rity. I'm asking for the simple set of rules to be spelled out. >> The ONLY way that I can find to do this is from the M Priority and the >> Priority fields. =A0If you intend that RLOCs with a priority=3D255 are >> assumed to be RLOCs associated with ITRs, then that should be clearly >> stated. =A0I certainly assumed not - there can be reasons to have an >> inactive RLOC, as I understand it. > > Wherever the text says where to send joins and talks about priorities, ea= ch > occurrence refers to "multicast priority". I'd have to reread the draft, but I didn't interpret it that way. > And the Basic Overview section says: > > =A0 At this point in time, we don't see a requirement for different > =A0 locator-sets, priority, and weight policies for multicast than we > =A0 have for unicast. =A0However, when traffic engineering policies are > =A0 different for unicast versus multicast flows, it will be desirable to > =A0 use multicast-based priority and weight values in Map-Reply messages. And, again, my point is that the multicast-based priority and weight values are needed to identify the ITR RLOCs that can be used. I guess that you are talking about traffic engineering policies to distingu= ish between the cases where there are xTRs and where there are separate ITRs and ETRs. That isn't something which an ETR can trivially deduce about a different site - which is why there are the multicast priority and weight. PLEASE just give the simple rules for what should be taken from a locator-s= et and what should be placed in it for multicast - and either acknowledge that the M priority is needed or provide what the other mechanism is. >>>> What would be good to add to the draft is the changes to be made to >>>> information such as the Map-Reply messages. =A0E.g. >>>> =A0Set the M Priority for all ETR RLOCs to be 255 >>>> =A0Add the ITR RLOCs and set the Priority to 255 & the M Priority to >>>> =A0something else. >>> >>> They are the same locators. The xTR has one locator-set, the RLOCs are >>> used >>> as a destination for unicast packets or for a destination for multicast >>> joins. >> >> The unicast traffic needs to go to ETRs. =A0The multicast traffic needs >> to go to ITRs. =A0My understanding is that these can be deployed >> separately. =A0If this is not the case for multicast, then that should >> certainly be stated! > > There is one locator-set that is shared when but unicast and multicast > priority is non-255. Otherwise, some locators are used for unicast-only a= nd > others can be used for multicast-only. Sure - the ETR and ITR can be co-located with the same RLOCs. Different sets of RLOCs may be pulled from the same locator-set for unicast and for multicast according to different rules. IF the ETRs are always co-located = with the ITRs, then the sets of RLOCs would match. At a meta-level here, this is a case where I feel that clear and exact beha= vior could be specified - and there aren't questions about experimental uncertai= nty. However, that has not been done - and is what I am asking for. I think we = agree on the desired behavior - but it took inference, substantial background, and assumptions on my part to get there. >>>> c) What happens if the S-EID and S-RLOC collide? =A0In particular, at >>> >>> You have to be more specific on what you mean here. >> >> Can an S-EID and an S-RLOC have the same value? =A0If not, why not? > > Yes, they will when a mPETR sends a native join to a non-LISP source > multicast site. Ok - I think that you answered some of my question in the responses to the main lisp draft. I am concerned about confusion between different trees - if the S-RLOC is used separately and independently of the S-EID. >>>> the ETR and ITR, it seems useful to specify that the xTR has knowledge >>>> of whether the packet was LISP-encapsulated & forwards it either to >>>> receivers that expect it un-LISP-encapsulated (ETR) or to receivers >>>> that expect it LISP-encapsulated (ITR). >> >> If an S-EID and S-RLOC have the same value, what helps disambiguate them >> in a received multicast packet is whether the packet was >> LISP-encapsulated. > > A LISP multicast packet is defined to be a UDP packet with a destination > port of 4341. Yes - but what would be useful is to clearly specify the rules and behavior. Again, this isn't a point where I think there is >>> An EID and RLOC can have the same value just like in the unicast >>> scenario. >> >> That is what I initially assumed - but there are places in the drafts >> where it is assumed that one can tell an EID from an RLOC without any >> additional information or look-ups. =A0I tried to pull them out in my >> comments and mentioned this as a general concern. > > Not true. If you have a specific location of this confusion, POINT OUT TH= E > TEXT, and we can try to clarify it. I will DEFINITELY do this. There were, in fact, so many (3-4) that I resorted to pulling it out as a higher-layer concern since I thought I must have misunderstood. I will read your updated versions and tell you the specific sentences. An example is immediately below in item (d) on p.15 at the end of MSDP. >>>> d) p. 15 end of MSDP: >>>> =A0"And the choice can be made unilaterally because the ITR at the >>>> =A0site will determine which namespace the destination peer address is >>>> =A0out of by looking in the mapping database service." >>>> >>>> Is there an assumption in LISP that an EID and an RLOC MUST NOT have >>>> the same value?? =A0I've seen this potentially implied, but not >>>> proscriptively stated. >>> >>> There is not architectural. >> >> So how can the ITR determine which namespace the destination peer addres= s >> is >> out of by looking in the mapping database service?? > > I don't understand the question. What is a destination peer address. Plea= se > use LISP defined terminology or else we be second guessing each other. Dino, I am QUOTING the draft text - given above. >> >>>> e) p. 22 first paragraph: >>>> =A0"So the ETR knows to simply propagate the PIM Join/Prune message to >>>> =A0a external-facing interface without converting the (S-EID,G) becaus= e >>>> =A0it is an (S,G) where S is routable and reachable via core routing >>>> =A0tables." >>>> >>>> In [INTWRK], it is clear that an EID may be globally routable. =A0This >>>> creates a conflict here, where there is an assumption that if an IP >>>> address is globally routable, then it is not in the EID/RLOC mapping >>>> database. >>> >>> The text says: >>> >>> =A0In this case, S-EID is not in the >>> >>> Farinacci, et al. =A0 =A0 =A0 Expires December 1, 2011 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 [Page 21] >>> Internet-Draft =A0 =A0 =A0 LISP for Multicast Environments =A0 =A0 =A0 = =A0 =A0 =A0May 2011 >>> >>> >>> =A0mapping database because the source multicast site is using a >>> =A0routable address and not an EID prefix address. =A0So the ETR knows = to >>> =A0simply propagate the PIM Join/Prune message to a external-facing >>> =A0interface without converting the (S-EID,G) because it is an (S,G) >>> =A0where S is routable and reachable via core routing tables. >>> >>> So the ETR knows because "there is no mapping database entry and the >>> S-EID >>> is routable". >> >> But in [INTWRK}, the same IP address can be globally routable AND appear >> in the mapping database. > > Then it can be reached either way. Not a problem. It is up the ITR to dec= ide > to encapsulate to the LISP site or send natively. Could you please add that to the draft? As written, I think it says that the ETR can unambiguously tell whether it is an EID or globally routable address. Clarifying that in the cases where this can not be determined, it is up to the ETR to decide how to join would help immensely with clarity. >> Also, how does the ETR know that the S-EID is routable - by getting a >> negative >> Map-Reply? > > It assumes it is routable if not in the mapping database. I understand that there can be different mechanisms for mapping databases -= but I think that clearly describing the methods for doing this check - and the appropriate decision-making after would be useful. >> Statements like that of "is using a routable address and not an EID >> prefix address" >> without any further hints imply that there isn't overlap of addresses. > > This string is in two locations in the spec. And it is here: > > =A0 Since the ITR in the source multicast site has never received a > =A0 unicast encapsulated PIM Join/Prune message from any ETR in a > =A0 receiver multicast site, it knows there are no LISP-Multicast > =A0 receiver sites. =A0Therefore, there is no need for the ITR to > =A0 encapsulate data. =A0Since it will know a priori (via configuration) > =A0 that its site's EIDs are not routable, it assumes that the multicast > =A0 packets from the source host are sent by a routable address. =A0That > =A0 is, it is the responsibility of the multicast source host's system > =A0 administrator to ensure that the source host sends multicast traffic > =A0 using a routable source address. =A0When this happens, the ITR acts > =A0 simply as a router and forwards the multicast packet like an ordinary > =A0 multicast router. > > And here: > > =A0 The solution to this problem is the same as when an ITR wants to send > =A0 a unicast packet to a destination site but needs determine if the > =A0 site is LISP capable or not. =A0When it is not LISP capable, the ITR > =A0 does not encapsulate the packet. =A0So for the multicast case, when E= TR > =A0 receives a PIM Join/Prune message for (S-EID,G) state, it will do a > =A0 mapping table lookup on S-EID. =A0In this case, S-EID is not in the > > > > Farinacci, et al. =A0 =A0 =A0 Expires December 1, 2011 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 [Page 21] > Internet-Draft =A0 =A0 =A0 LISP for Multicast Environments =A0 =A0 =A0 = =A0 =A0 =A0May 2011 > > > =A0 mapping database because the source multicast site is using a > =A0 routable address and not an EID prefix address. =A0So the ETR knows t= o > =A0 simply propagate the PIM Join/Prune message to a external-facing > =A0 interface without converting the (S-EID,G) because it is an (S,G) > =A0 where S is routable and reachable via core routing tables. > > > Does your comment pertain to these paragraphs. I can change the first to > "using a routable source address (meaning that it is not in the mapping > database system)". Would that suffice? Yes - because it could be both according to [INTWRK]. > The second occurrence says "In this case, the S-EID is not in the mapping > database ...". So it is clear IMO. Why is an S-EID not in the mapping database? Also, the higher meta-question is whether a value A is assigned to either the EID space or the RLOC space? Could site X have an EID with value A while site = Y (or even a non-LISP) has an RLOC (or globally routable address) with the same value A? I'll bring this up more clearly in separate email - because this is the crux of many questions I have about being able to tell whether a value A is an EID or an RLOC/globally-routable. >>>> Couldn't a more specific check be done along the lines of: >>>> =A0if the S-EID is reachable via core routing and >>>> =A0 =A0 i) it is not in the mapping database or >>>> =A0 =A0 ii) it is in the mapping database, but there are no RLOCs with >>>> =A0 =A0 =A0 =A0 an M Priority other than 255? >>>> >>>> f) Text in 9.1.1, 9.1.2 doesn't match the headings well. =A0For >>>> instance, in 9.1.1, there is discussion of how a LISP source site that >>>> sends to non-LISP or uLISP receiver sites also can send to LISP >>>> receiver sites. >>> >>> They actually are correct, but the first start out saying how the trees >>> are >>> built from the receiver side so that text can support the data-flow >>> description that comes later. >>> >>>> In 9.1.2, maybe renaming it to non-mLISP Receiver Sites would be >>>> clearer? >>> >>> We stated up from the definition of a non-LISP receiver site. Creating = a >>> new >>> term would add to the number of combinations. The spec doesn't need tha= t >>> extra complexity. >>> >>>> g) In 9.1.4, Mpriority and Mweight are finally mentioned - but as far >>>> as I can tell, they are needed earlier and for the pure mLISP to mLISP >>>> case. =A0Please pull the discussion of this earlier. >>> >>> Can you be more specific please. >> >> Please look at my comment (b) and further elaboration there. =A0I think >> Mpriority is >> needed to find the RLOCs associated with an ITR. > > We already covered this and I hope you are satisfied with my response. If > not, you need to PLEASE SITE TEXT SO WE CAN CORRECT IT. The text is above in the email. I've responded there. >>>> Also, this case is discussed in 9.1.1 last paragraph on p. 21 - but >>>> claimed that it is sufficient to look in the mapping database. =A0Coul= d >>>> you please combine these and bring more consistency to the draft? >>> >>> Combine what? Please be more specific. >> >> How much more specific than the exact sections and paragraphs do you >> need? > > Point out text please in the email. I am asking to combine or clarify the differences between the cases in 9.1.= 4 and in 9.1.1 last paragraph on p. 21. The specific texts are: "The solution to this problem is the same as when an ITR wants to send a unicast packet to a destination site but needs determine if the site is LISP capable or not. When it is not LISP capable, the ITR does not encapsulate the packet. So for the multicast case, when ETR receives a PIM Join/Prune message for (S-EID,G) state, it will do a mapping table lookup on S-EID. In this case, S-EID is not in the Farinacci, et al. Expires October 7, 2011 [Page 21] Internet-Draft LISP for Multicast Environments April 2011 mapping database because the source multicast site is using a routable address and not an EID prefix address. So the ETR knows to simply propagate the PIM Join/Prune message to a external-facing interface without converting the (S-EID,G) because it is an (S,G) where S is routable and reachable via core routing tables. " and " Special considerations are required for LISP receiver multicast sites since they think the source multicast site is LISP capable, the ETR cannot know if ITR is LISP-Multicast capable. To solve this problem, each mapping database entry will have a multicast 2-tuple (Mpriority, Mweight) per RLOC. When the Mpriority is set to 255, the site is considered not multicast capable. So an ETR in a LISP receiver multicast site can distinguish whether a LISP source multicast site is LISP-Multicast site from a uLISP site. " These are parts of the same "if-then-else" for behavior that are scattered.= The first handles the case where the source multicast site is non-LISP & the se= cond handles the case where the source multicast site is uLISP. What is not clear is why/when a uLISP-site would use an EID instead of a globally routable address for a source multicast??? Is that legit? I think the "if-then-else" is: if the source address is not in the mapping database: then it is globally routable - use the (S-global, G) else if the locator-set has no Mpriority < 255 locators then it is a uLISP-site & the source address is globally routable - use the (S-global, G) else pick an RLOC from the locator-set and use (S-RLOC, G) >>>> h) In 9.1.5, is it possible to make a recommendation (e.g. an ITR >>>> SHOULD be able to send two packets based on what its oif-lists are? >>> >>> No, we want to leave it up to the implementation. >> >> So both solutions must be implemented (see your response to my first >> question), configured, and managed??? =A0Why? =A0How will there be >> interoperable implementations? >> >>>> Isn't this already the case because the mLISP ITR could have >>>> internal-facing entries in the (S-EID,G) that need to be replicated >>>> without encapsulation and external-facing entries in the (S-RLOC, G) >>>> that need encapsulation? >>> >>> Yes, but those forwarding rules are up to the multicast routing protoco= l >>> run >>> in the site. That is, if your comment is to document this. >> >> So - clarity of understanding what needs to be done and ITR behavior is >> good. >> Yes, please document this. =A0As phrased, there's the appearance that an= ITR >> doesn't normally need to duplicate packets. > > I am sorry, I am not going to document PIM-DM, PIM-SM, DVMRP, MOSPF, IGMP= , > and MLD in this document. If that is your request, it is unreasonable and > adds no value and just creates opportunity for complexity, confusion, and > errors. That is, of course, not my request. My request is to add clarity to the additional behavior that LISP imposes. "Via a multicast protocol, an mLISP ITR may have internal-facing entries in= the (S-EID, G) that need to be replicated without LISP-encapsulation (e.g. norm= al IP behavior) as well as external-facing entries in the (S-RLOC, G) that require encapsulation." That is straightforward and brings a bit of clarity - and also makes it clear that an ITR must be able to make two copies of a packet - one encapsulated & one not. >>>> I understand that this isn't ideal because multiple copies of data are >>>> going into the core - but the trees are different there too. >>> >>> Which trees are different? >> >> The ones referred to in sec 9.1.5: >> >> " =A0 1. =A0Make the LISP ITR in the source multicast site send two pack= ets, >> =A0 =A0 =A0one that is encapsulated with (S-RLOC,G) to reach LISP receiv= er >> =A0 =A0 =A0multicast sites and another that is not encapsulated with >> =A0 =A0 =A0(S-EID,G) to reach non-LISP and uLISP receiver multicast site= s." > > We have no choice but to do this. The receiver sites are incompatible. Right - this is a fine approach. I'm looking for a stake that says "Because an ITR must be able to send two packets, one encapsulated to external-facing entries and one not encapsulated to internal-facing entries, approach (1) SHOULD be implemented." >>>> What I'm looking for is some normative text about what MUST/SHOULD be >>>> supported - even for experimental interoperability. >>> >>> If there are mPETRs deployed an ITR can use option 2. If not, option 1 = is >>> the only option. >> >> So - why not require option 1 to be implemented? =A0Is it a requirement = to >> support >> mPETRs? > > Yes. So - the operator configures whether mPETRs are available for all cases??? = How does an ITR know? >>>> The second option seems like it comes naturally - if a Join comes for >>>> the (S-RLOC, G), then it is sent the encapsulated packet. >>> >>> Right, if joins come from the mPETRs. >> >> Regardless of where the join came from... >> Otherwise, how does the ITR know that the join is from an mPETR > > The joins we are talking about here are native ones, not ECM based joins.= So > you don't know if they are coming from mPETRs or non-LISP receiver multic= ast > sites. ?? If a join comes to (S-RLOC, G), then it is coming from an ETR or mPETR. If the join comes to (S-global/EID, G), then it is coming from a non-LISP receiver multicast site or uLISP site. Alia From akatlas@gmail.com Wed Jun 22 15:32:49 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C141F0C44 for ; Wed, 22 Jun 2011 15:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rw0yHYL1X9W9 for ; Wed, 22 Jun 2011 15:32:46 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9671F0C42 for ; Wed, 22 Jun 2011 15:32:45 -0700 (PDT) Received: by ewy19 with SMTP id 19so479798ewy.31 for ; Wed, 22 Jun 2011 15:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ttQT5wcRJ/ll4/53eyxqLV2yiQHUJWfQUe1HXxdV81o=; b=ZhgsNRolZOZJ08WTP43xNDZ+GultdNm5t3xW+nNRQMftzIhPXJedCck9MkoLkjNGGX TdcDirV4g0QHPztmU9dAiIQB22scdXz40+3fxoaKJxfMyK4Gmf8Smc3B8ab4fdNda2va 6dLI9QQwtD3HGGAtfJV9W34XI2RFwayuPopcg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=bE/j8jg1+qc1QbjeE1anC0MqS0nJoOu5wjv7nYFLfl5B4VNgSOnlXKXHgvHeBr9Oy0 xpTeDJXCeLzXUcoUEon0p/ltuJCJCDGBYJEnZQL6B42muD0ZlEKKzTAjNmeVsGhE3FKo OPyLq3L1KNM2jSMPaGaMdpfemmzL77ffKs8zM= MIME-Version: 1.0 Received: by 10.14.95.68 with SMTP id o44mr929148eef.208.1308781964500; Wed, 22 Jun 2011 15:32:44 -0700 (PDT) Received: by 10.14.189.3 with HTTP; Wed, 22 Jun 2011 15:32:44 -0700 (PDT) In-Reply-To: <00D02FFF-2E45-4F5D-9DEC-F5F0961C62D3@cisco.com> References: <00D02FFF-2E45-4F5D-9DEC-F5F0961C62D3@cisco.com> Date: Wed, 22 Jun 2011 18:32:44 -0400 Message-ID: From: Alia Atlas To: Dino Farinacci Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "lisp@ietf.org" Subject: Re: [lisp] Last call for draft-ietf-lisp-12 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2011 22:32:49 -0000 Dino, Thanks for your responses - mine are in-line below. Alia On Mon, Jun 20, 2011 at 6:19 PM, Dino Farinacci wrote: >> I have reviewed this this draft and think it needs more work before it >> is ready to proceed. >> I have a few general questions and comments - as well as text-specific >> ones. > > Thanks for the thorough review Alia, it is appreciated. See responses in > line. Sorry it took over a month to get back to you on this. > >> I hope this leads to fruitful discussion on the list. =A0I am also happy >> to add all of these to >> the Issue Tracker if necessary. >> >> 1) Can an EID and an RLOC have the same value? =A0They are different >> namespaces, >> =A0but assumptions in the various drafts imply not. =A0Could this please >> be explicitly stated? > > See my explanation below. > >> 2) Where is the explicit text saying what EID-prefixes an ETR can >> register or reply authoritatively? =A0E.g. Can an ETR advertise a prefix >> (10.1/16) with holes (10.1.1/24)? =A0Answer should be no, of course, but >> extremely clear >> rules on this are needed. > > If the site has an EID-prefix of the /16 that is the one it Map-Replies f= or. > We have rules in section 6.1.5 "EID-to-RLOC UDP Map-Reply Message" on how= to > send Map-Replies when there are overlapping EID-prefixes and there has be= en > much discussion on this mailing list about it. I agree that there's been lots of discussion on the list. Capturing the decisions made into the draft would be good practice, IMHO, and ensure it has been resolve= d. Can an ETR have an prefix which has a hole in it? What happens if the ETR does not know the correct RLOCs to use for that hole (since it isn't owned)? I'm thinking of a case where initially there is a LISP site with a /16. Then, part of that company is sold along with the /24 that is used in that division. Now, can the original site advertise the /16 with a hole? How would it do that? The problem here is that the ETR does NOT KNOW the correct locator-set for the /24 hole that has been sold off. >> 3) Generally, a section specifying ETR behavior in regard to packets >> is missing. =A0 What is specified is scattered widely. > > "in regard to packets" is not clear what you are asking for. Do you mean = for > decapsulation purposes? If so, > in section 5.3 starting with text "When doing ETR/PETR decapsulation:" wi= ll > explain it. I was looking for details beyond the basic packet manipulation. I gave a c= ouple examples of the type of info I'm looking for in i) and ii) below. Having clearly specified behavior in one location that relates to packet-handling and errors/ICMP is useful. Another example is the R-bits manipulation... This is, I think, another place where there aren't experimental questions -= and a very clear straightforward section describing what MUST be done would hel= p with interoperability. >> =A0i) For instance, if an ETR receives a LISP encapsulated packet and >> decapsulates it, >> =A0 =A0 but does not have EID locally, what should the ETR do? > > Drop the packet. When decapsulation occurs, the inner header is inspected > and what an IP router does today is what it does post decapsulation. Another option is for the ETR to look up the EID in the mapping database an= d forward it. Or the ETR could try and route it assuming the destination IP address is globally routable. That the correct decision is to drop the packet is NOT specified. There are indications in the draft of decapsulation and reencapsulation & when those should be do= ne is not specified. >> =A0ii) Does an ETR have to do packet fragment reassembly? =A0If an ETR >> does not support >> =A0 =A0 fragment reassembly, should it send an ICMP Too Big message and >> drop the fragment? >> =A0 =A0 What should an ETR do with a fragment directed to its RLOC? > > The ETR follows the IP and IPv6 specification in regards to reassemly of > fragments. However, we try to avoid fragmentation. See section 5.4 "Deali= ng > with Large Encapsulated Packets" for solutions. Of course, I read through that section. My concern is the case where an IT= R may set the DF bit to 0. "When the outer header encapsulation uses an IPv4 header, an implementation SHOULD set the DF bit to 1 so ETR fragment reassembly can be avoided. An implementation MAY set the DF bit in such headers to 0 if it has good reason to believe there are unresolvable path MTU issues between the sending ITR and the receiving ETR." IF everything needs to be implemented, then an ETR has to be prepared for an ITR to do that (adversarially if nothing else) and handle reassembly at line-rate. >> 4) Generally, a section specifying ITR behavior in regard to packets >> is missing. >> =A0i) For instance, if an ITR receives a Negative Map Reply indicated >> =A0"drop", should the ITR send an ICMP Destination Unreachable with >> =A0Host Unreachable? > > We did not want to specify this because in practice when this is done eit= her > the ICMP messages are either rate-limited or filtered so ICMP is not a > reliable mechanism. > > Experimentation will tell us more on what to do. Do you think those are strong concerns inside a single LISP site? Rate-lim= ited is not the same as completely removed. As specified, there is no mechanism for the end-host to tell what's happening to its packets. If you are going for parallelism to what an IP router does, then I think an= ICMP Destination Unreachable is appropriate. IF not, then similarly specifying that it should not be sent & why would be useful. >> =A0ii) If an ITR receives an ICMP packet (other than TTL exceeded) to >> =A0its RLOC, how does it properly handle or forward it? > > Just like an IP router does today. An IP router doesn't have to figure out which end-host the message should h= ave gone to instead; the ICMP packet would have gone there. This is a PURELY = LISP problem. The ICMP packet is in response to an encapsulated packet. There are explic= it mechanisms described to make sure that TTL exceeded works. What about Port Unknown or all the other ICMP messages that are intended to reach the end-host associated with the EID? How does an ITR know which EID was the source of the packet that the ICMP packet is responding to? >> 5) Are interfaces inside the LISP site explicitly configured on the >> xTR or is there a way for the ITR to identify them? > > That is up to the implementation, but the 3 cisco implementations do not > have this explicit configuration. Is there a mechanism that is expected to inter-operate by which the cisco implementations do not need this? >> Here are my questions tied specifically to the points in the text (and >> some typos): > > Consider these done. I will comment for which comments we will make a cha= nge > and when you don't see that, we did not make a change for your comment. > >> a) On p 8 in EID-prefix: >> =A0"A globally routed address block may be used by its assignee as an >> =A0EID block." >> >> There are comments in other drafts also being last-called that imply >> it is possible to tell is a value is an EID or an RLOC - but other >> places, such as this, where it is clear that a value may be both an >> EID and an RLOC. > > An address is an EID for sake of encapsulation when it is found in the > mapping database. Since EID namespace and RLOC namespace *architecturally= * > are different spaces, an EID and an RLOC can have the same value. In > practice, we believe when a prefix is not in the BGP DFZ core routing tab= les > and registered to the mapping database is when the personality of an IP > address changes from an locator prefix to an EID-prefix. > > In practice, we have to deal with interworking, so we will find that > EID-prefixes will be in the DFZ for transition purposes. And an EID-prefi= x > and a regular route-prefix do not have to match, one can be a more-specif= ic > of the other which does complicate things. In any event, using more speci= fic > lookup matches, as we have been doing for decades in the routing system, > will continue to happen. So if a destination address in a packet matches = a > more specific prefix in the mapping database, then the destination is > considered an EID. If the more specific route is in the DFZ, then the > destination is not considered an EID and is routed natively. > > I like to call the addresses we use today as locators or RLOCs. Not every= one > agrees with this thinking because things are more complicated than that. = But > I would like to think the addresses that are in the DFZ routing table tod= ay > are "topological locations" and when a locator or RLOC is used in LISP, i= t > is exactly this same routable address that is used. OK - so the EID and RLOC space are *architecturally* different namespaces, = but in reality any overlap is assumed to be used by the same entity and go to the same end-host?? >> Clarification of this is important >> >> b) p. 10 Reencapsulating Tunnels: I do not see any references or >> suggestions on how these would be used. =A0I am also concerned about how >> routing/forwarding loops are prevented. > > The rules for TTL decrement occur across these re-encapsulating boundarie= s. Yes - but while that eventually kills the packets, other traffic on the links is impacted and continues to be. If xTR A forwards a packet to ETR B who forwards it to ETR C and ETR C forwards it back to xTR A, there's a forwarding loop that continues to have a negative impact. TTL is to stop a packet caught in a forwarding loop from living forever in the network. It doesn't stop more packets from getting caught in the forwarding loop. >> Could this be explicitly set as for future study & experimentation? > > The use-cases are cropping up and yes we are experimenting with solutions > for them. > >> I can see ways to make it work and ways that might fail - but nothing >> providing details or mechanisms to avoid, detect, handle, or manage >> problems. >> >> c) p. 13: 3rd paragraph from bottom: The discussion about prepending >> additional LISP headers for TE doesn't give any indications or ideas >> of how an ISP transit might identify that it needs to prepend a TE-ETR >> RLOC or how it would find such an RLOC. =A0Given the complete lack of >> detail about this in this draft and the others being last-called, >> please explicitly specify this as experimental and for future study. > > Please when you make comments, provide the text from the spec, so others > reading this can understand the context. Then my comments will be 10 times as long... but I'll try. > So for others, here is the > paragraph that Alia is referring to: > > =A0 An additional LISP header may be prepended to packets by a TE-ITR > =A0 when re-routing of the path for a packet is desired. =A0An obvious > =A0 instance of this would be an ISP router that needs to perform traffic > =A0 engineering for packets flowing through its network. =A0In such a > =A0 situation, termed Recursive Tunneling, an ISP transit acts as an > =A0 additional ingress tunnel router and the RLOC it uses for the new > =A0 prepended header would be either a TE-ETR within the ISP (along > =A0 intra-ISP traffic engineered path) or a TE-ETR within another ISP (an > =A0 inter-ISP traffic engineered path, where an agreement to build such a > =A0 path exists). > > It was mentioned at a working group meeting that a Traffic Engineering dr= aft > needs to be written, but since that is out of charter, it has not been > assigned. Perhaps, when the working group changes charter after posting o= f > the experimental RFCs, we can do this work. Yup - that sounds like future study to me. >> Also, please change "An obvious instance of this would be..." to "A >> potential use-case would be..." > > Consider this changed. > >> d) p. 13: 2nd paragraph from bottom: What is the appropriate behavior >> for an ITR to do when it receives a packet that it would normally >> prepend a LISP header to but cannot? =A0Could you please add a "SHOULD >> drop and SHOULD send back an ICMP message"? =A0I don't see an appropriat= e >> code point defined yet... > > Here is the 2nd paragraph from the bottom of page 13: > > =A0 In order to avoid excessive packet overhead as well as possible > =A0 encapsulation loops, this document mandates that a maximum of two > =A0 LISP headers can be prepended to a packet. =A0It is believed two > =A0 headers is sufficient, where the first prepended header is used at a > =A0 site for Location/Identity separation and second prepended header is > =A0 used inside a service provider for Traffic Engineering purposes. > >> To contradict the idea that 2 headers is sufficient, just look at the >> deployment draft where a LISP site is dangling off another LISP site - >> causing 2 LISP headers and then the possibility of a Service Provider >> wanting to prepend one for TE purposes. > > Right, when we go off and do the TE spec, we will decide if this should b= e > lifted. We want this to be strict now because hardware engineers want a h= ard > limit. My feedback from doing MPLS in hardware was that having it variabl= e > length and limitless was a huge problem. So most hardware implementations= of > MPLS ship with just 2 label stacks. Yes, there's a game in MPLS of deciding how many labels down one needs to g= o - but it has allowed a lot more flexibility. Anyhow, on the packet-handling bit - what should be done if this limit woul= d be violated? >> Third, please rephrase the "It is believed..." to something like "The >> LISP experiment will presume..." or "LISP experimentation will start >> with the assumption that..." > > I changed the text to "For initial LISP deployments, is is assumed two > headers is sufficient". "but no explicit error-handling will be done??" >> e) Sec 5, first paragraph: How does an ITR that wants to encapsulate a >> LISP-encapsulated packet for TE send back an ICMP Too Big message? > > You didn't get to section 5.4 yet. When you get there, you should have yo= ur > answers. =A0;-) Sadly, I actually had. This is the TE-part, where an ITR needs to tell ano= ther ITR (I guess) or the end-host that the packet is too big. >> f) Sec 5: There is no indication in the packet formats that IPv4 in >> IPv6 or IPv6 in IPv4 SHOULD be supported. =A0I don't care about long >> format sections - but at a minimum, there should be a paragraph that >> specifies the encapsulation possibilities: >> >> =A0"A LISP packet consists of an outer header, a UDP header, and an >> =A0inner header. =A0The following combinations MUST be supported: >> =A0 =A0i) IPv4 outer header and IPv4 inner header (in Sec. 5.1) >> =A0 =A0ii) IPv6 outer header and IPv4 inner header >> =A0 =A0iii) IPv6 outer header and IPv6 inner header (in Sec 5.2) >> =A0 =A0iv) IPv4 outer header and IPv6 inner header " > > I don't understand this comment. The summary is in the table of contents > section names: > > =A0 5. =A0LISP Encapsulation Details . . . . . . . . . . . . . . . . . . = 16 > =A0 =A0 5.1. =A0LISP IPv4-in-IPv4 Header Format =A0. . . . . . . . . . . = . . 17 > =A0 =A0 5.2. =A0LISP IPv6-in-IPv6 Header Format =A0. . . . . . . . . . . = . . 17 > =A0 =A0 5.3. =A0Tunnel Header Field Descriptions . . . . . . . . . . . . = . 19 Right - there is no description of DIFFERENT IP VERSIONS - e.g. IPv6 in IPv= 4 or IPv4 in IPv6 NOWHERE in the draft is this specifically said to be allowed or expected, but list conversations certainly imply it. >> g) An explicit statement that a LISP data packet appears as a UDP >> packet destined to port 4341 and a LISP control packet appears as a >> UDP packet destined to port 4342 would help for those who skim packet >> formats. > > You can find that here in section 5.3: > > =A0 UDP Header: =A0The UDP header contains a ITR selected source port whe= n > =A0 =A0 =A0encapsulating a packet. =A0See Section 6.5 for details on the = hash > =A0 =A0 =A0algorithm used to select a source port based on the 5-tuple of= the > =A0 =A0 =A0inner header. =A0The destination port MUST be set to the well-= known > =A0 =A0 =A0IANA assigned port value 4341. > > and here for control packets: > > =A0 The LISP UDP-based messages are the Map-Request and Map-Reply > =A0 messages. =A0When a UDP Map-Request is sent, the UDP source port is > =A0 chosen by the sender and the destination UDP port number is set to > =A0 4342. =A0When a UDP Map-Reply is sent, the source UDP port number is > =A0 set to 4342 and the destination UDP port number is copied from the > =A0 source port of either the Map-Request or the invoking data packet. > =A0 Implementations MUST be prepared to accept packets when either the > =A0 source port or destination UDP port is set to 4342 due to NATs > =A0 changing port number values. Yes, I was looking for something short, pithy, and sooner. This isn't a bi= g deal - obviously, it is specified. I'd just missed it the first time or so reading through. >> h) p.19: When is it desirable to not have a Nonce value in a packet? >> The Map-Version seems rather useful; which is required for support for >> the initial LISP experimentation? > > When doing the echo-nonce Locator Reachability Algorithm. > >> Also, the Nonce field could use similar description to that on p.29 >> for the Nonce value - at least as far as how to produce one and >> what it is protecting against. > > It says it here: > > =A0 Nonce: =A0An 8-byte random value created by the sender of the Map- > =A0 =A0 =A0Request. =A0This nonce will be returned in the Map-Reply. =A0T= he > =A0 =A0 =A0security of the LISP mapping protocol depends critically on th= e > =A0 =A0 =A0strength of the nonce in the Map-Request message. =A0The nonce > =A0 =A0 =A0SHOULD be generated by a properly seeded pseudo-random (or str= ong > > > > Farinacci, et al. =A0 =A0 =A0 Expires December 8, 2011 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 [Page 29] > Internet-Draft =A0 =A0Locator/ID Separation Protocol (LISP) =A0 =A0 =A0 = =A0June 2011 > > > =A0 =A0 =A0random) source. =A0See [RFC4086] for advice on generating secu= rity- > =A0 =A0 =A0sensitive random data. Yup - that is for the Map-Request and Map-Reply. It doesn't mean that it applies to the Echo-Nonce Locator Reachability Algorithm. In fact, I'd assumed that it didn't.. >> i) p. 20 L: The diagram indicates that the 2nd 32 bits are only >> Locator Status Bits, but the description under the I bit indicates >> that the I and L bit could be set at the same time - in which case the >> 2nd 32 bits aren't just Locator Status Bits. =A0Please align the diagram >> and description to better match the existence of the I bit. > > I think you misread this. The text and the diagrams are consistent. And y= ou > must note the binary settings (with the notation of "x" as don't care bit= s). > =A0See here: > > =A0 L: The L bit is the Locator-Status-Bits field enabled bit. =A0When th= is > =A0 =A0 =A0bit is set to 1, the Locator-Status-Bits in the second 32-bits= of > =A0 =A0 =A0the LISP header are in use. > > > =A0 =A0 x 1 x x 0 x x x > =A0 =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =A0 =A0|N|L|E|V|I|flags| =A0 =A0 =A0 =A0 =A0 =A0Nonce/Map-Version =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0| > =A0 =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Locator Status Bits = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| > =A0 =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sorry, let me try again. The description and diagram for the L bit ignores= the existence and changes done by the I bit. Is it possible to have the I and L bit both set? The description under the I bit implies that the L bit could be set to 1 - but gives the behavior if the L bit is 0. Just looking for consistency and clarity on this nit-picking detail. >> j) typo: p. 20 V >> =A0"This bit indicates that the first 4 bytes of the LISP header is >> =A0 encoded as:" >> but it show the 8 bytes of the LISP header and the second 4 are shown >> as being "Instance ID/Locator Status Bits" > > Right, the description wants to show the entire LISP header but wants you= , > the reader, to focus on the ulong that the V-bit is pertaining to. What about a minor text change: "This bit indicates that the first 4 bytes of the LISP header is encoded as= :" =3D> "This bit indicates that the first 4 bytes of the LISP header is encoded as shown below in the complete LISP header." Again, this is more of a nitpick - but it was confusing the first couple ti= mes I read it over. >> Also, for the I bit, the last 4 bytes are referred to, but all 8 are >> shown. > > Same as above comment. > >> k) p. 21 flags: I think this should be a "It MUST be set to 0 on >> transmit and MUST be ignored on receipt" - if we want it to be really >> available for the future... >> >> Same for the Reserved field on p.29, p.33 > > Consider text updated for all 3 places. thanks >> l) typo p. 21, end of LISTP Locator Status Bits: >> =A0"with that address taht the ETR is considered 'up'" -> ITR >> I think the ITR is the one who decides and sets the LSBs... > > Fixed typo. No it is ETR. New text is clearer - or makes more sense to me now. >> m) p. 21/22: The TTL copying from inner to outer should be a MUST not >> a SHOULD on encapsulation. =A0The TTL copying from outer to inner should >> be a MUST not a SHOULD on decapsulation. > > It was agreed on by the working group to be SHOULD. Really?? *shock* I wonder why - it seems quite dangerous to me. >> Why does the draft say "when the Time to Live field of the outer >> header is less than the Time to Live of the inner header"? How could >> that not be the case if copying the TTL from inner to outer is >> required? =A0Please remove the text: > > Because there can be a bug on the ITR/PITR where it is violating the spec= . Ah - the joys of defensive coding. Perhaps a hint that this isn't an expec= ted condition and is an indication of an error (or at least a SHOULD violation)= . >> =A0", when the Time to Live field of the outer header is less than the >> =A0Time to Live of the inner header. =A0Failing to perform this check ca= n >> =A0cause the Time to Live of the inner header to increment across >> =A0encapsulation/decapsulation cycle. =A0This check is also performed >> =A0when doing initial encapsulation when a packet comes to an ITR or >> =A0PITR destined for a LISP site." >> >> n) Sec 5.4: This says that both, either or neither of the mechanisms >> can be implemented. =A0However, in Sec 5.4.1, it says: >> =A0"An implementation MAY set the DF bit in such headers to 0 if it has >> =A0good reason to believe there are unresolvable path MTU issues >> =A0between the sending ITR and the receiving ETR." >> >> This transforms the requirement from being imposed just on the ITR to >> something that the ETR has to deal with. =A0If a LISP-encapsulated >> packet is fragmented, then the ETR needs to do the reassembly. > > Right, and the ITR has violated the spec. The spec is saying that > fragmentation is done first and encapsulation second so the end-system > reassembles and not the ETR. So - I agree that the ITR should fragment first and then encapsulate - but the ITR MAY set the DF bit to 0. That's right above in the spec so I don't see how it is violating the spec - and it opens up the standard reassembly at line-= rate problems to the ETR. >> o) Sec 5.5: While an Instance ID allows disambiguation of addresses, I >> do not see any means of requesting or obtaining a EID-to-RLOC mapping. >> There is no such field in the Map-Request or Map-Reply messages. =A0It >> doesn't work with [ALT]. =A0Please add a paragraph such as: >> >> =A0"While a LISP header can contain an Instance ID, there are currently >> =A0no provisions for requesting or receiving an EID-to-RLOC mapping >> =A0that considers Instance-IDs. =A0A LISP-NAT (described in [INTWRK]) ma= y >> =A0provide a better solution for private addresses. =A0The use of >> =A0Instance-ID as described here is provided for future study." > > The AFI encoded addresses can carry different address formats. Once AFI i= s > called LCAF. See draft-farinacci-lisp-lcaf-05.txt for details. That still sounds like future study to me - or at least a note that "work is on-going" or such. >> p) Sec 6.1: "The following new UDP packet types are used to retrieve >> EID-to-RLOC mappings" >> >> Please change to the more accurate: >> >> =A0"The following new UDP packet formats are used for LISP control >> =A0packets. The different packet types are listed in Sec. 6.1.1." > > I changed to the first sentence. Thanks. > >> Please move Sec 6.1.1 to before Sec 6.1 - so that readers know the >> allocated packet types before reading the descriptive text. > > This part introduces UDP. We go the the LISP header in the next sub-secti= on. > That is why it was sequenced that way. Note in section 6 there is no deta= ils > of the format of the "LISP Message". Ok - I still think knowing about the packet types before they're talked abo= ut is useful - but the names are pretty descriptive in general. >> After the packet formats, please change: >> =A0"The LISP UDP-based messages are the Map-Request and Map-Reply >> =A0messages. =A0When a UDP Map-Request is sent, the UDP source port is >> =A0chosen by the sender and the destination UDP port number is set to >> =A04342. =A0When a UDP Map-Reply is sent, the source UDP port number is >> =A0set to 4342 and the destination UDP port number is copied from the >> =A0source port of either the Map-Request or the invoking data packet." >> >> to >> >> =A0"When a Map-Request or a Map-Register, encapsulated or not, is sent, >> =A0the UDP source port is chosen by the sender and the destination UDP >> =A0port number is set to 4342. =A0When a Map-Reply or Map-Notify is sent= , >> =A0the source UDP port number is set to 4342 and the destination UDP >> =A0port number is copied from the source port of either the Map-Request >> =A0or the invoking data packet." > > I prefer to not change it to what you suggest. Because you could imply fr= om > your text that a Map-Register message is encapsulated. It can be encapsulated!!! " UDP: The inner UDP header where the port assignments depends on the control packet being encapsulated. When the control packet is a Map-Request or Map-Register, the source port is ITR/PITR selected and the destination port is 4342. When the control packet is a Map-Reply, the source port is 4342 and the destination port is assigned from the source port of the invoking Map-Request. Port number 4341 MUST NOT be assigned to either port. The checksum field MUST be non-zero. " > And each section indicates how each packet is sent. I was trying to combine the logic so it is clear what the set of common behavior is. >> q) Sec 6.1.2: =A0Is the A bit ever non-zero for a Map-Request? > > We did not want to specify it but we were thinking of an option where the > Map-Request sender could request an authoritative request so if there wer= e > cachers of a matching mapping, that the cachers would send to the ETRs. So - is this a reserved for future use thing? Where currently a Map-Reques= t sender MUST set it to 0 and it MUST be ignored - for now? >> r) Sec 6.1.2: Why is the p bit needed? =A0What does a ETR do based upon >> the Map-Request coming from a PITR (or not)? > > It is useful for debugging. The ETR could cache the number of PITRs that > have sent Map-Requests to it. K - clarification in the text? >> s) Sec 6.1.3 first paragraph: Without LISP encapsulation and a >> Map Server, there isn't a way for an ITR to send a Map-Request to a >> destination-EID. > > If the ITR is connected to the ALT, it can send the Map-Request to a > destination EID. It assumes that the ALT carries EID-prefixes in its rout= ing > system. It does?? Where was I supposed to have figured that out? I really did rea= d all these drafts thoroughly! >> The Mapping Service is required for operation - so it should be ok for > > Not true. k - I was combining the mapping database and the mapping service interface. >> the draft to mention the interfaces to it! =A0How about replacing this >> first paragraph with the below: >> >> =A0"An ITR can need to send a Map-Request for numerous reasons (e.g. to >> =A0get a mapping for an EID, testing an RLOC for reachability, or >> =A0refreshing a mapping before TTL expiry). =A0When the ITR knows an RLO= C >> =A0for the relevant ETR (e.g. from the map-cache entry), the ITR can >> =A0create a Map-Request destined directly to that RLOC. =A0If the ITR >> =A0does not know the relevant ETR to query, then the Mapping Service >> =A0[LISP-MS] must be used. =A0To do this, the ITR creates a Map-Request >> =A0destined to the destination-EID and LISP encapsulates it as an >> =A0"Encapsulated Control Message" that is destined to the Mapping >> =A0Service [LISP-MS]. =A0When an ITR receives a successful Map-Reply, th= e >> =A0ITR updates the cached set of RLOCs associated with the EID prefix >> =A0range." > > We don't want to say this right here because there are too many options a= nd > if we reduce the set, we don't want to rewrite this text. > > The API to the mapping system that xTRs use are the Map-Request, Map-Repl= y, > and Map-Register messages. That we don't want to change if we change the > mapping system. Right now, the mapping system is pretty modular and it is > easy to change in and out without modifications to ITRs and ETRs. I was trying to specify the use of the mapping system APIs and that logic. >> t) p.33 Record TTL: >> =A0"Record TTL: The time in minutes the recipient of the Map-Reply will >> =A0store the mapping. =A0If the TTL is 0, the entry SHOULD be removed >> =A0from the cache immediately. =A0If the value is 0xffffffff, the >> =A0recipient can decide locally how long to store the mapping." >> >> Since the ITR controls its own cache and cache entries, what I think >> you meant and would be more clear is: >> >> =A0"Record TTL: The maximum time in minutes that the recipient of the >> =A0Map-Reply may store the mapping. =A0If the TTL is 0, the entry MUST >> =A0be removed from the cache immediately. =A0IF the value is 0xFFFFFFFF, >> =A0the mapping does not expire and may be stored indefinitely." > > You changed "will" to "may". We wanted stronger language than what you > provided. We don't want ITRs to ignore TTL values. But either the ITR is in charge of its cache or it isn't! If the ITR can't decide to remove the entry, then how can the ITR do cache management?? >> u) p. 33 No-Action: What packet encapsulation can happen!??!! =A0There's >> no RLOC to send the packet to! =A0Please clarify. > > I will fix and say, the packet is dropped. Thanks. > >> v) p. 33 Drop: On dropping the packet, is the sender ever notified? >> What about some ICMP for troubleshooting? > > Up to the implementation. That's going to make management fun - particularly of mixed environments. What about a recommendation for ICMP or at least consideration - so that it can be manageable when implemented b= y mere mortals? >> w) p. 34 Weight: Why is the ETR specifying that all locators get equal >> weight used for the ITR getting to decide? =A0This seems like a valid >> decision by the ETR! =A0Why not use weight=3D0 means ITR gets to decide = as >> clearly specified on p.44 first full bullet? > > The ETR allows the ITR to decide *within the highest priority* set of > locators. Yes, the question isn't about the "within the highest priority" set. The question is why is there different logic specified in p.44 first bullet: " o Server-side sets weight of 0 for the RLOC subset list. In this case, the client-side can choose how the traffic load is spread across the subset list. Control is shared by the server-side determining the list and the client determining load distribution. Again, the client can use alternative RLOCs if the server-provided list of RLOCs are unreachable. " versus the different and inconsistent on p.34 " Weight: when priorities are the same for multiple RLOCs, the weight indicates how to balance unicast traffic between them. Weight is encoded as a relative weight of total unicast packets that match the mapping entry. For example if there are 4 locators in a locator set, where the weights assigned are 30, 20, 20, and 10, the first locator will get 37.5% of the traffic, the 2nd and 3rd locators will get 25% of traffic and the 4th locator will get 12.5% of the traffic. If all weights for a locator-set are equal, receiver of the Map-Reply will decide how to load-split traffic. See Section 6.5 for a suggested hash algorithm to distribute load across locators with same priority and equal weight values." I am asking why setting the weights for a locator-set equal (assume case with one priority for all) means that the ITR gets to decide how to split t= he traffic? If you want the ability to specify that, why not use a weight of = 0 - as specified on p.44 and quoted in the first paragraph above. >> x) p. 36 Mapping Protocol Data: [ALT] does not use this field. =A0Please >> remove the reference. > > Agree, will remove. > >> y) p.46: What happens when two ITRs send different LSB information >> (e.g. in the case of a partitioned LISP site)? > > The ETR can note the fact and decide to probe each one to find out what i= s > going on. If the LSBs are in conflict, the ETR can conclude that the site= is > partitioned. K - did you add some text specifying this? Otherwise, I can see the set bouncing... >> z) p.53 2nd paragraph from end: Unsolicited SMR-based Map-Requests >> MUST be sent to the mapping database system seems like an easy way to >> do a DDoS on the mapping database system - and have them all look >> valid and authenticated. > > That is not what the 2nd paragraph on page 53 says. Again, this is confus= ing > to parse since you don't sight the exact text. I meant 2nd paragraph as opposed to the bullets. It is below. " For security reasons an ITR MUST NOT process unsolicited Map-Replies. To avoid map-cache entry corruption by a third-party, a sender of an SMR-based Map-Request MUST be verified. If an ITR receives an SMR- based Map-Request and the source is not in the locator-set for the stored map-cache entry, then the responding Map-Request MUST be sent with an EID destination to the mapping database system. Since the mapping database system is more secure to reach an authoritative ETR, it will deliver the Map-Request to the authoritative source of the mapping data." > Map-Requests of all kind need to be rate-limited if the implementation is > spec compliant. If not, then the MR should rate-limit accepting them. We = did > not specify this since there are all sorts of ways to mitigate this and m= ore > experimentation will be necessary to understand solutions better. ?? K - where is that specified? I agree that it makes sense for system des= ign - though it can cause problems in terms of latency. >> aa) Sec 7: How is a tunnel encapsulated packet received by an ETR with >> an EID in the destination? =A0Do you mean a non-LISP-tunnel encapsulated >> packet?? > > Years ago we used a concept of data-probes. That was a map-request in the > form of an encapsulated data packet where the inner destination and outer > destination were the same value. This assumed the core carried EID-prefix= es. > This is still in the spec because there are people who believe packets > should not be dropped while waiting for a Map-Reply to be returned to an > ITR. Hmm, what about a brief intro comment such as: "As in the case of data-probes, ..." >> ab) Sec 8 last bullet: >> =A0"The technique of re-encapsulation ensures that packets only require >> =A0one tunnel header. =A0So if a packet needs to be rerouted, it is firs= t >> =A0decapsulated by the ETR and then re-encapsulated with a new tunnel >> =A0header using a new RLOC." >> >> When would this legitimately happen? =A0It seems like risking looping... > > When you want to redirect your encapsulation to an intermediate point for= TE > purposes, packet scrubbing purposes, to go through a stateful firewall, e= tc. > And the TTL copying rules make it not loop forever. Some specification of these cases as examples would bring clarity. And the death of one lemming doesn't stop the others from going over the cliff :-) >> ac) Sec 14: The list of LISP Control Packet types (Sec 6.1.1) should >> also be an IANA registry... > > That has not been decided by the working group. Oh - ok. I'm used to it being standard practice. How else would they be managed? Thanks - I don't think you missed a question! Alia >> Looking forward to your responses, >> Alia > > Thanks again, > Dino/Vince/Darrel/Dave > > From akatlas@gmail.com Wed Jun 22 15:38:22 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66DE1F0C4A for ; Wed, 22 Jun 2011 15:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBwGnIzBzEsx for ; Wed, 22 Jun 2011 15:38:22 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8641F0C41 for ; Wed, 22 Jun 2011 15:38:21 -0700 (PDT) Received: by ewy19 with SMTP id 19so481159ewy.31 for ; Wed, 22 Jun 2011 15:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=NHwes5d9MY/jDNz7gNpywjenh4BIp6pxcAzPW+KSyas=; b=aDvwGQjqSiM8rLHm5XhWWil9U6rqif0GHNC78klOHMY6To1rCeSThoXQ2urUad7vdX 1hJbCCrtkCvDPeZio70cLtsM8RDrx5OK7cOPtY9fFuHDu5ZNtrY+8IK7Zk9IlQQTYEQG lb7OeagabfuEJfkHWi7FdtJevCvcIWHUGzWeE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=K7wv0wZ8nelff/ul8MpDf1oxbW9TcCnIzyGkPwPIqwYDOR6xstNNq+5g3lEv5VmTBg WGisTR/K0XN1YjgBCv108ixCOZnnxtxWozhocTjwUWQa0/y+gh1WS7mvi+yxMJGJi+5E FiBIR46tE3ZW33YfsjnPnD/mHaMjsgNljjPtw= MIME-Version: 1.0 Received: by 10.14.28.16 with SMTP id f16mr954828eea.176.1308782301166; Wed, 22 Jun 2011 15:38:21 -0700 (PDT) Received: by 10.14.189.3 with HTTP; Wed, 22 Jun 2011 15:38:21 -0700 (PDT) Date: Wed, 22 Jun 2011 18:38:21 -0400 Message-ID: From: Alia Atlas To: lisp Content-Type: text/plain; charset=ISO-8859-1 Subject: [lisp] architecturally separate name-spaces - but assumption about a single value means same thing if in both? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2011 22:38:23 -0000 >From the discussion on draft comments, I have the following basic question: Is a value A is assigned to either the EID space or the RLOC space? Could site X have an EID with value A while site Y (or even a non-LISP) has an RLOC (or globally routable address) with the same value A? For instance, consider deploying an IPv4 LISP site now. Could one take an IPv4 prefix already used globally by a different company/site - and use it for my new LISP site as an EID prefix? Do all the drafts always check for the IP address in the mapping database to see if it is an EID? I recall seeing some cases of checking the global routing table - but that could be bad memory at this point. Could a host in a LISP site send to an IP address as an EID and the same IP address as a globally addressable (or routable)? I am confused because "architecturally" I believe the EID space and the RLOC space are separate namespaces - but in practice in the drafts, it seems that a given value must belong to a single entity, whether it is used as an EID, globally addressable, or both. Is this clearly specified anywhere? What am I missing? Alia From jmh@joelhalpern.com Wed Jun 22 15:49:55 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6EF69E8040 for ; Wed, 22 Jun 2011 15:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.71 X-Spam-Level: X-Spam-Status: No, score=-102.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ogt2LXHhr-lG for ; Wed, 22 Jun 2011 15:49:55 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfa.amsl.com (Postfix) with ESMTP id 20E489E803F for ; Wed, 22 Jun 2011 15:49:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 1480E3246533; Wed, 22 Jun 2011 15:49:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.154.181.49] (unknown [129.192.185.163]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 715FB3228BF3; Wed, 22 Jun 2011 15:49:24 -0700 (PDT) Message-ID: <4E027170.9030802@joelhalpern.com> Date: Wed, 22 Jun 2011 18:49:20 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Alia Atlas References: <00D02FFF-2E45-4F5D-9DEC-F5F0961C62D3@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] Last call for draft-ietf-lisp-12: EID holes X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2011 22:49:55 -0000 The normal situation is that an EID block is delegated to an administrative authority (a company). They use it. They may use the main block, and use some sub-blocks. That produces "holes" which are overlapping prefixes. The handling of that is described in the document. The ETRs which are responsible for the covering EID prefix must know which blocks are allocated elsewhere. They have to identify those in the response. THe details are spelled out. The normal case would be that the division that was sold would be renumbered into its own or its new parents EID block. After all, they are no longer part of the original site. The overlapping prefix mechanisms allow for transition. The more extreme case is not permitted. You can not have a LISP EID block, within which there is a hole which is used as IP addresses but not as LISP EIDs. (The inner portion can be used as both, but it has to be an EID.) Yours, Joel On 6/22/2011 6:32 PM, Alia Atlas wrote: > Dino, > > Thanks for your responses - mine are in-line below. > > Alia > > On Mon, Jun 20, 2011 at 6:19 PM, Dino Farinacci wrote: ... >> If the site has an EID-prefix of the /16 that is the one it Map-Replies for. >> We have rules in section 6.1.5 "EID-to-RLOC UDP Map-Reply Message" on how to >> send Map-Replies when there are overlapping EID-prefixes and there has been >> much discussion on this mailing list about it. > > I agree that there's been lots of discussion on the list. Capturing > the decisions made > into the draft would be good practice, IMHO, and ensure it has been resolved. > > Can an ETR have an prefix which has a hole in it? What happens if the > ETR does not > know the correct RLOCs to use for that hole (since it isn't owned)? > > I'm thinking of a case where initially there is a LISP site with a > /16. Then, part of that > company is sold along with the /24 that is used in that division. > Now, can the original > site advertise the /16 with a hole? How would it do that? > > The problem here is that the ETR does NOT KNOW the correct locator-set > for the /24 hole > that has been sold off. > > From dino@cisco.com Wed Jun 22 16:07:55 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B9E21F84CC for ; Wed, 22 Jun 2011 16:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjnsnrXLS5a3 for ; Wed, 22 Jun 2011 16:07:55 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id F1BC521F84CB for ; Wed, 22 Jun 2011 16:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=3145; q=dns/txt; s=iport; t=1308784069; x=1309993669; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=hFZQsiBs/zczcG15r58+jGuhDEA9Wg5W+AML2zKc1xs=; b=I6++4wBj6ZWIl1/4M4nRWPNHRRJb23yYzfitA5/7OncrXn2dfgoReAQb 54aZxTjoDe0ncPtGuBnJcx66JfCi+sc3X3BduDisBfhT7HIKrcU2onk5q AaVOFqGj2d5ECaoVC6GCQbeRzFoXx/tMVg3zkcrcQHtJf95/O5t+Yx/5o Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPZ0Ak5Io8UQ/2dsb2JhbABTpxx3iHOiOJ4uhi0EhyWKRYRli0c X-IronPort-AV: E=Sophos;i="4.65,409,1304294400"; d="scan'208";a="96228003" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 22 Jun 2011 23:07:46 +0000 Received: from [192.168.1.200] (sjc-vpn5-1889.cisco.com [10.21.95.97]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5MN7hmM020791; Wed, 22 Jun 2011 23:07:44 GMT Message-Id: <21B84ED0-A75A-4160-8320-5E61AC154485@cisco.com> From: Dino Farinacci To: Alia Atlas In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 22 Jun 2011 16:02:48 -0700 References: X-Mailer: Apple Mail (2.936) Cc: lisp Subject: Re: [lisp] architecturally separate name-spaces - but assumption about a single value means same thing if in both? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2011 23:07:56 -0000 > From the discussion on draft comments, I have the following basic > question: > > Is a value A is assigned to either the EID space or the RLOC space? > Could site X have an EID with value A while site Y (or > even a non-LISP) has an RLOC (or globally routable address) with the > same value A? Architecturally, yes, the value A can be an EID and an RLOC. In practice, no, for IPv4 and maybe for IPv6. Let me explain. Since there are two namespaces for each of IPv4 and IPv6, it means, for the case of IPv4, there are two 2^^32 number assignment spaces. But we don't have two allocation authorities, one for each, so the addresses will be assigned from one 2^^32 pool and be used as either an EID or an RLOC depending if the site has converted to being a LISP site. For IPv6, if we had a PI allocation authority, then it would hand out EID prefixes to end sites. If we also had a PA allocation authority, then it would hand out RLOC addresses to infrastructure providers. In this case, if the two authorities acted independently, then the same value could be assigned for each namespace. This is not a problem to duplicate the address in each namespace. But I do believe for operational sanity it would be nice to look at logs, debugs, or whatever, see an address and decipher it is an EID versus an RLOC. This is one of the reasons the working group wants to request an IANA assigned /12 or /16 (not decided yet I think). > For instance, consider deploying an IPv4 LISP site now. Could one > take an IPv4 prefix already used > globally by a different company/site - and use it for my new LISP site > as an EID prefix? No because there is one allocation authority and it is enforcing a unique address allocation policy. > Do all the drafts always check for the IP address in the mapping > database to see if it is an EID? I recall seeing some > cases of checking the global routing table - but that could be bad > memory at this point. If you look in the ALT routing table and find a prefix, it is an EID. That is an example of looking in *a routing table*. But that is part of the mapping database system. So it is one in the same. > Could a host in a LISP site send to an IP address as an EID and the > same IP address as a globally addressable (or routable)? A host sends to destinations. So it doesn't know one from the other (a feature). So yes, both a non-LISP site host and a LISP site host can talk to both a non-LISP site and LISP site destination. > I am confused because "architecturally" I believe the EID space and > the RLOC space are separate namespaces - but in practice > in the drafts, it seems that a given value must belong to a single > entity, whether it is used as an EID, globally addressable, or both. That is what you get when you build an architecture after the network is built. ;-) Dino > Is this clearly specified anywhere? What am I missing? > > Alia > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jmh@joelhalpern.com Wed Jun 22 16:41:37 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002CB11E80B3 for ; Wed, 22 Jun 2011 16:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.053 X-Spam-Level: X-Spam-Status: No, score=-102.053 tagged_above=-999 required=5 tests=[AWL=-0.746, BAYES_00=-2.599, MISSING_HEADERS=1.292, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YB5Iehz-pSPS for ; Wed, 22 Jun 2011 16:41:36 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfa.amsl.com (Postfix) with ESMTP id 93D6B11E80BD for ; Wed, 22 Jun 2011 16:41:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 86A1F32464AF; Wed, 22 Jun 2011 16:41:06 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.154.181.49] (unknown [129.192.185.163]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id E31843246136; Wed, 22 Jun 2011 16:41:05 -0700 (PDT) Message-ID: <4E027D8D.2020909@joelhalpern.com> Date: Wed, 22 Jun 2011 19:41:01 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 References: <00D02FFF-2E45-4F5D-9DEC-F5F0961C62D3@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] Last call for draft-ietf-lisp-12: packet handling X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2011 23:41:37 -0000 Maybe I am missing something, but these two look like changes to the spec which will improve interoperability, and are easily done. Is there a good reason not to add the clarifications that are requested here? Yours, Joel On 6/22/2011 6:32 PM, Alia Atlas wrote: >>> i) For instance, if an ETR receives a LISP encapsulated packet and >>> >> decapsulates it, >>> >> but does not have EID locally, what should the ETR do? >> > >> > Drop the packet. When decapsulation occurs, the inner header is inspected >> > and what an IP router does today is what it does post decapsulation. > Another option is for the ETR to look up the EID in the mapping database and > forward it. Or the ETR could try and route it assuming the > destination IP address > is globally routable. > > That the correct decision is to drop the packet is NOT specified. > There are indications > in the draft of decapsulation and reencapsulation& when those should be done is > not specified. > >>> >> ii) Does an ETR have to do packet fragment reassembly? If an ETR >>> >> does not support >>> >> fragment reassembly, should it send an ICMP Too Big message and >>> >> drop the fragment? >>> >> What should an ETR do with a fragment directed to its RLOC? >> > >> > The ETR follows the IP and IPv6 specification in regards to reassemly of >> > fragments. However, we try to avoid fragmentation. See section 5.4 "Dealing >> > with Large Encapsulated Packets" for solutions. > Of course, I read through that section. My concern is the case where an ITR > may set the DF bit to 0. > "When the outer header encapsulation uses an IPv4 header, an > implementation SHOULD set the DF bit to 1 so ETR fragment reassembly > can be avoided. An implementation MAY set the DF bit in such headers > to 0 if it has good reason to believe there are unresolvable path MTU > issues between the sending ITR and the receiving ETR." > > IF everything needs to be implemented, then an ETR has to be prepared for > an ITR to do that (adversarially if nothing else) and handle reassembly at > line-rate. > From jmh@joelhalpern.com Wed Jun 22 16:45:20 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4ECF11E809C for ; Wed, 22 Jun 2011 16:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.631 X-Spam-Level: X-Spam-Status: No, score=-102.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moW9+od0SJoX for ; Wed, 22 Jun 2011 16:45:20 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfa.amsl.com (Postfix) with ESMTP id D011A11E807B for ; Wed, 22 Jun 2011 16:45:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id CB1A93244FAD; Wed, 22 Jun 2011 16:44:49 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.154.181.49] (unknown [129.192.185.163]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 54670322804C; Wed, 22 Jun 2011 16:44:49 -0700 (PDT) Message-ID: <4E027E6D.6060403@joelhalpern.com> Date: Wed, 22 Jun 2011 19:44:45 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "lisp@ietf.org" References: <00D02FFF-2E45-4F5D-9DEC-F5F0961C62D3@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] Last call for draft-ietf-lisp-12: mixed address modes X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2011 23:45:20 -0000 Since we have said repeatedly we waat this to work, it should be stated. If it is already stated, I apologize but I can not find it. The section you quoted from the ToC doesn't. Yours, Joel On 6/22/2011 6:32 PM, Alia Atlas wrote: >>> f) Sec 5: There is no indication in the packet formats that IPv4 in >>> >> IPv6 or IPv6 in IPv4 SHOULD be supported. I don't care about long >>> >> format sections - but at a minimum, there should be a paragraph that >>> >> specifies the encapsulation possibilities: >>> >> >>> >> "A LISP packet consists of an outer header, a UDP header, and an >>> >> inner header. The following combinations MUST be supported: >>> >> i) IPv4 outer header and IPv4 inner header (in Sec. 5.1) >>> >> ii) IPv6 outer header and IPv4 inner header >>> >> iii) IPv6 outer header and IPv6 inner header (in Sec 5.2) >>> >> iv) IPv4 outer header and IPv6 inner header " >> > >> > I don't understand this comment. The summary is in the table of contents >> > section names: >> > >> > 5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . . 16 >> > 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 17 >> > 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 17 >> > 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 19 > Right - there is no description of DIFFERENT IP VERSIONS - e.g. IPv6 in IPv4 > or IPv4 in IPv6 > > NOWHERE in the draft is this specifically said to be allowed or expected, > but list conversations certainly imply it. > From akatlas@gmail.com Thu Jun 23 11:43:22 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932BB21F84CF for ; Thu, 23 Jun 2011 11:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5GA3tNEAWLK for ; Thu, 23 Jun 2011 11:43:22 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id DEEF621F84CE for ; Thu, 23 Jun 2011 11:43:21 -0700 (PDT) Received: by pwj5 with SMTP id 5so1499700pwj.31 for ; Thu, 23 Jun 2011 11:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XSfjesncwHMjkrh+U6MnuMN30EUUmjq2GNYIXyMYCk4=; b=FsaMxvzjUdTTa6wFOipPnDTYDOmeq922DigFTm9EdrYt+ch2Ao9WfOD95JuR2ql7kX uXWOPhfJBWSk5jwtruMgFKFZ1YENBCOZW6LIgpT9W19GxN4EtmhbcKUnk0Np6E1pj3Iy 4GKfqsISeHjMtPT+JPFyDd728zGbQy3AlTPDE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VBEQ+Ve0aGHkQy+Yh/RNrCR7oohIhBnoGhlq4Wm56+P0QRL23NQtoK1TjW1S0LQF2G wEtTZ2as0HSkUGQvXPptc2kfpXaF2J+XRTKrm8LV9GReRv8p5DkctCuECv1Cl4tPJ4Ed j4zTxiQnB/xWlfb+QOdDGroOgVk08TF6696ts= MIME-Version: 1.0 Received: by 10.68.13.73 with SMTP id f9mr1371245pbc.100.1308854601369; Thu, 23 Jun 2011 11:43:21 -0700 (PDT) Received: by 10.68.46.98 with HTTP; Thu, 23 Jun 2011 11:43:21 -0700 (PDT) In-Reply-To: <21B84ED0-A75A-4160-8320-5E61AC154485@cisco.com> References: <21B84ED0-A75A-4160-8320-5E61AC154485@cisco.com> Date: Thu, 23 Jun 2011 14:43:21 -0400 Message-ID: From: Alia Atlas To: Dino Farinacci Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: lisp Subject: Re: [lisp] architecturally separate name-spaces - but assumption about a single value means same thing if in both? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jun 2011 18:43:22 -0000 So - although theoretically the value A can be an EID and an RLOC, the LISP protocol as specified does not permit this. I understand that was a choice started based upon assumptions around the allocation authority for number spaces. I strongly think that this clarification must be made in the [LISP] draft. Without that assumption, various parts of what is specified simply do not work. Alia On Wed, Jun 22, 2011 at 7:02 PM, Dino Farinacci wrote: >> From the discussion on draft comments, I have the following basic >> question: >> >> Is a value A is assigned to either the EID space or the RLOC space? >> Could site X have an EID with value A while site Y (or >> even a non-LISP) has an RLOC (or globally routable address) with the >> same value A? > > Architecturally, yes, the value A can be an EID and an RLOC. In practice, > no, for IPv4 and maybe for IPv6. Let me explain. > > Since there are two namespaces for each of IPv4 and IPv6, it means, for t= he > case of IPv4, there are two 2^^32 number assignment spaces. But we don't > have two allocation authorities, one for each, so the addresses will be > assigned from one 2^^32 pool and be used as either an EID or an RLOC > depending if the site has converted to being a LISP site. > > For IPv6, if we had a PI allocation authority, then it would hand out EID > prefixes to end sites. If we also had a PA allocation authority, then it > would hand out RLOC addresses to infrastructure providers. In this case, = if > the two authorities acted independently, then the same value could be > assigned for each namespace. > > This is not a problem to duplicate the address in each namespace. But I d= o > believe for operational sanity it would be nice to look at logs, debugs, = or > whatever, see an address and decipher it is an EID versus an RLOC. This i= s > one of the reasons the working group wants to request an IANA assigned /1= 2 > or /16 (not decided yet I think). > >> For instance, consider deploying an IPv4 LISP site now. =A0Could one >> take an IPv4 prefix already used >> globally by a different company/site - and use it for my new LISP site >> as an EID prefix? > > No because there is one allocation authority and it is enforcing a unique > address allocation policy. > >> Do all the drafts always check for the IP address in the mapping >> database to see if it is an EID? =A0I recall seeing some >> cases of checking the global routing table - but that could be bad >> memory at this point. > > If you look in the ALT routing table and find a prefix, it is an EID. Tha= t > is an example of looking in *a routing table*. But that is part of the > mapping database system. So it is one in the same. > >> Could a host in a LISP site send to an IP address as an EID and the >> same IP address as a globally addressable (or routable)? > > A host sends to destinations. So it doesn't know one from the other (a > feature). So yes, both a non-LISP site host and a LISP site host can talk= to > both a non-LISP site and LISP site destination. > >> I am confused because "architecturally" I believe the EID space and >> the RLOC space are separate namespaces - but in practice >> in the drafts, it seems that a given value must belong to a single >> entity, whether it is used as an EID, globally addressable, or both. > > That is what you get when you build an architecture after the network is > built. =A0;-) > > Dino > >> Is this clearly specified anywhere? =A0What am I missing? >> >> Alia >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > > From akatlas@gmail.com Thu Jun 23 11:52:29 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A919711E80EE for ; Thu, 23 Jun 2011 11:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAkf+y2kKRIu for ; Thu, 23 Jun 2011 11:52:29 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id E813011E807D for ; Thu, 23 Jun 2011 11:52:28 -0700 (PDT) Received: by pzk5 with SMTP id 5so1466111pzk.31 for ; Thu, 23 Jun 2011 11:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=G2re+t1TJ0UAiLWuS2SSeLFqfE+iNjW28VpriTgXH+E=; b=SuSfq95X1CX6D2biLg8fnlUCpZvyuQN4gdu2GB6Ib7+RaVdHwVelvspNJ//LSpVEcr d0STDP/Sx5g7ho7Nv8PGXaTrUdvoifjb+j2rOlO4bN4hn1rZxrJOOr+qAA3gqS0lmf/P Oie6xop3v37MBsy2Az9M56/uOIlsYDiVpDfHM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rEGA5wroRXQLfhSpEmAyX6batgQew/uY2ITHRrdITVCVAtGG/TQbBpBN2XTJ/GdY/S hPWx4kIk6/tzWJJmTnaaoh5eC/6bj6FzLPvJtezzJwLJ/Ux7DyQuzZwLIqHKSSkasveE FyVKgqDJT8CT74ics2JY0QIS14R19TLrN2dIU= MIME-Version: 1.0 Received: by 10.68.30.68 with SMTP id q4mr1454398pbh.435.1308855148368; Thu, 23 Jun 2011 11:52:28 -0700 (PDT) Received: by 10.68.46.98 with HTTP; Thu, 23 Jun 2011 11:52:28 -0700 (PDT) In-Reply-To: <21B84ED0-A75A-4160-8320-5E61AC154485@cisco.com> References: <21B84ED0-A75A-4160-8320-5E61AC154485@cisco.com> Date: Thu, 23 Jun 2011 14:52:28 -0400 Message-ID: From: Alia Atlas To: Dino Farinacci Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: lisp Subject: Re: [lisp] architecturally separate name-spaces - but assumption about a single value means same thing if in both? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jun 2011 18:52:29 -0000 Sorry - a couple more comments in-line: On Wed, Jun 22, 2011 at 7:02 PM, Dino Farinacci wrote: >> From the discussion on draft comments, I have the following basic >> question: >> >> Is a value A is assigned to either the EID space or the RLOC space? >> Could site X have an EID with value A while site Y (or >> even a non-LISP) has an RLOC (or globally routable address) with the >> same value A? > > Architecturally, yes, the value A can be an EID and an RLOC. In practice, > no, for IPv4 and maybe for IPv6. Let me explain. > > Since there are two namespaces for each of IPv4 and IPv6, it means, for t= he > case of IPv4, there are two 2^^32 number assignment spaces. But we don't > have two allocation authorities, one for each, so the addresses will be > assigned from one 2^^32 pool and be used as either an EID or an RLOC > depending if the site has converted to being a LISP site. > > For IPv6, if we had a PI allocation authority, then it would hand out EID > prefixes to end sites. If we also had a PA allocation authority, then it > would hand out RLOC addresses to infrastructure providers. In this case, = if > the two authorities acted independently, then the same value could be > assigned for each namespace. > > This is not a problem to duplicate the address in each namespace. But I d= o > believe for operational sanity it would be nice to look at logs, debugs, = or > whatever, see an address and decipher it is an EID versus an RLOC. This i= s > one of the reasons the working group wants to request an IANA assigned /1= 2 > or /16 (not decided yet I think). I believe there are assumptions in the drafts now that prevent duplicating = an address in each namespace. >> For instance, consider deploying an IPv4 LISP site now. =A0Could one >> take an IPv4 prefix already used >> globally by a different company/site - and use it for my new LISP site >> as an EID prefix? > > No because there is one allocation authority and it is enforcing a unique > address allocation policy. If you decided that EIDs were a real separate namespace - managed by anothe= r entity? >> Do all the drafts always check for the IP address in the mapping >> database to see if it is an EID? =A0I recall seeing some >> cases of checking the global routing table - but that could be bad >> memory at this point. > > If you look in the ALT routing table and find a prefix, it is an EID. Tha= t > is an example of looking in *a routing table*. But that is part of the > mapping database system. So it is one in the same. I believe it was, and certainly my interpretation, was to look it up in the "Global Routing Table". For consistency, if a lookup is done in the Routing Datab= ase, then the same terminology should be used. >> Could a host in a LISP site send to an IP address as an EID and the >> same IP address as a globally addressable (or routable)? > > A host sends to destinations. So it doesn't know one from the other (a > feature). So yes, both a non-LISP site host and a LISP site host can talk= to > both a non-LISP site and LISP site destination. Let me provide examples, since I strongly think the answer is NO and feel y= ou have side-stepped the question into vague generalities that ignores the iss= ue. An end-host in a LISP site puts a destination of A in its packet. The ITR checks for A in the Mapping Database & finds it. Therefore, the ITR encapsulates the packet and sends it to an RLOC specified in the locator-set. There is NO WAY for a LISP end-host to send a packet to the globally addressable destination A - unless the EID A and the globally addressable destination A refer to the exact same host. Similarly, an end-host that is not in a LISP site puts a destination of A in its packet. If an PITR tries to claim value A because it is an EID, then depending on route-preferences, the non-LISP end-host may be able to send to globally addressable destination A or its traffic might end up going to the advertising PITR. >> I am confused because "architecturally" I believe the EID space and >> the RLOC space are separate namespaces - but in practice >> in the drafts, it seems that a given value must belong to a single >> entity, whether it is used as an EID, globally addressable, or both. > > That is what you get when you build an architecture after the network is > built. =A0;-) It is an amusing challenge - but basic architectural assumptions need to be clearly documented as the reality they are. Alia > Dino > >> Is this clearly specified anywhere? =A0What am I missing? >> >> Alia >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > > From akatlas@gmail.com Thu Jun 23 11:59:04 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F113611E8136 for ; Thu, 23 Jun 2011 11:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64vIpomij7SQ for ; Thu, 23 Jun 2011 11:59:04 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2844E11E80EE for ; Thu, 23 Jun 2011 11:59:03 -0700 (PDT) Received: by ewy19 with SMTP id 19so818504ewy.31 for ; Thu, 23 Jun 2011 11:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=F7hSPV2Sgc2LduU9UTV4Q3y4VHcyZa6Bah4O4T7Xe2Y=; b=JW9Xsz8Lm1mlNKgvrQYo1Mkmvdk9IvmEAwPjCWPNyMz3YXxxApG5uZYoEUvtM4oqLe 7zp2jXKrZ+i0/s5KqP0tx9Dfw3GH0LVsJUBVwVnxduAcht+dg2q4wAPFbWLNungbq3tB YDLrCDzK+TzBvpr+RbkBenLW4MfoOoXwsk6fo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gC0NXQASyG3sXM6XmXXxerW4b+xhCyMHCiB8pl9stJzUzh7f/OcZvnKVFV9IsFk3GZ Aj4ySXmCKZTlcEvHNX7CZBQFu+QX6ha/ToIKf1oxnmcFuEZi7ZLQwwc2v2a/rfVvng0Q YLy/xwgaWm45CC9t+/nJVGDWDSCzHE7eZxRFs= MIME-Version: 1.0 Received: by 10.14.189.4 with SMTP id b4mr1658594een.144.1308855543171; Thu, 23 Jun 2011 11:59:03 -0700 (PDT) Received: by 10.14.189.3 with HTTP; Thu, 23 Jun 2011 11:59:03 -0700 (PDT) In-Reply-To: <4E027170.9030802@joelhalpern.com> References: <00D02FFF-2E45-4F5D-9DEC-F5F0961C62D3@cisco.com> <4E027170.9030802@joelhalpern.com> Date: Thu, 23 Jun 2011 14:59:03 -0400 Message-ID: From: Alia Atlas To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "lisp@ietf.org" Subject: Re: [lisp] Last call for draft-ietf-lisp-12: EID holes X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jun 2011 18:59:05 -0000 Joel, Certainly I agree that the text in [LISP] addresses some of the basics of handling overlapping prefixes. I had thought that one point of LISP was to avoid needing to renumber; I believe that in a similar case with IPv4 addresses today, it's not unusual to get the smaller prefix announced. However, in response to more detailed questions, I keep hearing back assumptions or things that have been discussed on the list and are not captured in a draft. For a protocol like LISP, there are clearly many operational details and assumptions to be agreed upon and that need to be consistent. Last time I looked at the deployment draft, I didn't notice them captured anywhere. Are there plans for such a draft? Alia On Wed, Jun 22, 2011 at 6:49 PM, Joel M. Halpern wrot= e: > The normal situation is that an EID block is delegated to an administrati= ve > authority (a company). =A0They use it. > They may use the main block, and use some sub-blocks. =A0That produces "h= oles" > which are overlapping prefixes. =A0The handling of that is described in t= he > document. =A0The ETRs which are responsible for the covering EID prefix m= ust > know which blocks are allocated elsewhere. > They have to identify those in the response. > > THe details are spelled out. > > The normal case would be that the division that was sold would be renumbe= red > into its own or its new parents EID block. =A0After all, they are no long= er > part of the original site. =A0The overlapping prefix mechanisms allow for > transition. > > The more extreme case is not permitted. =A0You can not have a LISP EID bl= ock, > within which there is a hole which is used as IP addresses but not as LIS= P > EIDs. =A0(The inner portion can be used as both, but it has to be an EID.= ) > > Yours, > Joel > > On 6/22/2011 6:32 PM, Alia Atlas wrote: >> >> Dino, >> >> Thanks for your responses - mine are in-line below. >> >> Alia >> >> On Mon, Jun 20, 2011 at 6:19 PM, Dino Farinacci =A0wrote= : > > ... >>> >>> If the site has an EID-prefix of the /16 that is the one it Map-Replies >>> for. >>> We have rules in section 6.1.5 "EID-to-RLOC UDP Map-Reply Message" on h= ow >>> to >>> send Map-Replies when there are overlapping EID-prefixes and there has >>> been >>> much discussion on this mailing list about it. >> >> I agree that there's been lots of discussion on the list. =A0Capturing >> the decisions made >> into the draft would be good practice, IMHO, and ensure it has been >> resolved. >> >> Can an ETR have an prefix which has a hole in it? =A0What happens if the >> ETR does not >> know the correct RLOCs to use for that hole (since it isn't owned)? >> >> I'm thinking of a case where initially there is a LISP site with a >> /16. =A0Then, part of that >> company is sold along with the /24 that is used in that division. >> Now, can the original >> site advertise the /16 with a hole? =A0How would it do that? >> >> The problem here is that the ETR does NOT KNOW the correct locator-set >> for the /24 hole >> that has been sold off. >> >> > From jnc@mercury.lcs.mit.edu Thu Jun 23 12:04:26 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3651121F8498 for ; Thu, 23 Jun 2011 12:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2-94RM0J6aD for ; Thu, 23 Jun 2011 12:04:25 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id AD4AC21F848F for ; Thu, 23 Jun 2011 12:04:25 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 7528D18C082; Thu, 23 Jun 2011 15:04:24 -0400 (EDT) To: lisp@ietf.org Message-Id: <20110623190424.7528D18C082@mercury.lcs.mit.edu> Date: Thu, 23 Jun 2011 15:04:24 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] architecturally separate name-spaces - but assumption about a single value means same thing if in both? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jun 2011 19:04:26 -0000 > From: Alia Atlas > So - although theoretically the value A can be an EID and an RLOC, > the LISP protocol as specified does not permit this. Well, yes and no. As long as you include the "as specified", perhaps. But there are some places (e.g. mobility, where the mobile entity moves into a LISP site) where a particular value is both an 'EID' (but not really, in semantic terms - only in terms of the protocol operation - see below) and an RLOC. For the example of the mobile node which has moved inside a LISP site, it's actual EID is first mapped to a 'temporary care-of EID' (a term I just made up), which is its 'address' inside the LISP site. That TC-EID then has to be mapped to the RLOC of the LISP site. (And the packets wind up double wrapped, so that each ETR which it traverses can remove one layer - one at the site boundary, and one at the moble node.) The 'temporary care-of EID' looks like an RLOC in a sense, because it is the _output_ of a mapping stage ... but in the very next moment it's also the _input_ to a mapping stage, and thus an EID in a sense. The thing is that because it's an incremental, interoperable, add-on to the existing architecture, things in LISP as not always as clear and crisp as one might like - and they often change from case to case. (The LISP EIDs are an example - and a lot of people are somewhat unhappy that they are called EIDs, with some justification: sometimes they have no location information in them, sometimes they do.) So, applying that general concept to this particular case, while one might say, in theory, that there is a crisp division between EIDs and RLOCs, in practice it's probably going to be a bit muddy. > Without that assumption, various parts of what is specified simply > do not work. Ah, why not? Noel From jmh@joelhalpern.com Thu Jun 23 12:38:34 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B24F11E80AC for ; Thu, 23 Jun 2011 12:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.626 X-Spam-Level: X-Spam-Status: No, score=-102.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLKYx8-JQnrW for ; Thu, 23 Jun 2011 12:38:33 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfa.amsl.com (Postfix) with ESMTP id 75FEF11E807D for ; Thu, 23 Jun 2011 12:38:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 65E753244AD9; Thu, 23 Jun 2011 12:38:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.154.181.49] (unknown [129.192.185.163]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id A42FF3244CB1; Thu, 23 Jun 2011 12:38:02 -0700 (PDT) Message-ID: <4E039617.30901@joelhalpern.com> Date: Thu, 23 Jun 2011 15:37:59 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Alia Atlas References: <21B84ED0-A75A-4160-8320-5E61AC154485@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp Subject: Re: [lisp] architecturally separate name-spaces - but assumption about a single value means same thing if in both? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jun 2011 19:38:34 -0000 I don't think your paraphrase quite captures it. In the abstract theory, the bit string represented by A could be an EID for one device and an RLOC for a different device. As the architecture is realized, if a given bit string is both an RLOC and an EID, it must refer to the same entity in both cases. Yours, Joel On 6/23/2011 2:43 PM, Alia Atlas wrote: > So - although theoretically the value A can be an EID and an RLOC, the LISP > protocol as specified does not permit this. > > I understand that was a choice started based upon assumptions around the > allocation authority for number spaces. > > I strongly think that this clarification must be made in the [LISP] > draft. Without > that assumption, various parts of what is specified simply do not work. > > Alia > > On Wed, Jun 22, 2011 at 7:02 PM, Dino Farinacci wrote: >>> From the discussion on draft comments, I have the following basic >>> question: >>> >>> Is a value A is assigned to either the EID space or the RLOC space? >>> Could site X have an EID with value A while site Y (or >>> even a non-LISP) has an RLOC (or globally routable address) with the >>> same value A? >> >> Architecturally, yes, the value A can be an EID and an RLOC. In practice, >> no, for IPv4 and maybe for IPv6. Let me explain. >> >> Since there are two namespaces for each of IPv4 and IPv6, it means, for the >> case of IPv4, there are two 2^^32 number assignment spaces. But we don't >> have two allocation authorities, one for each, so the addresses will be >> assigned from one 2^^32 pool and be used as either an EID or an RLOC >> depending if the site has converted to being a LISP site. >> >> For IPv6, if we had a PI allocation authority, then it would hand out EID >> prefixes to end sites. If we also had a PA allocation authority, then it >> would hand out RLOC addresses to infrastructure providers. In this case, if >> the two authorities acted independently, then the same value could be >> assigned for each namespace. >> >> This is not a problem to duplicate the address in each namespace. But I do >> believe for operational sanity it would be nice to look at logs, debugs, or >> whatever, see an address and decipher it is an EID versus an RLOC. This is >> one of the reasons the working group wants to request an IANA assigned /12 >> or /16 (not decided yet I think). >> >>> For instance, consider deploying an IPv4 LISP site now. Could one >>> take an IPv4 prefix already used >>> globally by a different company/site - and use it for my new LISP site >>> as an EID prefix? >> >> No because there is one allocation authority and it is enforcing a unique >> address allocation policy. >> >>> Do all the drafts always check for the IP address in the mapping >>> database to see if it is an EID? I recall seeing some >>> cases of checking the global routing table - but that could be bad >>> memory at this point. >> >> If you look in the ALT routing table and find a prefix, it is an EID. That >> is an example of looking in *a routing table*. But that is part of the >> mapping database system. So it is one in the same. >> >>> Could a host in a LISP site send to an IP address as an EID and the >>> same IP address as a globally addressable (or routable)? >> >> A host sends to destinations. So it doesn't know one from the other (a >> feature). So yes, both a non-LISP site host and a LISP site host can talk to >> both a non-LISP site and LISP site destination. >> >>> I am confused because "architecturally" I believe the EID space and >>> the RLOC space are separate namespaces - but in practice >>> in the drafts, it seems that a given value must belong to a single >>> entity, whether it is used as an EID, globally addressable, or both. >> >> That is what you get when you build an architecture after the network is >> built. ;-) >> >> Dino >> >>> Is this clearly specified anywhere? What am I missing? >>> >>> Alia >>> _______________________________________________ >>> 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 jmh@joelhalpern.com Thu Jun 23 12:47:01 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450D321F848E for ; Thu, 23 Jun 2011 12:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.624 X-Spam-Level: X-Spam-Status: No, score=-102.624 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WRQu-HSreSq for ; Thu, 23 Jun 2011 12:47:00 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfa.amsl.com (Postfix) with ESMTP id 225DD21F848C for ; Thu, 23 Jun 2011 12:47:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 2122D32466F1; Thu, 23 Jun 2011 12:46:30 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.154.181.49] (unknown [129.192.185.163]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id EF9BC32466FE; Thu, 23 Jun 2011 12:46:26 -0700 (PDT) Message-ID: <4E03980F.8030800@joelhalpern.com> Date: Thu, 23 Jun 2011 15:46:23 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Alia Atlas References: <00D02FFF-2E45-4F5D-9DEC-F5F0961C62D3@cisco.com> <4E027170.9030802@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] Last call for draft-ietf-lisp-12: EID holes X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jun 2011 19:47:01 -0000 While I would have liked a solution that completely removed renumbering, LISP does not cope with all of the cases that cause renumbering. It is hard to state the tradeoff clearly and concisely, although it is inherent in teh fact that LISP is site oriented. (Yes, there are some interesting extension to mobility, but those are out of scope...) If there are operational issues that need to be consistent, those should be captured in the deployment document. If they aren't, we need to fix that. But there are limits. I do not think we need to deal at this time with describing exactly what has to happen when a LISP site sells part of its network to another organization, that either is or is not using LISP. Yours, Joel On 6/23/2011 2:59 PM, Alia Atlas wrote: > Joel, > > Certainly I agree that the text in [LISP] addresses some of the basics > of handling overlapping > prefixes. I had thought that one point of LISP was to avoid needing > to renumber; I believe that in > a similar case with IPv4 addresses today, it's not unusual to get the > smaller prefix announced. > > However, in response to more detailed questions, I keep hearing back > assumptions or things > that have been discussed on the list and are not captured in a draft. > > For a protocol like LISP, there are clearly many operational details > and assumptions to be agreed > upon and that need to be consistent. Last time I looked at the > deployment draft, I didn't notice > them captured anywhere. > > Are there plans for such a draft? > > Alia > > > On Wed, Jun 22, 2011 at 6:49 PM, Joel M. Halpern wrote: >> The normal situation is that an EID block is delegated to an administrative >> authority (a company). They use it. >> They may use the main block, and use some sub-blocks. That produces "holes" >> which are overlapping prefixes. The handling of that is described in the >> document. The ETRs which are responsible for the covering EID prefix must >> know which blocks are allocated elsewhere. >> They have to identify those in the response. >> >> THe details are spelled out. >> >> The normal case would be that the division that was sold would be renumbered >> into its own or its new parents EID block. After all, they are no longer >> part of the original site. The overlapping prefix mechanisms allow for >> transition. >> >> The more extreme case is not permitted. You can not have a LISP EID block, >> within which there is a hole which is used as IP addresses but not as LISP >> EIDs. (The inner portion can be used as both, but it has to be an EID.) >> >> Yours, >> Joel >> >> On 6/22/2011 6:32 PM, Alia Atlas wrote: >>> >>> Dino, >>> >>> Thanks for your responses - mine are in-line below. >>> >>> Alia >>> >>> On Mon, Jun 20, 2011 at 6:19 PM, Dino Farinacci wrote: >> >> ... >>>> >>>> If the site has an EID-prefix of the /16 that is the one it Map-Replies >>>> for. >>>> We have rules in section 6.1.5 "EID-to-RLOC UDP Map-Reply Message" on how >>>> to >>>> send Map-Replies when there are overlapping EID-prefixes and there has >>>> been >>>> much discussion on this mailing list about it. >>> >>> I agree that there's been lots of discussion on the list. Capturing >>> the decisions made >>> into the draft would be good practice, IMHO, and ensure it has been >>> resolved. >>> >>> Can an ETR have an prefix which has a hole in it? What happens if the >>> ETR does not >>> know the correct RLOCs to use for that hole (since it isn't owned)? >>> >>> I'm thinking of a case where initially there is a LISP site with a >>> /16. Then, part of that >>> company is sold along with the /24 that is used in that division. >>> Now, can the original >>> site advertise the /16 with a hole? How would it do that? >>> >>> The problem here is that the ETR does NOT KNOW the correct locator-set >>> for the /24 hole >>> that has been sold off. >>> >>> >> > From dino@cisco.com Thu Jun 23 13:23:59 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1AF11E8197 for ; Thu, 23 Jun 2011 13:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCYZUBKeVho8 for ; Thu, 23 Jun 2011 13:23:58 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id C0E2511E8180 for ; Thu, 23 Jun 2011 13:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=732; q=dns/txt; s=iport; t=1308860637; x=1310070237; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=N4FxDC6guW6+Bl8l8fI5Jph4L0+fwEVi5GCjzShdRyA=; b=l41lgBkVXd2rN1jmZ+wDJXxaTCkZ8XNVgRbYTB2esr29YfoHYFKbrXQU bcj2l6DDpafI2R3OEafRUQv36+EDXa5/D5N8MJRx0JzOQywjEmkomFM9f e+rKs2yijP3EWRYP9tfx+2OlNQ4J6asit6uTTHMtrfP7y1Qkt94tDtzdU Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAWgA06rRDoH/2dsb2JhbABSpyp3iHOjIZ13hi0EhyaKTIRli0k X-IronPort-AV: E=Sophos;i="4.65,414,1304294400"; d="scan'208";a="720919133" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 23 Jun 2011 20:23:50 +0000 Received: from [10.34.153.93] ([10.34.153.93]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5NKNoIG004399; Thu, 23 Jun 2011 20:23:50 GMT Message-Id: <69829339-5EA2-44E2-AF0E-F4B4AAB04FE6@cisco.com> From: Dino Farinacci To: Alia Atlas In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 23 Jun 2011 13:23:50 -0700 References: <21B84ED0-A75A-4160-8320-5E61AC154485@cisco.com> X-Mailer: Apple Mail (2.936) Cc: lisp Subject: Re: [lisp] architecturally separate name-spaces - but assumption about a single value means same thing if in both? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jun 2011 20:23:59 -0000 >>> Could a host in a LISP site send to an IP address as an EID and the >>> same IP address as a globally addressable (or routable)? >> >> A host sends to destinations. So it doesn't know one from the other >> (a >> feature). So yes, both a non-LISP site host and a LISP site host >> can talk to >> both a non-LISP site and LISP site destination. > > Let me provide examples, since I strongly think the answer is NO and > feel you > have side-stepped the question into vague generalities that ignores > the issue. I will be very specific. Today my systems at home use an EID for TCP connections. That same 32-bit value is used as an RLOC for LISP encapsulating packets that come into my house. Dino From akatlas@gmail.com Thu Jun 23 13:24:31 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC87011E8198 for ; Thu, 23 Jun 2011 13:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BG1lwn68tTkn for ; Thu, 23 Jun 2011 13:24:30 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8DC11E8190 for ; Thu, 23 Jun 2011 13:24:29 -0700 (PDT) Received: by ewy19 with SMTP id 19so842884ewy.31 for ; Thu, 23 Jun 2011 13:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0S7xuMZES3kdegTAmb07lWIf1P2a9R8O4XDfVip3Bqg=; b=w+uFQPnQ7RGygtT3K26UEdaW2rhsv+ZfCEOTYOVSuf9uAVWLpGV4j9ZtjMOayxJanm xDNEMdHt1IvmBa64N6OdZ1RFU7B/mWfy+FDTCQDAPEBRKPhtDhCC/Qrn0BHWAcE3OiQx yaJx0jEjTNcdsNsyB2k2Ac0Kilo6fDbkHfrXA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=G6vy4fdQ3SZS0rdH+UowuGCAOjOEY4lLgkbcGaFTyoto9iOwdfYR/ZokwqCcD+/Qqf ajYFQS2KemHz6H3iDm/nnw+OQ1VjURNeEL4rOqNo7hW400E9ZguyaGhATL2erPurvzbI fa1bK8ifemu+vnmtLeFgledC6P/8ohl/rtRYk= MIME-Version: 1.0 Received: by 10.14.189.4 with SMTP id b4mr1710886een.144.1308860669105; Thu, 23 Jun 2011 13:24:29 -0700 (PDT) Received: by 10.14.189.3 with HTTP; Thu, 23 Jun 2011 13:24:29 -0700 (PDT) In-Reply-To: <4E03980F.8030800@joelhalpern.com> References: <00D02FFF-2E45-4F5D-9DEC-F5F0961C62D3@cisco.com> <4E027170.9030802@joelhalpern.com> <4E03980F.8030800@joelhalpern.com> Date: Thu, 23 Jun 2011 16:24:29 -0400 Message-ID: From: Alia Atlas To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "lisp@ietf.org" Subject: Re: [lisp] Last call for draft-ietf-lisp-12: EID holes X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jun 2011 20:24:32 -0000 On Thu, Jun 23, 2011 at 3:46 PM, Joel M. Halpern wrot= e: > While I would have liked a solution that completely removed renumbering, > LISP does not cope with all of the cases that cause renumbering. =A0It is= hard > to state the tradeoff clearly and concisely, although it is inherent in t= eh > fact that LISP is site oriented. =A0(Yes, there are some interesting exte= nsion > to mobility, but those are out of scope...) > > If there are operational issues that need to be consistent, those should = be > captured in the deployment document. =A0If they aren't, we need to fix th= at. > =A0But there are limits. =A0 I do not think we need to deal at this time = with > describing exactly what has to happen when a LISP site sells part of its > network to another organization, that either is or is not using LISP. Sure - I'm not focused on that specific case. What I'm after is the assump= tion that an ETR knows the correct locator-set and statuses for a sub-prefix tha= t has been delegated away... The locator-status bits make sense when the ETR= s are all in the same IGP; if that isn't the case, additional explicit work is needed. What would be useful is capturing the assumptions on knowledge and use-case= s. I know the deployment doc is a start of that, but some of this seems to me to belong in the protocol docs. What must an ETR know and with what dynamics to adve= rtise a prefix and what issues come up with holes and delegation? Is it a deliberate decision that there is no way for an ETR to say for a hole that it doesn't know what do with it - which means that if an ITR hit that entry, it would need to query... > Yours, > Joel > > On 6/23/2011 2:59 PM, Alia Atlas wrote: >> >> Joel, >> >> Certainly I agree that the text in [LISP] addresses some of the basics >> of handling overlapping >> prefixes. =A0I had thought that one point of LISP was to avoid needing >> to renumber; I believe that in >> a similar case with IPv4 addresses today, it's not unusual to get the >> smaller prefix announced. >> >> However, in response to more detailed questions, I keep hearing back >> assumptions or things >> that have been discussed on the list and are not captured in a draft. >> >> For a protocol like LISP, there are clearly many operational details >> and assumptions to be agreed >> upon and that need to be consistent. =A0Last time I looked at the >> deployment draft, I didn't notice >> them captured anywhere. >> >> Are there plans for such a draft? >> >> Alia >> >> >> On Wed, Jun 22, 2011 at 6:49 PM, Joel M. Halpern >> =A0wrote: >>> >>> The normal situation is that an EID block is delegated to an >>> administrative >>> authority (a company). =A0They use it. >>> They may use the main block, and use some sub-blocks. =A0That produces >>> "holes" >>> which are overlapping prefixes. =A0The handling of that is described in= the >>> document. =A0The ETRs which are responsible for the covering EID prefix >>> must >>> know which blocks are allocated elsewhere. >>> They have to identify those in the response. >>> >>> THe details are spelled out. >>> >>> The normal case would be that the division that was sold would be >>> renumbered >>> into its own or its new parents EID block. =A0After all, they are no lo= nger >>> part of the original site. =A0The overlapping prefix mechanisms allow f= or >>> transition. >>> >>> The more extreme case is not permitted. =A0You can not have a LISP EID >>> block, >>> within which there is a hole which is used as IP addresses but not as >>> LISP >>> EIDs. =A0(The inner portion can be used as both, but it has to be an EI= D.) >>> >>> Yours, >>> Joel >>> >>> On 6/22/2011 6:32 PM, Alia Atlas wrote: >>>> >>>> Dino, >>>> >>>> Thanks for your responses - mine are in-line below. >>>> >>>> Alia >>>> >>>> On Mon, Jun 20, 2011 at 6:19 PM, Dino Farinacci >>>> =A0wrote: >>> >>> ... >>>>> >>>>> If the site has an EID-prefix of the /16 that is the one it Map-Repli= es >>>>> for. >>>>> We have rules in section 6.1.5 "EID-to-RLOC UDP Map-Reply Message" on >>>>> how >>>>> to >>>>> send Map-Replies when there are overlapping EID-prefixes and there ha= s >>>>> been >>>>> much discussion on this mailing list about it. >>>> >>>> I agree that there's been lots of discussion on the list. =A0Capturing >>>> the decisions made >>>> into the draft would be good practice, IMHO, and ensure it has been >>>> resolved. >>>> >>>> Can an ETR have an prefix which has a hole in it? =A0What happens if t= he >>>> ETR does not >>>> know the correct RLOCs to use for that hole (since it isn't owned)? >>>> >>>> I'm thinking of a case where initially there is a LISP site with a >>>> /16. =A0Then, part of that >>>> company is sold along with the /24 that is used in that division. >>>> Now, can the original >>>> site advertise the /16 with a hole? =A0How would it do that? >>>> >>>> The problem here is that the ETR does NOT KNOW the correct locator-set >>>> for the /24 hole >>>> that has been sold off. >>>> >>>> >>> >> > From akatlas@gmail.com Thu Jun 23 13:25:06 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45B911E8190 for ; Thu, 23 Jun 2011 13:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Voszpp95ujSv for ; Thu, 23 Jun 2011 13:25:05 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 91C5311E8180 for ; Thu, 23 Jun 2011 13:25:05 -0700 (PDT) Received: by eye13 with SMTP id 13so842042eye.31 for ; Thu, 23 Jun 2011 13:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=39FAfU1YU323l0bFvIgmvJveoIKV4Bk8iBbbaMdDEPk=; b=oVpWUWy/VeTwc1L5zOThAxAyTfBgieCUsG/kjAWs30qHePhmbpzjlKl6zd30FcVFCn zPvz9daO4ugu0N7k7oI4GCneaOTqKlEIG4jPLcGYXkYgIqv4Bjd7N3jEpoujEyEqmnSB TtOvT5MXHTBmAZswJHasBzHGn0cHKP6Ca3GF8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kDo2GJ2xH/5rTWg3SbGLv/H4196dL5wjkUvcfnh+XQZ2s66PtiaCYiD3UQK3eEfQ9S GUqqNWEep8Kh7dMkjorN9JaDETB4egKEkml+yWt12LviAhUvNQTQKwxJerODKDBHAiSe 2+jtuF94t7g6IQyK3I4GlBK/ATYCg3cg4n840= MIME-Version: 1.0 Received: by 10.14.189.4 with SMTP id b4mr1711195een.144.1308860704598; Thu, 23 Jun 2011 13:25:04 -0700 (PDT) Received: by 10.14.189.3 with HTTP; Thu, 23 Jun 2011 13:25:04 -0700 (PDT) In-Reply-To: <69829339-5EA2-44E2-AF0E-F4B4AAB04FE6@cisco.com> References: <21B84ED0-A75A-4160-8320-5E61AC154485@cisco.com> <69829339-5EA2-44E2-AF0E-F4B4AAB04FE6@cisco.com> Date: Thu, 23 Jun 2011 16:25:04 -0400 Message-ID: From: Alia Atlas To: Dino Farinacci Content-Type: text/plain; charset=ISO-8859-1 Cc: lisp Subject: Re: [lisp] architecturally separate name-spaces - but assumption about a single value means same thing if in both? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jun 2011 20:25:07 -0000 Yes - so the EID and RLOC refer to the same end-host. On Thu, Jun 23, 2011 at 4:23 PM, Dino Farinacci wrote: >>>> Could a host in a LISP site send to an IP address as an EID and the >>>> same IP address as a globally addressable (or routable)? >>> >>> A host sends to destinations. So it doesn't know one from the other (a >>> feature). So yes, both a non-LISP site host and a LISP site host can talk >>> to >>> both a non-LISP site and LISP site destination. >> >> Let me provide examples, since I strongly think the answer is NO and feel >> you >> have side-stepped the question into vague generalities that ignores the >> issue. > > I will be very specific. Today my systems at home use an EID for TCP > connections. That same 32-bit value is used as an RLOC for LISP > encapsulating packets that come into my house. > > Dino > > From akatlas@gmail.com Thu Jun 23 13:25:37 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C709421F843F for ; Thu, 23 Jun 2011 13:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dS3LrxAaG9S for ; Thu, 23 Jun 2011 13:25:37 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id AF3F121F8440 for ; Thu, 23 Jun 2011 13:25:36 -0700 (PDT) Received: by ewy19 with SMTP id 19so843178ewy.31 for ; Thu, 23 Jun 2011 13:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AG9Bcwjfy3uC16+o5M1Dh8Chgvt0hGM0/S6rSVemMQM=; b=kVOhWM71evuLJTio1PoqRanZVeYzsVJ/Sg+bXjPclGlr+ncEh11RUW2pvQSBUhCNV0 z/ZwOLMcmE329aGVD4Ueo/t9QExdPG4DWaFShYOwinqeXKNyCFyg4QUYLvFfAaQvhQw6 tmOQg5JGFJPUoLMsqb1oT87kC/2+z1pi8iv3Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=aXx748jWl/g9APs1YUUNyDjLhZr058X0hiZ1+qJyDsoVI5oHca4MFmXYl4x80eXEq/ izqtwvfasUX7WHPMjLzoKPkeeBCxrZNJizaql2ukrWdpLXwbkoffh6LZexKpXOb2H4JK bpTlIT4Ff/GidHR94FFnD8JR5WdHjrcchvm7Q= MIME-Version: 1.0 Received: by 10.14.119.8 with SMTP id m8mr1610570eeh.48.1308860735759; Thu, 23 Jun 2011 13:25:35 -0700 (PDT) Received: by 10.14.189.3 with HTTP; Thu, 23 Jun 2011 13:25:35 -0700 (PDT) In-Reply-To: <4E039617.30901@joelhalpern.com> References: <21B84ED0-A75A-4160-8320-5E61AC154485@cisco.com> <4E039617.30901@joelhalpern.com> Date: Thu, 23 Jun 2011 16:25:35 -0400 Message-ID: From: Alia Atlas To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: lisp Subject: Re: [lisp] architecturally separate name-spaces - but assumption about a single value means same thing if in both? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jun 2011 20:25:37 -0000 Joel, Yes, thank you - that is a better phrasing. Alia On Thu, Jun 23, 2011 at 3:37 PM, Joel M. Halpern wrot= e: > I don't think your paraphrase quite captures it. > In the abstract theory, the bit string represented by A could be an EID f= or > one device and an RLOC for a different device. > As the architecture is realized, if a given bit string is both an RLOC an= d > an EID, it must refer to the same entity in both cases. > > Yours, > Joel > > On 6/23/2011 2:43 PM, Alia Atlas wrote: >> >> So - although theoretically the value A can be an EID and an RLOC, the >> LISP >> protocol as specified does not permit this. >> >> I understand that was a choice started based upon assumptions around the >> allocation authority for number spaces. >> >> I strongly think that this clarification must be made in the [LISP] >> draft. =A0Without >> that assumption, various parts of what is specified simply do not work. >> >> Alia >> >> On Wed, Jun 22, 2011 at 7:02 PM, Dino Farinacci =A0wrote= : >>>> >>>> =A0From the discussion on draft comments, I have the following basic >>>> question: >>>> >>>> Is a value A is assigned to either the EID space or the RLOC space? >>>> Could site X have an EID with value A while site Y (or >>>> even a non-LISP) has an RLOC (or globally routable address) with the >>>> same value A? >>> >>> Architecturally, yes, the value A can be an EID and an RLOC. In practic= e, >>> no, for IPv4 and maybe for IPv6. Let me explain. >>> >>> Since there are two namespaces for each of IPv4 and IPv6, it means, for >>> the >>> case of IPv4, there are two 2^^32 number assignment spaces. But we don'= t >>> have two allocation authorities, one for each, so the addresses will be >>> assigned from one 2^^32 pool and be used as either an EID or an RLOC >>> depending if the site has converted to being a LISP site. >>> >>> For IPv6, if we had a PI allocation authority, then it would hand out E= ID >>> prefixes to end sites. If we also had a PA allocation authority, then i= t >>> would hand out RLOC addresses to infrastructure providers. In this case= , >>> if >>> the two authorities acted independently, then the same value could be >>> assigned for each namespace. >>> >>> This is not a problem to duplicate the address in each namespace. But I >>> do >>> believe for operational sanity it would be nice to look at logs, debugs= , >>> or >>> whatever, see an address and decipher it is an EID versus an RLOC. This >>> is >>> one of the reasons the working group wants to request an IANA assigned >>> /12 >>> or /16 (not decided yet I think). >>> >>>> For instance, consider deploying an IPv4 LISP site now. =A0Could one >>>> take an IPv4 prefix already used >>>> globally by a different company/site - and use it for my new LISP site >>>> as an EID prefix? >>> >>> No because there is one allocation authority and it is enforcing a uniq= ue >>> address allocation policy. >>> >>>> Do all the drafts always check for the IP address in the mapping >>>> database to see if it is an EID? =A0I recall seeing some >>>> cases of checking the global routing table - but that could be bad >>>> memory at this point. >>> >>> If you look in the ALT routing table and find a prefix, it is an EID. >>> That >>> is an example of looking in *a routing table*. But that is part of the >>> mapping database system. So it is one in the same. >>> >>>> Could a host in a LISP site send to an IP address as an EID and the >>>> same IP address as a globally addressable (or routable)? >>> >>> A host sends to destinations. So it doesn't know one from the other (a >>> feature). So yes, both a non-LISP site host and a LISP site host can ta= lk >>> to >>> both a non-LISP site and LISP site destination. >>> >>>> I am confused because "architecturally" I believe the EID space and >>>> the RLOC space are separate namespaces - but in practice >>>> in the drafts, it seems that a given value must belong to a single >>>> entity, whether it is used as an EID, globally addressable, or both. >>> >>> That is what you get when you build an architecture after the network i= s >>> built. =A0;-) >>> >>> Dino >>> >>>> Is this clearly specified anywhere? =A0What am I missing? >>>> >>>> Alia >>>> _______________________________________________ >>>> 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 dino@cisco.com Thu Jun 23 13:25:49 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6ACE21F8446 for ; Thu, 23 Jun 2011 13:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.548 X-Spam-Level: X-Spam-Status: No, score=-10.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cne4MCk09QWC for ; Thu, 23 Jun 2011 13:25:48 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 31F9821F8443 for ; Thu, 23 Jun 2011 13:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=1047; q=dns/txt; s=iport; t=1308860748; x=1310070348; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=prQX2QI25k6IQDRzVTQ0c2hCsdhOim0geoyyKGn5dUk=; b=jfljXkaAO/eGCxKADpsUElUjRvgMnzC7eYpp2QcSYf00jSinkfsk46Pf MQVzfWp26XE/uMR2XFZpaP334QT98ztwMyA1hqoSzhpCivNdeazMQqQLO D9f3bsaFqWsGYcmMtsdWPC1SYc3b67UaAyCrqjfygVk+IodaX5JJ7s1+f g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAWgA06rRDoI/2dsb2JhbABSpyp3iHOjIZ13hi0EhyaKTIRli0k X-IronPort-AV: E=Sophos;i="4.65,414,1304294400"; d="scan'208";a="720920414" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 23 Jun 2011 20:25:44 +0000 Received: from [10.34.153.93] ([10.34.153.93]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5NKPiCE001997; Thu, 23 Jun 2011 20:25:44 GMT Message-Id: From: Dino Farinacci To: Alia Atlas In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 23 Jun 2011 13:25:44 -0700 References: <21B84ED0-A75A-4160-8320-5E61AC154485@cisco.com> <69829339-5EA2-44E2-AF0E-F4B4AAB04FE6@cisco.com> X-Mailer: Apple Mail (2.936) Cc: lisp Subject: Re: [lisp] architecturally separate name-spaces - but assumption about a single value means same thing if in both? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jun 2011 20:25:50 -0000 > Yes - so the EID and RLOC refer to the same end-host. Wrong. The EID is assigned to the end-host and the RLOC is assigned to the LISP router. Dino > > On Thu, Jun 23, 2011 at 4:23 PM, Dino Farinacci > wrote: >>>>> Could a host in a LISP site send to an IP address as an EID and >>>>> the >>>>> same IP address as a globally addressable (or routable)? >>>> >>>> A host sends to destinations. So it doesn't know one from the >>>> other (a >>>> feature). So yes, both a non-LISP site host and a LISP site host >>>> can talk >>>> to >>>> both a non-LISP site and LISP site destination. >>> >>> Let me provide examples, since I strongly think the answer is NO >>> and feel >>> you >>> have side-stepped the question into vague generalities that >>> ignores the >>> issue. >> >> I will be very specific. Today my systems at home use an EID for TCP >> connections. That same 32-bit value is used as an RLOC for LISP >> encapsulating packets that come into my house. >> >> Dino >> >> From akatlas@gmail.com Thu Jun 23 13:30:56 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8F7D21F8522 for ; Thu, 23 Jun 2011 13:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j49aD8YZOEqI for ; Thu, 23 Jun 2011 13:30:56 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id B596421F851B for ; Thu, 23 Jun 2011 13:30:55 -0700 (PDT) Received: by eye13 with SMTP id 13so843668eye.31 for ; Thu, 23 Jun 2011 13:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4+7hIBhmiZOWm6xGAB3z6iA5TrE1vAu3BwTZL4tq8to=; b=oNpmPJw+3rgbZpd9fGEekg/3Jl0twpX8uZyspZIIeTftb20UgcU+ljz4SIxslRiEQL JbMdF8nmCSpqfhLGIddnTkgwQaGo27rV9pahYJSB2MIBMe6r3L4CqzWQ0jV0VJ9tp8qd OLeXez/SLN7nrIDJTV4Uuj9Yj4snlu2x7qUBc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=J/37m6OrOtcHWY6G6g4LxQPdgOd3XjYvMFvbrLkHAn/N700QlDPv7/BFR8MwLRLMWP VuJc6THAm5wPXpSDT/+qapqB7zBMrSYP2FjrOIDdjO1yzAxMaWOmm7yv0K2izGGrLMAA mqT7XAjGkc3hNzmKb26eFJ7O6xXCVjl9uiqTI= MIME-Version: 1.0 Received: by 10.14.98.137 with SMTP id v9mr1730829eef.80.1308861054771; Thu, 23 Jun 2011 13:30:54 -0700 (PDT) Received: by 10.14.189.3 with HTTP; Thu, 23 Jun 2011 13:30:54 -0700 (PDT) In-Reply-To: <20110623190424.7528D18C082@mercury.lcs.mit.edu> References: <20110623190424.7528D18C082@mercury.lcs.mit.edu> Date: Thu, 23 Jun 2011 16:30:54 -0400 Message-ID: From: Alia Atlas To: Noel Chiappa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: lisp@ietf.org Subject: Re: [lisp] architecturally separate name-spaces - but assumption about a single value means same thing if in both? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jun 2011 20:30:56 -0000 Noel, I am very specifically addressing the set of drafts as specified and having just been last called. I do understand that there are a lot of ideas floating around about how to use LISP to do various things - some in charter and some out. To be implemented interoperably based upon reading the drafts, I don't think there is another option. At this point, it seems to me that much of the probability cloud around LISP has to resolve. I'm not trying to be architecturally pure - I want to see something that has the assumptions written down and can be implemented. At least one case of parts that don't work when the same bit-pattern is used as an EID for one host and as an RLOC (or globally routeable address) for another is: ANYWHERE that a lookup in the mapping database is done to determine if an address is an EID or RLOC Alia On Thu, Jun 23, 2011 at 3:04 PM, Noel Chiappa wro= te: > =A0 =A0> From: Alia Atlas > > =A0 =A0> So - although theoretically the value A can be an EID and an RLO= C, > =A0 =A0> the LISP protocol as specified does not permit this. > > Well, yes and no. As long as you include the "as specified", perhaps. But > there are some places (e.g. mobility, where the mobile entity moves into = a > LISP site) where a particular value is both an 'EID' (but not really, in > semantic terms - only in terms of the protocol operation - see below) and > an RLOC. > > For the example of the mobile node which has moved inside a LISP site, > it's actual EID is first mapped to a 'temporary care-of EID' (a term I > just made up), which is its 'address' inside the LISP site. That TC-EID > then has to be mapped to the RLOC of the LISP site. (And the packets wind > up double wrapped, so that each ETR which it traverses can remove one > layer - one at the site boundary, and one at the moble node.) > > The 'temporary care-of EID' looks like an RLOC in a sense, because it is > the _output_ of a mapping stage ... but in the very next moment it's also > the _input_ to a mapping stage, and thus an EID in a sense. > > > The thing is that because it's an incremental, interoperable, add-on to > the existing architecture, things in LISP as not always as clear and cris= p > as one might like - and they often change from case to case. (The LISP > EIDs are an example - and a lot of people are somewhat unhappy that they > are called EIDs, with some justification: sometimes they have no location > information in them, sometimes they do.) > > So, applying that general concept to this particular case, while one migh= t > say, in theory, that there is a crisp division between EIDs and RLOCs, in > practice it's probably going to be a bit muddy. > > > =A0 =A0> Without that assumption, various parts of what is specified simp= ly > =A0 =A0> do not work. > > Ah, why not? > > =A0 =A0 =A0 =A0Noel > From akatlas@gmail.com Thu Jun 23 13:33:10 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E09221F851B for ; Thu, 23 Jun 2011 13:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WN1amgAkzSHh for ; Thu, 23 Jun 2011 13:33:09 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 690A121F850B for ; Thu, 23 Jun 2011 13:33:09 -0700 (PDT) Received: by eye13 with SMTP id 13so844310eye.31 for ; Thu, 23 Jun 2011 13:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3tPIDpAIugII6/LVDvZGFCr93nUiiyfykIBq3GAQXCQ=; b=oZsEstbHpkyE9edF4xKPTJqShTo8MI14EUfqTgf/GkOraiy9VMS06QxqwL9x7qZ9jy A2uueyzxb2IRmAqP/dZ8U19eOnmWshDWHEJRJ5Jx/swCihhXAAMojVDzsSspSrBwt5Ek VrgHTXLc+NG6zI90WA580CF6vkaMEPbCAMTec= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hVgySSLy1v0IUX4u5rlLC5bwuBYjWMyqaluaxzq1KgT5atpR1pRy3/idLr/Y8NItfM cIgHXxeP3Tn1vvEWBVgF+cIka7VGL4auLV8Wtk4QO2DYDsL5Ysjtn4O7iyXJ1Bl1UhH/ lxHyIbrfxh847HhBd5s6RBfTCIVaRy0bYTKfg= MIME-Version: 1.0 Received: by 10.14.22.7 with SMTP id s7mr254385ees.240.1308861188434; Thu, 23 Jun 2011 13:33:08 -0700 (PDT) Received: by 10.14.189.3 with HTTP; Thu, 23 Jun 2011 13:33:08 -0700 (PDT) In-Reply-To: References: <21B84ED0-A75A-4160-8320-5E61AC154485@cisco.com> <69829339-5EA2-44E2-AF0E-F4B4AAB04FE6@cisco.com> Date: Thu, 23 Jun 2011 16:33:08 -0400 Message-ID: From: Alia Atlas To: Dino Farinacci Content-Type: text/plain; charset=ISO-8859-1 Cc: lisp Subject: Re: [lisp] architecturally separate name-spaces - but assumption about a single value means same thing if in both? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jun 2011 20:33:10 -0000 On Thu, Jun 23, 2011 at 4:25 PM, Dino Farinacci wrote: >> Yes - so the EID and RLOC refer to the same end-host. > > Wrong. The EID is assigned to the end-host and the RLOC is assigned to the > LISP router. Fine - but if the RLOC were a globally routable address assigned to me instead of your LISP router- then your computer with its EID couldn't talk to me. (and you might be happier ;-) (And an end-host can have a globally routable address during transition for interworking..) Alia P.S. Do you disagree with Joel's rephrasing of the issue? > Dino > >> >> On Thu, Jun 23, 2011 at 4:23 PM, Dino Farinacci wrote: >>>>>> >>>>>> Could a host in a LISP site send to an IP address as an EID and the >>>>>> same IP address as a globally addressable (or routable)? >>>>> >>>>> A host sends to destinations. So it doesn't know one from the other (a >>>>> feature). So yes, both a non-LISP site host and a LISP site host can >>>>> talk >>>>> to >>>>> both a non-LISP site and LISP site destination. >>>> >>>> Let me provide examples, since I strongly think the answer is NO and >>>> feel >>>> you >>>> have side-stepped the question into vague generalities that ignores the >>>> issue. >>> >>> I will be very specific. Today my systems at home use an EID for TCP >>> connections. That same 32-bit value is used as an RLOC for LISP >>> encapsulating packets that come into my house. >>> >>> Dino >>> >>> > > From dino@cisco.com Thu Jun 23 13:34:30 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98AA21F8522 for ; Thu, 23 Jun 2011 13:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.554 X-Spam-Level: X-Spam-Status: No, score=-10.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMlOOIeqnF+E for ; Thu, 23 Jun 2011 13:34:30 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA4721F851B for ; Thu, 23 Jun 2011 13:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=1772; q=dns/txt; s=iport; t=1308861270; x=1310070870; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=a9BVs79Bkxe9Zd1jAbXM2BrKlxKiYQYRr7liAZ6MLg0=; b=a0NXreGVUib/NBQ069FyXYQ3hIMqa5r5rHwX0/xCGTfLMrMF9Uex+g1E I6z6aOoqPBCBPzT+f1ViSip3Z1cYcvFOBbwYTah1kq8fq3rB/P8UJ1feF 1nxtDYE41QskL8USbeAj5XioHWvcr3hJIPUTeUkZFcYAHezmbYv1dJvPE c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAB2iA06rRDoH/2dsb2JhbABSpyp3iHOjP513hi0EhyaKTIRli0k X-IronPort-AV: E=Sophos;i="4.65,415,1304294400"; d="scan'208";a="468530555" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 23 Jun 2011 20:34:29 +0000 Received: from [10.34.153.93] ([10.34.153.93]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5NKYThn027670; Thu, 23 Jun 2011 20:34:29 GMT Message-Id: <4ED7485E-F87B-4B73-9464-FC69D8366A53@cisco.com> From: Dino Farinacci To: Alia Atlas In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 23 Jun 2011 13:34:29 -0700 References: <21B84ED0-A75A-4160-8320-5E61AC154485@cisco.com> <69829339-5EA2-44E2-AF0E-F4B4AAB04FE6@cisco.com> X-Mailer: Apple Mail (2.936) Cc: lisp Subject: Re: [lisp] architecturally separate name-spaces - but assumption about a single value means same thing if in both? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jun 2011 20:34:31 -0000 > On Thu, Jun 23, 2011 at 4:25 PM, Dino Farinacci > wrote: >>> Yes - so the EID and RLOC refer to the same end-host. >> >> Wrong. The EID is assigned to the end-host and the RLOC is assigned >> to the >> LISP router. > > Fine - but if the RLOC were a globally routable address assigned to me > instead of > your LISP router- then your computer with its EID couldn't talk to me. > (and you might > be happier ;-) It would still work. You are missing something conceptually. We have to talk through this. Maybe at IETF if you are going to be there. Dino > > (And an end-host can have a globally routable address during > transition for interworking..) > > Alia > > P.S. Do you disagree with Joel's rephrasing of the issue? > >> Dino >> >>> >>> On Thu, Jun 23, 2011 at 4:23 PM, Dino Farinacci >>> wrote: >>>>>>> >>>>>>> Could a host in a LISP site send to an IP address as an EID >>>>>>> and the >>>>>>> same IP address as a globally addressable (or routable)? >>>>>> >>>>>> A host sends to destinations. So it doesn't know one from the >>>>>> other (a >>>>>> feature). So yes, both a non-LISP site host and a LISP site >>>>>> host can >>>>>> talk >>>>>> to >>>>>> both a non-LISP site and LISP site destination. >>>>> >>>>> Let me provide examples, since I strongly think the answer is NO >>>>> and >>>>> feel >>>>> you >>>>> have side-stepped the question into vague generalities that >>>>> ignores the >>>>> issue. >>>> >>>> I will be very specific. Today my systems at home use an EID for >>>> TCP >>>> connections. That same 32-bit value is used as an RLOC for LISP >>>> encapsulating packets that come into my house. >>>> >>>> Dino >>>> >>>> >> >> From akatlas@gmail.com Thu Jun 23 13:38:22 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D32F21F84AC for ; Thu, 23 Jun 2011 13:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+ceTHqeJcSa for ; Thu, 23 Jun 2011 13:38:21 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 700A621F84A7 for ; Thu, 23 Jun 2011 13:38:21 -0700 (PDT) Received: by ewy19 with SMTP id 19so846508ewy.31 for ; Thu, 23 Jun 2011 13:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gv9y34sQZ7XEbbz04xnlPuVg16aqOutBzp/l3epjbYg=; b=sRVA8VYQP2odPxL3t80wjmSe+aiG80xF+vawgj9LWrdIHpcy7FwLrmgPmi4VojXe+G g+zPgBKciYDK5+CngbrzbhoJmEhZEX1bIT9t9YGxESkrcy/27uVowu0gHI6z2UNWg2o2 ziAGI/8NmqNRz9BPqO0cj5fEHmhnQ2d4tLVrE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=bOHCFUz+EWnFcV1MSgpXceNvR1dyLFH2n758F13TaaUuaWQ+ECN5UPFmAcVBV0CAgp wt5nEmZ2OlQoIbWS9sRzch4ah0j+EsVr55SIbkgpNYcb1wfkhuh5lfSxRbXGCp2fNWLj r0ic8lowaKHfMWv0JvdFOlO+JiTQgveFnFx4Y= MIME-Version: 1.0 Received: by 10.14.189.4 with SMTP id b4mr1717957een.144.1308861500551; Thu, 23 Jun 2011 13:38:20 -0700 (PDT) Received: by 10.14.189.3 with HTTP; Thu, 23 Jun 2011 13:38:20 -0700 (PDT) In-Reply-To: <4ED7485E-F87B-4B73-9464-FC69D8366A53@cisco.com> References: <21B84ED0-A75A-4160-8320-5E61AC154485@cisco.com> <69829339-5EA2-44E2-AF0E-F4B4AAB04FE6@cisco.com> <4ED7485E-F87B-4B73-9464-FC69D8366A53@cisco.com> Date: Thu, 23 Jun 2011 16:38:20 -0400 Message-ID: From: Alia Atlas To: Dino Farinacci Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: lisp Subject: Re: [lisp] architecturally separate name-spaces - but assumption about a single value means same thing if in both? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jun 2011 20:38:22 -0000 I'd be quite happy to chat at IETF. Could you look at the details of the cases I sent and tell me what I'm missing? Do you disagree with Joel's rephrasing of my concern? Alia On Thu, Jun 23, 2011 at 4:34 PM, Dino Farinacci wrote: >> On Thu, Jun 23, 2011 at 4:25 PM, Dino Farinacci wrote: >>>> >>>> Yes - so the EID and RLOC refer to the same end-host. >>> >>> Wrong. The EID is assigned to the end-host and the RLOC is assigned to >>> the >>> LISP router. >> >> Fine - but if the RLOC were a globally routable address assigned to me >> instead of >> your LISP router- then your computer with its EID couldn't talk to me. >> (and you might >> be happier ;-) > > It would still work. You are missing something conceptually. We have to t= alk > through this. Maybe at IETF if you are going to be there. > > Dino > >> >> (And an end-host can have a globally routable address during >> transition for interworking..) >> >> Alia >> >> P.S. =A0Do you disagree with Joel's rephrasing of the issue? >> >>> Dino >>> >>>> >>>> On Thu, Jun 23, 2011 at 4:23 PM, Dino Farinacci wrote= : >>>>>>>> >>>>>>>> Could a host in a LISP site send to an IP address as an EID and th= e >>>>>>>> same IP address as a globally addressable (or routable)? >>>>>>> >>>>>>> A host sends to destinations. So it doesn't know one from the other >>>>>>> (a >>>>>>> feature). So yes, both a non-LISP site host and a LISP site host ca= n >>>>>>> talk >>>>>>> to >>>>>>> both a non-LISP site and LISP site destination. >>>>>> >>>>>> Let me provide examples, since I strongly think the answer is NO and >>>>>> feel >>>>>> you >>>>>> have side-stepped the question into vague generalities that ignores >>>>>> the >>>>>> issue. >>>>> >>>>> I will be very specific. Today my systems at home use an EID for TCP >>>>> connections. That same 32-bit value is used as an RLOC for LISP >>>>> encapsulating packets that come into my house. >>>>> >>>>> Dino >>>>> >>>>> >>> >>> > > From jmh@joelhalpern.com Thu Jun 23 13:52:53 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A5311E8185 for ; Thu, 23 Jun 2011 13:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.623 X-Spam-Level: X-Spam-Status: No, score=-102.623 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5UclOLJZUKR for ; Thu, 23 Jun 2011 13:52:52 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfa.amsl.com (Postfix) with ESMTP id C19B011E817E for ; Thu, 23 Jun 2011 13:52:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id B643532465FF; Thu, 23 Jun 2011 13:52:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.154.181.49] (unknown [129.192.185.163]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 1869132466F2; Thu, 23 Jun 2011 13:52:21 -0700 (PDT) Message-ID: <4E03A782.6010705@joelhalpern.com> Date: Thu, 23 Jun 2011 16:52:18 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Alia Atlas References: <00D02FFF-2E45-4F5D-9DEC-F5F0961C62D3@cisco.com> <4E027170.9030802@joelhalpern.com> <4E03980F.8030800@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] Last call for draft-ietf-lisp-12: EID holes X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jun 2011 20:52:53 -0000 Unless I am very confused, an ETR can actually provide information that certain EID sub-blocks are delegated, without even providing the RLOCs. For taht EID sub-prefix, it sets the locator count to 0, and sets the ACT bits to Send-Map-Request. (This is useful in a number of other cases, for example, if a sub-block is used for something with very fine grain RLOCs.) So I am still missing what needs to be specified. The text says taht the ETR needs to know about all sub-blocks. Yours, Joel On 6/23/2011 4:24 PM, Alia Atlas wrote: > On Thu, Jun 23, 2011 at 3:46 PM, Joel M. Halpern wrote: >> While I would have liked a solution that completely removed renumbering, >> LISP does not cope with all of the cases that cause renumbering. It is hard >> to state the tradeoff clearly and concisely, although it is inherent in teh >> fact that LISP is site oriented. (Yes, there are some interesting extension >> to mobility, but those are out of scope...) >> >> If there are operational issues that need to be consistent, those should be >> captured in the deployment document. If they aren't, we need to fix that. >> But there are limits. I do not think we need to deal at this time with >> describing exactly what has to happen when a LISP site sells part of its >> network to another organization, that either is or is not using LISP. > > > Sure - I'm not focused on that specific case. What I'm after is the assumption > that an ETR knows the correct locator-set and statuses for a sub-prefix that > has been delegated away... The locator-status bits make sense when the ETRs > are all in the same IGP; if that isn't the case, additional explicit > work is needed. > > What would be useful is capturing the assumptions on knowledge and use-cases. > I know the deployment doc is a start of that, but some of this seems > to me to belong > in the protocol docs. What must an ETR know and with what dynamics to advertise > a prefix and what issues come up with holes and delegation? > > Is it a deliberate decision that there is no way for an ETR to say for > a hole that it > doesn't know what do with it - which means that if an ITR hit that > entry, it would need > to query... > >> Yours, >> Joel >> >> On 6/23/2011 2:59 PM, Alia Atlas wrote: >>> >>> Joel, >>> >>> Certainly I agree that the text in [LISP] addresses some of the basics >>> of handling overlapping >>> prefixes. I had thought that one point of LISP was to avoid needing >>> to renumber; I believe that in >>> a similar case with IPv4 addresses today, it's not unusual to get the >>> smaller prefix announced. >>> >>> However, in response to more detailed questions, I keep hearing back >>> assumptions or things >>> that have been discussed on the list and are not captured in a draft. >>> >>> For a protocol like LISP, there are clearly many operational details >>> and assumptions to be agreed >>> upon and that need to be consistent. Last time I looked at the >>> deployment draft, I didn't notice >>> them captured anywhere. >>> >>> Are there plans for such a draft? >>> >>> Alia >>> >>> >>> On Wed, Jun 22, 2011 at 6:49 PM, Joel M. Halpern >>> wrote: >>>> >>>> The normal situation is that an EID block is delegated to an >>>> administrative >>>> authority (a company). They use it. >>>> They may use the main block, and use some sub-blocks. That produces >>>> "holes" >>>> which are overlapping prefixes. The handling of that is described in the >>>> document. The ETRs which are responsible for the covering EID prefix >>>> must >>>> know which blocks are allocated elsewhere. >>>> They have to identify those in the response. >>>> >>>> THe details are spelled out. >>>> >>>> The normal case would be that the division that was sold would be >>>> renumbered >>>> into its own or its new parents EID block. After all, they are no longer >>>> part of the original site. The overlapping prefix mechanisms allow for >>>> transition. >>>> >>>> The more extreme case is not permitted. You can not have a LISP EID >>>> block, >>>> within which there is a hole which is used as IP addresses but not as >>>> LISP >>>> EIDs. (The inner portion can be used as both, but it has to be an EID.) >>>> >>>> Yours, >>>> Joel >>>> >>>> On 6/22/2011 6:32 PM, Alia Atlas wrote: >>>>> >>>>> Dino, >>>>> >>>>> Thanks for your responses - mine are in-line below. >>>>> >>>>> Alia >>>>> >>>>> On Mon, Jun 20, 2011 at 6:19 PM, Dino Farinacci >>>>> wrote: >>>> >>>> ... >>>>>> >>>>>> If the site has an EID-prefix of the /16 that is the one it Map-Replies >>>>>> for. >>>>>> We have rules in section 6.1.5 "EID-to-RLOC UDP Map-Reply Message" on >>>>>> how >>>>>> to >>>>>> send Map-Replies when there are overlapping EID-prefixes and there has >>>>>> been >>>>>> much discussion on this mailing list about it. >>>>> >>>>> I agree that there's been lots of discussion on the list. Capturing >>>>> the decisions made >>>>> into the draft would be good practice, IMHO, and ensure it has been >>>>> resolved. >>>>> >>>>> Can an ETR have an prefix which has a hole in it? What happens if the >>>>> ETR does not >>>>> know the correct RLOCs to use for that hole (since it isn't owned)? >>>>> >>>>> I'm thinking of a case where initially there is a LISP site with a >>>>> /16. Then, part of that >>>>> company is sold along with the /24 that is used in that division. >>>>> Now, can the original >>>>> site advertise the /16 with a hole? How would it do that? >>>>> >>>>> The problem here is that the ETR does NOT KNOW the correct locator-set >>>>> for the /24 hole >>>>> that has been sold off. >>>>> >>>>> >>>> >>> >> > From akatlas@gmail.com Thu Jun 23 14:11:39 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC88111E81A3 for ; Thu, 23 Jun 2011 14:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kD93fldcVWg3 for ; Thu, 23 Jun 2011 14:11:38 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA2F11E80AC for ; Thu, 23 Jun 2011 14:11:38 -0700 (PDT) Received: by eye13 with SMTP id 13so854584eye.31 for ; Thu, 23 Jun 2011 14:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LhssoH+x37Cy7aH0Tp1gIY8rvWKhsJ57LjGJ4/PASTk=; b=xUC840Ln2XAK0ON8EyI4pdi+sU7KUITHV1OQxySkzWKlIl2DAomEEgxpu9sucj96Y4 JcfXZTNspZggo3nqiMfemNFQ6+HDO9GsmkmFr2+jjLTribulsTPMI0aVPfGqqQx53NZO qL9gq/wsRde3LIyud4khNBcdWPo3PDpdYEXn0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SRQyzVDN7hMmcaKhJmYdNQO1Xc6SeBU5urCMGPooCa4CE5cOcWyhriqaLImUNuqSk6 PwjgYge/YHfa05ENo5IBCn3V8znL8+qij2gSPY2GMqLNEyVTtl0nQ6u8gnhO8OJv6XIQ 3h4aLSsaPJdwxXgRFQrxeqd8fD604KxYXDMw0= MIME-Version: 1.0 Received: by 10.14.28.16 with SMTP id f16mr1738290eea.176.1308863497346; Thu, 23 Jun 2011 14:11:37 -0700 (PDT) Received: by 10.14.189.3 with HTTP; Thu, 23 Jun 2011 14:11:37 -0700 (PDT) In-Reply-To: <4E03A782.6010705@joelhalpern.com> References: <00D02FFF-2E45-4F5D-9DEC-F5F0961C62D3@cisco.com> <4E027170.9030802@joelhalpern.com> <4E03980F.8030800@joelhalpern.com> <4E03A782.6010705@joelhalpern.com> Date: Thu, 23 Jun 2011 17:11:37 -0400 Message-ID: From: Alia Atlas To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "lisp@ietf.org" Subject: Re: [lisp] Last call for draft-ietf-lisp-12: EID holes X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jun 2011 21:11:40 -0000 Ah - I had seen the negative Map-Replies - but only in the contexts described on p. 37 of [lisp-13] (and quoted below). I did not realize that what you are suggested was possible in what is specified. That answers a number of my concerns about the overlapping prefixes - and even seems to be able to address the problem of an EID sub-prefix being given away. If a packet hits that EID sub-prefix and does the Map-Request, when the new Map-Reply is received, presumably it replaces the previous entry for the EID sub-prefix. Later, if the original entries time-out and are refreshed - does that also flush the non-negative sub-prefix entry and replace it with the negative Send-Map-Request entry? I don't think doing so is a problem, but I'm trying to clarify the behavior. Would it be possible to describe this very briefly in the section about prefixes? Something like "The third use is when, due to overlapping prefixes, an ETR needs to convey information about a sub-prefix for which it does not have an accurate locator-set or know their associated statuses. In that case, an ETR could include a record for that sub-prefix with an empty locator-set and specifying an ACT of (2) Send-Map-Request." to go at the end of this paragraph on p. 37: "Map-Reply records can have an empty locator-set. A negative Map- Reply is a Map-Reply with an empty locator-set. Negative Map-Replies convey special actions by the sender to the ITR or PTR which have solicited the Map-Reply. There are two primary applications for Negative Map-Replies. The first is for a Map-Resolver to instruct an ITR or PTR when a destination is for a LISP site versus a non-LISP site. And the other is to source quench Map-Requests which are sent for non-allocated EIDs." Thanks, Alia On Thu, Jun 23, 2011 at 4:52 PM, Joel M. Halpern wrot= e: > Unless I am very confused, an ETR can actually provide information that > certain EID sub-blocks are delegated, without even providing the RLOCs. = =A0For > taht EID sub-prefix, it sets the locator count to 0, and sets the ACT bit= s > to Send-Map-Request. =A0(This is useful in a number of other cases, for > example, if a sub-block is used for something with very fine grain RLOCs.= ) > > So I am still missing what needs to be specified. > The text says taht the ETR needs to know about all sub-blocks. > > Yours, > Joel > > On 6/23/2011 4:24 PM, Alia Atlas wrote: >> >> On Thu, Jun 23, 2011 at 3:46 PM, Joel M. Halpern >> =A0wrote: >>> >>> While I would have liked a solution that completely removed renumbering= , >>> LISP does not cope with all of the cases that cause renumbering. =A0It = is >>> hard >>> to state the tradeoff clearly and concisely, although it is inherent in >>> teh >>> fact that LISP is site oriented. =A0(Yes, there are some interesting >>> extension >>> to mobility, but those are out of scope...) >>> >>> If there are operational issues that need to be consistent, those shoul= d >>> be >>> captured in the deployment document. =A0If they aren't, we need to fix >>> that. >>> =A0But there are limits. =A0 I do not think we need to deal at this tim= e with >>> describing exactly what has to happen when a LISP site sells part of it= s >>> network to another organization, that either is or is not using LISP. >> >> >> Sure - I'm not focused on that specific case. =A0What I'm after is the >> assumption >> that an ETR knows the correct locator-set and statuses for a sub-prefix >> that >> has been delegated away... =A0The locator-status bits make sense when th= e >> ETRs >> are all in the same IGP; if that isn't the case, additional explicit >> work is needed. >> >> What would be useful is capturing the assumptions on knowledge and >> use-cases. >> I know the deployment doc is a start of that, but some of this seems >> to me to belong >> in the protocol docs. =A0What must an ETR know and with what dynamics to >> advertise >> a prefix and what issues come up with holes and delegation? >> >> Is it a deliberate decision that there is no way for an ETR to say for >> a hole that it >> doesn't know what do with it - which means that if an ITR hit that >> entry, it would need >> to query... >> >>> Yours, >>> Joel >>> >>> On 6/23/2011 2:59 PM, Alia Atlas wrote: >>>> >>>> Joel, >>>> >>>> Certainly I agree that the text in [LISP] addresses some of the basics >>>> of handling overlapping >>>> prefixes. =A0I had thought that one point of LISP was to avoid needing >>>> to renumber; I believe that in >>>> a similar case with IPv4 addresses today, it's not unusual to get the >>>> smaller prefix announced. >>>> >>>> However, in response to more detailed questions, I keep hearing back >>>> assumptions or things >>>> that have been discussed on the list and are not captured in a draft. >>>> >>>> For a protocol like LISP, there are clearly many operational details >>>> and assumptions to be agreed >>>> upon and that need to be consistent. =A0Last time I looked at the >>>> deployment draft, I didn't notice >>>> them captured anywhere. >>>> >>>> Are there plans for such a draft? >>>> >>>> Alia >>>> >>>> >>>> On Wed, Jun 22, 2011 at 6:49 PM, Joel M. Halpern >>>> =A0wrote: >>>>> >>>>> The normal situation is that an EID block is delegated to an >>>>> administrative >>>>> authority (a company). =A0They use it. >>>>> They may use the main block, and use some sub-blocks. =A0That produce= s >>>>> "holes" >>>>> which are overlapping prefixes. =A0The handling of that is described = in >>>>> the >>>>> document. =A0The ETRs which are responsible for the covering EID pref= ix >>>>> must >>>>> know which blocks are allocated elsewhere. >>>>> They have to identify those in the response. >>>>> >>>>> THe details are spelled out. >>>>> >>>>> The normal case would be that the division that was sold would be >>>>> renumbered >>>>> into its own or its new parents EID block. =A0After all, they are no >>>>> longer >>>>> part of the original site. =A0The overlapping prefix mechanisms allow= for >>>>> transition. >>>>> >>>>> The more extreme case is not permitted. =A0You can not have a LISP EI= D >>>>> block, >>>>> within which there is a hole which is used as IP addresses but not as >>>>> LISP >>>>> EIDs. =A0(The inner portion can be used as both, but it has to be an >>>>> EID.) >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 6/22/2011 6:32 PM, Alia Atlas wrote: >>>>>> >>>>>> Dino, >>>>>> >>>>>> Thanks for your responses - mine are in-line below. >>>>>> >>>>>> Alia >>>>>> >>>>>> On Mon, Jun 20, 2011 at 6:19 PM, Dino Farinacci >>>>>> =A0wrote: >>>>> >>>>> ... >>>>>>> >>>>>>> If the site has an EID-prefix of the /16 that is the one it >>>>>>> Map-Replies >>>>>>> for. >>>>>>> We have rules in section 6.1.5 "EID-to-RLOC UDP Map-Reply Message" = on >>>>>>> how >>>>>>> to >>>>>>> send Map-Replies when there are overlapping EID-prefixes and there >>>>>>> has >>>>>>> been >>>>>>> much discussion on this mailing list about it. >>>>>> >>>>>> I agree that there's been lots of discussion on the list. =A0Capturi= ng >>>>>> the decisions made >>>>>> into the draft would be good practice, IMHO, and ensure it has been >>>>>> resolved. >>>>>> >>>>>> Can an ETR have an prefix which has a hole in it? =A0What happens if= the >>>>>> ETR does not >>>>>> know the correct RLOCs to use for that hole (since it isn't owned)? >>>>>> >>>>>> I'm thinking of a case where initially there is a LISP site with a >>>>>> /16. =A0Then, part of that >>>>>> company is sold along with the /24 that is used in that division. >>>>>> Now, can the original >>>>>> site advertise the /16 with a hole? =A0How would it do that? >>>>>> >>>>>> The problem here is that the ETR does NOT KNOW the correct locator-s= et >>>>>> for the /24 hole >>>>>> that has been sold off. >>>>>> >>>>>> >>>>> >>>> >>> >> > From vaf@cisco.com Thu Jun 23 14:46:50 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23DE11E80D7 for ; Thu, 23 Jun 2011 14:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7DzX+7Mno7f for ; Thu, 23 Jun 2011 14:46:49 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 45E3811E8086 for ; Thu, 23 Jun 2011 14:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=4039; q=dns/txt; s=iport; t=1308865609; x=1310075209; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=9S3hlqbG3g8fCuKkLSuVywSBxSB4umgpGKqrjpqE6PY=; b=VYi+H8TwGu/qm28rlgS9YND5JJhfQKrRj41hYp+UHZSLueE0ok9GOzC7 ItDs6yuZMG8lCoFBGIQtpEMcJlHdS6p8PLVEIlvRfrANSw7QLXEkyEuqy 8V4+wKUXWZAssF7SNIcK42nF76/x1l9ZxwQnWqqraJs7X7dpnorjWQbDz c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAO0A06rRDoH/2dsb2JhbABSpy13iHOjfZ18hi0Ehyaaeg X-IronPort-AV: E=Sophos;i="4.65,415,1304294400"; d="scan'208";a="720997320" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 23 Jun 2011 21:46:45 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5NLkjCJ012965; Thu, 23 Jun 2011 21:46:45 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 2D84F1260CE4; Thu, 23 Jun 2011 14:46:57 -0700 (PDT) Date: Thu, 23 Jun 2011 14:46:57 -0700 From: Vince Fuller To: Alia Atlas Message-ID: <20110623214656.GA54962@vaf-mac1.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "lisp@ietf.org" Subject: Re: [lisp] last call for draft-ietf-lisp-alt-06 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jun 2011 21:46:50 -0000 On Mon, May 16, 2011 at 06:26:53PM -0400, Alia Atlas wrote: > This is a very well written and clear document. I think it is in good > shape. > > I do have a few questions: > > a) In Sec. 4.1, > "This "first hop" ALT Router uses EID-prefix routing information > learned from other ALT Routers via BGP to guide the packet to the > ETR which "owns" the prefix." > > If an ETR provides more than 1 RLOC for an EID-prefix or multiple ETRs > provide different RLOCs, how does the ALT Router decide which to use > to guide the packet to the ETR? Does the ALT Router determine > that the ETR is reachable? > > Perhaps this is a question better asked of draft-ietf-lisp-ms, but I > do not see it addressed there either and the guiding of the > unencapsulated Map-Request appears to be left to the ALT > infrastructure. I don't understand this question. The forwarding table on an ALT router is composed of EID prefixes with next hops over tunnels to other ALT routers. RLOCs are not used when forwarding ALT Datagrams. If an ETR connects to the ALT (which is rarely done; ETRs usually register their prefixes with Map Servers rather than participating in the ALT directly), then it does so with tunnels to other ALT routers. An ALT Datagram destined to that ETR (i.e. one which has a destination IP address that matches the EID prefix advertised into the ALT by the ETR) will be forwarded to a tunnel endpoint address on that ETR, not to an ETR RLOC. > b) How can an ETR tell if the outer header Source Address of an ALT > datagram is an RLOC or an EID? I do see that using an EID is not > supported by initial LISP+ALT implementations (this could be pulled > early in the draft where the idea is first proposed), but I also don't > see a mechanism to do the disambiguation. The ETR does not attempt to determine whether the outer header source address is an RLOC or an EID; when it sends a Map-Reply to that address, it simply forwards it using the contents of its forwarding table. If the original source address was an EID and the ETR is connected to the ALT (again, this is a rare, degenerate case; ITRs and ETRs do not normally connect directly to the ALT), then the Map-Reply will be sent back over the ALT, which is not recommended and may or may not acheive the desired result. > c) In Sec 7.2, there is a sentence: "Should a receiving ITR decide > that it does not wish to store such more-specific information, it has > the option of discarding it as long as a shorter, covering EID-prefix > exists." I found this confusing and it seems to violate the prefix > rules in [LISP], as well as they were described. If a covering map cache entry exists (i.e. 153.16.0.0/16) and the more- specific prefixes are discarded (i.e. 153.16.10.0/24), then data traffic would be LISP-encapsulated and sent to one of the RLOCs for the covering map cache. This is no different than the way a shorter prefix can be used for IP forwarding to any more-specifics of that prefix. > d) In [LISP] sec 5.5., there is discussion of using Instance IDs to > disambiguate. "When multiple organizations inside of a LISP site are > using private addresses [RFC1918] as EID-prefixes, their address > spaces MUST remain segregated due to possible address duplication. An > Instance ID in the address encoding can aid in making the entire AFI > based address unique. See IANA Considerations Section 14.1 for > details for possible address encodings." > > I am not suggesting adding explicit support for this at this point, but > adding a caveat that supporting this is for future study & experimentation > would provide clarity. The use of instance IDs is outside of the scope of the ALT document. > f) Typo in 2nd to last paragraph on p.20: > "This is, by no means, and exhaustive list." > ^^^ > an Thanks. Fixed in the -07 draft, which will be published shortly. --Vince (on behalf of the other co-authors) From jnc@mercury.lcs.mit.edu Thu Jun 23 14:47:00 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C7011E810A for ; Thu, 23 Jun 2011 14:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9deA4hShWF8g for ; Thu, 23 Jun 2011 14:47:00 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 3658411E80EB for ; Thu, 23 Jun 2011 14:47:00 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A7A9218C0FA; Thu, 23 Jun 2011 17:46:59 -0400 (EDT) To: lisp@ietf.org Message-Id: <20110623214659.A7A9218C0FA@mercury.lcs.mit.edu> Date: Thu, 23 Jun 2011 17:46:59 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] architecturally separate name-spaces - but assumption about a single value means same thing if in both? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jun 2011 21:47:00 -0000 > From: Alia Atlas > I want to see something that has the assumptions written down and > can be implemented. How about 'Anything that can be fed _into_ the mapping system, and get an answer, is an LEID; anything that can be seen in the _output_ from the mapping system is an RLOC.' Although even that's probably too precise - it my mind were fully awake, I could probably come up with some countexamples. > At least one case of parts that don't work when the same bit-pattern > is used as an EID for one host and as an RLOC (or globally routeable > address) for another is: > ANYWHERE that a lookup in the mapping database is done to determine > if an address is an EID or RLOC Mu. The assumption in that question (that something is _either_ an RLOC _or_ an LEID) does not hold 100.00000% - although I wish it did! (Leaving aside the cases of legacy addresses, which are all both at once, of course.) If you can look up a bit-pattern in the mapping database, and get back an answer, that bit-pattern has LEID-nature. But that doesn't mean it can't also have RLOC-nature. Yes, having that kind of mixed-up semantics a lot is not good; and for the simple (and hopefully by far and away the most common) model, it does not happen. But the Internet is large, and there are more kludges in it than any of us dream of in our architectures.... Noel From akatlas@gmail.com Thu Jun 23 15:40:18 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F1911E8084 for ; Thu, 23 Jun 2011 15:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHtmogymUbCr for ; Thu, 23 Jun 2011 15:40:18 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3379C11E8078 for ; Thu, 23 Jun 2011 15:40:18 -0700 (PDT) Received: by pwj5 with SMTP id 5so1606682pwj.31 for ; Thu, 23 Jun 2011 15:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Q1C9saWD1jetamsu4OyDh8o5+6GmBn2KlZOymMRrP48=; b=ornFw1Z21LtXeZHfvERqNFMZ6GpgVpMq57HUtwm6w0dwHejfZZONEZiUx41G8tqGrL b5xMdKs0RcPzLJERlENrynoVmgZu6afRM9njn4YyKWbMpntJqQ7LbEheX85v+c+Xq1G3 9TRm8TvRYJFMFp/+V6W2TcVNekENH0P6J26Tw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qt9NfOEt+08PEdCCCKobp4n4ZPYFnpjBT7S0k8tYVasbpeXY4AyMkcYeMtSl4qpVlF 360e1ew5po1dZrfWFpsclNXwJal1KZfH/lWvLI7La4KUs1SIJD0lszhx2tXYL6MchVB6 VwbujQrY24ijEWPnq7/R3ec0z4frqkOp1uzjE= MIME-Version: 1.0 Received: by 10.68.46.73 with SMTP id t9mr1535892pbm.234.1308868817728; Thu, 23 Jun 2011 15:40:17 -0700 (PDT) Received: by 10.68.46.98 with HTTP; Thu, 23 Jun 2011 15:40:17 -0700 (PDT) In-Reply-To: <20110623214659.A7A9218C0FA@mercury.lcs.mit.edu> References: <20110623214659.A7A9218C0FA@mercury.lcs.mit.edu> Date: Thu, 23 Jun 2011 18:40:17 -0400 Message-ID: From: Alia Atlas To: Noel Chiappa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: lisp@ietf.org Subject: Re: [lisp] architecturally separate name-spaces - but assumption about a single value means same thing if in both? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jun 2011 22:40:18 -0000 Hi Noel, On Thu, Jun 23, 2011 at 5:46 PM, Noel Chiappa wro= te: > =A0 =A0> From: Alia Atlas > > =A0 =A0> I want to see something that has the assumptions written down an= d > =A0 =A0> can be implemented. > > How about 'Anything that can be fed _into_ the mapping system, and get an > answer, is an LEID; anything that can be seen in the _output_ from the > mapping system is an RLOC.' Although even that's probably too precise - i= t > my mind were fully awake, I could probably come up with some countexample= s. > > =A0 =A0> At least one case of parts that don't work when the same bit-pat= tern > =A0 =A0> is used as an EID for one host and as an RLOC (or globally route= able > =A0 =A0> address) for another is: > =A0 =A0> =A0ANYWHERE that a lookup in the mapping database is done to det= ermine > =A0 =A0> =A0if an address is an EID or RLOC > > Mu. The assumption in that question (that something is _either_ an RLOC > _or_ an LEID) does not hold 100.00000% - although I wish it did! (Leaving > aside the cases of legacy addresses, which are all both at once, of > course.) If you can look up a bit-pattern in the mapping database, and ge= t > back an answer, that bit-pattern has LEID-nature. But that doesn't mean i= t > can't also have RLOC-nature. Yes - but the question is whether the same bitpattern must belong to the same site and end-host. Please see Joel's rephrasing of my concern. I'm fine with the mixed up semantics for interworking and so on. I'm not h= appy about separate namespaces not being separate (e.g. independently allocatabl= e) without that being clearly written down. What is written down is that they= are separate name-spaces. > Yes, having that kind of mixed-up semantics a lot is not good; and for th= e > simple (and hopefully by far and away the most common) model, it does not > happen. But the Internet is large, and there are more kludges in it than = any > of us dream of in our architectures.... Kludges happen - I want documentation of them though. Alia From jnc@mercury.lcs.mit.edu Thu Jun 23 16:11:29 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5EC21F8485 for ; Thu, 23 Jun 2011 16:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSfW57xpP3E2 for ; Thu, 23 Jun 2011 16:11:28 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 6468921F8484 for ; Thu, 23 Jun 2011 16:11:28 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 410D718C0FD; Thu, 23 Jun 2011 19:11:15 -0400 (EDT) To: lisp@ietf.org Message-Id: <20110623231121.410D718C0FD@mercury.lcs.mit.edu> Date: Thu, 23 Jun 2011 19:11:15 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] architecturally separate name-spaces - but assumption about a single value means same thing if in both? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jun 2011 23:11:29 -0000 > From: Alia Atlas > the question is whether the same bitpattern must belong to the same > site and end-host. I would tend to say 'yes' - but I'm sure some bright spark will find a use for having that not be true! > I'm not happy about separate namespaces not being separate (e.g. > independently allocatable) without that being clearly written down. > What is written down is that they are separate name-spaces. I think that's more of a goal, or perhaps more accurately a gross simplification made for the sake of a clear, simple explanation, than a strict statement of fact. (If nothing else, they aren't independently allocated.) So maybe the wording could use some clarification - as long as we don't make it harder to understand for the average network engineer out there (especially bearing in mind what Bob Dobbs said about average people...) Noel From vaf@cisco.com Thu Jun 23 17:03:45 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249EE11E80D8 for ; Thu, 23 Jun 2011 17:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlQVJG8+C8Uf for ; Thu, 23 Jun 2011 17:03:44 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 00AD011E807C for ; Thu, 23 Jun 2011 17:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=5460; q=dns/txt; s=iport; t=1308873823; x=1310083423; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=OjpL+1R9fDmnUeBJmjGrKElPEuB5UmeAQ9L03VvXcI4=; b=SZiCr2Nl5iy1A/H7iNYWl+QeeFIqVvu40gOKGyBwCg6x2/cNUXC5kYiz gu0ZFOyfhwYtsJD+X2DpQdjBhZkVUBYm3yysRBOINUu5IFmXa8Y/sF/pr 4nAsNU/x8sCVaw4e8a5getGPDtbvJ+L/pytj37BcXmLQk60Nm6KFW5X3W M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGHTA06rRDoI/2dsb2JhbABSpy53iHOkU514hi0Ehyaaeg X-IronPort-AV: E=Sophos;i="4.65,416,1304294400"; d="scan'208";a="468722980" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 24 Jun 2011 00:03:43 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5O03hws001865; Fri, 24 Jun 2011 00:03:43 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 451D5126114A; Thu, 23 Jun 2011 15:15:31 -0700 (PDT) Date: Thu, 23 Jun 2011 15:15:31 -0700 From: Vince Fuller To: Alia Atlas Message-ID: <20110623221530.GB54962@vaf-mac1.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "lisp@ietf.org" Subject: Re: [lisp] last call for draft-ietf-lisp-ms-08 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2011 00:03:45 -0000 > a) When an ETR sends a Map-Register to a Map Server, does the ETR have > to include all the RLOCs associated with the EID-prefix and > specifically even those not associated with that particular ETR? From > what I understood from the draft, the RLOCs are used to either forward > Map-Requests to the ETR as indicated in Sec. 3 > "Intermediate ALT routers forward Map-Requests to the Map-Server > that advertises a particular EID-prefix and the Map-Server forwards > them to the owning ETR, which responds with Map-Reply messages." > > or, as specified in Sec 4.4, to directly provide the RLOCs in a Map-Reply: > "Upon receipt of an Encapsulated Map-Request, a Map-Resolver de- > capsulates the enclosed message then searches for the requested EID > in its local database of mapping entries (statically configured, > cached, or learned from associated ETRs). If it finds a matching > entry, it returns a non-authoritative LISP Map-Reply with the known > mapping." > > I don't see any language that explicitly defines what set of RLOCs > should be included. The full list of RLOCs is returned in a Map-Reply from an ETR to an ITR. An ETR is not required to supply the full set of RLOCs when it registers with a Map-Server; the ETR need only need provide those RLOCs that it wishes the MS to use when forwarding a Map-Request to the ETR. > b) What does a Map-Server do when it gets Map-Register messages from > different ETRs for the same EID-prefix? This seems to me to be a > likely case where for resiliency there could be 2 ETRs and each would > register with two Map-Servers. Even if all the RLOCs are supposed to > be included, what happens when there is a chance and one ETR is > (temporarily) out of sync with the other? Each ETR for a particular EID-prefix is expected to register with all of the Map-Servers that publish that prefix into the mapping database. When a Map-Server receives an Encapsulated Map-Request for that prefix, it sends to one of the registered ETRs. The exact process that it uses for distributing the Map-Request load among multiple registered ETRs is not specified but round robin would be a reasonable choice. If one ETR has out-of-date information relative to the others, then yes, temporary inconsistencies may result, just as is the case with any other distributed database (i.e. multi-homed sites connected via BGP). > c) If an ETR is supposed to send all the RLOCs associated with an > EID-prefix in a Map-Register message, then how is the R-bit for each > locator record specified by the Map-Server? Does the Map-Server > confirm reachability to each of the RLOCs specified before sending any > Map-Replies? I will have to defer to Dino to answer this detail. > d) The Map-Server is described in the Introduction as: > "a Map-Server, which learns authoritative EID-to-RLOC mappings from > an ETR and publish them in the database." > I found this confusing, since the mapping service seems to me to be > about determining which ETR (or proxy) to ask for the EID-to-RLOC > mapping and is providing an lookup service to get to the ETR and not > necessarily the full RLOC mapping. Please suggest alternative text. > e) For clarification, why does a Map-Resolver return a Map-Reply for > EID-prefixes in its local database? I could see doing that if the ETR > had requested proxying, but if not - why is there a potential > difference in what is returned for a local Map-Request versus a remote > one? As I understand it, in the remote case, the Map-Request is > unencapsulated (as per Sec 4.4 (1)) and is therefore handed to the ETR. A single device may act as both a Map-Server and a Map-Resolver. In such a situation, a Map-Resolver will consult its local database to see if it is also configured as a Map-Server for the EID-prefix being requested. > f) Further, the appropriate behavior of a Map-Resolver when proxying > is requested is NOT specified anywhere. Please provide suggested text to describe this behavior. > g) On p.6, a negative LISP Map-Reply is sent, but the details of the > action selected is not defined anywhere. I assume that the draft > means to specify as natively forward, but as written I did not find it > clear (perhaps because I didn't have the Map-Reply packet format > memorized). I will reword this section to reference the action codes defined in the LISP base document. > h) What is the purpose of frequently (1/min) resending the > Map-Register message? It is only verifying that the ETR still owns > the EID-prefix? If it is verifying liveness - why is that ETR special > compared to others whose RLOCs are also given. Why not depend on the > underlying routing to be sure of liveness? It is a simple keepalive mechanism between an MS and an ETR to ensure that not only is the ETR reachable but that it both responsive and wants the MS to continue to publish its EID prefixes in the mapping database. Underlying routing would not accomplish this. > > i) typo on p.8 item (1), 3rd line: "mapaping" -> "mapping" > > j) typo in 2nd paragraph, last sentence in Sec 4.1: > "Using the Map-Resolver greatly reduces both the complexity of the > ITR implementation the costs associated with its operation." > ^^ > and Thanks, fixed in -09. --Vince (for the other co-authors) From vaf@cisco.com Thu Jun 23 17:33:48 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53EDF11E8180 for ; Thu, 23 Jun 2011 17:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFyB4ZcJl8nz for ; Thu, 23 Jun 2011 17:33:47 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBB711E80A4 for ; Thu, 23 Jun 2011 17:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=421; q=dns/txt; s=iport; t=1308875627; x=1310085227; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Yqpd15lXDqnkt+4zkPZ59HO6OEV3GyHhWqHATLyJTxc=; b=AybIYtbImIe5WFWwF44hDv19cDGqhbee9MEIkbrYnwZavJcHE+JxU9cy syJiuAFfHa45afvW6pZUN5ZwRAeMfLrS1ZH8wDnTKrmBdIgd+l55rded6 u5zXO15pNsN92iQkkxCv6wUFUndnBF1Q06sOMKwvIc9rw4WnDui2/7rdf I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEDaA06rRDoG/2dsb2JhbABSpy93iHOkO517hi0Ehyaaeg X-IronPort-AV: E=Sophos;i="4.65,416,1304294400"; d="scan'208";a="384928452" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 24 Jun 2011 00:33:47 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5O0Xlvh011700; Fri, 24 Jun 2011 00:33:47 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id C65821261292; Thu, 23 Jun 2011 15:26:21 -0700 (PDT) Date: Thu, 23 Jun 2011 15:26:21 -0700 From: Vince Fuller To: Alia Atlas Message-ID: <20110623222621.GD54962@vaf-mac1.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "lisp@ietf.org" Subject: Re: [lisp] last call for draft-ietf-lisp-ms-08 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2011 00:33:48 -0000 I realized after I sent my last note that I forgot one of the points: > f) Further, the appropriate behavior of a Map-Resolver when proxying > is requested is NOT specified anywhere. A Map Resolver doesn't act as a proxy; a Map Server may. If a Map Server is acting as a proxy, then it returns a Map-Reply on behalf of a registered ETR that has requested proxy service. --Vince (for the other co-authors) From akatlas@gmail.com Thu Jun 23 23:22:13 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0455311E817B for ; Thu, 23 Jun 2011 23:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8ntOqjkMl8S for ; Thu, 23 Jun 2011 23:22:12 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 37E0511E811B for ; Thu, 23 Jun 2011 23:22:12 -0700 (PDT) Received: by eye13 with SMTP id 13so962287eye.31 for ; Thu, 23 Jun 2011 23:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=xY2BZl/Hkgftx52gnDRqcDRe8MwHx/xZY7eP6XKTgu0=; b=thiEoI66FixxkFscvcZFFFy6W4HHpLHbTX3sWCbo7rRRF6rOCtYR1IGBpx44Skds2m s32YFdp9ksl/RtjamDtuggWnjaAYXkVxEeL2WUr+zTJX6qvZC8XGXfmklktuaeYgxqnv LF3wgNP0V4V01IYPD96HlPApBX+WWDO/tvApk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=WtLZUkNw7ye6rTXVPIb+rC2Ss5ZK3/3J0CExLRUSmG2bCX79Wb6+Vg1/q0DytAgv9p Hm65qwgsI/b4YgIOaASW3dIZnW7LnK57bufh6bXkXgEl91JfT3WEj7QYcDoXJEuRsHBx DCcqo6FsxVHUTd60dMvEhY7O+jh+UfBohnyWk= MIME-Version: 1.0 Received: by 10.14.22.7 with SMTP id s7mr505938ees.240.1308896530896; Thu, 23 Jun 2011 23:22:10 -0700 (PDT) Received: by 10.14.189.3 with HTTP; Thu, 23 Jun 2011 23:22:10 -0700 (PDT) Date: Fri, 24 Jun 2011 02:22:10 -0400 Message-ID: From: Alia Atlas To: Vince Fuller , Dino Farinacci , "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "lisp@ietf.org" Subject: Re: [lisp] last call for draft-ietf-lisp-alt-06: question c - discarding more specific prefixes X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2011 06:22:13 -0000 Vince, Dino & Joel, On Thu, Jun 23, 2011 at 5:46 PM, Vince Fuller wrote: > On Mon, May 16, 2011 at 06:26:53PM -0400, Alia Atlas wrote: >> c) In Sec 7.2, there is a sentence: "Should a receiving ITR decide >> that it does not wish to store such more-specific information, it has >> the option of discarding it as long as a shorter, covering EID-prefix >> exists." =A0I found this confusing and it seems to violate the prefix >> rules in [LISP], as well as they were described. > > If a covering map cache entry exists (i.e. 153.16.0.0/16) and the more- > specific prefixes are discarded (i.e. 153.16.10.0/24), then data traffic > would be LISP-encapsulated and sent to one of the RLOCs for the covering > map cache. This is no different than the way a shorter prefix can be used > for IP forwarding to any more-specifics of that prefix. It's possible I'm missing something (as always), but I would like to be persuaded because this sounds like a clear case of the ability to cause traffic dropping accidentally. First, the covering map cache entry may send traffic to RLOC A while a more specific prefix would send the traffic to RLOC B. The ETR which owns RLOC A has, as required in [LISP] sent the more specific prefixes - but an ITR, according to the above quoted sentence in Sec 7.2, c= an discard them. As I understand it, if the ITR chooses to do so, then the ITR would forward packets in the more specific prefix to RLOC A. At the same time, in the email thread with Dino on [LISP], I asked: " For instance, if an ETR receives a LISP encapsulated packet and decapsulates it, but does not have EID locally, what should the ETR do?" and Dino said "Drop it". If both his answer and your response on correct, then the ITR, by dropping a more specific prefix mapping, is guaranteeing that traffic to that more specific prefix will be dropped. I do not believe this meets a reasonable definition of "correct" behavior. It also contradicts the carefully detailed rules in the base LISP draft. Can we please clarify the correct behavior so that the appropriate draft(s) can be updated? Thanks, Alia From akatlas@gmail.com Thu Jun 23 23:25:02 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB43211E817B for ; Thu, 23 Jun 2011 23:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaK6v5OFnBZp for ; Thu, 23 Jun 2011 23:25:01 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8C18611E811B for ; Thu, 23 Jun 2011 23:25:01 -0700 (PDT) Received: by ewy19 with SMTP id 19so965297ewy.31 for ; Thu, 23 Jun 2011 23:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jOvAKh36KdXbICEP5s3FmDyBdl6dvQzOWFAeAmNTEZY=; b=I3CHz/KCzgmjkhY9vG6KnOc0U5O7k8lqOHl9xfz3aLzFkHNfsN4iWtTiQm8gIvjOi4 tRW5Wh0U+u9qeWkxhzhLN/8pIb06RoIRguvFwlycjDVgdqyikLi3rGSwOC5qpDapH/FL rM+yhHHjoSiAOu5iPN/IJAZu8zta+5vtfwBi8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cwVgWjbjRzL62qYDNYmiGbdXrZTruX0fBRDA0a2AtaJLuukt/7sN6+GULWquoGm4B/ SmBT/+pmuLwpdXZrORazfqlO+MXYocVPibHYuecTj1unBmRUEFiKGSQFprGe64v5Gte+ c8IwYWI9uwExD2t0pOW2kCO/eEFhEwS+KOnl8= MIME-Version: 1.0 Received: by 10.14.187.11 with SMTP id x11mr1808250eem.112.1308896700561; Thu, 23 Jun 2011 23:25:00 -0700 (PDT) Received: by 10.14.189.3 with HTTP; Thu, 23 Jun 2011 23:25:00 -0700 (PDT) In-Reply-To: <20110623231121.410D718C0FD@mercury.lcs.mit.edu> References: <20110623231121.410D718C0FD@mercury.lcs.mit.edu> Date: Fri, 24 Jun 2011 02:25:00 -0400 Message-ID: From: Alia Atlas To: Noel Chiappa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: lisp@ietf.org Subject: Re: [lisp] architecturally separate name-spaces - but assumption about a single value means same thing if in both? X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2011 06:25:02 -0000 On Thu, Jun 23, 2011 at 7:11 PM, Noel Chiappa wro= te: > =A0 =A0> From: Alia Atlas > > =A0 =A0> the question is whether the same bitpattern must belong to the s= ame > =A0 =A0> site and end-host. > > I would tend to say 'yes' - but I'm sure some bright spark will find a us= e > for having that not be true! Useful or not - that is not possible with what is currently specified. > =A0 =A0> I'm not happy about separate namespaces not being separate (e.g. > =A0 =A0> independently allocatable) without that being clearly written do= wn. > =A0 =A0> What is written down is that they are separate name-spaces. > > I think that's more of a goal, or perhaps more accurately a gross > simplification made for the sake of a clear, simple explanation, than a > strict statement of fact. (If nothing else, they aren't independently > allocated.) > > So maybe the wording could use some clarification - as long as we don't > make it harder to understand for the average network engineer out there > (especially bearing in mind what Bob Dobbs said about average people...) I strongly think it needs clarification; Joel's text is a good start. Certainly, starting from the natural assumption about two namespaces being completely independent, it was "clear= " that there were problems as specified. Alia From jmh@joelhalpern.com Thu Jun 23 23:34:07 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4435111E81C3 for ; Thu, 23 Jun 2011 23:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.024 X-Spam-Level: X-Spam-Status: No, score=-102.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GjW0wNN5IlQ for ; Thu, 23 Jun 2011 23:34:06 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfa.amsl.com (Postfix) with ESMTP id AF39711E81C2 for ; Thu, 23 Jun 2011 23:34:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 87B3E32466F1; Thu, 23 Jun 2011 23:33:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [172.17.114.244] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 340B632466D4; Thu, 23 Jun 2011 23:33:36 -0700 (PDT) Message-ID: <4E042FBB.7050800@joelhalpern.com> Date: Fri, 24 Jun 2011 02:33:31 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Alia Atlas References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] last call for draft-ietf-lisp-alt-06: question c - discarding more specific prefixes X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2011 06:34:07 -0000 I believe Alia is correct about this. Unless I have missed something, there is no way for an ITR receiving nested prefixes to tell the difference between the case (described in the base LISP spec) when the longer prefix MUST be used, and cases of traffic engineering where it is only a matter of preference. As such, since the base overlap case requires that longer prefixes be retained, this text (in the second paragraph of 7.2) seems to violate the base requirements. If there is some way that an ITR can actually tell the difference between the two cases, this text needs to say taht. I don't think there is any such method. Yours, Joel On 6/24/2011 2:22 AM, Alia Atlas wrote: > Vince, Dino& Joel, > > On Thu, Jun 23, 2011 at 5:46 PM, Vince Fuller wrote: >> On Mon, May 16, 2011 at 06:26:53PM -0400, Alia Atlas wrote: > >>> c) In Sec 7.2, there is a sentence: "Should a receiving ITR decide >>> that it does not wish to store such more-specific information, it has >>> the option of discarding it as long as a shorter, covering EID-prefix >>> exists." I found this confusing and it seems to violate the prefix >>> rules in [LISP], as well as they were described. >> >> If a covering map cache entry exists (i.e. 153.16.0.0/16) and the more- >> specific prefixes are discarded (i.e. 153.16.10.0/24), then data traffic >> would be LISP-encapsulated and sent to one of the RLOCs for the covering >> map cache. This is no different than the way a shorter prefix can be used >> for IP forwarding to any more-specifics of that prefix. > > It's possible I'm missing something (as always), but I would like to be > persuaded because this sounds like a clear case of the ability to cause > traffic dropping accidentally. > > First, the covering map cache entry may send traffic to RLOC A while > a more specific prefix would send the traffic to RLOC B. > > The ETR which owns RLOC A has, as required in [LISP] sent the more specific > prefixes - but an ITR, according to the above quoted sentence in Sec 7.2, can > discard them. > > As I understand it, if the ITR chooses to do so, then the ITR would > forward packets > in the more specific prefix to RLOC A. > > At the same time, in the email thread with Dino on [LISP], I asked: > > " For instance, if an ETR receives a LISP encapsulated packet and > decapsulates it, but > does not have EID locally, what should the ETR do?" > > and Dino said "Drop it". > > If both his answer and your response on correct, then the ITR, by > dropping a more > specific prefix mapping, is guaranteeing that traffic to that more > specific prefix will be dropped. > > I do not believe this meets a reasonable definition of "correct" behavior. > > It also contradicts the carefully detailed rules in the base LISP draft. > > Can we please clarify the correct behavior so that the appropriate > draft(s) can be updated? > > Thanks, > Alia > From akatlas@gmail.com Fri Jun 24 00:02:53 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BD211E8092 for ; Fri, 24 Jun 2011 00:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Th320bAWXxUW for ; Fri, 24 Jun 2011 00:02:52 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 22B9F11E8091 for ; Fri, 24 Jun 2011 00:02:52 -0700 (PDT) Received: by pwj5 with SMTP id 5so1778309pwj.31 for ; Fri, 24 Jun 2011 00:02:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mtTHCAHVq+hfnfqRO8SfuWMjGVKgj2nB6uuWD0n+g9s=; b=eFBVDLIZw06hjj7fjOu7CJUTeCvCOpNnP3lGZSqzh4oox/76m7rQiat5yGrCwRRF7C gzfdA1kmheTibVge3RkbAQDL5PC1R20QrjTD+snUYHUf0Nomk6ThqcWXF36KCnibNn3l StTuEdX4ezVecVxlZypXGZOXbzl9oFhByr/V8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=a2cQC4hi/gGvraPov4S1YMz9uMXKiDH8qlGBT+Sy1nvoaHsh/ovl8zlO0z6bfViopa oKaycNmhmN56BkHPg+QNWYRHMOGRIq2RZAJ2E4L8Uyr5CnJ4lE5arbdbehsp4SSTOxwK VNYY6bOZbUQgl3XCj6r20LC9Vtiup1gUYnWUk= MIME-Version: 1.0 Received: by 10.68.16.8 with SMTP id b8mr1718375pbd.368.1308898971243; Fri, 24 Jun 2011 00:02:51 -0700 (PDT) Received: by 10.68.54.69 with HTTP; Fri, 24 Jun 2011 00:02:51 -0700 (PDT) In-Reply-To: <20110623214656.GA54962@vaf-mac1.cisco.com> References: <20110623214656.GA54962@vaf-mac1.cisco.com> Date: Fri, 24 Jun 2011 03:02:51 -0400 Message-ID: From: Alia Atlas To: Vince Fuller Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "lisp@ietf.org" Subject: Re: [lisp] last call for draft-ietf-lisp-alt-06 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2011 07:02:53 -0000 Vince, Thanks for the responses - comments in-line. On Thu, Jun 23, 2011 at 5:46 PM, Vince Fuller wrote: > On Mon, May 16, 2011 at 06:26:53PM -0400, Alia Atlas wrote: >> This is a very well written and clear document. =A0I think it is in good >> shape. >> >> I do have a few questions: >> >> a) In Sec. 4.1, >> =A0 =A0"This "first hop" ALT Router uses EID-prefix routing information >> =A0 =A0learned from other ALT Routers via BGP to guide the packet to the >> =A0 =A0ETR which "owns" the prefix." >> >> If an ETR provides more than 1 RLOC for an EID-prefix or multiple ETRs >> provide different RLOCs, how does the ALT Router decide which to use >> to guide the packet to the ETR? =A0Does the ALT Router determine >> that the ETR is reachable? >> >> Perhaps this is a question better asked of draft-ietf-lisp-ms, but I >> do not see it addressed there either and the guiding of the >> unencapsulated Map-Request appears to be left to the ALT >> infrastructure. > > I don't understand this question. The forwarding table on an ALT router i= s > composed of EID prefixes with next hops over tunnels to other ALT routers= . > RLOCs are not used when forwarding ALT Datagrams. If an ETR connects to > the ALT (which is rarely done; ETRs usually register their prefixes with > Map Servers rather than participating in the ALT directly), then it does > so with tunnels to other ALT routers. An ALT Datagram destined to that > ETR (i.e. one which has a destination IP address that matches the EID > prefix advertised into the ALT by the ETR) will be forwarded to a tunnel > endpoint address on that ETR, not to an ETR RLOC. Thanks - this was my confusion. I got the question from the [MS] draft and clearly dropped a bit of context. >> b) How can an ETR tell if the outer header Source Address of an ALT >> datagram is an RLOC or an EID? =A0I do see that using an EID is not >> supported by initial LISP+ALT implementations (this could be pulled >> early in the draft where the idea is first proposed), but I also don't >> see a mechanism to do the disambiguation. > > The ETR does not attempt to determine whether the outer header source > address is an RLOC or an EID; when it sends a Map-Reply to that address, > it simply forwards it using the contents of its forwarding table. If the > original source address was an EID and the ETR is connected to the ALT > (again, this is a rare, degenerate case; ITRs and ETRs do not normally > connect directly to the ALT), then the Map-Reply will be sent back over > the ALT, which is not recommended and may or may not acheive the desired > result. This question was in reference to the last paragraph in Sec 3: "The term "ALT Datagram" is short-hand for a Map-Request or Data Probe to be sent into or forwarded on the ALT. Note that while the outer header Source Address of an ALT Datagram is currently expected to be an RLOC, there may be situations (e.g. for experimentation with caching in intermediate ALT nodes) where an EID would be used to force a Map-Reply to be routed back through the ALT. " I think the base of the question is whether the ETR can just know if a give= n bit-pattern is an EID by seeing if it is in the mapping database. This com= es back to the general question that I've been discussing with Joel, Dino & No= el on the list. If the ETR can't tell whether a source address is an EID - and therefore to be routed back to ALT - or an RLOC - and therefore to be routed across the current internet, then there is a problem. IF the assumption is that a given bit-pattern cannot refer to different sites/endhosts by one use being a RLOC and the other an EID, then I think this concern is partially addressed - but that assumption NEEDS to be written down into the base LISP draft. As I understand it, an ETR (not co-located with an ITR) would not have direct access to the mapping database & may not even support sending Map-Requests. This implies that the ETR would need to send any Map-Replies out via an ITR that would do this look-up?? Is this the expected behavior? I'd prefer to see a short explicit description of rules and behavior around this. Certainly, the need for the ETR to route its Map-Replies via an ITR was not clear. The main confusion, of course, is differing assumptions about what different name-spaces mean in practice. >> c) In Sec 7.2, there is a sentence: "Should a receiving ITR decide >> that it does not wish to store such more-specific information, it has >> the option of discarding it as long as a shorter, covering EID-prefix >> exists." =A0I found this confusing and it seems to violate the prefix >> rules in [LISP], as well as they were described. > > If a covering map cache entry exists (i.e. 153.16.0.0/16) and the more- > specific prefixes are discarded (i.e. 153.16.10.0/24), then data traffic > would be LISP-encapsulated and sent to one of the RLOCs for the covering > map cache. This is no different than the way a shorter prefix can be used > for IP forwarding to any more-specifics of that prefix. I have pulled my response into a separate email. As far as I can tell, thi= s behavior would cause the ETR to drop traffic. I understand that the context of the section is TE - but do not see that context resolving the problem. >> d) In [LISP] sec 5.5., there is discussion of using Instance IDs to >> disambiguate. "When multiple organizations inside of a LISP site are >> using private addresses [RFC1918] as EID-prefixes, their address >> spaces MUST remain segregated due to possible address duplication. =A0An >> Instance ID in the address encoding can aid in making the entire AFI >> based address unique. =A0See IANA Considerations Section 14.1 for >> details for possible address encodings." >> >> I am not suggesting adding explicit support for this at this point, but >> adding a caveat that supporting this is for future study & experimentati= on >> would provide clarity. > > The use of instance IDs is outside of the scope of the ALT document. OK - it is hard to tell what parts in the base spec are must-implement and = what are the fragments of an undeveloped idea. Thanks, Alia >> f) Typo in 2nd to last paragraph on p.20: >> =A0 "This is, by no means, and exhaustive list." >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^^^ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0an > > Thanks. Fixed in the -07 draft, which will be published shortly. > > =A0 =A0 =A0 =A0--Vince > =A0 =A0 =A0 =A0(on behalf of the other co-authors) > From akatlas@gmail.com Fri Jun 24 01:21:22 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1A011E80A7 for ; Fri, 24 Jun 2011 01:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.585 X-Spam-Level: X-Spam-Status: No, score=-3.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1tc0b-pk9wX for ; Fri, 24 Jun 2011 01:21:21 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4649411E8089 for ; Fri, 24 Jun 2011 01:21:21 -0700 (PDT) Received: by pwj5 with SMTP id 5so1811048pwj.31 for ; Fri, 24 Jun 2011 01:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XteirWM0N9Xeg3gJrWd9752yv6M+wv/Uthe2qsbwoMg=; b=lFxmV/SvnR2XoSOJ5MFSK2tg4kF0vWijC8zmGEzTcbe66kWXYeFXZuVS7EkZjYIkSp yDNuFs/kInWBPqQJKa5Gf/WlstJfBwthx39ZUNqvNLukkLL5gI1nPN0UCCzb0qNZY7Nc lY4f211de204fLNrob/i69a8dQ8Anpf2LIiNU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=i0zsZyPUUmPtdikIPIJjs9XMaSS+8o9450qMz3TA9+JwVIiflGuBzShD3Azsig6EHh /x0PPy/2FEZYoxCl6HmXdUTIl8WdrYIvevVN6fk520E66VJNelhy70wwN5HyEHros/h9 Ebp2q2Qf4YZ5vrPA6ibjPVibwsefUkuPNFpgk= MIME-Version: 1.0 Received: by 10.68.49.227 with SMTP id x3mr1751769pbn.33.1308903678387; Fri, 24 Jun 2011 01:21:18 -0700 (PDT) Received: by 10.68.54.69 with HTTP; Fri, 24 Jun 2011 01:21:18 -0700 (PDT) In-Reply-To: <20110623221530.GB54962@vaf-mac1.cisco.com> References: <20110623221530.GB54962@vaf-mac1.cisco.com> Date: Fri, 24 Jun 2011 04:21:18 -0400 Message-ID: From: Alia Atlas To: Vince Fuller Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "lisp@ietf.org" Subject: Re: [lisp] last call for draft-ietf-lisp-ms-08 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2011 08:21:22 -0000 Vince, Thanks for the response. My comments are in-line. On Thu, Jun 23, 2011 at 6:15 PM, Vince Fuller wrote: >> a) When an ETR sends a Map-Register to a Map Server, does the ETR have >> to include all the RLOCs associated with the EID-prefix and >> specifically even those not associated with that particular ETR? =A0From >> what I understood from the draft, the RLOCs are used to either forward >> Map-Requests to the ETR as indicated in Sec. 3 >> =A0 "Intermediate ALT routers forward Map-Requests to the Map-Server >> =A0 that advertises a particular EID-prefix and the Map-Server forwards >> =A0 them to the owning ETR, which responds with Map-Reply messages." >> >> or, as specified in Sec 4.4, to directly provide the RLOCs in a Map-Repl= y: >> =A0 =A0"Upon receipt of an Encapsulated Map-Request, a Map-Resolver de- >> =A0 =A0capsulates the enclosed message then searches for the requested E= ID >> =A0 =A0in its local database of mapping entries (statically configured, >> =A0 =A0cached, or learned from associated ETRs). =A0If it finds a matchi= ng >> =A0 =A0entry, it returns a non-authoritative LISP Map-Reply with the kno= wn >> =A0 =A0mapping." >> >> I don't see any language that explicitly defines what set of RLOCs >> should be included. > > The full list of RLOCs is returned in a Map-Reply from an ETR to an ITR. > An ETR is not required to supply the full set of RLOCs when it registers > with a Map-Server; the ETR need only need provide those RLOCs that it wis= hes > the MS to use when forwarding a Map-Request to the ETR. OK - my concern is that a Map-Server may implement both types of actions - = as a Map-Resolver and a Map-Server. ("A single device may implement one or bo= th types of operation.") In Sec 4.4, it says that Map-Resolver may use "its local database of mapping entries (statically configured, cached, or learned from associated ETRs)". However, I saw no discussion of how a Map-Resolver might learn mappings from associated ETRs. I therefore assumed that "learned from associated ETRs" is via the Map-Register messages that an ETR would send. I don't know how an ETR would know whether its Map-Server is serving as a Map-Resolver as well, except via manual configuration. Therefore, I think it would be very useful to add explicitly "When an ETR sends a Map-Register message to a Map-Server, the ETR MUST include at least one locator, but need not include the full locator-set. These records, stored by a Map-Server, should be used for directing Map-Requests and SHOULD NOT be used in a Map-Resolver operation." in Sec 4.2 >> b) What does a Map-Server do when it gets Map-Register messages from >> different ETRs for the same EID-prefix? =A0This seems to me to be a >> likely case where for resiliency there could be 2 ETRs and each would >> register with two Map-Servers. =A0Even if all the RLOCs are supposed to >> be included, what happens when there is a chance and one ETR is >> (temporarily) out of sync with the other? > > Each ETR for a particular EID-prefix is expected to register with all of > the Map-Servers that publish that prefix into the mapping database. When > a Map-Server receives an Encapsulated Map-Request for that prefix, it sen= ds > to one of the registered ETRs. The exact process that it uses for distrib= uting > the Map-Request load among multiple registered ETRs is not specified but > round robin would be a reasonable choice. If one ETR has out-of-date > information relative to the others, then yes, temporary inconsistencies > may result, just as is the case with any other distributed database (i.e. > multi-homed sites connected via BGP). Ok - makes sense. Thanks for the clarification. >> c) If an ETR is supposed to send all the RLOCs associated with an >> EID-prefix in a Map-Register message, then how is the R-bit for each >> locator record specified by the Map-Server? =A0Does the Map-Server >> confirm reachability to each of the RLOCs specified before sending any >> Map-Replies? > > I will have to defer to Dino to answer this detail. Ok - I think I meant the Map-Resolver operation here. >> d) The Map-Server is described in the Introduction as: >> =A0 =A0"a Map-Server, which learns authoritative EID-to-RLOC mappings fr= om >> =A0 =A0an ETR and publish them in the database." >> I found this confusing, since the mapping service seems to me to be >> about determining which ETR (or proxy) to ask for the EID-to-RLOC >> mapping and is providing an lookup service to get to the ETR and not >> necessarily the full RLOC mapping. > > Please suggest alternative text. "a Map-Server, which learns the authoritative ownership of EID-prefixes by = ETRs from those ETRs and publishes those EID-prefixes in the database." Feel free to word-smith >> e) For clarification, why does a Map-Resolver return a Map-Reply for >> EID-prefixes in its local database? =A0I could see doing that if the ETR >> had requested proxying, but if not - why is there a potential >> difference in what is returned for a local Map-Request versus a remote >> one? =A0As I understand it, in the remote case, the Map-Request is >> unencapsulated (as per Sec 4.4 (1)) and is therefore handed to the ETR. > > A single device may act as both a Map-Server and a Map-Resolver. In such > a situation, a Map-Resolver will consult its local database to see if it > is also configured as a Map-Server for the EID-prefix being requested. Do you mean configured to proxy-reply? Is that the only case where you thi= nk a Map-Resolver should respond itself? Could you clearly state that? It se= ems like a Map-Resolver could have lots of things in its local database (cached= , statically configured, etc.) as per Sec 4.4. >> f) Further, the appropriate behavior of a Map-Resolver when proxying >> is requested is NOT specified anywhere. > > Please provide suggested text to describe this behavior. Here's the start of text to go towards the end of Sec. 4.2: "When an ETR sets the proxy-map-request bit in its Map-Register, the ETR MUST include complete locator-set(s) in the included record. The ETR MUST set the L-bit associated with at least one locator; this will be used by the Map-Server to verify reachability and to forward Map-Requests when proxying is not feasible. An ETR SHOULD be able to provide Map-Replies even when it has requested proxying. When an ETR's registration is removed by the Map-Server, of course no more proxyin= g is done by the Map-Server. If a Map-Server can no longer reach the source = RLOC from which the ETR sent the most recent Map-Register message, then the Map-Server should pause in proxying until reachability is restored. When a Map-Server sends a proxied Map-Reply in response to a Map-Request, as specified in [LISP], it clears the Authoritative bit in the message and clears the L bits associated with each locator. To properly set the R-bits associated with each locator, a Map-Server SHOULD determine if it has a current valid route to the specified RLOC and set the R-bit for that locator to 1 if so and 0 otherwise. To determine the Record TTL to be sent in a proxied Map-Reply, the Record TTL that is included in the Map-Register message should be decreased by the number of seconds since the last Map-Register message was received. This is to better support mechanisms such as Clock Sweep [LISP]" I do have two open questions around the correct behavior. i) Should the Record TTL just be set to what is sent instead of being decremented? If an ETR is doing Clock Sweep, shouldn't that ETR also send out updated Map-Register messages? ii) How should overlapping prefixes be handled? I.e. does an ETR send a Map-Register with all the EID-prefixes and then the Map-Server determines which need to be sent in response to a Map-Request? Should a Map-Server just send the whole record that was registered for any match within it? I can see the argument both ways and would, naturally, like to know your thoughts. >> g) On p.6, a negative LISP Map-Reply is sent, but the details of the >> action selected is not defined anywhere. =A0I assume that the draft >> means to specify as natively forward, but as written I did not find it >> clear (perhaps because I didn't have the Map-Reply packet format >> memorized). > > I will reword this section to reference the action codes defined in the > LISP base document. Thanks - the problem with not having this all embedded in memory already. >> h) What is the purpose of frequently (1/min) resending the >> Map-Register message? =A0It is only verifying that the ETR still owns >> the EID-prefix? =A0If it is verifying liveness - why is that ETR special >> compared to others whose RLOCs are also given. =A0Why not depend on the >> underlying routing to be sure of liveness? > > It is a simple keepalive mechanism between an MS and an ETR to ensure tha= t > not only is the ETR reachable but that it both responsive and wants the M= S > to continue to publish its EID prefixes in the mapping database. Underlyi= ng > routing would not accomplish this. Ok - seems a bit heavy-weight to me, but it does work for that. If you wanted to add that first sentence in, I'd cheer :-) Thanks, Alia >> >> i) typo on p.8 item (1), 3rd line: =A0"mapaping" -> "mapping" >> >> j) typo in 2nd paragraph, last sentence in Sec 4.1: >> =A0 =A0"Using the Map-Resolver greatly reduces both the complexity of th= e >> =A0 =A0ITR implementation the costs associated with its operation." >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^^ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0and > > Thanks, fixed in -09. > > =A0 =A0 =A0 =A0--Vince > =A0 =A0 =A0 =A0(for the other co-authors) > From akatlas@gmail.com Fri Jun 24 01:23:03 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E8611E8095 for ; Fri, 24 Jun 2011 01:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNLztRdvL4tM for ; Fri, 24 Jun 2011 01:23:02 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id EE89F11E8089 for ; Fri, 24 Jun 2011 01:23:01 -0700 (PDT) Received: by pvh18 with SMTP id 18so1714406pvh.31 for ; Fri, 24 Jun 2011 01:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3kyA5DW7FkmQYyDNC6MvNffIkV5Smk9BZW9/WiRsr8Q=; b=WmquEYWFI+RR+mOog1vsW0aOdyggYiJTTWnzHjRUwbx7XfeXeKc7FG29MbMWUYgyui kEq+frbB3MvE1ra9WDo8E/QxLA/Js6z4HmhL3CR6UaZtInNpS3QEMtcx1JYqJI7OU+r6 jdAoHo+C0Jng3Yss+mIeApvEUxgYnHpLIILTo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=JtNORQvgnPjTBLLoi2rfRDBLa09Qtrt7/z/EN4+iwXkEIYsQ1ouaAMJA6KqqyfoMlM 686dwi7TepziHFek1rZse3BsEgmQdkU7E/y6Ol5NZNQNw8wtXCBMcXVfv79+vHbXLCHT w8bRqLCQK44eEycjuD+pN++Dci4fKjYtCGdRI= MIME-Version: 1.0 Received: by 10.68.16.8 with SMTP id b8mr1746567pbd.368.1308903780813; Fri, 24 Jun 2011 01:23:00 -0700 (PDT) Received: by 10.68.54.69 with HTTP; Fri, 24 Jun 2011 01:23:00 -0700 (PDT) In-Reply-To: <20110623222621.GD54962@vaf-mac1.cisco.com> References: <20110623222621.GD54962@vaf-mac1.cisco.com> Date: Fri, 24 Jun 2011 04:23:00 -0400 Message-ID: From: Alia Atlas To: Vince Fuller Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "lisp@ietf.org" Subject: Re: [lisp] last call for draft-ietf-lisp-ms-08 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2011 08:23:03 -0000 On Thu, Jun 23, 2011 at 6:26 PM, Vince Fuller wrote: > I realized after I sent my last note that I forgot one of the points: > >> f) Further, the appropriate behavior of a Map-Resolver when proxying >> is requested is NOT specified anywhere. > > A Map Resolver doesn't act as a proxy; a Map Server may. If a Map Server > is acting as a proxy, then it returns a Map-Reply on behalf of a register= ed > ETR that has requested proxy service. True - but the logic is specified for a Map Resolver to consult its local database... I've sent you copious text that I think describes the proxying behavior Alia > > =A0 =A0 =A0 =A0--Vince > =A0 =A0 =A0 =A0(for the other co-authors) > From jmh@joelhalpern.com Fri Jun 24 11:29:12 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C7511E813D for ; Fri, 24 Jun 2011 11:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38mZDeGztQIV for ; Fri, 24 Jun 2011 11:29:12 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfa.amsl.com (Postfix) with ESMTP id 3094B11E80FF for ; Fri, 24 Jun 2011 11:29:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 5EB27324649E; Fri, 24 Jun 2011 11:28:41 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.242.59.134] (m1b0436d0.tmodns.net [208.54.4.27]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 859B83246748; Fri, 24 Jun 2011 11:28:39 -0700 (PDT) Message-ID: <4E04D753.7070703@joelhalpern.com> Date: Fri, 24 Jun 2011 14:28:35 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Vince Fuller References: <20110623214656.GA54962@vaf-mac1.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] last call for draft-ietf-lisp-alt-06 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2011 18:29:12 -0000 If I am reading the text Alia qutoed below correctly, the text assumes that an ETR will do something different with a map reply based on the whether it thinks the source address is an EID. I think this is basically indeterimnable. More importantly, that would be an ETR behavior, which the ALT spec can't change. I suspect this is a case of the authors, in good faith, trying to leave in a hook for an idea they have for the future. However, the effect is to introduce confusion. Can we not do that? Thanks, Joel PS: I was going to wait longer to give the authors more of a chance to comment first, but I have a flight shortly. On 6/24/2011 3:02 AM, Alia Atlas wrote: >>> b) How can an ETR tell if the outer header Source Address of an ALT >>> >> datagram is an RLOC or an EID? I do see that using an EID is not >>> >> supported by initial LISP+ALT implementations (this could be pulled >>> >> early in the draft where the idea is first proposed), but I also don't >>> >> see a mechanism to do the disambiguation. >> > >> > The ETR does not attempt to determine whether the outer header source >> > address is an RLOC or an EID; when it sends a Map-Reply to that address, >> > it simply forwards it using the contents of its forwarding table. If the >> > original source address was an EID and the ETR is connected to the ALT >> > (again, this is a rare, degenerate case; ITRs and ETRs do not normally >> > connect directly to the ALT), then the Map-Reply will be sent back over >> > the ALT, which is not recommended and may or may not acheive the desired >> > result. > This question was in reference to the last paragraph in Sec 3: > > "The term "ALT Datagram" is short-hand for a Map-Request or Data Probe > to be sent into or forwarded on the ALT. Note that while the outer > header Source Address of an ALT Datagram is currently expected to be > an RLOC, there may be situations (e.g. for experimentation with > caching in intermediate ALT nodes) where an EID would be used to > force a Map-Reply to be routed back through the ALT. > " > > I think the base of the question is whether the ETR can just know if a given > bit-pattern is an EID by seeing if it is in the mapping database. This comes > back to the general question that I've been discussing with Joel, Dino& Noel > on the list. > > If the ETR can't tell whether a source address is an EID - and > therefore to be routed > back to ALT - or an RLOC - and therefore to be routed across the > current internet, > then there is a problem. > > IF the assumption is that a given bit-pattern cannot refer to > different sites/endhosts > by one use being a RLOC and the other an EID, then I think this > concern is partially addressed > - but that assumption NEEDS to be written down into the base LISP draft. > > As I understand it, an ETR (not co-located with an ITR) would not have > direct access to > the mapping database& may not even support sending Map-Requests. > This implies that the > ETR would need to send any Map-Replies out via an ITR that would do > this look-up?? Is this > the expected behavior? > > I'd prefer to see a short explicit description of rules and behavior > around this. Certainly, the need > for the ETR to route its Map-Replies via an ITR was not clear. The > main confusion, of course, is > differing assumptions about what different name-spaces mean in practice. > From rbonica@juniper.net Fri Jun 24 14:02:54 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 063E711E80C2 for ; Fri, 24 Jun 2011 14:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.563 X-Spam-Level: X-Spam-Status: No, score=-106.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMmjMeDqV8np for ; Fri, 24 Jun 2011 14:02:53 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 56BC611E80AB for ; Fri, 24 Jun 2011 14:02:53 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTgT7fIlasa8TWGM8rUqonBAs5NYfwtvL@postini.com; Fri, 24 Jun 2011 14:02:53 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 24 Jun 2011 14:00:51 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 24 Jun 2011 17:00:50 -0400 From: Ronald Bonica To: "lisp@ietf.org" Date: Fri, 24 Jun 2011 17:00:50 -0400 Thread-Topic: EID-to-RLOC Cache Integrity Thread-Index: Acwyscv/byBSuawoTzW6Jn9X9gl9dQ== Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F1FB0626@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lisp] EID-to-RLOC Cache Integrity X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jun 2011 21:02:54 -0000 Dino,=20 A few weeks ago, we went round and round over the question of cache integri= ty and talked past one another. I think that I can formulate the question a= little better now. In order for an ITR to function properly, the EID-to-RLOC cache must confor= m to some integrity rules. These integrity rules are never stated explicitl= y in the base document. The reader is left to infer them from selected LISP= behaviors. For example, you say that when the EID-to-RLOC database contain= s several more specific prefixes (e.g., 10.1.1.0/24) and a single overlappi= ng less specific interface and the ITR sends a Map Request whose response i= s the less specific: - the ETR must respond with the less specific and all of the more specifics - the less specific must expire before the more specifics This leads me to infer that if the ITR is to behave correctly and its cache= contains the less specific, it must also contain all of the more specifics= . But you never say this explicitly. I must infer it. This integrity rule is important because it drives the answer to many other= questions. For example: - If the ITR uses the less specific and updates its expiration time, must = it update the expiration time of all of the more specifics, also? - If the EID-to-RLOC cache thrashes, and I am forced to delete unexpired en= tries, must I delete the less specific before the more specifics? Also, I am left to wonder if there are any other cache integrity rules that= I have not gleaned from the text. It would be good if you could add a section that explicitly states cache in= tegrity rules. Ron From rbonica@juniper.net Sat Jun 25 14:00:53 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EBE11E80BE for ; Sat, 25 Jun 2011 14:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.565 X-Spam-Level: X-Spam-Status: No, score=-106.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eYJIaS1H7xB for ; Sat, 25 Jun 2011 14:00:52 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 3799E11E80AC for ; Sat, 25 Jun 2011 14:00:51 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTgZMgrh7+uw2hgZhrPV585/Ld6+QFmPG@postini.com; Sat, 25 Jun 2011 14:00:52 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 25 Jun 2011 13:54:15 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Sat, 25 Jun 2011 16:54:14 -0400 From: Ronald Bonica To: Dino Farinacci , Alia Atlas Date: Sat, 25 Jun 2011 16:54:13 -0400 Thread-Topic: [lisp] Last call for draft-ietf-lisp-12 Thread-Index: AcwvmCU/sxDHg7BDT1G9zJaFJpNnEwD4cDaQ Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F28F0081@EMBX01-WF.jnpr.net> References: <00D02FFF-2E45-4F5D-9DEC-F5F0961C62D3@cisco.com> In-Reply-To: <00D02FFF-2E45-4F5D-9DEC-F5F0961C62D3@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] Last call for draft-ietf-lisp-12 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2011 21:00:53 -0000 Dino, Why not take the advice of RFC 4443? It says that a router SHOULD send an I= CMP message. Ron > 4) Generally, a section specifying ITR behavior in regard to packets > is missing. > i) For instance, if an ITR receives a Negative Map Reply indicated > "drop", should the ITR send an ICMP Destination Unreachable with > Host Unreachable? We did not want to specify this because in practice when this is done =20 either the ICMP messages are either rate-limited or filtered so ICMP =20 is not a reliable mechanism. Experimentation will tell us more on what to do. From terry.manderson@icann.org Sun Jun 26 20:42:24 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0CA11E80AF for ; Sun, 26 Jun 2011 20:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i62G2cCwNMEp for ; Sun, 26 Jun 2011 20:42:24 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 297D411E80A8 for ; Sun, 26 Jun 2011 20:42:24 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Sun, 26 Jun 2011 20:42:23 -0700 From: Terry Manderson To: "lisp@ietf.org" Date: Sun, 26 Jun 2011 20:42:26 -0700 Thread-Topic: Draft agenda due soon. Thread-Index: Acw0fDsolgR3LfF8r02E8AFyn7ZKxA== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lisp] Draft agenda due soon. X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2011 03:42:24 -0000 Folks, It's that time once again. Time to construct the draft agenda - Our current time slot is 2 hours, and as usual preference will be given to on charter items, and expecting updates from the existing WG items. Please email me if you wish to have a speaking slot in Quebec. It is also helpful to keep these deadlines in mind: 2011-06-27 (Monday): Working Group Chair approval for initial document (Version -00) submissions appreciated by 17:00 PT (00:00 UTC). 2011-07-01 (Friday): Final agenda to be published. 2011-07-04 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (00:00 UTC), upload using IETF ID Submission Tool. 2011-07-11 (Monday): Internet Draft final submission cut-off by 17:00 PT (00:00 UTC), upload using IETF ID Submission Tool. 2011-07-13 (Wednesday): Draft Working Group agendas due by 17:00 PT (00:00 UTC), upload using IETF Meeting Materials Management Tool. 2011-07-15 (Friday): Early Bird registration and payment cut-off at 17:00 P= T (00:00 UTC). 2011-07-18 (Monday): Revised Working Group agendas due by 17:00 PT (00:00 UTC), upload using IETF Meeting Materials Management Tool. 2011-07-18 (Monday): Registration cancellation cut-off at 17:00 PT (00:00 UTC). 2011-07-22 (Friday): Final Pre-Registration and Pre-Payment cut-off at 17:0= 0 local meeting time. 2011-07-24 - 2011-07-29: 81st IETF Meeting in Quebec City, Canada. Cheers Terry From dino@cisco.com Mon Jun 27 09:06:59 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDA211E809B for ; Mon, 27 Jun 2011 09:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKHPBAy2SPX6 for ; Mon, 27 Jun 2011 09:06:59 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE6D11E80C7 for ; Mon, 27 Jun 2011 09:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=846; q=dns/txt; s=iport; t=1309190819; x=1310400419; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=6/T35mlvBxMvD4yV4RZZv5wbj0Q1fPvY4oNZ7Rwtblc=; b=gopl7ZNLEEBNzd6HO9ShKmzuN8EPTgvixPrcHkzhZjQLAJ7+ve1mtrkv g9suMpkrjIa6dh8/hNlk2IGSIWOmY8yaSkNmiiO4rMDMv8gs4Z3k41kxu AQDkAQbB/tSxIVyZvWyTXqFxsBtvQdQ9988cfYmillEovwiBB/PolLF9u A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMypCE6rRDoI/2dsb2JhbABSpy53iHSiFJ1yhjAEhyyKV4Rui00 X-IronPort-AV: E=Sophos;i="4.65,432,1304294400"; d="scan'208";a="348193136" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 27 Jun 2011 16:06:54 +0000 Received: from [192.168.1.4] (sjc-vpn6-1891.cisco.com [10.21.127.99]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5RG6rJI001083; Mon, 27 Jun 2011 16:06:53 GMT Message-Id: <2C3D0842-5C28-45C4-AFBC-CFB8CE8CCCBB@cisco.com> From: Dino Farinacci To: Ronald Bonica In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F28F0081@EMBX01-WF.jnpr.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 27 Jun 2011 09:06:53 -0700 References: <00D02FFF-2E45-4F5D-9DEC-F5F0961C62D3@cisco.com> <13205C286662DE4387D9AF3AC30EF456D3F28F0081@EMBX01-WF.jnpr.net> X-Mailer: Apple Mail (2.936) Cc: "lisp@ietf.org" Subject: Re: [lisp] Last call for draft-ietf-lisp-12 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2011 16:06:59 -0000 > Dino, > > Why not take the advice of RFC 4443? It says that a router SHOULD > send an ICMP message. Why duplicate what another document is specifying? The LISP router should send an ARP also when it decaps and the EID is directly connected. Should we specify that as well? Dino > > Ron > >> 4) Generally, a section specifying ITR behavior in regard to packets >> is missing. >> i) For instance, if an ITR receives a Negative Map Reply indicated >> "drop", should the ITR send an ICMP Destination Unreachable with >> Host Unreachable? > > We did not want to specify this because in practice when this is done > either the ICMP messages are either rate-limited or filtered so ICMP > is not a reliable mechanism. > > Experimentation will tell us more on what to do. > > From rbonica@juniper.net Mon Jun 27 09:25:26 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2D911E8106 for ; Mon, 27 Jun 2011 09:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.299 X-Spam-Level: X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXUXHrvQZfYR for ; Mon, 27 Jun 2011 09:25:26 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 3385F11E80E3 for ; Mon, 27 Jun 2011 09:25:21 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTgiu8NXDwD7XEeiR0WzIoWE1bOB9sJZN@postini.com; Mon, 27 Jun 2011 09:25:26 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 27 Jun 2011 09:23:28 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 27 Jun 2011 12:23:27 -0400 From: Ronald Bonica To: Dino Farinacci Date: Mon, 27 Jun 2011 12:23:25 -0400 Thread-Topic: [lisp] Last call for draft-ietf-lisp-12 Thread-Index: Acw05ECsdiRkorNvQbyg79ptBGGuAQAAOwQA Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F28F072F@EMBX01-WF.jnpr.net> References: <00D02FFF-2E45-4F5D-9DEC-F5F0961C62D3@cisco.com> <13205C286662DE4387D9AF3AC30EF456D3F28F0081@EMBX01-WF.jnpr.net> <2C3D0842-5C28-45C4-AFBC-CFB8CE8CCCBB@cisco.com> In-Reply-To: <2C3D0842-5C28-45C4-AFBC-CFB8CE8CCCBB@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] Last call for draft-ietf-lisp-12 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2011 16:25:26 -0000 Dino, Maybe I am misreading you, but your response to me seems to contradict your= response to Alia. When Alia asked, you said, "Experimentation will tell us= more on what to do." When I asked, you seemed to have made up your mind ab= out following the recommendation of RFC 4443. Which is it? Ron -----Original Message----- From: Dino Farinacci [mailto:dino@cisco.com]=20 Sent: Monday, June 27, 2011 12:07 PM To: Ronald Bonica Cc: Alia Atlas; lisp@ietf.org Subject: Re: [lisp] Last call for draft-ietf-lisp-12 > Dino, > > Why not take the advice of RFC 4443? It says that a router SHOULD =20 > send an ICMP message. Why duplicate what another document is specifying? The LISP router =20 should send an ARP also when it decaps and the EID is directly =20 connected. Should we specify that as well? Dino > > Ron > >> 4) Generally, a section specifying ITR behavior in regard to packets >> is missing. >> i) For instance, if an ITR receives a Negative Map Reply indicated >> "drop", should the ITR send an ICMP Destination Unreachable with >> Host Unreachable? > > We did not want to specify this because in practice when this is done > either the ICMP messages are either rate-limited or filtered so ICMP > is not a reliable mechanism. > > Experimentation will tell us more on what to do. > > From dino@cisco.com Mon Jun 27 09:26:39 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B2911E80E3 for ; Mon, 27 Jun 2011 09:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAg4v4jakDYI for ; Mon, 27 Jun 2011 09:26:39 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7D83511E80DB for ; Mon, 27 Jun 2011 09:26:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=1544; q=dns/txt; s=iport; t=1309191999; x=1310401599; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=c74JqCQfXNNPnaWAjwxWVw2nJCQVAKFchrPEtnaK/KM=; b=UFB2wUv8VABk/Jo/nAlK3hBxC6VUt/Z4BOr23Pog+3/+qaWqqvWj4Jz5 SRwL3heG6JiMf3w97pF3B89wlHpI6YTXOP4tHMGO62PgU8qfhBUvhsECB zva4m3YEcJ1w92Y5ZGjs//sfnx5ABe///ihMndDgs/BNw5VHmSF1ndvof w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAJGuCE6rRDoJ/2dsb2JhbABSmAGPLXeIdKIDnXWGMASHLIpXhG6LTQ X-IronPort-AV: E=Sophos;i="4.65,433,1304294400"; d="scan'208";a="348206208" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 27 Jun 2011 16:26:39 +0000 Received: from [192.168.1.4] (sjc-vpn6-1891.cisco.com [10.21.127.99]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5RGP7Kl016414; Mon, 27 Jun 2011 16:26:38 GMT Message-Id: <383BF203-27D2-4375-A8FF-63D1176F1366@cisco.com> From: Dino Farinacci To: Ronald Bonica In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F28F072F@EMBX01-WF.jnpr.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 27 Jun 2011 09:26:38 -0700 References: <00D02FFF-2E45-4F5D-9DEC-F5F0961C62D3@cisco.com> <13205C286662DE4387D9AF3AC30EF456D3F28F0081@EMBX01-WF.jnpr.net> <2C3D0842-5C28-45C4-AFBC-CFB8CE8CCCBB@cisco.com> <13205C286662DE4387D9AF3AC30EF456D3F28F072F@EMBX01-WF.jnpr.net> X-Mailer: Apple Mail (2.936) Cc: "lisp@ietf.org" Subject: Re: [lisp] Last call for draft-ietf-lisp-12 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2011 16:26:40 -0000 > Dino, > > Maybe I am misreading you, but your response to me seems to > contradict your response to Alia. When Alia asked, you said, > "Experimentation will tell us more on what to do." When I asked, you > seemed to have made up your mind about following the recommendation > of RFC 4443. > > Which is it? I want to leave the spec as is. Dino > > Ron > > > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com] > Sent: Monday, June 27, 2011 12:07 PM > To: Ronald Bonica > Cc: Alia Atlas; lisp@ietf.org > Subject: Re: [lisp] Last call for draft-ietf-lisp-12 > >> Dino, >> >> Why not take the advice of RFC 4443? It says that a router SHOULD >> send an ICMP message. > > Why duplicate what another document is specifying? The LISP router > should send an ARP also when it decaps and the EID is directly > connected. Should we specify that as well? > > Dino > >> >> Ron >> >>> 4) Generally, a section specifying ITR behavior in regard to packets >>> is missing. >>> i) For instance, if an ITR receives a Negative Map Reply indicated >>> "drop", should the ITR send an ICMP Destination Unreachable with >>> Host Unreachable? >> >> We did not want to specify this because in practice when this is done >> either the ICMP messages are either rate-limited or filtered so ICMP >> is not a reliable mechanism. >> >> Experimentation will tell us more on what to do. >> >> > From dino@cisco.com Mon Jun 27 09:34:43 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F37D11E80C7 for ; Mon, 27 Jun 2011 09:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yX9SwoP+qern for ; Mon, 27 Jun 2011 09:34:43 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0A59821F85E7 for ; Mon, 27 Jun 2011 09:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=2508; q=dns/txt; s=iport; t=1309192482; x=1310402082; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=lkP0p8lU4tkUVaupLKWc4+K3jlkZjjARjjZNPwz/fZ0=; b=m3jGAACsM36gxHv4e78PmQ/XrOTLjugFlUenC6SIYIFzl/xSMVqBDBvl bKXOCrBHs7P9E5+JthLeZ7g5LzmiikkD/J10knzz/Sksv6rUKqWOllJsj yXFvbQArRSy0NHL/0r17tVMDYHKssNg3zIjbCV0uxST2avCf2pSzAlxFj A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANawCE6rRDoJ/2dsb2JhbABSpy53iHShaZ11hjAEhyyKV4Rui00 X-IronPort-AV: E=Sophos;i="4.65,433,1304294400"; d="scan'208";a="348211514" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 27 Jun 2011 16:34:42 +0000 Received: from [192.168.1.4] (sjc-vpn6-1891.cisco.com [10.21.127.99]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5RGYgWl027309; Mon, 27 Jun 2011 16:34:42 GMT Message-Id: <225E8E0C-ED97-4487-81B8-ADBA7A5689FE@cisco.com> From: Dino Farinacci To: Ronald Bonica In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F1FB0626@EMBX01-WF.jnpr.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 27 Jun 2011 09:34:42 -0700 References: <13205C286662DE4387D9AF3AC30EF456D3F1FB0626@EMBX01-WF.jnpr.net> X-Mailer: Apple Mail (2.936) Cc: "lisp@ietf.org" Subject: Re: [lisp] EID-to-RLOC Cache Integrity X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2011 16:34:43 -0000 > Dino, > > A few weeks ago, we went round and round over the question of cache > integrity and talked past one another. I think that I can formulate > the question a little better now. > > In order for an ITR to function properly, the EID-to-RLOC cache must > conform to some integrity rules. These integrity rules are never > stated explicitly in the base document. The reader is left to infer > them from selected LISP behaviors. For example, you say that when > the EID-to-RLOC database contains several more specific prefixes > (e.g., 10.1.1.0/24) and a single overlapping less specific interface > and the ITR sends a Map Request whose response is the less specific: Sorry, I cannot parse your "For example" sentence. What is a "less specific interface"? > - the ETR must respond with the less specific and all of the more > specifics > - the less specific must expire before the more specifics > > This leads me to infer that if the ITR is to behave correctly and > its cache contains the less specific, it must also contain all of > the more specifics. But you never say this explicitly. I must infer > it. Yes. > This integrity rule is important because it drives the answer to > many other questions. For example: > > - If the ITR uses the less specific and updates its expiration > time, must it update the expiration time of all of the more > specifics, also? The update of the expiration time is based on receiving a Map-Reply and in section 6.1.5, it is documented how to send and process Map- Replies when overlapping EID-prefixes are in use. > - If the EID-to-RLOC cache thrashes, and I am forced to delete > unexpired entries, must I delete the less specific before the more > specifics? You could. But you could also use an LRU algorithm on EID-prefixes which are not overlapping. > Also, I am left to wonder if there are any other cache integrity > rules that I have not gleaned from the text. > > It would be good if you could add a section that explicitly states > cache integrity rules. We have been over this a number of times. The chairs believe the text that is already in the spec is sufficient and leaves opportunities open to experiment. Dino > > Ron > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From rbonica@juniper.net Mon Jun 27 09:36:29 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C6711E80C7 for ; Mon, 27 Jun 2011 09:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F36owEpGCDPG for ; Mon, 27 Jun 2011 09:36:28 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id F417321F85E7 for ; Mon, 27 Jun 2011 09:36:26 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTgixio2c4C3OIiADkskaUzBMA/WJcHix@postini.com; Mon, 27 Jun 2011 09:36:28 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 27 Jun 2011 09:34:53 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 27 Jun 2011 12:34:52 -0400 From: Ronald Bonica To: Dino Farinacci Date: Mon, 27 Jun 2011 12:34:51 -0400 Thread-Topic: [lisp] Last call for draft-ietf-lisp-12 Thread-Index: Acw05v/b+YZRJsobT42yRYPyYraOWgAADydg Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F28F077E@EMBX01-WF.jnpr.net> References: <00D02FFF-2E45-4F5D-9DEC-F5F0961C62D3@cisco.com> <13205C286662DE4387D9AF3AC30EF456D3F28F0081@EMBX01-WF.jnpr.net> <2C3D0842-5C28-45C4-AFBC-CFB8CE8CCCBB@cisco.com> <13205C286662DE4387D9AF3AC30EF456D3F28F072F@EMBX01-WF.jnpr.net> <383BF203-27D2-4375-A8FF-63D1176F1366@cisco.com> In-Reply-To: <383BF203-27D2-4375-A8FF-63D1176F1366@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] Last call for draft-ietf-lisp-12 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2011 16:36:29 -0000 Dino, That is to say, "silent on the matter"? Ron -----Original Message----- From: Dino Farinacci [mailto:dino@cisco.com]=20 Sent: Monday, June 27, 2011 12:27 PM To: Ronald Bonica Cc: Alia Atlas; lisp@ietf.org Subject: Re: [lisp] Last call for draft-ietf-lisp-12 > Dino, > > Maybe I am misreading you, but your response to me seems to =20 > contradict your response to Alia. When Alia asked, you said, =20 > "Experimentation will tell us more on what to do." When I asked, you =20 > seemed to have made up your mind about following the recommendation =20 > of RFC 4443. > > Which is it? I want to leave the spec as is. Dino > > Ron > > > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com] > Sent: Monday, June 27, 2011 12:07 PM > To: Ronald Bonica > Cc: Alia Atlas; lisp@ietf.org > Subject: Re: [lisp] Last call for draft-ietf-lisp-12 > >> Dino, >> >> Why not take the advice of RFC 4443? It says that a router SHOULD >> send an ICMP message. > > Why duplicate what another document is specifying? The LISP router > should send an ARP also when it decaps and the EID is directly > connected. Should we specify that as well? > > Dino > >> >> Ron >> >>> 4) Generally, a section specifying ITR behavior in regard to packets >>> is missing. >>> i) For instance, if an ITR receives a Negative Map Reply indicated >>> "drop", should the ITR send an ICMP Destination Unreachable with >>> Host Unreachable? >> >> We did not want to specify this because in practice when this is done >> either the ICMP messages are either rate-limited or filtered so ICMP >> is not a reliable mechanism. >> >> Experimentation will tell us more on what to do. >> >> > From jmh@joelhalpern.com Mon Jun 27 09:37:47 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A83011E8131 for ; Mon, 27 Jun 2011 09:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axCvkTjmzYGj for ; Mon, 27 Jun 2011 09:37:46 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfa.amsl.com (Postfix) with ESMTP id 95C1611E810D for ; Mon, 27 Jun 2011 09:37:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 8608D32467BA; Mon, 27 Jun 2011 09:37:10 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-50-66.clppva.btas.verizon.net [71.161.50.66]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id C0ECB324656E; Mon, 27 Jun 2011 09:37:09 -0700 (PDT) Message-ID: <4E08B1B3.9050301@joelhalpern.com> Date: Mon, 27 Jun 2011 12:37:07 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Dino Farinacci References: <00D02FFF-2E45-4F5D-9DEC-F5F0961C62D3@cisco.com> <13205C286662DE4387D9AF3AC30EF456D3F28F0081@EMBX01-WF.jnpr.net> <2C3D0842-5C28-45C4-AFBC-CFB8CE8CCCBB@cisco.com> <13205C286662DE4387D9AF3AC30EF456D3F28F072F@EMBX01-WF.jnpr.net> <383BF203-27D2-4375-A8FF-63D1176F1366@cisco.com> In-Reply-To: <383BF203-27D2-4375-A8FF-63D1176F1366@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] Last call for draft-ietf-lisp-12 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2011 16:37:47 -0000 If I am reading this exchange properly, Dino, you are saying you do not want LISP ITRs to follow the general router advice from RFC 4443. Is this a matter of taste? Is there a technical difference that should be stated why different behavior may be appropriate? Yours, Joel On 6/27/2011 12:26 PM, Dino Farinacci wrote: >> Dino, >> >> Maybe I am misreading you, but your response to me seems to contradict >> your response to Alia. When Alia asked, you said, "Experimentation >> will tell us more on what to do." When I asked, you seemed to have >> made up your mind about following the recommendation of RFC 4443. >> >> Which is it? > > I want to leave the spec as is. > > Dino > >> >> Ron >> >> >> -----Original Message----- >> From: Dino Farinacci [mailto:dino@cisco.com] >> Sent: Monday, June 27, 2011 12:07 PM >> To: Ronald Bonica >> Cc: Alia Atlas; lisp@ietf.org >> Subject: Re: [lisp] Last call for draft-ietf-lisp-12 >> >>> Dino, >>> >>> Why not take the advice of RFC 4443? It says that a router SHOULD >>> send an ICMP message. >> >> Why duplicate what another document is specifying? The LISP router >> should send an ARP also when it decaps and the EID is directly >> connected. Should we specify that as well? >> >> Dino >> >>> >>> Ron >>> >>>> 4) Generally, a section specifying ITR behavior in regard to packets >>>> is missing. >>>> i) For instance, if an ITR receives a Negative Map Reply indicated >>>> "drop", should the ITR send an ICMP Destination Unreachable with >>>> Host Unreachable? >>> >>> We did not want to specify this because in practice when this is done >>> either the ICMP messages are either rate-limited or filtered so ICMP >>> is not a reliable mechanism. >>> >>> Experimentation will tell us more on what to do. >>> >>> >> > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From dino@cisco.com Mon Jun 27 09:39:44 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A4D11E812F for ; Mon, 27 Jun 2011 09:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLg+mb6MVcxr for ; Mon, 27 Jun 2011 09:39:44 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2B62311E810D for ; Mon, 27 Jun 2011 09:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=2186; q=dns/txt; s=iport; t=1309192784; x=1310402384; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=+hBavIzbe6WziwoCjDPZ/pUp5otR9feBBxBOhEC2nM8=; b=Qswof93eDb1YgBgvoSeAulUZYW6rUuCX7wWn26M3+G2Jy7iLMjNbwaiu RzTo6Chbmhah1WQz//0rug9ww1vB15ZuGO+E7xcY8suo6hcFyo5y/aIYC yt/Rd8nGC+Pv3H2zHcraPiKJjONDWHMfOQD87IRymvD37SrKX74gM88GG g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAAaxCE6rRDoG/2dsb2JhbABSmAGPLXeIdKFlnXWGMASHLIpXhG6LTQ X-IronPort-AV: E=Sophos;i="4.65,433,1304294400"; d="scan'208";a="470660942" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 27 Jun 2011 16:39:43 +0000 Received: from [192.168.1.4] (sjc-vpn6-1891.cisco.com [10.21.127.99]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5RGdfLs008222; Mon, 27 Jun 2011 16:39:42 GMT Message-Id: From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4E08B1B3.9050301@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 27 Jun 2011 09:39:41 -0700 References: <00D02FFF-2E45-4F5D-9DEC-F5F0961C62D3@cisco.com> <13205C286662DE4387D9AF3AC30EF456D3F28F0081@EMBX01-WF.jnpr.net> <2C3D0842-5C28-45C4-AFBC-CFB8CE8CCCBB@cisco.com> <13205C286662DE4387D9AF3AC30EF456D3F28F072F@EMBX01-WF.jnpr.net> <383BF203-27D2-4375-A8FF-63D1176F1366@cisco.com> <4E08B1B3.9050301@joelhalpern.com> X-Mailer: Apple Mail (2.936) Cc: "lisp@ietf.org" Subject: Re: [lisp] Last call for draft-ietf-lisp-12 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2011 16:39:44 -0000 > If I am reading this exchange properly, Dino, you are saying you do > not want LISP ITRs to follow the general router advice from RFC 4443. I am not saying that. > Is this a matter of taste? No. > Is there a technical difference that should be stated why different > behavior may be appropriate? I am confused on this thread now. Ron is confusing matters. Dino > > Yours, > Joel > > On 6/27/2011 12:26 PM, Dino Farinacci wrote: >>> Dino, >>> >>> Maybe I am misreading you, but your response to me seems to >>> contradict >>> your response to Alia. When Alia asked, you said, "Experimentation >>> will tell us more on what to do." When I asked, you seemed to have >>> made up your mind about following the recommendation of RFC 4443. >>> >>> Which is it? >> >> I want to leave the spec as is. >> >> Dino >> >>> >>> Ron >>> >>> >>> -----Original Message----- >>> From: Dino Farinacci [mailto:dino@cisco.com] >>> Sent: Monday, June 27, 2011 12:07 PM >>> To: Ronald Bonica >>> Cc: Alia Atlas; lisp@ietf.org >>> Subject: Re: [lisp] Last call for draft-ietf-lisp-12 >>> >>>> Dino, >>>> >>>> Why not take the advice of RFC 4443? It says that a router SHOULD >>>> send an ICMP message. >>> >>> Why duplicate what another document is specifying? The LISP router >>> should send an ARP also when it decaps and the EID is directly >>> connected. Should we specify that as well? >>> >>> Dino >>> >>>> >>>> Ron >>>> >>>>> 4) Generally, a section specifying ITR behavior in regard to >>>>> packets >>>>> is missing. >>>>> i) For instance, if an ITR receives a Negative Map Reply indicated >>>>> "drop", should the ITR send an ICMP Destination Unreachable with >>>>> Host Unreachable? >>>> >>>> We did not want to specify this because in practice when this is >>>> done >>>> either the ICMP messages are either rate-limited or filtered so >>>> ICMP >>>> is not a reliable mechanism. >>>> >>>> Experimentation will tell us more on what to do. >>>> >>>> >>> >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >> From jmh@joelhalpern.com Mon Jun 27 09:44:49 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A1811E812C for ; Mon, 27 Jun 2011 09:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkUqZo7B0Osq for ; Mon, 27 Jun 2011 09:44:49 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfa.amsl.com (Postfix) with ESMTP id 24F7611E8122 for ; Mon, 27 Jun 2011 09:44:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 62E2B32467A1; Mon, 27 Jun 2011 09:44:15 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-50-66.clppva.btas.verizon.net [71.161.50.66]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id ABDF73246710; Mon, 27 Jun 2011 09:44:14 -0700 (PDT) Message-ID: <4E08B35C.1060301@joelhalpern.com> Date: Mon, 27 Jun 2011 12:44:12 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Dino Farinacci References: <13205C286662DE4387D9AF3AC30EF456D3F1FB0626@EMBX01-WF.jnpr.net> <225E8E0C-ED97-4487-81B8-ADBA7A5689FE@cisco.com> In-Reply-To: <225E8E0C-ED97-4487-81B8-ADBA7A5689FE@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] EID-to-RLOC Cache Integrity X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2011 16:44:49 -0000 There appear to be two related technical issues here. The first one is on refreshing entries. A refresh of a less-specific with overlapping more-specifics will inherently provide refresh of the more-specifics. Even if an implementor does not realize that, he will do the right thing. We can live with the text asa is on that. The second one deals with a different issue. In performing local maintenance of a cache with overlapping entries, one could easily get into a situation where the less-specific is being used (its use time would be updated), but the more-specifics are not being used. An LRU-based cache maintenance algorithm could, according to what is written in the spec, remove these relatively-unused entries in teh event of cache exhaustion. HOWEVER, such removal would actually be wrong. It would break the coherence requirement. As far as I know, nothing in the spec says taht. Yes, a sufficiently attentive reader could realize that one set of protocol behavior could impact another. But we do NOT normally expect readers to perform that level of inference. Specs are to be implementable by folks who are not protocol designers. Is there some place in the space where it says this? If not, could we add a sentence or two in the text on local cache management. Yours, Joel On 6/27/2011 12:34 PM, Dino Farinacci wrote: >> This integrity rule is important because it drives the answer to many >> other questions. For example: >> >> - If the ITR uses the less specific and updates its expiration time, >> must it update the expiration time of all of the more specifics, also? > > The update of the expiration time is based on receiving a Map-Reply and > in section 6.1.5, it is documented how to send and process Map-Replies > when overlapping EID-prefixes are in use. > >> - If the EID-to-RLOC cache thrashes, and I am forced to delete >> unexpired entries, must I delete the less specific before the more >> specifics? > > You could. But you could also use an LRU algorithm on EID-prefixes which > are not overlapping. From jmh@joelhalpern.com Mon Jun 27 10:18:07 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 551D511E807A for ; Mon, 27 Jun 2011 10:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bzdtBKAxEte for ; Mon, 27 Jun 2011 10:18:06 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfa.amsl.com (Postfix) with ESMTP id 37BA321F84BC for ; Mon, 27 Jun 2011 10:18:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id E666932466F9; Mon, 27 Jun 2011 10:17:35 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-50-66.clppva.btas.verizon.net [71.161.50.66]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 3B74F32465F8; Mon, 27 Jun 2011 10:17:35 -0700 (PDT) Message-ID: <4E08BB2C.2020507@joelhalpern.com> Date: Mon, 27 Jun 2011 13:17:32 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Ronald Bonica References: <00D02FFF-2E45-4F5D-9DEC-F5F0961C62D3@cisco.com> <13205C286662DE4387D9AF3AC30EF456D3F28F0081@EMBX01-WF.jnpr.net> <2C3D0842-5C28-45C4-AFBC-CFB8CE8CCCBB@cisco.com> <13205C286662DE4387D9AF3AC30EF456D3F28F072F@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F28F072F@EMBX01-WF.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] Last call for draft-ietf-lisp-12 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2011 17:18:07 -0000 Just to clarify what you are asking Ron, would you like the text to say "SHOULD send an ICMP"? And in which places would you like it to say that? Thanks, Joel On 6/27/2011 12:23 PM, Ronald Bonica wrote: > Dino, > > Maybe I am misreading you, but your response to me seems to contradict your response to Alia. When Alia asked, you said, "Experimentation will tell us more on what to do." When I asked, you seemed to have made up your mind about following the recommendation of RFC 4443. > > Which is it? > > Ron > > > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com] > Sent: Monday, June 27, 2011 12:07 PM > To: Ronald Bonica > Cc: Alia Atlas; lisp@ietf.org > Subject: Re: [lisp] Last call for draft-ietf-lisp-12 > >> Dino, >> >> Why not take the advice of RFC 4443? It says that a router SHOULD >> send an ICMP message. > > Why duplicate what another document is specifying? The LISP router > should send an ARP also when it decaps and the EID is directly > connected. Should we specify that as well? > > Dino > >> >> Ron >> >>> 4) Generally, a section specifying ITR behavior in regard to packets >>> is missing. >>> i) For instance, if an ITR receives a Negative Map Reply indicated >>> "drop", should the ITR send an ICMP Destination Unreachable with >>> Host Unreachable? >> >> We did not want to specify this because in practice when this is done >> either the ICMP messages are either rate-limited or filtered so ICMP >> is not a reliable mechanism. >> >> Experimentation will tell us more on what to do. >> >> > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From dino@cisco.com Mon Jun 27 10:23:34 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321B111E811A for ; Mon, 27 Jun 2011 10:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vG7pZ-nnQwAU for ; Mon, 27 Jun 2011 10:23:33 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE5221F85D9 for ; Mon, 27 Jun 2011 10:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=1989; q=dns/txt; s=iport; t=1309195393; x=1310404993; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=F5bw1Idjti4tKOAnbupvfk0+JV2kLKmi/KZ61iwNITM=; b=VLJplrb5Yl01kNkFWM1JL4Wmay9kphD/aa/PHdSVvtxybeVltRWvuO7T WS1RDsfaySu2iWRqVQwNLi6Y5uuDaVNuVG+n5LEjXnDHwzJXVC61eVLxD AemfKfNJm+4EvKVjZ06eG4A1HS0oypmqYpMUvktyVhN9ZfiHyaIfpK5ox k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAN67CE6rRDoI/2dsb2JhbABSmAGPLXeIdKFWnX2GMASHLIpXhG6LTQ X-IronPort-AV: E=Sophos;i="4.65,433,1304294400"; d="scan'208";a="722869978" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 27 Jun 2011 17:23:13 +0000 Received: from [192.168.1.4] (sjc-vpn6-1891.cisco.com [10.21.127.99]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5RHMFnu003322; Mon, 27 Jun 2011 17:23:13 GMT Message-Id: <9EC8E33E-3A68-463F-991A-1219536353D8@cisco.com> From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4E08BB2C.2020507@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 27 Jun 2011 10:23:12 -0700 References: <00D02FFF-2E45-4F5D-9DEC-F5F0961C62D3@cisco.com> <13205C286662DE4387D9AF3AC30EF456D3F28F0081@EMBX01-WF.jnpr.net> <2C3D0842-5C28-45C4-AFBC-CFB8CE8CCCBB@cisco.com> <13205C286662DE4387D9AF3AC30EF456D3F28F072F@EMBX01-WF.jnpr.net> <4E08BB2C.2020507@joelhalpern.com> X-Mailer: Apple Mail (2.936) Cc: "lisp@ietf.org" Subject: Re: [lisp] Last call for draft-ietf-lisp-12 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2011 17:23:34 -0000 > Just to clarify what you are asking Ron, > would you like the text to say "SHOULD send an ICMP"? Right. > And in which places would you like it to say that? Which places in the spec yes. Dino > > Thanks, > Joel > > On 6/27/2011 12:23 PM, Ronald Bonica wrote: >> Dino, >> >> Maybe I am misreading you, but your response to me seems to >> contradict your response to Alia. When Alia asked, you said, >> "Experimentation will tell us more on what to do." When I asked, >> you seemed to have made up your mind about following the >> recommendation of RFC 4443. >> >> Which is it? >> >> Ron >> >> >> -----Original Message----- >> From: Dino Farinacci [mailto:dino@cisco.com] >> Sent: Monday, June 27, 2011 12:07 PM >> To: Ronald Bonica >> Cc: Alia Atlas; lisp@ietf.org >> Subject: Re: [lisp] Last call for draft-ietf-lisp-12 >> >>> Dino, >>> >>> Why not take the advice of RFC 4443? It says that a router SHOULD >>> send an ICMP message. >> >> Why duplicate what another document is specifying? The LISP router >> should send an ARP also when it decaps and the EID is directly >> connected. Should we specify that as well? >> >> Dino >> >>> >>> Ron >>> >>>> 4) Generally, a section specifying ITR behavior in regard to >>>> packets >>>> is missing. >>>> i) For instance, if an ITR receives a Negative Map Reply indicated >>>> "drop", should the ITR send an ICMP Destination Unreachable with >>>> Host Unreachable? >>> >>> We did not want to specify this because in practice when this is >>> done >>> either the ICMP messages are either rate-limited or filtered so ICMP >>> is not a reliable mechanism. >>> >>> Experimentation will tell us more on what to do. >>> >>> >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >> From rbonica@juniper.net Mon Jun 27 10:44:28 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F9311E80EE for ; Mon, 27 Jun 2011 10:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.166 X-Spam-Level: X-Spam-Status: No, score=-106.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7M8IXPELBxpL for ; Mon, 27 Jun 2011 10:44:27 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id B871511E80CF for ; Mon, 27 Jun 2011 10:44:25 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTgjBb+2CyZa41wlFV70ot6u0a6+3XUZo@postini.com; Mon, 27 Jun 2011 10:44:26 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 27 Jun 2011 10:43:51 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 27 Jun 2011 13:43:51 -0400 From: Ronald Bonica To: "Joel M. Halpern" Date: Mon, 27 Jun 2011 13:43:49 -0400 Thread-Topic: [lisp] Last call for draft-ietf-lisp-12 Thread-Index: Acw07i2psM4RGQbXRkuxv4XM9kjDhgAAhuWA Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F28F0945@EMBX01-WF.jnpr.net> References: <00D02FFF-2E45-4F5D-9DEC-F5F0961C62D3@cisco.com> <13205C286662DE4387D9AF3AC30EF456D3F28F0081@EMBX01-WF.jnpr.net> <2C3D0842-5C28-45C4-AFBC-CFB8CE8CCCBB@cisco.com> <13205C286662DE4387D9AF3AC30EF456D3F28F072F@EMBX01-WF.jnpr.net> <4E08BB2C.2020507@joelhalpern.com> In-Reply-To: <4E08BB2C.2020507@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] Last call for draft-ietf-lisp-12 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2011 17:44:28 -0000 Joel, An ITR should send an ICMP message whenever it discards a packet because it= has been instructed to do so by a Negative Map Reply Message with indicati= on to drop. As the document is currently organized, I am not sure where tha= t detail fits. Ron =20 -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Monday, June 27, 2011 1:18 PM To: Ronald Bonica Cc: Dino Farinacci; lisp@ietf.org Subject: Re: [lisp] Last call for draft-ietf-lisp-12 Just to clarify what you are asking Ron, would you like the text to say "SHOULD send an ICMP"? And in which places would you like it to say that? Thanks, Joel On 6/27/2011 12:23 PM, Ronald Bonica wrote: > Dino, > > Maybe I am misreading you, but your response to me seems to contradict yo= ur response to Alia. When Alia asked, you said, "Experimentation will tell = us more on what to do." When I asked, you seemed to have made up your mind = about following the recommendation of RFC 4443. > > Which is it? > > Ron > > > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com] > Sent: Monday, June 27, 2011 12:07 PM > To: Ronald Bonica > Cc: Alia Atlas; lisp@ietf.org > Subject: Re: [lisp] Last call for draft-ietf-lisp-12 > >> Dino, >> >> Why not take the advice of RFC 4443? It says that a router SHOULD >> send an ICMP message. > > Why duplicate what another document is specifying? The LISP router > should send an ARP also when it decaps and the EID is directly > connected. Should we specify that as well? > > Dino > >> >> Ron >> >>> 4) Generally, a section specifying ITR behavior in regard to packets >>> is missing. >>> i) For instance, if an ITR receives a Negative Map Reply indicated >>> "drop", should the ITR send an ICMP Destination Unreachable with >>> Host Unreachable? >> >> We did not want to specify this because in practice when this is done >> either the ICMP messages are either rate-limited or filtered so ICMP >> is not a reliable mechanism. >> >> Experimentation will tell us more on what to do. >> >> > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From dino@cisco.com Mon Jun 27 11:19:36 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0EF011E80F6 for ; Mon, 27 Jun 2011 11:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COQOFGXnnYVP for ; Mon, 27 Jun 2011 11:19:36 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7A911E80DD for ; Mon, 27 Jun 2011 11:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=2557; q=dns/txt; s=iport; t=1309198776; x=1310408376; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=QnP1mP5waZePxkvlMolwfFjJVtnO0N5DokpO+dYNUgQ=; b=ADrGSGXSgiw/6Umbm6JX0S+PZXpNOMD2hxhP89jt6zBqpJQeAH0oIusa 2CYS0Q+gAfDaeLKwOPogOTox5d54rgOG08WTADB8l1ybYkHYNnTgSUlEv CzSxaay3EQ0WAxXQE74YEDhjeqF1ULGjLH9k8jbCfxY39xMs4Seinfqri c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAN/ICE6rRDoI/2dsb2JhbABSmAGPLXeIdKFQng2GMASHLIpXhG6LTQ X-IronPort-AV: E=Sophos;i="4.65,433,1304294400"; d="scan'208";a="722908530" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 27 Jun 2011 18:19:33 +0000 Received: from [192.168.1.4] (sjc-vpn2-5.cisco.com [10.21.112.5]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5RIIpKc027252; Mon, 27 Jun 2011 18:19:33 GMT Message-Id: <5CD149AE-4341-4605-B77F-63801B4D1249@cisco.com> From: Dino Farinacci To: Ronald Bonica In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F28F0945@EMBX01-WF.jnpr.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 27 Jun 2011 11:19:31 -0700 References: <00D02FFF-2E45-4F5D-9DEC-F5F0961C62D3@cisco.com> <13205C286662DE4387D9AF3AC30EF456D3F28F0081@EMBX01-WF.jnpr.net> <2C3D0842-5C28-45C4-AFBC-CFB8CE8CCCBB@cisco.com> <13205C286662DE4387D9AF3AC30EF456D3F28F072F@EMBX01-WF.jnpr.net> <4E08BB2C.2020507@joelhalpern.com> <13205C286662DE4387D9AF3AC30EF456D3F28F0945@EMBX01-WF.jnpr.net> X-Mailer: Apple Mail (2.936) Cc: "lisp@ietf.org" Subject: Re: [lisp] Last call for draft-ietf-lisp-12 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2011 18:19:36 -0000 > Joel, > > An ITR should send an ICMP message whenever it discards a packet > because it has been instructed to do so by a Negative Map Reply > Message with indication to drop. As the document is currently > organized, I am not sure where that detail fits. I will fix it. Dino > > Ron > > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Monday, June 27, 2011 1:18 PM > To: Ronald Bonica > Cc: Dino Farinacci; lisp@ietf.org > Subject: Re: [lisp] Last call for draft-ietf-lisp-12 > > Just to clarify what you are asking Ron, > would you like the text to say "SHOULD send an ICMP"? > And in which places would you like it to say that? > > Thanks, > Joel > > On 6/27/2011 12:23 PM, Ronald Bonica wrote: >> Dino, >> >> Maybe I am misreading you, but your response to me seems to >> contradict your response to Alia. When Alia asked, you said, >> "Experimentation will tell us more on what to do." When I asked, >> you seemed to have made up your mind about following the >> recommendation of RFC 4443. >> >> Which is it? >> >> Ron >> >> >> -----Original Message----- >> From: Dino Farinacci [mailto:dino@cisco.com] >> Sent: Monday, June 27, 2011 12:07 PM >> To: Ronald Bonica >> Cc: Alia Atlas; lisp@ietf.org >> Subject: Re: [lisp] Last call for draft-ietf-lisp-12 >> >>> Dino, >>> >>> Why not take the advice of RFC 4443? It says that a router SHOULD >>> send an ICMP message. >> >> Why duplicate what another document is specifying? The LISP router >> should send an ARP also when it decaps and the EID is directly >> connected. Should we specify that as well? >> >> Dino >> >>> >>> Ron >>> >>>> 4) Generally, a section specifying ITR behavior in regard to >>>> packets >>>> is missing. >>>> i) For instance, if an ITR receives a Negative Map Reply indicated >>>> "drop", should the ITR send an ICMP Destination Unreachable with >>>> Host Unreachable? >>> >>> We did not want to specify this because in practice when this is >>> done >>> either the ICMP messages are either rate-limited or filtered so ICMP >>> is not a reliable mechanism. >>> >>> Experimentation will tell us more on what to do. >>> >>> >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >> From fmaino@cisco.com Mon Jun 27 11:23:28 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2543611E80CF for ; Mon, 27 Jun 2011 11:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2J0L+wYOP07 for ; Mon, 27 Jun 2011 11:23:27 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id D33D521F84F1 for ; Mon, 27 Jun 2011 11:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fmaino@cisco.com; l=6274; q=dns/txt; s=iport; t=1309199006; x=1310408606; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=gTHObJnRsod8JWSrlPh7h4ewPUfEI6Dgosh5OSbnaeY=; b=HzGs00/q4oYuXKcpq93iR/54rRToIy5ZPINE3ZuyZskMmM/VJhETYri+ RuXXI6q6kFw1PSW3SJLHN76nsmHAUtoYyutR60PyodGcMjFbEFsKrkKwQ ilOEYPu2dNzhrNjqfC1lIYlIu0sN5OA9v1duDPgdhotS7LK2l4NDQ2BJr A=; X-IronPort-AV: E=Sophos;i="4.65,433,1304294400"; d="scan'208,217";a="722910738" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 27 Jun 2011 18:23:26 +0000 Received: from dhcp-128-107-166-207.cisco.com (dhcp-128-107-166-207.cisco.com [128.107.166.207]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5RINQDJ027793; Mon, 27 Jun 2011 18:23:26 GMT Message-ID: <4E08CA9B.3080001@cisco.com> Date: Mon, 27 Jun 2011 11:23:23 -0700 From: Fabio Maino User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: lisp@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010504010905010709020302" Subject: Re: [lisp] Draft agenda due soon. X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jun 2011 18:23:28 -0000 This is a multi-part message in MIME format. --------------010504010905010709020302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Terry, we would like to have 5 min for a status update on draft-ietf-lisp-sec-00.txt (that will be posted this friday july 1st). Presenter Vina Ermagan. Thanks, Fabio On 6/26/11 8:42 PM, Terry Manderson wrote: > > Folks, > > It's that time once again. Time to construct the draft agenda - Our > current > time slot is 2 hours, and as usual preference will be given to on charter > items, and expecting updates from the existing WG items. > > Please email me if you wish to have a speaking slot in Quebec. > > It is also helpful to keep these deadlines in mind: > > 2011-06-27 (Monday): Working Group Chair approval for initial document > (Version -00) submissions appreciated by 17:00 PT (00:00 UTC). > > 2011-07-01 (Friday): Final agenda to be published. > > 2011-07-04 (Monday): Internet Draft Cut-off for initial document (-00) > submission by 17:00 PT (00:00 UTC), upload using IETF ID Submission Tool. > > 2011-07-11 (Monday): Internet Draft final submission cut-off by 17:00 PT > (00:00 UTC), upload using IETF ID Submission Tool. > > 2011-07-13 (Wednesday): Draft Working Group agendas due by 17:00 PT (00:00 > UTC), upload using IETF Meeting Materials Management Tool. > > 2011-07-15 (Friday): Early Bird registration and payment cut-off at > 17:00 PT > (00:00 UTC). > > 2011-07-18 (Monday): Revised Working Group agendas due by 17:00 PT (00:00 > UTC), upload using IETF Meeting Materials Management Tool. > > 2011-07-18 (Monday): Registration cancellation cut-off at 17:00 PT (00:00 > UTC). > > 2011-07-22 (Friday): Final Pre-Registration and Pre-Payment cut-off at > 17:00 > local meeting time. > > 2011-07-24 - 2011-07-29: 81st IETF Meeting in Quebec City, Canada. > > Cheers > Terry > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > -- Fabio Maino fmaino@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------010504010905010709020302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Terry,
we would like to have 5 min for a status update on draft-ietf-lisp-sec-00.txt (that will be posted this friday july 1st). Presenter Vina Ermagan.

Thanks,
Fabio

On 6/26/11 8:42 PM, Terry Manderson wrote:
[lisp] Draft agenda due soon.

Folks,

It's that time once again. Time to construct the draft agenda - Our current
time slot is 2 hours, and as usual preference will be given to on charter
items, and expecting updates from the existing WG items.

Please email me if you wish to have a speaking slot in Quebec.

It is also helpful to keep these deadlines in mind:

2011-06-27 (Monday): Working Group Chair approval for initial document
(Version -00) submissions appreciated by 17:00 PT (00:00 UTC).

2011-07-01 (Friday): Final agenda to be published.

2011-07-04 (Monday): Internet Draft Cut-off for initial document (-00)
submission by 17:00 PT (00:00 UTC), upload using IETF ID Submission Tool.

2011-07-11 (Monday): Internet Draft final submission cut-off by 17:00 PT
(00:00 UTC), upload using IETF ID Submission Tool.

2011-07-13 (Wednesday): Draft Working Group agendas due by 17:00 PT (00:00
UTC), upload using IETF Meeting Materials Management Tool.

2011-07-15 (Friday): Early Bird registration and payment cut-off at 17:00 PT
(00:00 UTC).

2011-07-18 (Monday): Revised Working Group agendas due by 17:00 PT (00:00
UTC), upload using IETF Meeting Materials Management Tool.

2011-07-18 (Monday): Registration cancellation cut-off at 17:00 PT (00:00
UTC).

2011-07-22 (Friday): Final Pre-Registration and Pre-Payment cut-off at 17:00
local meeting time.

2011-07-24 - 2011-07-29: 81st IETF Meeting in Quebec City, Canada.

Cheers
Terry

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



-- 
Fabio Maino
fmaino@cisco.com

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------010504010905010709020302-- From dino@cisco.com Mon Jun 27 19:01:47 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0164221F8496 for ; Mon, 27 Jun 2011 19:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OaFi8beJe-M for ; Mon, 27 Jun 2011 19:01:46 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8252921F8489 for ; Mon, 27 Jun 2011 19:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=2380; q=dns/txt; s=iport; t=1309226506; x=1310436106; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=Jp1cQ+2jH0qhT2gs+n8gCy/hd+Eh2fze3ejDVESP8kM=; b=XqJbGitLzOoWNR6iiwDoHZykiDxfLVY1nK3d4LSQLH8h2n0ElkVRFl5U EK+wwNA/TvtRl+IqCZkXdbweaJAp1LSz7cacPfKqDm5jLUvKK13wxJGcx vMiGMXZE/o5LoInWFNflFQKclVaISXlEYDVh+tWwMzYH0HSdG35PINiHO Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAH01CU6rRDoJ/2dsb2JhbABSpzp3iHSiQZ48hjAEhzKKWYRui1E X-IronPort-AV: E=Sophos;i="4.65,435,1304294400"; d="scan'208";a="470951758" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 28 Jun 2011 02:01:46 +0000 Received: from [192.168.1.4] (sjc-vpn7-1262.cisco.com [10.21.148.238]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5S21jtL011120; Tue, 28 Jun 2011 02:01:46 GMT Message-Id: <8B169DDB-3DEB-4DDF-B1E3-CAEA7F630733@cisco.com> From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4E08B35C.1060301@joelhalpern.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 27 Jun 2011 19:01:43 -0700 References: <13205C286662DE4387D9AF3AC30EF456D3F1FB0626@EMBX01-WF.jnpr.net> <225E8E0C-ED97-4487-81B8-ADBA7A5689FE@cisco.com> <4E08B35C.1060301@joelhalpern.com> X-Mailer: Apple Mail (2.936) Cc: "lisp@ietf.org" Subject: Re: [lisp] EID-to-RLOC Cache Integrity X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jun 2011 02:01:47 -0000 > There appear to be two related technical issues here. > > The first one is on refreshing entries. A refresh of a less- > specific with overlapping more-specifics will inherently provide > refresh of the more-specifics. Even if an implementor does not > realize that, he will do the right thing. We can live with the text > asa is on that. > > The second one deals with a different issue. In performing local > maintenance of a cache with overlapping entries, one could easily > get into a situation where the less-specific is being used (its use > time would be updated), but the more-specifics are not being used. > An LRU-based cache maintenance algorithm could, according to what is > written in the spec, remove these relatively-unused entries in teh > event of cache exhaustion. > HOWEVER, such removal would actually be wrong. It would break the > coherence requirement. > As far as I know, nothing in the spec says taht. > Yes, a sufficiently attentive reader could realize that one set of > protocol behavior could impact another. But we do NOT normally > expect readers to perform that level of inference. Specs are to be > implementable by folks who are not protocol designers. > > Is there some place in the space where it says this? If not, could > we add a sentence or two in the text on local cache management. Yes, I will make sure I mention how to time out entries when there are overlapping EID-prefixes. Thanks a lot for clarifying things Joel. Dino > > Yours, > Joel > > On 6/27/2011 12:34 PM, Dino Farinacci wrote: >>> This integrity rule is important because it drives the answer to >>> many >>> other questions. For example: >>> >>> - If the ITR uses the less specific and updates its expiration time, >>> must it update the expiration time of all of the more specifics, >>> also? >> >> The update of the expiration time is based on receiving a Map-Reply >> and >> in section 6.1.5, it is documented how to send and process Map- >> Replies >> when overlapping EID-prefixes are in use. >> >>> - If the EID-to-RLOC cache thrashes, and I am forced to delete >>> unexpired entries, must I delete the less specific before the more >>> specifics? >> >> You could. But you could also use an LRU algorithm on EID-prefixes >> which >> are not overlapping. From vaf@cisco.com Tue Jun 28 11:47:47 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529B411E8132 for ; Tue, 28 Jun 2011 11:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cwn823Abp1F for ; Tue, 28 Jun 2011 11:47:46 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 8976311E8120 for ; Tue, 28 Jun 2011 11:47:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=2549; q=dns/txt; s=iport; t=1309286866; x=1310496466; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=wn1G7jLkf03jNTbDP5/M+inxJ3nQh1M3Nge23VZKdtw=; b=NBaS5FM4AOu1N/CVIKWmv+NY/cYWu3AMlj1o0ek71AmOzqznBgzr5iIT OlAbMwn4c1oI5/ujg1oZPdLJCF8s4Qm5xDbAP+/+IZG5ehI93CyG0mKPm Pkkpvzsx0mPeNyRJr0bpHKiE9cPsJTgw12jkZDqmsVcxMeRuoo8IKMEX5 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHUhCk6rRDoJ/2dsb2JhbABTp0B3qzieH4YwBIc0mx0 X-IronPort-AV: E=Sophos;i="4.65,438,1304294400"; d="scan'208";a="723608380" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 28 Jun 2011 18:47:45 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5SIljv7003505; Tue, 28 Jun 2011 18:47:45 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 000A2128F5BD; Tue, 28 Jun 2011 11:47:44 -0700 (PDT) Date: Tue, 28 Jun 2011 11:47:44 -0700 From: Vince Fuller To: "Joel M. Halpern" Message-ID: <20110628184744.GD77000@vaf-mac1.cisco.com> References: <20110623214656.GA54962@vaf-mac1.cisco.com> <4E04D753.7070703@joelhalpern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E04D753.7070703@joelhalpern.com> User-Agent: Mutt/1.4.2.3i Cc: "lisp@ietf.org" Subject: Re: [lisp] last call for draft-ietf-lisp-alt-06 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jun 2011 18:47:47 -0000 On Fri, Jun 24, 2011 at 02:28:35PM -0400, Joel M. Halpern wrote: > If I am reading the text Alia qutoed below correctly, the text assumes > that an ETR will do something different with a map reply based on the > whether it thinks the source address is an EID. > > I think this is basically indeterimnable. > More importantly, that would be an ETR behavior, which the ALT spec > can't change. > I suspect this is a case of the authors, in good faith, trying to leave > in a hook for an idea they have for the future. > However, the effect is to introduce confusion. > Can we not do that? I am not sure if you are asking for a text change here. The current ALT document says the following regarding the source IP address of an ALT datagram: - the last paragraph in section 3: The term "ALT Datagram" is short-hand for a Map-Request or Data Probe to be sent into or forwarded on the ALT. Note that while the outer header Source Address of an ALT Datagram is currently expected to be an RLOC, there may be situations (e.g. for experimentation with caching in intermediate ALT nodes) where an EID would be used to force a Map-Reply to be routed back through the ALT. - first paragraph in section 5.1: 5.1. Changes to ITR behavior with LISP+ALT As previously described, an ITR will usually use the Map Resolver interface and will send its Map Requests to a Map Resolver. When an ITR instead connects via tunnels and BGP to the ALT, it sends ALT Datagrams to one of its "upstream" ALT Routers; these are sent only to obtain new EID-to-RLOC mappings - RLOC probe and cache TTL refresh Map-Requests are not sent on the ALT. As in basic LISP, it should use one of its RLOCs as the source address of these queries; it should not use a tunnel interface as the source address as doing so will cause replies to be forwarded over the tunneled topology and may be problematic if the tunnel interface address is not routed throughout the ALT. Are you saying that one of these sections needs to be changed to make it more clear that the source IP address of an ALT datagram should, in normal use, be an RLOC? If so, please provide suggested text; IMHO, the existing text is rather explicit about warning that using an EID as the source of an ALT Datagram could have undefined consequences. We do not intend for the infrastructure to test for that situation since the cost of doing so would be unancceptably high. --Vince From jmh@joelhalpern.com Tue Jun 28 11:55:51 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B4211E8132 for ; Tue, 28 Jun 2011 11:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.257 X-Spam-Level: X-Spam-Status: No, score=-102.257 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFvuDMP2bsgt for ; Tue, 28 Jun 2011 11:55:51 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfa.amsl.com (Postfix) with ESMTP id 1142911E811F for ; Tue, 28 Jun 2011 11:55:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id DA5633245E48; Tue, 28 Jun 2011 11:55:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-50-66.clppva.btas.verizon.net [71.161.50.66]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 17D993228BE9; Tue, 28 Jun 2011 11:55:19 -0700 (PDT) Message-ID: <4E0A2394.6000008@joelhalpern.com> Date: Tue, 28 Jun 2011 14:55:16 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Vince Fuller References: <20110623214656.GA54962@vaf-mac1.cisco.com> <4E04D753.7070703@joelhalpern.com> <20110628184744.GD77000@vaf-mac1.cisco.com> In-Reply-To: <20110628184744.GD77000@vaf-mac1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] last call for draft-ietf-lisp-alt-06 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jun 2011 18:55:51 -0000 Unless we are prepared to modify the base LISP spec ETR behavior, I would remove everything from "Note" to the end of of the quoted paragraph from section 3. I think it would be helpful to instead say "Such datagrams carry RLOCs as their outer header source addresses, and EIDs as their outer header destination addresses." Yours, Joel On 6/28/2011 2:47 PM, Vince Fuller wrote: > On Fri, Jun 24, 2011 at 02:28:35PM -0400, Joel M. Halpern wrote: >> If I am reading the text Alia qutoed below correctly, the text assumes >> that an ETR will do something different with a map reply based on the >> whether it thinks the source address is an EID. >> >> I think this is basically indeterimnable. >> More importantly, that would be an ETR behavior, which the ALT spec >> can't change. >> I suspect this is a case of the authors, in good faith, trying to leave >> in a hook for an idea they have for the future. >> However, the effect is to introduce confusion. >> Can we not do that? > > I am not sure if you are asking for a text change here. > > The current ALT document says the following regarding the source IP address > of an ALT datagram: > > - the last paragraph in section 3: > > The term "ALT Datagram" is short-hand for a Map-Request or Data Probe > to be sent into or forwarded on the ALT. Note that while the outer > header Source Address of an ALT Datagram is currently expected to be > an RLOC, there may be situations (e.g. for experimentation with > caching in intermediate ALT nodes) where an EID would be used to > force a Map-Reply to be routed back through the ALT. > > - first paragraph in section 5.1: > > 5.1. Changes to ITR behavior with LISP+ALT > > As previously described, an ITR will usually use the Map Resolver > interface and will send its Map Requests to a Map Resolver. When an > ITR instead connects via tunnels and BGP to the ALT, it sends ALT > Datagrams to one of its "upstream" ALT Routers; these are sent only > to obtain new EID-to-RLOC mappings - RLOC probe and cache TTL refresh > Map-Requests are not sent on the ALT. As in basic LISP, it should > use one of its RLOCs as the source address of these queries; it > should not use a tunnel interface as the source address as doing so > will cause replies to be forwarded over the tunneled topology and may > be problematic if the tunnel interface address is not routed > throughout the ALT. > > Are you saying that one of these sections needs to be changed to make it > more clear that the source IP address of an ALT datagram should, in normal > use, be an RLOC? If so, please provide suggested text; IMHO, the existing > text is rather explicit about warning that using an EID as the source of > an ALT Datagram could have undefined consequences. We do not intend for the > infrastructure to test for that situation since the cost of doing so would > be unancceptably high. > > --Vince > From vaf@cisco.com Tue Jun 28 12:02:51 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3306811E811C for ; Tue, 28 Jun 2011 12:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZY6KuNE260N0 for ; Tue, 28 Jun 2011 12:02:50 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0481521F8513 for ; Tue, 28 Jun 2011 12:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=536; q=dns/txt; s=iport; t=1309287730; x=1310497330; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=VaednMA/9cUfvk5lV2PoBGYCvmguDvg/jC19pCkJC2M=; b=CymfVkdIQIf0FjGMERURLt6O+Kn0hnBiSo/eAy031+ciUWbLMvcX8JmM kl/dwfswzGlAO8HY8yWNH9KuvwbC8qZBREcgjcZV1yeoaPwRyXctJL/R8 D14q/dKE3gIHqizZAUbvC8u/1PirtfR9Q4WObliHbMb1n7yM4HUEbxlkj E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFgkCk6rRDoI/2dsb2JhbABTp0B3qymeHYYwBIc0mx0 X-IronPort-AV: E=Sophos;i="4.65,438,1304294400"; d="scan'208";a="471493498" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 28 Jun 2011 19:02:10 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5SJ2AuN023219; Tue, 28 Jun 2011 19:02:10 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 5BE77128F904; Tue, 28 Jun 2011 12:02:10 -0700 (PDT) Date: Tue, 28 Jun 2011 12:02:10 -0700 From: Vince Fuller To: "Joel M. Halpern" Message-ID: <20110628190209.GA77741@vaf-mac1.cisco.com> References: <20110623214656.GA54962@vaf-mac1.cisco.com> <4E04D753.7070703@joelhalpern.com> <20110628184744.GD77000@vaf-mac1.cisco.com> <4E0A2394.6000008@joelhalpern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E0A2394.6000008@joelhalpern.com> User-Agent: Mutt/1.4.2.3i Cc: "lisp@ietf.org" Subject: Re: [lisp] last call for draft-ietf-lisp-alt-06 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jun 2011 19:02:51 -0000 On Tue, Jun 28, 2011 at 02:55:16PM -0400, Joel M. Halpern wrote: > Unless we are prepared to modify the base LISP spec ETR behavior, I > would remove everything from "Note" to the end of of the quoted > paragraph from section 3. > I think it would be helpful to instead say "Such datagrams carry RLOCs > as their outer header source addresses, and EIDs as their outer header > destination addresses." OK. Change will appear in ALT 07, to be published later this week when several other comments are resolved. --Vince From jmh@joelhalpern.com Tue Jun 28 13:10:42 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADEEC11E80CA for ; Tue, 28 Jun 2011 13:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5Hn7oVECuo9 for ; Tue, 28 Jun 2011 13:10:42 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED2411E807B for ; Tue, 28 Jun 2011 13:10:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 2F229324428A; Tue, 28 Jun 2011 13:10:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.0.0.134] (unknown [208.253.77.202]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id B965732466FE; Tue, 28 Jun 2011 13:10:11 -0700 (PDT) Message-ID: <4E0A351F.30705@joelhalpern.com> Date: Tue, 28 Jun 2011 16:10:07 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Vince Fuller References: <20110623214656.GA54962@vaf-mac1.cisco.com> <4E04D753.7070703@joelhalpern.com> <20110628184744.GD77000@vaf-mac1.cisco.com> <4E0A2394.6000008@joelhalpern.com> <20110628190209.GA77741@vaf-mac1.cisco.com> In-Reply-To: <20110628190209.GA77741@vaf-mac1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] last call for draft-ietf-lisp-alt-06 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jun 2011 20:10:42 -0000 Thanks. Joel On 6/28/2011 3:02 PM, Vince Fuller wrote: > On Tue, Jun 28, 2011 at 02:55:16PM -0400, Joel M. Halpern wrote: >> Unless we are prepared to modify the base LISP spec ETR behavior, I >> would remove everything from "Note" to the end of of the quoted >> paragraph from section 3. >> I think it would be helpful to instead say "Such datagrams carry RLOCs >> as their outer header source addresses, and EIDs as their outer header >> destination addresses." > > OK. Change will appear in ALT 07, to be published later this week when > several other comments are resolved. > > --Vince > From akatlas@gmail.com Tue Jun 28 13:25:27 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CC711E819C for ; Tue, 28 Jun 2011 13:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOXJkyJ7btom for ; Tue, 28 Jun 2011 13:25:26 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 50AB511E80CA for ; Tue, 28 Jun 2011 13:25:26 -0700 (PDT) Received: by pzk5 with SMTP id 5so489261pzk.31 for ; Tue, 28 Jun 2011 13:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KBELXNmEXE20bErLU90NXT3VMJs4aYVLVX+7alrK0Dg=; b=fhsOMlfbEsYEJBZYC1oGOJXwn4PmHx8ttvOTnKMMI4mmXS4V/YU9gizGl8rdp3btp+ BNdwj9DNPDMyzaFzqEp25s9XZXNYRie4mV5c8oDFEHj7gWbE7d4u7ADeclZ2klIQbaGf Me+7qP2ulvYxBRgfo3zetVp0cgUdKEvZC/rhk= MIME-Version: 1.0 Received: by 10.68.15.71 with SMTP id v7mr4486444pbc.116.1309292725642; Tue, 28 Jun 2011 13:25:25 -0700 (PDT) Received: by 10.68.52.68 with HTTP; Tue, 28 Jun 2011 13:25:25 -0700 (PDT) In-Reply-To: <20110628190209.GA77741@vaf-mac1.cisco.com> References: <20110623214656.GA54962@vaf-mac1.cisco.com> <4E04D753.7070703@joelhalpern.com> <20110628184744.GD77000@vaf-mac1.cisco.com> <4E0A2394.6000008@joelhalpern.com> <20110628190209.GA77741@vaf-mac1.cisco.com> Date: Tue, 28 Jun 2011 16:25:25 -0400 Message-ID: From: Alia Atlas To: Vince Fuller Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "lisp@ietf.org" Subject: Re: [lisp] last call for draft-ietf-lisp-alt-06 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jun 2011 20:25:27 -0000 Thanks Alia On Tue, Jun 28, 2011 at 3:02 PM, Vince Fuller wrote: > On Tue, Jun 28, 2011 at 02:55:16PM -0400, Joel M. Halpern wrote: >> Unless we are prepared to modify the base LISP spec ETR behavior, I >> would remove everything from "Note" to the end of of the quoted >> paragraph from section 3. >> I think it would be helpful to instead say "Such datagrams carry RLOCs >> as their outer header source addresses, and EIDs as their outer header >> destination addresses." > > OK. Change will appear in ALT 07, to be published later this week when > several other comments are resolved. > > =A0 =A0 =A0 =A0--Vince > From vaf@cisco.com Tue Jun 28 13:37:38 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276EF11E819E for ; Tue, 28 Jun 2011 13:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvzAGUYgDkcm for ; Tue, 28 Jun 2011 13:37:37 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFAE11E8158 for ; Tue, 28 Jun 2011 13:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=785; q=dns/txt; s=iport; t=1309293457; x=1310503057; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Ilncxm8ljeBavugp/fo9FOCsWQ3AdRMvsQ7spQoUZlc=; b=jvYIj3H67MF3IV/prs5WWoNBdOyNmyM/3Qg1W+P4HxELAskZeEJj7p89 V/o3iWyKmgMxSPmx7KCr4xohDMnYA5jVmnMZV362OvWz4KGIbqw4Ebfn0 uKGx5DEvSQnUa6te6R8Gkjw69BPnMjAYxbtfE08gQzlx+WL8ed3A9QE40 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJI6Ck6rRDoJ/2dsb2JhbABTp0J3iHejUJ4WhjAEhzSbHQ X-IronPort-AV: E=Sophos;i="4.65,438,1304294400"; d="scan'208";a="471550683" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 28 Jun 2011 20:37:29 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5SKbTFd000467; Tue, 28 Jun 2011 20:37:29 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id E83EA129067D; Tue, 28 Jun 2011 13:37:28 -0700 (PDT) Date: Tue, 28 Jun 2011 13:37:28 -0700 From: Vince Fuller To: Alia Atlas Message-ID: <20110628203728.GA79229@vaf-mac1.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "lisp@ietf.org" Subject: Re: [lisp] last call for draft-ietf-lisp-alt-06 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jun 2011 20:37:38 -0000 > c) In Sec 7.2, there is a sentence: "Should a receiving ITR decide > that it does not wish to store such more-specific information, it has > the option of discarding it as long as a shorter, covering EID-prefix > exists." I found this confusing and it seems to violate the prefix > rules in [LISP], as well as they were described. After further consideration and discussion, I agree that such discarding of more-specific map cache entries would be a bad idea. Even in cases where it could be done without adverse traffic forwarding impact (such as when the covering route and the more-specifics share the same set of RLOCs) it would add complexity to the cache management problem. This sentence has been removed in the upcoming version 7 of the ALT spec. --Vince From internet-drafts@ietf.org Wed Jun 29 14:53:43 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888EB11E80E3; Wed, 29 Jun 2011 14:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIKQRQJkumZh; Wed, 29 Jun 2011 14:53:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFDEE11E80A8; Wed, 29 Jun 2011 14:53:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110629215342.27033.41597.idtracker@ietfa.amsl.com> Date: Wed, 29 Jun 2011 14:53:42 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-14.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jun 2011 21:53:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : Locator/ID Separation Protocol (LISP) Author(s) : Dino Farinacci Vince Fuller Dave Meyer Darrel Lewis Filename : draft-ietf-lisp-14.txt Pages : 91 Date : 2011-06-29 This draft describes a network-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. LISP can be incrementally deployed, without a "flag day", and offers traffic engineering, multi-homing, and mobility benefits even to early adopters, when there are relatively few LISP- capable sites. Design and development of LISP was largely motivated by the problem statement produced by the October, 2006 IAB Routing and Addressing Workshop. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-14.txt From dino@cisco.com Wed Jun 29 14:55:50 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A3611E80AB for ; Wed, 29 Jun 2011 14:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gfc+pcF+-I4Q for ; Wed, 29 Jun 2011 14:55:50 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id B9F8611E80A8 for ; Wed, 29 Jun 2011 14:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=410464; q=dns/txt; s=iport; t=1309384549; x=1310594149; h=message-id:from:to:mime-version:subject:date; bh=9/4yDLaCkXlUaVO+dMH6qXUmoDmnk4Tio/ULERmna5s=; b=TzO3oXXJcIoNUUsZySGXX3qtMRk/KUUMxNuygG7Tha6i+E1uvJmsYybF HYiMG8dF9HZ8x47GNMUR0QBLLi6WcuHRahiH8pyOosjsV6rmQ/cq2WMvx gL3TtSxAPZmLSIXaPTxtT0mhDiNtgVEfL+04ekLryLVQZ8/Bc6Ka66z7I 8=; X-Files: rfcdiff-lisp-13-to-14.html, draft-ietf-lisp-14.txt : 194530, 204367 X-IronPort-AV: E=Sophos;i="4.65,446,1304294400"; d="txt'?html'217?scan'217,208,217";a="472345143" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 29 Jun 2011 21:55:40 +0000 Received: from dhcp-171-70-217-219.cisco.com (dhcp-171-70-217-219.cisco.com [171.70.217.219]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5TLte0e026662 for ; Wed, 29 Jun 2011 21:55:40 GMT Message-Id: From: Dino Farinacci To: lisp@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-116-364858833 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 29 Jun 2011 14:55:40 -0700 X-Mailer: Apple Mail (2.936) Subject: [lisp] draft-ietf-lisp-14 posted to ID directory X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jun 2011 21:55:50 -0000 --Apple-Mail-116-364858833 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Folks a new last call draft has been posted to reflect comments from Alia and Ron. Thanks, Dino/Vince/Darrel/Dave B.1. Changes to draft-ietf-lisp-14.txt o Post working group last call and pre-IESG last call review. o Indicate that an ICMP Unreachable message should be sent when a packet matches a drop-based negative map-cache entry. o Indicate how a map-cache set of overlapping EID-prefixes must maintian integrity when the map-cache maximum cap is reached. o Add Joel's description for the definition of an EID, that the bit string value can be an RLOC for another device in abstract but the architecture allows it to be an EID of one device and the same value as an RLOC for another device. o In the "Tunnel Encapsulation Details" section, indicate that 4 combinations of encapsulation are supported. o Add what ETR should do for a Data-Probe when received for a destination EID outside of its EID-prefix range. This was added in the Data Probe definition section. o Added text indicating that more-specific EID-prefixes must not be removed when less-specific entries stay in the map-cache. This is to preserve the integrity of the EID-prefix set. o Add clarifying text in the Security Considerations section about how an ETR must not decapsulate and forward a packet that is not for its configured EID-prefix range. --Apple-Mail-116-364858833 Content-Disposition: attachment; filename=rfcdiff-lisp-13-to-14.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-lisp-13-to-14.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-13.txt draft-ietf-lisp-14.txt 
Network Working Group                                       D. Farinacci
Internet-Draft                                                 V. Fuller
Intended status: Experimental                                   D. Meyer
Expires: December 23, 31, 2011                                      D. Lewis
                                                           cisco Systems
                                                           June 21, 29, 2011

                 Locator/ID Separation Protocol (LISP)
                           draft-ietf-lisp-13
                           draft-ietf-lisp-14

Abstract

   This draft describes a network-based protocol that enables separation
   of IP addresses into two new numbering spaces: Endpoint Identifiers
   (EIDs) and Routing Locators (RLOCs).  No changes are required to
   either host protocol stacks or to the "core" of the Internet
   infrastructure.  LISP can be incrementally deployed, without a "flag
   day", and offers traffic engineering, multi-homing, and mobility
   benefits even to early adopters, when there are relatively few LISP-
   capable sites.

   Design and development of LISP was largely motivated by the problem
   statement produced by the October, 2006 IAB Routing and Addressing
   Workshop.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 23, 31, 2011.

Copyright Notice

   Copyright (c) 2011 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 BSD License.

Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  7
   4.  Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14
   5.  LISP Encapsulation Details . . . . . . . . . . . . . . . . . . 16
     5.1.  LISP IPv4-in-IPv4 Header Format  . . . . . . . . . . . . . 17
     5.2.  LISP IPv6-in-IPv6 Header Format  . . . . . . . . . . . . . 17
     5.3.  Tunnel Header Field Descriptions . . . . . . . . . . . . . 19
     5.4.  Dealing with Large Encapsulated Packets  . . . . . . . . . 22
       5.4.1.  A Stateless Solution to MTU Handling . . . . . . . . . 23
       5.4.2.  A Stateful Solution to MTU Handling  . . . . . . . . . 24
     5.5.  Using Virtualization and Segmentation with LISP  . . . . . 24
   6.  EID-to-RLOC Mapping  . . . . . . . . . . . . . . . . . . . . . 26
     6.1.  LISP IPv4 and IPv6 Control Plane Packet Formats  . . . . . 26
       6.1.1.  LISP Packet Type Allocations . . . . . . . . . . . . . 28
       6.1.2.  Map-Request Message Format . . . . . . . . . . . . . . 28
       6.1.3.  EID-to-RLOC UDP Map-Request Message  . . . . . . . . . 31
       6.1.4.  Map-Reply Message Format . . . . . . . . . . . . . . . 32
       6.1.5.  EID-to-RLOC UDP Map-Reply Message  . . . . . . . . . . 36
       6.1.6.  Map-Register Message Format  . . . . . . . . . . . . . 38
       6.1.7.  Map-Notify Message Format  . . . . . . . . . . . . . . 40
       6.1.8.  Encapsulated Control Message Format  . . . . . . . . . 41
     6.2.  Routing Locator Selection  . . . . . . . . . . . . . . . . 43
     6.3.  Routing Locator Reachability . . . . . . . . . . . . . . . 45
       6.3.1.  Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 47
       6.3.2.  RLOC Probing Algorithm . . . . . . . . . . . . . . . . 48
     6.4.  EID Reachability within a LISP Site  . . . . . . . . . . . 49
     6.5.  Routing Locator Hashing  . . . . . . . . . . . . . . . . . 50
     6.6.  Changing the Contents of EID-to-RLOC Mappings  . . . . . . 50
       6.6.1.  Clock Sweep  . . . . . . . . . . . . . . . . . . . . . 51
       6.6.2.  Solicit-Map-Request (SMR)  . . . . . . . . . . . . . . 52
       6.6.3.  Database Map Versioning  . . . . . . . . . . . . . . . 54
   7.  Router Performance Considerations  . . . . . . . . . . . . . . 55
   8.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 56
     8.1.  First-hop/Last-hop Tunnel Routers  . . . . . . . . . . . . 57
     8.2.  Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 57
     8.3.  ISP Provider-Edge (PE) Tunnel Routers  . . . . . . . . . . 58
     8.4.  LISP Functionality with Conventional NATs  . . . . . . . . 58
     8.5.  Packets Egressing a LISP Site  . . . . . . . . . . . . . . 59
   9.  Traceroute Considerations  . . . . . . . . . . . . . . . . . . 60
     9.1.  IPv6 Traceroute  . . . . . . . . . . . . . . . . . . . . . 61
     9.2.  IPv4 Traceroute  . . . . . . . . . . . . . . . . . . . . . 61
     9.3.  Traceroute using Mixed Locators  . . . . . . . . . . . . . 61
   10. Mobility Considerations  . . . . . . . . . . . . . . . . . . . 63
     10.1. Site Mobility  . . . . . . . . . . . . . . . . . . . . . . 63
     10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 63
     10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 63
     10.4. Fast Network Mobility  . . . . . . . . . . . . . . . . . . 65
     10.5. LISP Mobile Node Mobility  . . . . . . . . . . . . . . . . 65
   11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 67
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 68
   13. Network Management Considerations  . . . . . . . . . . . . . . 70
   14. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 71
     14.1. LISP Address Type Codes  . . . . . . . . . . . . . . . . . 71
     14.2. LISP UDP Port Numbers  . . . . . . . . . . . . . . . . . . 71
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 72
     15.2. Informative References . . . . . . . . . . . . . . . . . . 73
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 77
   Appendix B.  Document Change Log . . . . . . . . . . . . . . . . . 78
     B.1.  Changes to draft-ietf-lisp-13.txt draft-ietf-lisp-14.txt  . . . . . . . . . . . . 78
     B.2.  Changes to draft-ietf-lisp-12.txt draft-ietf-lisp-13.txt  . . . . . . . . . . . . 78
     B.3.  Changes to draft-ietf-lisp-11.txt draft-ietf-lisp-12.txt  . . . . . . . . . . . . 80 79
     B.4.  Changes to draft-ietf-lisp-10.txt draft-ietf-lisp-11.txt  . . . . . . . . . . . . 80
     B.5.  Changes to draft-ietf-lisp-09.txt draft-ietf-lisp-10.txt  . . . . . . . . . . . . 81
     B.6.  Changes to draft-ietf-lisp-08.txt draft-ietf-lisp-09.txt  . . . . . . . . . . . . 81
     B.7.  Changes to draft-ietf-lisp-07.txt draft-ietf-lisp-08.txt  . . . . . . . . . . . . 83 82
     B.8.  Changes to draft-ietf-lisp-07.txt  . . . . . . . . . . . . 84
     B.9.  Changes to draft-ietf-lisp-06.txt  . . . . . . . . . . . . 85
     B.9.
     B.10. Changes to draft-ietf-lisp-05.txt  . . . . . . . . . . . . 86
     B.10.
     B.11. Changes to draft-ietf-lisp-04.txt  . . . . . . . . . . . . 86
     B.11. 87
     B.12. Changes to draft-ietf-lisp-03.txt  . . . . . . . . . . . . 88
     B.12. 89
     B.13. Changes to draft-ietf-lisp-02.txt  . . . . . . . . . . . . 88
     B.13. 89
     B.14. Changes to draft-ietf-lisp-01.txt  . . . . . . . . . . . . 89
     B.14.
     B.15. Changes to draft-ietf-lisp-00.txt  . . . . . . . . . . . . 89 90
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 90 91

1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   This document describes the Locator/Identifier Separation Protocol
   (LISP), which provides a set of functions for routers to exchange
   information used to map from non-routeable Endpoint Identifiers
   (EIDs) to routeable Routing Locators (RLOCs).  It also defines a
   mechanism for these LISP routers to encapsulate IP packets addressed
   with EIDs for transmission across an Internet that uses RLOCs for
   routing and forwarding.

   Creation of LISP was initially motivated by discussions during the
   IAB-sponsored Routing and Addressing Workshop held in Amsterdam in
   October, 2006 (see [RFC4984]).  A key conclusion of the workshop was
   that the Internet routing and addressing system was not scaling well
   in the face of the explosive growth of new sites; one reason for this
   poor scaling is the increasing number of multi-homed and other sites
   that cannot be addressed as part of topologically- or provider-based
   aggregated prefixes.  Additional work that more completely described
   the problem statement may be found in [RADIR].

   A basic observation, made many years ago in early networking research
   such as that documented in [CHIAPPA] and [RFC4984], is that using a
   single address field for both identifying a device and for
   determining where it is topologically located in the network requires
   optimization along two conflicting axes: for routing to be efficient,
   the address must be assigned topologically; for collections of
   devices to be easily and effectively managed, without the need for
   renumbering in response to topological change (such as that caused by
   adding or removing attachment points to the network or by mobility
   events), the address must explicitly not be tied to the topology.

   The approach that LISP takes to solving the routing scalability
   problem is to replace IP addresses with two new types of numbers:
   Routing Locators (RLOCs), which are topologically assigned to network
   attachment points (and are therefore amenable to aggregation) and
   used for routing and forwarding of packets through the network; and
   Endpoint Identifiers (EIDs), which are assigned independently from
   the network topology, are used for numbering devices, and are
   aggregated along administrative boundaries.  LISP then defines
   functions for mapping between the two numbering spaces and for
   encapsulating traffic originated by devices using non-routeable EIDs
   for transport across a network infrastructure that routes and
   forwards using RLOCs.  Both RLOCs and EIDs are syntactically-
   identical to IP addresses; it is the semantics of how they are used
   that differs.

   This document describes the protocol that implements these functions.
   The database which stores the mappings between EIDs and RLOCs is
   explicitly a separate "module" to facilitate experimentation with a
   variety of approaches.  One database design that is being developed
   and prototyped as part of the LISP working group work is [ALT].
   Others that have been described but not implemented include [CONS],
   [EMACS], [RPMD], [NERD].  Finally, [LISP-MS], documents a general-
   purpose service interface for accessing a mapping database; this
   interface is intended to make the mapping database modular so that
   different approaches can be tried without the need to modify
   installed xTRs.

   This experimental specification does not address automated key
   management.  Addressing automated key management is necessary for
   Internet standards.  See Section 12 for further security details.

3.  Definition of Terms

   Provider Independent (PI) Addresses:   PI addresses are an address
      block assigned from a pool where blocks are not associated with
      any particular location in the network (e.g. from a particular
      service provider), and is therefore not topologically aggregatable
      in the routing system.

   Provider Assigned (PA) Addresses:   PA addresses are an a address
      block assigned to a site by each service provider to which a site
      connects.  Typically, each block is sub-block of a service
      provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and
      is aggregated into the larger block before being advertised into
      the global Internet.  Traditionally, IP multihoming has been
      implemented by each multi-homed site acquiring its own, globally-
      visible prefix.  LISP uses only topologically-assigned and
      aggregatable address blocks for RLOCs, eliminating this
      demonstrably non-scalable practice.

   Routing Locator (RLOC):   A RLOC is an IPv4 or IPv6 address of an
      egress tunnel router (ETR).  A RLOC is the output of a EID-to-RLOC
      mapping lookup.  An EID maps to one or more RLOCs.  Typically,
      RLOCs are numbered from topologically-aggregatable blocks that are
      assigned to a site at each point to which it attaches to the
      global Internet; where the topology is defined by the connectivity
      of provider networks, RLOCs can be thought of as PA addresses.
      Multiple RLOCs can be assigned to the same ETR device or to
      multiple ETR devices at a site.

   Endpoint ID (EID):   An EID is a 32-bit (for IPv4) or 128-bit (for
      IPv6) value used in the source and destination address fields of
      the first (most inner) LISP header of a packet.  The host obtains
      a destination EID the same way it obtains an destination address
      today, for example through a Domain Name System (DNS) [RFC1034]
      lookup or Session Invitation Protocol (SIP) [RFC3261] exchange.
      The source EID is obtained via existing mechanisms used to set a
      host's "local" IP address.  An EID is allocated to a host from an
      EID-prefix block associated with the site where the host is
      located.  An EID can be used by a host to refer to other hosts.
      EIDs MUST NOT be used as LISP RLOCs.  Note that EID blocks may be
      assigned in a hierarchical manner, independent of the network
      topology, to facilitate scaling of the mapping database.  In
      addition, an EID block assigned to a site may have site-local
      structure (subnetting) for routing within the site; this structure
      is not visible to the global routing system.  In theory, the bit
      string that represents an EID for one device can represent an RLOC
      for a different device.  As the architecture is realized, if a
      given bit string is both an RLOC and an EID, it must refer to the
      same entity in both cases.  When used in discussions with other
      Locator/ID separation proposals, a LISP EID will be called a
      "LEID".  Throughout this document, any references to "EID" refers
      to an LEID.

   EID-prefix:   An EID-prefix is a power-of-two block of EIDs which are
      allocated to a site by an address allocation authority.  EID-
      prefixes are associated with a set of RLOC addresses which make up
      a "database mapping".  EID-prefix allocations can be broken up
      into smaller blocks when an RLOC set is to be associated with the
      smaller EID-prefix.  A globally routed address block (whether PI
      or PA) is not inherently an EID-prefix.  A globally routed address
      block may be used by its assignee as an EID block.  The converse
      is not supported.  That is, a site which receives an explicitly
      allocated EID-prefix may not use that EID-prefix as a globally
      prefix.  This would require coordination and cooperation with the
      entities managing the mapping infrastructure.  Once this has been
      done, that block could be removed from the globally routed IP
      system, if other suitable transition and access mechanisms are in
      place.  Discussion of such transition and access mechanisms can be
      found in [INTERWORK] and [LISP-DEPLOY].

   End-system:   An end-system is an IPv4 or IPv6 device that originates
      packets with a single IPv4 or IPv6 header.  The end-system
      supplies an EID value for the destination address field of the IP
      header when communicating globally (i.e. outside of its routing
      domain).  An end-system can be a host computer, a switch or router
      device, or any network appliance.

   Ingress Tunnel Router (ITR):   An ITR is a router which accepts an IP
      packet with a single IP header (more precisely, an IP packet that
      does not contain a LISP header).  The router treats this "inner"
      IP destination address as an EID and performs an EID-to-RLOC
      mapping lookup.  The router then prepends an "outer" IP header
      with one of its globally-routable RLOCs in the source address
      field and the result of the mapping lookup in the destination
      address field.  Note that this destination RLOC may be an
      intermediate, proxy device that has better knowledge of the EID-
      to-RLOC mapping closer to the destination EID.  In general, an ITR
      receives IP packets from site end-systems on one side and sends
      LISP-encapsulated IP packets toward the Internet on the other
      side.

      Specifically, when a service provider prepends a LISP header for
      Traffic Engineering purposes, the router that does this is also
      regarded as an ITR.  The outer RLOC the ISP ITR uses can be based
      on the outer destination address (the originating ITR's supplied
      RLOC) or the inner destination address (the originating hosts
      supplied EID).

   TE-ITR:   A TE-ITR is an ITR that is deployed in a service provider
      network that prepends an additional LISP header for Traffic
      Engineering purposes.

   Egress Tunnel Router (ETR):   An ETR is a router that accepts an IP
      packet where the destination address in the "outer" IP header is
      one of its own RLOCs.  The router strips the "outer" header and
      forwards the packet based on the next IP header found.  In
      general, an ETR receives LISP-encapsulated IP packets from the
      Internet on one side and sends decapsulated IP packets to site
      end-systems on the other side.  ETR functionality does not have to
      be limited to a router device.  A server host can be the endpoint
      of a LISP tunnel as well.

   TE-ETR:   A TE-ETR is an ETR that is deployed in a service provider
      network that strips an outer LISP header for Traffic Engineering
      purposes.

   xTR:   A xTR is a reference to an ITR or ETR when direction of data
      flow is not part of the context description. xTR refers to the
      router that is the tunnel endpoint.  Used synonymously with the
      term "Tunnel Router".  For example, "An xTR can be located at the
      Customer Edge (CE) router", meaning both ITR and ETR functionality
      is at the CE router.

   EID-to-RLOC Cache:   The EID-to-RLOC cache is a short-lived, on-
      demand table in an ITR that stores, tracks, and is responsible for
      timing-out and otherwise validating EID-to-RLOC mappings.  This
      cache is distinct from the full "database" of EID-to-RLOC
      mappings, it is dynamic, local to the ITR(s), and relatively small
      while the database is distributed, relatively static, and much
      more global in scope.

   EID-to-RLOC Database:   The EID-to-RLOC database is a global
      distributed database that contains all known EID-prefix to RLOC
      mappings.  Each potential ETR typically contains a small piece of
      the database: the EID-to-RLOC mappings for the EID prefixes
      "behind" the router.  These map to one of the router's own,
      globally-visible, IP addresses.  The same database mapping entries
      MUST be configured on all ETRs for a given site.  In a steady
      state the EID-prefixes for the site and the locator-set for each
      EID-prefix MUST be the same on all ETRs.  Procedures to enforce
      and/or verify this are outside the scope of this document.  Note
      that there may be transient conditions when the EID-prefix for the
      site and locator-set for each EID-prefix may not be the same on
      all ETRs.  This has no negative implications.

   Recursive Tunneling:   Recursive tunneling occurs when a packet has
      more than one LISP IP header.  Additional layers of tunneling may
      be employed to implement traffic engineering or other re-routing
      as needed.  When this is done, an additional "outer" LISP header
      is added and the original RLOCs are preserved in the "inner"
      header.  Any references to tunnels in this specification refers to
      dynamic encapsulating tunnels and never are they statically
      configured.

   Reencapsulating Tunnels:   Reencapsulating tunneling occurs when an
      ETR removes a LISP header, then acts as an ITR to prepend another
      LISP header.  Doing this allows a packet to be re-routed by the
      re-encapsulating router without adding the overhead of additional
      tunnel headers.  Any references to tunnels in this specification
      refers to dynamic encapsulating tunnels and never are they
      statically configured.  When using multiple mapping database
      systems, care must be taken to not create reencapsulation loops.

   LISP Header:   a term used in this document to refer to the outer
      IPv4 or IPv6 header, a UDP header, and a LISP-specific 8-byte
      header that follows the UDP header, an ITR prepends or an ETR
      strips.

   Address Family Identifier (AFI):   a term used to describe an address
      encoding in a packet.  An address family currently pertains to an
      IPv4 or IPv6 address.  See [AFI]/[AFI-REGISTRY] and [RFC1700] for
      details.  An AFI value of 0 used in this specification indicates
      an unspecified encoded address where the length of the address is
      0 bytes following the 16-bit AFI value of 0.

   Negative Mapping Entry:   A negative mapping entry, also known as a
      negative cache entry, is an EID-to-RLOC entry where an EID-prefix
      is advertised or stored with no RLOCs.  That is, the locator-set
      for the EID-to-RLOC entry is empty or has an encoded locator count
      of 0.  This type of entry could be used to describe a prefix from
      a non-LISP site, which is explicitly not in the mapping database.
      There are a set of well defined actions that are encoded in a
      Negative Map-Reply.

   Data Probe:   A data-probe is a LISP-encapsulated data packet where
      the inner header destination address equals the outer header
      destination address used to trigger a Map-Reply by a decapsulating
      ETR.  In addition, the original packet is decapsulated and
      delivered to the destination host. host if the destination EID is in the
      EID-prefix range configured on the ETR.  Otherwise, the packet is
      discarded.  A Data Probe is used in some of the mapping database
      designs to "probe" or request a Map-Reply from an ETR; in other
      cases, Map-Requests are used.  See each mapping database design
      for details.

   Proxy ITR (PITR):   A PITR is also known as a PTR is defined and
      described in [INTERWORK], a PITR acts like an ITR but does so on
      behalf of non-LISP sites which send packets to destinations at
      LISP sites.

   Proxy ETR (PETR):   A PETR is defined and described in [INTERWORK], a
      PETR acts like an ETR but does so on behalf of LISP sites which
      send packets to destinations at non-LISP sites.

   Route-returnability:  is an assumption that the underlying routing
      system will deliver packets to the destination.  When combined
      with a nonce that is provided by a sender and returned by a
      receiver limits off-path data insertion.

   LISP site:  is a set of routers in an edge network that are under a
      single technical administration.  LISP routers which reside in the
      edge network are the demarcation points to separate the edge
      network from the core network.

   Client-side:  a term used in this document to indicate a connection
      initiation attempt by an EID.  The ITR(s) at the LISP site are the
      first to get involved in obtaining database map cache entries by
      sending Map-Request messages.

   Server-side:  a term used in this document to indicate a connection
      initiation attempt is being accepted for a destination EID.  The
      ETR(s) at the destination LISP site are the first to send Map-
      Replies to the source site initiating the connection.  The ETR(s)
      at this destination site can obtain mappings by gleaning
      information from Map-Requests, Data-Probes, or encapsulated
      packets.

   Locator-Status-Bits (LSBs):  Locator status bits are present in the
      LISP header.  They are used by ITRs to inform ETRs about the up/
      down status of all ETRs at the local site.  These bits are used as
      a hint to convey up/down router status and not path reachability
      status.  The LSBs can be verified by use of one of the Locator
      Reachability Algoriths described in Section 6.3.

4.  Basic Overview

   One key concept of LISP is that end-systems (hosts) operate the same
   way they do today.  The IP addresses that hosts use for tracking
   sockets, connections, and for sending and receiving packets do not
   change.  In LISP terminology, these IP addresses are called Endpoint
   Identifiers (EIDs).

   Routers continue to forward packets based on IP destination
   addresses.  When a packet is LISP encapsulated, these addresses are
   referred to as Routing Locators (RLOCs).  Most routers along a path
   between two hosts will not change; they continue to perform routing/
   forwarding lookups on the destination addresses.  For routers between
   the source host and the ITR as well as routers from the ETR to the
   destination host, the destination address is an EID.  For the routers
   between the ITR and the ETR, the destination address is an RLOC.

   Another key LISP concept is the "Tunnel Router".  A tunnel router
   prepends LISP headers on host-originated packets and strip them prior
   to final delivery to their destination.  The IP addresses in this
   "outer header" are RLOCs.  During end-to-end packet exchange between
   two Internet hosts, an ITR prepends a new LISP header to each packet
   and an egress tunnel router strips the new header.  The ITR performs
   EID-to-RLOC lookups to determine the routing path to the ETR, which
   has the RLOC as one of its IP addresses.

   Some basic rules governing LISP are:

   o  End-systems (hosts) only send to addresses which are EIDs.  They
      don't know addresses are EIDs versus RLOCs but assume packets get
      to LISP routers, which in turn, deliver packets to the destination
      the end-system has specified.

   o  EIDs are always IP addresses assigned to hosts.

   o  LISP routers mostly deal with Routing Locator addresses.  See
      details later in Section 4.1 to clarify what is meant by "mostly".

   o  RLOCs are always IP addresses assigned to routers; preferably,
      topologically-oriented addresses from provider CIDR blocks.

   o  When a router originates packets it may use as a source address
      either an EID or RLOC.  When acting as a host (e.g. when
      terminating a transport session such as SSH, TELNET, or SNMP), it
      may use an EID that is explicitly assigned for that purpose.  An
      EID that identifies the router as a host MUST NOT be used as an
      RLOC; an EID is only routable within the scope of a site.  A
      typical BGP configuration might demonstrate this "hybrid" EID/RLOC
      usage where a router could use its "host-like" EID to terminate
      iBGP sessions to other routers in a site while at the same time
      using RLOCs to terminate eBGP sessions to routers outside the
      site.

   o  EIDs are not expected to be usable for global end-to-end
      communication in the absence of an EID-to-RLOC mapping operation.
      They are expected to be used locally for intra-site communication.

   o  EID prefixes are likely to be hierarchically assigned in a manner
      which is optimized for administrative convenience and to
      facilitate scaling of the EID-to-RLOC mapping database.  The
      hierarchy is based on a address allocation hierarchy which is
      independent of the network topology.

   o  EIDs may also be structured (subnetted) in a manner suitable for
      local routing within an autonomous system.

   An additional LISP header may be prepended to packets by a TE-ITR
   when re-routing of the path for a packet is desired.  A potential
   use-case for this would be an ISP router that needs to perform
   traffic engineering for packets flowing through its network.  In such
   a situation, termed Recursive Tunneling, an ISP transit acts as an
   additional ingress tunnel router and the RLOC it uses for the new
   prepended header would be either a TE-ETR within the ISP (along
   intra-ISP traffic engineered path) or a TE-ETR within another ISP (an
   inter-ISP traffic engineered path, where an agreement to build such a
   path exists).

   In order to avoid excessive packet overhead as well as possible
   encapsulation loops, this document mandates that a maximum of two
   LISP headers can be prepended to a packet.  For initial LISP
   deployments, it is assumed two headers is sufficient, where the first
   prepended header is used at a site for Location/Identity separation
   and second prepended header is used inside a service provider for
   Traffic Engineering purposes.

   Tunnel Routers can be placed fairly flexibly in a multi-AS topology.
   For example, the ITR for a particular end-to-end packet exchange
   might be the first-hop or default router within a site for the source
   host.  Similarly, the egress tunnel router might be the last-hop
   router directly-connected to the destination host.  Another example,
   perhaps for a VPN service out-sourced to an ISP by a site, the ITR
   could be the site's border router at the service provider attachment
   point.  Mixing and matching of site-operated, ISP-operated, and other
   tunnel routers is allowed for maximum flexibility.  See Section 8 for
   more details.

4.1.  Packet Flow Sequence

   This section provides an example of the unicast packet flow with the
   following conditions:

   o  Source host "host1.abc.com" is sending a packet to
      "host2.xyz.com", exactly what host1 would do if the site was not
      using LISP.

   o  Each site is multi-homed, so each tunnel router has an address
      (RLOC) assigned from the service provider address block for each
      provider to which that particular tunnel router is attached.

   o  The ITR(s) and ETR(s) are directly connected to the source and
      destination, respectively, but the source and destination can be
      located anywhere in LISP site.

   o  Map-Requests can be sent on the underlying routing system topology
      or over an alternative topology [ALT].

   o  Map-Replies are sent on the underlying routing system topology.

   Client host1.abc.com wants to communicate with server host2.xyz.com:

   1.  host1.abc.com wants to open a TCP connection to host2.xyz.com.
       It does a DNS lookup on host2.xyz.com.  An A/AAAA record is
       returned.  This address is the destination EID.  The locally-
       assigned address of host1.abc.com is used as the source EID.  An
       IPv4 or IPv6 packet is built and forwarded through the LISP site
       as a normal IP packet until it reaches a LISP ITR.

   2.  The LISP ITR must be able to map the EID destination to an RLOC
       of one of the ETRs at the destination site.  The specific method
       used to do this is not described in this example.  See [ALT] or
       [CONS] for possible solutions.

   3.  The ITR will send a LISP Map-Request.  Map-Requests SHOULD be
       rate-limited.

   4.  When an alternate mapping system is not in use, the Map-Request
       packet is routed through the underlying routing system.
       Otherwise, the Map-Request packet is routed on an alternate
       logical topology.  In either case, when the Map-Request arrives
       at one of the ETRs at the destination site, it will process the
       packet as a control message.

   5.  The ETR looks at the destination EID of the Map-Request and
       matches it against the prefixes in the ETR's configured EID-to-
       RLOC mapping database.  This is the list of EID-prefixes the ETR
       is supporting for the site it resides in.  If there is no match,
       the Map-Request is dropped.  Otherwise, a LISP Map-Reply is
       returned to the ITR.

   6.  The ITR receives the Map-Reply message, parses the message (to
       check for format validity) and stores the mapping information
       from the packet.  This information is stored in the ITR's EID-to-
       RLOC mapping cache.  Note that the map cache is an on-demand
       cache.  An ITR will manage its map cache in such a way that
       optimizes for its resource constraints.

   7.  Subsequent packets from host1.abc.com to host2.xyz.com will have
       a LISP header prepended by the ITR using the appropriate RLOC as
       the LISP header destination address learned from the ETR.  Note
       the packet may be sent to a different ETR than the one which
       returned the Map-Reply due to the source site's hashing policy or
       the destination site's locator-set policy.

   8.  The ETR receives these packets directly (since the destination
       address is one of its assigned IP addresses), strips the LISP
       header and forwards the packets to the attached destination host.

   In order to defer the need for a mapping lookup in the reverse
   direction, an ETR MAY create a cache entry that maps the source EID
   (inner header source IP address) to the source RLOC (outer header
   source IP address) in a received LISP packet.  Such a cache entry is
   termed a "gleaned" mapping and only contains a single RLOC for the
   EID in question.  More complete information about additional RLOCs
   SHOULD be verified by sending a LISP Map-Request for that EID.  Both
   ITR and the ETR may also influence the decision the other makes in
   selecting an RLOC.  See Section 6 for more details.

5.  LISP Encapsulation Details

   Since additional tunnel headers are prepended, the packet becomes
   larger and can exceed the MTU of any link traversed from the ITR to
   the ETR.  It is recommended in IPv4 that packets do not get
   fragmented as they are encapsulated by the ITR.  Instead, the packet
   is dropped and an ICMP Too Big message is returned to the source.

   This specification recommends that implementations support for one of
   the proposed fragmentation and reassembly schemes.  These two
   existing schemes are detailed in Section 5.4.

   Since IPv4 or IPv6 addresses can be either EIDs or RLOCs, the LISP
   architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner
   header is in IPv4 packet format and the other header is in IPv6
   packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header
   is in IPv6 packet format and the other header is in IPv4 packet
   format).  The next sub-sections illustrate packet formats for the
   homogenous case (IPv4-in-IPv4 and IPv6-in-IPv6) but all 4
   combinations SHOULD be supported.

5.1.  LISP IPv4-in-IPv4 Header Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version|  IHL  |Type of Service|          Total Length         |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |         Identification        |Flags|      Fragment Offset    |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   OH  |  Time to Live | Protocol = 17 |         Header Checksum       |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                    Source Routing Locator                     |
    \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                 Destination Routing Locator                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4341        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L   |N|L|E|V|I|flags|            Nonce/Map-Version                  |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                 Instance ID/Locator Status Bits               |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version|  IHL  |Type of Service|          Total Length         |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |         Identification        |Flags|      Fragment Offset    |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   IH  |  Time to Live |    Protocol   |         Header Checksum       |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                           Source EID                          |
    \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                         Destination EID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2.  LISP IPv6-in-IPv6 Header Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version| Traffic Class |           Flow Label                  |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |   |         Payload Length        | Next Header=17|   Hop Limit   |
   v   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
   O   +                                                               +
   u   |                                                               |
   t   +                     Source Routing Locator                    +
   e   |                                                               |
   r   +                                                               +
       |                                                               |
   H   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   d   |                                                               |
   r   +                                                               +
       |                                                               |
   ^   +                  Destination Routing Locator                  +
   |   |                                                               |
    \  +                                                               +
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4341        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L   |N|L|E|V|I|flags|            Nonce/Map-Version                  |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                 Instance ID/Locator Status Bits               |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version| Traffic Class |           Flow Label                  |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /   |         Payload Length        |  Next Header  |   Hop Limit   |
   v   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
   I   +                                                               +
   n   |                                                               |
   n   +                          Source EID                           +
   e   |                                                               |
   r   +                                                               +
       |                                                               |
   H   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   d   |                                                               |
   r   +                                                               +
       |                                                               |
   ^   +                        Destination EID                        +
   \   |                                                               |
    \  +                                                               +
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.3.  Tunnel Header Field Descriptions

   Inner Header:  The inner header is the header on the datagram
      received from the originating host.  The source and destination IP
      addresses are EIDs.

   Outer Header:  The outer header is a new header prepended by an ITR.
      The address fields contain RLOCs obtained from the ingress
      router's EID-to-RLOC cache.  The IP protocol number is "UDP (17)"
      from [RFC0768].  The DF bit of the Flags field is set to 0 when
      the method in Section 5.4.1 is used and set to 1 when the method
      in Section 5.4.2 is used.

   UDP Header:  The UDP header contains a ITR selected source port when
      encapsulating a packet.  See Section 6.5 for details on the hash
      algorithm used to select a source port based on the 5-tuple of the
      inner header.  The destination port MUST be set to the well-known
      IANA assigned port value 4341.

   UDP Checksum:  The UDP checksum field SHOULD be transmitted as zero
      by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation
      [UDP-TUNNELS].  When a packet with a zero UDP checksum is received
      by an ETR, the ETR MUST accept the packet for decapsulation.  When
      an ITR transmits a non-zero value for the UDP checksum, it MUST
      send a correctly computed value in this field.  When an ETR
      receives a packet with a non-zero UDP checksum, it MAY choose to
      verify the checksum value.  If it chooses to perform such
      verification, and the verification fails, the packet MUST be
      silently dropped.  If the ETR chooses not to perform the
      verification, or performs the verification successfully, the
      packet MUST be accepted for decapsulation.  The handling of UDP
      checksums for all tunneling protocols, including LISP, is under
      active discussion within the IETF.  When that discussion
      concludes, any necessary changes will be made to align LISP with
      the outcome of the broader discussion.

   UDP Length:  The UDP length field is for an IPv4 encapsulated packet,
      the inner header Total Length plus the UDP and LISP header lengths
      are used.  For an IPv6 encapsulated packet, the inner header
      Payload Length plus the size of the IPv6 header (40 bytes) plus
      the size of the UDP and LISP headers are used.  The UDP header
      length is 8 bytes.

   N: The N bit is the nonce-present bit.  When this bit is set to 1,
      the low-order 24-bits of the first 32-bits of the LISP header
      contains a Nonce.  See Section 6.3.1 for details.  Both N and V
      bits MUST NOT be set in the same packet.  If they are, a
      decapsulating ETR MUST treat the "Nonce/Map-Version" field as
      having a Nonce value present.

   L: The L bit is the Locator-Status-Bits field enabled bit.  When this
      bit is set to 1, the Locator-Status-Bits in the second 32-bits of
      the LISP header are in use.

     x 1 x x 0 x x x
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|flags|            Nonce/Map-Version                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Locator Status Bits                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   E: The E bit is the echo-nonce-request bit.  When this bit is set to
      1, the N bit MUST be 1.  This bit SHOULD be ignored and has no
      meaning when the N bit is set to 0.  See Section 6.3.1 for
      details.

   V: The V bit is the Map-Version present bit.  When this bit is set to
      1, the N bit MUST be 0.  Refer to Section 6.6.3 for more details.
      This bit indicates that the first 4 bytes of the LISP header is
      encoded as:

     0 x 0 1 x x x x
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|flags|  Source Map-Version   |   Dest Map-Version    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Instance ID/Locator Status Bits               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   I: The I bit is the Instance ID bit.  See Section 5.5 for more
      details.  When this bit is set to 1, the Locator Status Bits field
      is reduced to 8-bits and the high-order 24-bits are used as an
      Instance ID.  If the L-bit is set to 0, then the low-order 8 bits
      are transmitted as zero and ignored on receipt.  The format of the
      last 4 bytes of the LISP header would look like:

     x x x x 1 x x x
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|flags|            Nonce/Map-Version                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Instance ID                   |     LSBs      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   flags:  The flags field is a 3-bit field is reserved for future flag
      use.  It MUST be set to 0 on transmit and MUST be ignored on
      receipt.

   LISP Nonce:  The LISP nonce field is a 24-bit value that is randomly
      generated by an ITR when the N-bit is set to 1.  The nonce is also
      used when the E-bit is set to request the nonce value to be echoed
      by the other side when packets are returned.  When the E-bit is
      clear but the N-bit is set, a remote ITR is either echoing a
      previously requested echo-nonce or providing a random nonce.  See
      Section 6.3.1 for more details.

   LISP Locator Status Bits:  The locator status bits field in the LISP
      header is set by an ITR to indicate to an ETR the up/down status
      of the Locators in the source site.  Each RLOC in a Map-Reply is
      assigned an ordinal value from 0 to n-1 (when there are n RLOCs in
      a mapping entry).  The Locator Status Bits are numbered from 0 to
      n-1 from the least significant bit of field.  The field is 32-bits
      when the I-bit is set to 0 and is 8 bits when the I-bit is set to
      1.  When a Locator Status Bit is set to 1, the ITR is indicating
      to the ETR the RLOC associated with the bit ordinal has up status.
      See Section 6.3 for details on how an ITR can determine the status
      of the ETRs at the same site.  When a site has multiple EID-
      prefixes which result in multiple mappings (where each could have
      a different locator-set), the Locator Status Bits setting in an
      encapsulated packet MUST reflect the mapping for the EID-prefix
      that the inner-header source EID address matches.  If the LSB for
      an anycast locator is set to 1, then there is at least one RLOC
      with that address the ETR is considered 'up'.

   When doing ITR/PITR encapsulation:

   o  The outer header Time to Live field (or Hop Limit field, in case
      of IPv6) SHOULD be copied from the inner header Time to Live
      field.

   o  The outer header Type of Service field (or the Traffic Class
      field, in the case of IPv6) SHOULD be copied from the inner header
      Type of Service field (with one caveat, see below).

   When doing ETR/PETR decapsulation:

   o  The inner header Time to Live field (or Hop Limit field, in case
      of IPv6) SHOULD be copied from the outer header Time to Live
      field, when the Time to Live field of the outer header is less
      than the Time to Live of the inner header.  Failing to perform
      this check can cause the Time to Live of the inner header to
      increment across encapsulation/decapsulation cycle.  This check is
      also performed when doing initial encapsulation when a packet
      comes to an ITR or PITR destined for a LISP site.

   o  The inner header Type of Service field (or the Traffic Class
      field, in the case of IPv6) SHOULD be copied from the outer header
      Type of Service field (with one caveat, see below).

   Note if an ETR/PETR is also an ITR/PITR and choose to reencapsulate
   after decapsulating, the net effect of this is that the new outer
   header will carry the same Time to Live as the old outer header.

   Copying the TTL serves two purposes: first, it preserves the distance
   the host intended the packet to travel; second, and more importantly,
   it provides for suppression of looping packets in the event there is
   a loop of concatenated tunnels due to misconfiguration.  See
   Section 9.3 for TTL exception handling for traceroute packets.

   The ECN field occupies bits 6 and 7 of both the IPv4 Type of Service
   field and the IPv6 Traffic Class field [RFC3168].  The ECN field
   requires special treatment in order to avoid discarding indications
   of congestion [RFC3168].  ITR encapsulation MUST copy the 2-bit ECN
   field from the inner header to the outer header.  Re-encapsulation
   MUST copy the 2-bit ECN field from the stripped outer header to the
   new outer header.  If the ECN field contains a congestion indication
   codepoint (the value is '11', the Congestion Experienced (CE)
   codepoint), then ETR decapsulation MUST copy the 2-bit ECN field from
   the stripped outer header to the surviving inner header that is used
   to forward the packet beyond the ETR.  These requirements preserve
   Congestion Experienced (CE) indications when a packet that uses ECN
   traverses a LISP tunnel and becomes marked with a CE indication due
   to congestion between the tunnel endpoints.

5.4.  Dealing with Large Encapsulated Packets

   This section proposes two mechanisms to deal with packets that exceed
   the path MTU between the ITR and ETR.

   It is left to the implementor to decide if the stateless or stateful
   mechanism should be implemented.  Both or neither can be used since
   it is a local decision in the ITR regarding how to deal with MTU
   issues, and sites can interoperate with differing mechanisms.

   Both stateless and stateful mechanisms also apply to Reencapsulating
   and Recursive Tunneling.  So any actions below referring to an ITR
   also apply to an TE-ITR.

5.4.1.  A Stateless Solution to MTU Handling

   An ITR stateless solution to handle MTU issues is described as
   follows:

   1.  Define an architectural constant S for the maximum size of a
       packet, in bytes, an ITR would like to receive from a source
       inside of its site.

   2.  Define L to be the maximum size, in bytes, a packet of size S
       would be after the ITR prepends the LISP header, UDP header, and
       outer network layer header of size H.

   3.  Calculate: S + H = L.

   When an ITR receives a packet from a site-facing interface and adds H
   bytes worth of encapsulation to yield a packet size greater than L
   bytes, it resolves the MTU issue by first splitting the original
   packet into 2 equal-sized fragments.  A LISP header is then prepended
   to each fragment.  The size of the encapsulated fragments is then
   (S/2 + H), which is less than the ITR's estimate of the path MTU
   between the ITR and its correspondent ETR.

   When an ETR receives encapsulated fragments, it treats them as two
   individually encapsulated packets.  It strips the LISP headers then
   forwards each fragment to the destination host of the destination
   site.  The two fragments are reassembled at the destination host into
   the single IP datagram that was originated by the source host.

   This behavior is performed by the ITR when the source host originates
   a packet with the DF field of the IP header is set to 0.  When the DF
   field of the IP header is set to 1, or the packet is an IPv6 packet
   originated by the source host, the ITR will drop the packet when the
   size is greater than L, and sends an ICMP Too Big message to the
   source with a value of S, where S is (L - H).

   When the outer header encapsulation uses an IPv4 header, an
   implementation SHOULD set the DF bit to 1 so ETR fragment reassembly
   can be avoided.  An implementation MAY set the DF bit in such headers
   to 0 if it has good reason to believe there are unresolvable path MTU
   issues between the sending ITR and the receiving ETR.

   This specification recommends that L be defined as 1500.

5.4.2.  A Stateful Solution to MTU Handling

   An ITR stateful solution to handle MTU issues is described as follows
   and was first introduced in [OPENLISP]:

   1.  The ITR will keep state of the effective MTU for each locator per
       mapping cache entry.  The effective MTU is what the core network
       can deliver along the path between ITR and ETR.

   2.  When an IPv6 encapsulated packet or an IPv4 encapsulated packet
       with DF bit set to 1, exceeds what the core network can deliver,
       one of the intermediate routers on the path will send an ICMP Too
       Big message to the ITR.  The ITR will parse the ICMP message to
       determine which locator is affected by the effective MTU change
       and then record the new effective MTU value in the mapping cache
       entry.

   3.  When a packet is received by the ITR from a source inside of the
       site and the size of the packet is greater than the effective MTU
       stored with the mapping cache entry associated with the
       destination EID the packet is for, the ITR will send an ICMP Too
       Big message back to the source.  The packet size advertised by
       the ITR in the ICMP Too Big message is the effective MTU minus
       the LISP encapsulation length.

   Even though this mechanism is stateful, it has advantages over the
   stateless IP fragmentation mechanism, by not involving the
   destination host with reassembly of ITR fragmented packets.

5.5.  Using Virtualization and Segmentation with LISP

   When multiple organizations inside of a LISP site are using private
   addresses [RFC1918] as EID-prefixes, their address spaces MUST remain
   segregated due to possible address duplication.  An Instance ID in
   the address encoding can aid in making the entire AFI based address
   unique.  See IANA Considerations Section 14.1 for details for
   possible address encodings.

   An Instance ID can be carried in a LISP encapsulated packet.  An ITR
   that prepends a LISP header, will copy a 24-bit value, used by the
   LISP router to uniquely identify the address space.  The value is
   copied to the Instance ID field of the LISP header and the I-bit is
   set to 1.

   When an ETR decapsulates a packet, the Instance ID from the LISP
   header is used as a table identifier to locate the forwarding table
   to use for the inner destination EID lookup.

   For example, a 802.1Q VLAN tag or VPN identifier could be used as a
   24-bit Instance ID.

6.  EID-to-RLOC Mapping

6.1.  LISP IPv4 and IPv6 Control Plane Packet Formats

   The following UDP packet formats are used by the LISP control-plane.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Version|  IHL  |Type of Service|          Total Length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Identification        |Flags|      Fragment Offset    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Time to Live | Protocol = 17 |         Header Checksum       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Source Routing Locator                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Destination Routing Locator                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |           Source Port         |         Dest Port             |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                         LISP Message                          |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Version| Traffic Class |           Flow Label                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Payload Length        | Next Header=17|   Hop Limit   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                     Source Routing Locator                    +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                  Destination Routing Locator                  +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |           Source Port         |         Dest Port             |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                         LISP Message                          |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The LISP UDP-based messages are the Map-Request and Map-Reply
   messages.  When a UDP Map-Request is sent, the UDP source port is
   chosen by the sender and the destination UDP port number is set to
   4342.  When a UDP Map-Reply is sent, the source UDP port number is
   set to 4342 and the destination UDP port number is copied from the
   source port of either the Map-Request or the invoking data packet.
   Implementations MUST be prepared to accept packets when either the
   source port or destination UDP port is set to 4342 due to NATs
   changing port number values.

   The UDP Length field will reflect the length of the UDP header and
   the LISP Message payload.

   The UDP Checksum is computed and set to non-zero for Map-Request,
   Map-Reply, Map-Register and ECM control messages.  It MUST be checked
   on receipt and if the checksum fails, the packet MUST be dropped.

   LISP-CONS [CONS] uses TCP to send LISP control messages.  The format
   of control messages includes the UDP header so the checksum and
   length fields can be used to protect and delimit message boundaries.

   This main LISP specification is the authoritative source for message
   format definitions for the Map-Request and Map-Reply messages.

6.1.1.  LISP Packet Type Allocations

   This section will be the authoritative source for allocating LISP
   Type values.  Current allocations are:

       Reserved:                          0    b'0000'
       LISP Map-Request:                  1    b'0001'
       LISP Map-Reply:                    2    b'0010'
       LISP Map-Register:                 3    b'0011'
       LISP Map-Notify:                   4    b'0100'
       LISP Encapsulated Control Message: 8    b'1000'

6.1.2.  Map-Request Message Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=1 |A|M|P|S|p|s|    Reserved     |   IRC   | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Source-EID-AFI        |   Source EID Address  ...     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         ITR-RLOC-AFI 1        |    ITR-RLOC Address 1  ...    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         ITR-RLOC-AFI n        |    ITR-RLOC Address n  ...    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |   Reserved    | EID mask-len  |        EID-prefix-AFI         |
   Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                       EID-prefix  ...                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Map-Reply Record  ...                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Mapping Protocol Data                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet field descriptions:

   Type:   1 (Map-Request)

   A: This is an authoritative bit, which is set to 0 for UDP-based Map-
      Requests sent by an ITR.

   M: When set, it indicates a Map-Reply Record segment is included in
      the Map-Request.

   P: This is the probe-bit which indicates that a Map-Request SHOULD be
      treated as a locator reachability probe.  The receiver SHOULD
      respond with a Map-Reply with the probe-bit set, indicating the
      Map-Reply is a locator reachability probe reply, with the nonce
      copied from the Map-Request.  See Section 6.3.2 for more details.

   S: This is the SMR bit.  See Section 6.6.2 for details.

   p: This is the PITR bit.  This bit is set to 1 when a PITR sends a
      Map-Request.

   s: This is the SMR-invoked bit.  This bit is set to 1 when an xTR is
      sending a Map-Request in response to a received SMR-based Map-
      Request.

   Reserved:  It MUST be set to 0 on transmit and MUST be ignored on
      receipt.

   IRC:  This 5-bit field is the ITR-RLOC Count which encodes the
      additional number of (ITR-RLOC-AFI, ITR-RLOC Address) fields
      present in this message.  At least one (ITR-RLOC-AFI, ITR-RLOC-
      Address) pair must always be encoded.  Multiple ITR-RLOC Address
      fields are used so a Map-Replier can select which destination
      address to use for a Map-Reply.  The IRC value ranges from 0 to
      31, and for a value of 1, there are 2 ITR-RLOC addresses encoded
      and so on up to 31 which encodes a total of 32 ITR-RLOC addresses.

   Record Count:  The number of records in this Map-Request message.  A
      record is comprised of the portion of the packet that is labeled
      'Rec' above and occurs the number of times equal to Record Count.
      For this version of the protocol, a receiver MUST accept and
      process Map-Requests that contain one or more records, but a
      sender MUST only send Map-Requests containing one record.  Support
      for requesting multiple EIDs in a single Map-Request message will
      be specified in a future version of the protocol.

   Nonce:  An 8-byte random value created by the sender of the Map-
      Request.  This nonce will be returned in the Map-Reply.  The
      security of the LISP mapping protocol depends critically on the
      strength of the nonce in the Map-Request message.  The nonce
      SHOULD be generated by a properly seeded pseudo-random (or strong
      random) source.  See [RFC4086] for advice on generating security-
      sensitive random data.

   Source-EID-AFI:  Address family of the "Source EID Address" field.

   Source EID Address:  This is the EID of the source host which
      originated the packet which is invoking this Map-Request.  When
      Map-Requests are used for refreshing a map-cache entry or for
      RLOC-probing, an AFI value 0 is used and this field is of zero
      length.

   ITR-RLOC-AFI:  Address family of the "ITR-RLOC Address" field that
      follows this field.

   ITR-RLOC Address:  Used to give the ETR the option of selecting the
      destination address from any address family for the Map-Reply
      message.  This address MUST be a routable RLOC address of the
      sender of the Map-Request message.

   EID mask-len:  Mask length for EID prefix.

   EID-prefix-AFI:  Address family of EID-prefix according to [AFI]

   EID-prefix:  4 bytes if an IPv4 address-family, 16 bytes if an IPv6
      address-family.  When a Map-Request is sent by an ITR because a
      data packet is received for a destination where there is no
      mapping entry, the EID-prefix is set to the destination IP address
      of the data packet.  And the 'EID mask-len' is set to 32 or 128
      for IPv4 or IPv6, respectively.  When an xTR wants to query a site
      about the status of a mapping it already has cached, the EID-
      prefix used in the Map-Request has the same mask-length as the
      EID-prefix returned from the site when it sent a Map-Reply
      message.

   Map-Reply Record:  When the M bit is set, this field is the size of a
      single "Record" in the Map-Reply format.  This Map-Reply record
      contains the EID-to-RLOC mapping entry associated with the Source
      EID.  This allows the ETR which will receive this Map-Request to
      cache the data if it chooses to do so.

   Mapping Protocol Data:  See [CONS] for details.  This field is
      optional and present when the UDP length indicates there is enough
      space in the packet to include it.

6.1.3.  EID-to-RLOC UDP Map-Request Message

   A Map-Request is sent from an ITR when it needs a mapping for an EID,
   wants to test an RLOC for reachability, or wants to refresh a mapping
   before TTL expiration.  For the initial case, the destination IP
   address used for the Map-Request is the destination-EID from the
   packet which had a mapping cache lookup failure.  For the latter 2
   cases, the destination IP address used for the Map-Request is one of
   the RLOC addresses from the locator-set of the map cache entry.  The
   source address is either an IPv4 or IPv6 RLOC address depending if
   the Map-Request is using an IPv4 versus IPv6 header, respectively.
   In all cases, the UDP source port number for the Map-Request message
   is an ITR/PITR selected 16-bit value and the UDP destination port
   number is set to the well-known destination port number 4342.  A
   successful Map-Reply updates the cached set of RLOCs associated with
   the EID prefix range.

   One or more Map-Request (ITR-RLOC-AFI, ITR-RLOC-Address) fields MUST
   be filled in by the ITR.  The number of fields (minus 1) encoded MUST
   be placed in the IRC field.  The ITR MAY include all locally
   configured locators in this list or just provide one locator address
   from each address family it supports.  If the ITR erroneously
   provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map-
   Request.

   Map-Requests can also be LISP encapsulated using UDP destination port
   4342 with a LISP type value set to "Encapsulated Control Message",
   when sent from an ITR to a Map-Resolver.  Likewise, Map-Requests are
   LISP encapsulated the same way from a Map-Server to an ETR.  Details
   on encapsulated Map-Requests and Map-Resolvers can be found in
   [LISP-MS].

   Map-Requests MUST be rate-limited.  It is recommended that a Map-
   Request for the same EID-prefix be sent no more than once per second.

   An ITR that is configured with mapping database information (i.e. it
   is also an ETR) may optionally include those mappings in a Map-
   Request.  When an ETR configured to accept and verify such
   "piggybacked" mapping data receives such a Map-Request and it does
   not have this mapping in the map-cache, it may originate a "verifying
   Map-Request", addressed to the map-requesting ITR.  If the ETR has a
   map-cache entry that matches the "piggybacked" EID and the RLOC is in
   the locator-set for the entry, then it may send the "verifying Map-
   Request" directly to the originating Map-Request source.  If the RLOC
   is not in the locator-set, then the ETR MUST send the "verifying Map-
   Request" to the "piggybacked" EID.  Doing this forces the "verifying
   Map-Request" to go through the mapping database system to reach the
   authoritative source of information about that EID, guarding against
   RLOC-spoofing in in the "piggybacked" mapping data.

6.1.4.  Map-Reply Message Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=2 |P|E|S|          Reserved               | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   | Rsvd  |  Map-Version Number   |       EID-prefix-AFI          |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |        Unused Flags     |L|p|R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Mapping Protocol Data                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet field descriptions:

   Type:   2 (Map-Reply)

   P: This is the probe-bit which indicates that the Map-Reply is in
      response to a locator reachability probe Map-Request.  The nonce
      field MUST contain a copy of the nonce value from the original
      Map-Request.  See Section 6.3.2 for more details.

   E: Indicates that the ETR which sends this Map-Reply message is
      advertising that the site is enabled for the Echo-Nonce locator
      reachability algorithm.  See Section 6.3.1 for more details.

   S: This is the Security bit.  When set to 1 the field following the
      Mapping Protocol Data field will have the following format.  The
      detailed format of the Authentication Data Content is for further
      study.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    AD Type    |       Authentication Data Content . . .       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reserved:  It MUST be set to 0 on transmit and MUST be ignored on
      receipt.

   Record Count:  The number of records in this reply message.  A record
      is comprised of that portion of the packet labeled 'Record' above
      and occurs the number of times equal to Record count.

   Nonce:  A 24-bit value set in a Data-Probe packet or a 64-bit value
      from the Map-Request is echoed in this Nonce field of the Map-
      Reply.

   Record TTL:  The time in minutes the recipient of the Map-Reply will
      store the mapping.  If the TTL is 0, the entry SHOULD be removed
      from the cache immediately.  If the value is 0xffffffff, the
      recipient can decide locally how long to store the mapping.

   Locator Count:  The number of Locator entries.  A locator entry
      comprises what is labeled above as 'Loc'.  The locator count can
      be 0 indicating there are no locators for the EID-prefix.

   EID mask-len:  Mask length for EID prefix.

   ACT:  This 3-bit field describes negative Map-Reply actions.  These
      bits are used only when the 'Locator Count' field is set to 0.
      The action bits are encoded only in Map-Reply messages.  The
      actions defined are used by an ITR or PTR when a destination EID
      matches a negative mapping cache entry.  Unassigned values should
      cause a map-cache entry to be created and, when packets match this
      negative cache entry, they will be dropped.  The current assigned
      values are:

      (0) No-Action:  The map-cache is kept alive and no packet
         encapsulation occurs.

      (1) Natively-Forward:  The packet is not encapsulated or dropped
         but natively forwarded.

      (2) Send-Map-Request:  The packet invokes sending a Map-Request.

      (3) Drop:  A packet that matches this map-cache entry is dropped.
         An ICMP Unreachable message SHOULD be sent.

   A: The Authoritative bit, when sent by a UDP-based message is always
      set to 1 by an ETR.  See [CONS] for TCP-based Map-Replies.  When a
      Map-Server is proxy Map-Replying [LISP-MS] for a LISP site, the
      Authoritative bit is set to 0.  This indicates to requesting ITRs
      that the Map-Reply was not originated by a LISP node managed at
      the site that owns the EID-prefix.

   Map-Version Number:  When this 12-bit value is non-zero the Map-Reply
      sender is informing the ITR what the version number is for the
      EID-record contained in the Map-Reply.  The ETR can allocate this
      number internally but MUST coordinate this value with other ETRs
      for the site.  When this value is 0, there is no versioning
      information conveyed.  The Map-Version Number can be included in
      Map-Request and Map-Register messages.  See Section 6.6.3 for more
      details.

   EID-prefix-AFI:  Address family of EID-prefix according to [AFI].

   EID-prefix:  4 bytes if an IPv4 address-family, 16 bytes if an IPv6
      address-family.

   Priority:  each RLOC is assigned a unicast priority.  Lower values
      are more preferable.  When multiple RLOCs have the same priority,
      they may be used in a load-split fashion.  A value of 255 means
      the RLOC MUST NOT be used for unicast forwarding.

   Weight:  when priorities are the same for multiple RLOCs, the weight
      indicates how to balance unicast traffic between them.  Weight is
      encoded as a relative weight of total unicast packets that match
      the mapping entry.  For example if there are 4 locators in a
      locator set, where the weights assigned are 30, 20, 20, and 10,
      the first locator will get 37.5% of the traffic, the 2nd and 3rd
      locators will get 25% of traffic and the 4th locator will get
      12.5% of the traffic.  If all weights for a locator-set are equal,
      receiver of the Map-Reply will decide how to load-split traffic.
      See Section 6.5 for a suggested hash algorithm to distribute load
      across locators with same priority and equal weight values.

   M Priority:  each RLOC is assigned a multicast priority used by an
      ETR in a receiver multicast site to select an ITR in a source
      multicast site for building multicast distribution trees.  A value
      of 255 means the RLOC MUST NOT be used for joining a multicast
      distribution tree.

   M Weight:  when priorities are the same for multiple RLOCs, the
      weight indicates how to balance building multicast distribution
      trees across multiple ITRs.  The weight is encoded as a relative
      weight (similar to the unicast Weights) of total number of trees
      built to the source site identified by the EID-prefix.  If all
      weights for a locator-set are equal, the receiver of the Map-Reply
      will decide how to distribute multicast state across ITRs.

   Unused Flags:  set to 0 when sending and ignored on receipt.

   L: when this bit is set, the locator is flagged as a local locator to
      the ETR that is sending the Map-Reply.  When a Map-Server is doing
      proxy Map-Replying [LISP-MS] for a LISP site, the L bit is set to
      0 for all locators in this locator-set.

   p: when this bit is set, an ETR informs the RLOC-probing ITR that the
      locator address, for which this bit is set, is the one being RLOC-
      probed and may be different from the source address of the Map-
      Reply.  An ITR that RLOC-probes a particular locator, MUST use
      this locator for retrieving the data structure used to store the
      fact that the locator is reachable.  The "p" bit is set for a
      single locator in the same locator set.  If an implementation sets
      more than one "p" bit erroneously, the receiver of the Map-Reply
      MUST select the first locator.  The "p" bit MUST NOT be set for
      locator-set records sent in Map-Request and Map-Register messages.

   R: set when the sender of a Map-Reply has a route to the locator in
      the locator data record.  This receiver may find this useful to
      know if the locator is up but not necessarily reachable from the
      receiver's point of view.  See also Section 6.4 for another way
      the R-bit may be used.

   Locator:  an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field)
      assigned to an ETR.  Note that the destination RLOC address MAY be
      an anycast address.  A source RLOC can be an anycast address as
      well.  The source or destination RLOC MUST NOT be the broadcast
      address (255.255.255.255 or any subnet broadcast address known to
      the router), and MUST NOT be a link-local multicast address.  The
      source RLOC MUST NOT be a multicast address.  The destination RLOC
      SHOULD be a multicast address if it is being mapped from a
      multicast destination EID.

   Mapping Protocol Data:  See [CONS] for details.  This field is
      optional and present when the UDP length indicates there is enough
      space in the packet to include it.  The Mapping Protocol Data is
      used when needed by the particular mapping system.

6.1.5.  EID-to-RLOC UDP Map-Reply Message

   A Map-Reply returns an EID-prefix with a prefix length that is less
   than or equal to the EID being requested.  The EID being requested is
   either from the destination field of an IP header of a Data-Probe or
   the EID record of a Map-Request.  The RLOCs in the Map-Reply are
   globally-routable IP addresses of all ETRs for the LISP site.  Each
   RLOC conveys status reachability but does not convey path
   reachability from a requesters perspective.  Separate testing of path
   reachability is required, See Section 6.3 for details.

   Note that a Map-Reply may contain different EID-prefix granularity
   (prefix + length) than the Map-Request which triggers it.  This might
   occur if a Map-Request were for a prefix that had been returned by an
   earlier Map-Reply.  In such a case, the requester updates its cache
   with the new prefix information and granularity.  For example, a
   requester with two cached EID-prefixes that are covered by a Map-
   Reply containing one, less-specific prefix, replaces the entry with
   the less-specific EID-prefix.  Note that the reverse, replacement of
   one less-specific prefix with multiple more-specific prefixes, can
   also occur but not by removing the less-specific prefix rather by
   adding the more-specific prefixes which during a lookup will override
   the less-specific prefix.

   When an ETR is configured with overlapping EID-prefixes, a Map-
   Request with an EID that longest matches any EID-prefix MUST be
   returned in a single Map-Reply message.  For instance, if an ETR had
   database mapping entries for EID-prefixes:

     10.0.0.0/8
     10.1.0.0/16
     10.1.1.0/24
     10.1.2.0/24

   A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record
   count of 1 to be returned with a mapping record EID-prefix of
   10.1.1.0/24.

   A Map-Request for EID 10.1.5.5, would cause a Map-Reply with a record
   count of 3 to be returned with mapping records for EID-prefixes
   10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24.

   Note that not all overlapping EID-prefixes need to be returned, only
   the more specifics (note in the second example above 10.0.0.0/8 was
   not returned for requesting EID 10.1.5.5) entries for the matching
   EID-prefix of the requesting EID.  When more than one EID-prefix is
   returned, all SHOULD use the same Time-to-Live value so they can all
   time out at the same time.  When a more specific EID-prefix is
   received later, its Time-to-Live value in the Map-Reply record can be
   stored even when other less specifics exist.  When a less specific
   EID-prefix is received later, its map-cache expiration time SHOULD be
   set to the minimum expiration time of any more specific EID-prefix in
   the map-cache.  This is done so the integrity of the EID-prefix set
   is wholly maintained so no more-specific entries are removed from the
   map-cache while keeping less-specific entries.

   Map-Replies SHOULD be sent for an EID-prefix no more often than once
   per second to the same requesting router.  For scalability, it is
   expected that aggregation of EID addresses into EID-prefixes will
   allow one Map-Reply to satisfy a mapping for the EID addresses in the
   prefix range thereby reducing the number of Map-Request messages.

   Map-Reply records can have an empty locator-set.  A negative Map-
   Reply is a Map-Reply with an empty locator-set.  Negative Map-Replies
   convey special actions by the sender to the ITR or PTR which have
   solicited the Map-Reply.  There are two primary applications for
   Negative Map-Replies.  The first is for a Map-Resolver to instruct an
   ITR or PTR when a destination is for a LISP site versus a non-LISP
   site.  And the other is to source quench Map-Requests which are sent
   for non-allocated EIDs.

   For each Map-Reply record, the list of locators in a locator-set MUST
   appear in the same order for each ETR that originates a Map-Reply
   message.  The locator-set MUST be sorted in order of ascending IP
   address where an IPv4 locator address is considered numerically 'less
   than' an IPv6 locator address.

   When sending a Map-Reply message, the destination address is copied
   from the one of the ITR-RLOC fields from the Map-Request.  The ETR
   can choose a locator address from one of the address families it
   supports.  For Data-Probes, the destination address of the Map-Reply
   is copied from the source address of the Data-Probe message which is
   invoking the reply.  The source address of the Map-Reply is one of
   the local IP addresses chosen to allow uRPF checks to succeed in the
   upstream service provider.  The destination port of a Map-Reply
   message is copied from the source port of the Map-Request or Data-
   Probe and the source port of the Map-Reply message is set to the
   well-known UDP port 4342.

6.1.5.1.  Traffic Redirection with Coarse EID-Prefixes

   When an ETR is misconfigured or compromised, it could return coarse
   EID-prefixes in Map-Reply messages it sends.  The EID-prefix could
   cover EID-prefixes which are allocated to other sites redirecting
   their traffic to the locators of the compromised site.

   To solve this problem, there are two basic solutions that could be
   used.  The first is to have Map-Servers proxy-map-reply on behalf of
   ETRs so their registered EID-prefixes are the ones returned in Map-
   Replies.  Since the interaction between an ETR and Map-Server is
   secured with shared-keys, it is more difficult for an ETR to
   misbehave.  The second solution is to have ITRs and PTRs cache EID-
   prefixes with mask-lengths that are greater than or equal to a
   configured prefix length.  This limits the damage to a specific width
   of any EID-prefix advertised, but needs to be coordinated with the
   allocation of site prefixes.  These solutions can be used
   independently or at the same time.

   At the time of this writing, other approaches are being considered
   and researched.

6.1.6.  Map-Register Message Format

   The usage details of the Map-Register message can be found in
   specification [LISP-MS].  This section solely defines the message
   format.

   The message is sent in UDP with a destination UDP port of 4342 and a
   randomly selected UDP source port number.

   The Map-Register message format is:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=3 |P|            Reserved               |M| Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Key ID             |  Authentication Data Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                     Authentication Data                       ~
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   | Rsvd  |  Map-Version Number   |        EID-prefix-AFI         |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |        Unused Flags     |L|p|R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet field descriptions:

   Type:   3 (Map-Register)

   P: This is the proxy-map-reply bit, when set to 1 an ETR sends a Map-
      Register message requesting for the Map-Server to proxy Map-Reply.
      The Map-Server will send non-authoritative Map-Replies on behalf
      of the ETR.  Details on this usage will be provided in a future
      version of this draft.

   Reserved:  It MUST be set to 0 on transmit and MUST be ignored on
      receipt.

   M: This is the want-map-notify bit, when set to 1 an ETR is
      requesting for a Map-Notify message to be returned in response to
      sending a Map-Register message.  The Map-Notify message sent by a
      Map-Server is used to an acknowledge receipt of a Map-Register
      message.

   Record Count:  The number of records in this Map-Register message.  A
      record is comprised of that portion of the packet labeled 'Record'
      above and occurs the number of times equal to Record count.

   Nonce:  This 8-byte Nonce field is set to 0 in Map-Register messages.

   Key ID:  A configured ID to find the configured Message
      Authentication Code (MAC) algorithm and key value used for the
      authentication function.

   Authentication Data Length:  The length in bytes of the
      Authentication Data field that follows this field.  The length of
      the Authentication Data field is dependent on the Message
      Authentication Code (MAC) algorithm used.  The length field allows
      a device that doesn't know the MAC algorithm to correctly parse
      the packet.

   Authentication Data:  The message digest used from the output of the
      Message Authentication Code (MAC) algorithm.  The entire Map-
      Register payload is authenticated with this field preset to 0.
      After the MAC is computed, it is placed in this field.
      Implementations of this specification MUST include support for
      HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256 [RFC4634]
      is recommended.

   The definition of the rest of the Map-Register can be found in the
   Map-Reply section.

6.1.7.  Map-Notify Message Format

   The usage details of the Map-Notify message can be found in
   specification [LISP-MS].  This section solely defines the message
   format.

   The message is sent inside a UDP packet with a source UDP port equal
   to 4342 and a destination port equal to the source port from the Map-
   Register message this Map-Notify message is responding to.

   The Map-Notify message format is:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=4 |              Reserved                 | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Key ID             |  Authentication Data Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                     Authentication Data                       ~
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   | Rsvd  |  Map-Version Number   |         EID-prefix-AFI        |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |        Unused Flags     |L|p|R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet field descriptions:

   Type:   4 (Map-Notify)

   The Map-Notify message has the same contents as a Map-Register
   message.  See Map-Register section for field descriptions.

6.1.8.  Encapsulated Control Message Format

   An Encapsulated Control Message is used to encapsulate control
   packets sent between xTRs and the mapping database system described
   in [LISP-MS].

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |                       IPv4 or IPv6 Header                     |
   OH  |                      (uses RLOC addresses)                    |
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4342        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   LH  |Type=8 |S|                  Reserved                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |                       IPv4 or IPv6 Header                     |
   IH  |                  (uses RLOC or EID addresses)                 |
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = yyyy        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   LCM |                      LISP Control Message                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet header descriptions:

   OH:   The outer IPv4 or IPv6 header which uses RLOC addresses in the
      source and destination header address fields.

   UDP:   The outer UDP header with destination port 4342.  The source
      port is randomly allocated.  The checksum field MUST be non-zero.

   LH:   Type 8 is defined to be a "LISP Encapsulated Control Message"
      and what follows is either an IPv4 or IPv6 header as encoded by
      the first 4 bits after the reserved field.

   S:   This is the Security bit.  When set to 1 the field following the
      Reserved field will have the following format.  The detailed
      format of the Authentication Data Content is for further study.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    AD Type    |       Authentication Data Content . . .       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IH:   The inner IPv4 or IPv6 header which can use either RLOC or EID
      addresses in the header address fields.  When a Map-Request is
      encapsulated in this packet format the destination address in this
      header is an EID.

   UDP:   The inner UDP header where the port assignments depends on the
      control packet being encapsulated.  When the control packet is a
      Map-Request or Map-Register, the source port is ITR/PITR selected
      and the destination port is 4342.  When the control packet is a
      Map-Reply, the source port is 4342 and the destination port is
      assigned from the source port of the invoking Map-Request.  Port
      number 4341 MUST NOT be assigned to either port.  The checksum
      field MUST be non-zero.

   LCM:   The format is one of the control message formats described in
      this section.  At this time, only Map-Request messages and PIM
      Join-Prune messages [MLISP] are allowed to be encapsulated.
      Encapsulating other types of LISP control messages are for further
      study.  When Map-Requests are sent for RLOC-probing purposes (i.e
      the probe-bit is set), they MUST NOT be sent inside Encapsulated
      Control Messages.

6.2.  Routing Locator Selection

   Both client-side and server-side may need control over the selection
   of RLOCs for conversations between them.  This control is achieved by
   manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply
   messages.  Alternatively, RLOC information may be gleaned from
   received tunneled packets or EID-to-RLOC Map-Request messages.

   The following enumerates different scenarios for choosing RLOCs and
   the controls that are available:

   o  Server-side returns one RLOC.  Client-side can only use one RLOC.
      Server-side has complete control of the selection.

   o  Server-side returns a list of RLOC where a subset of the list has
      the same best priority.  Client can only use the subset list
      according to the weighting assigned by the server-side.  In this
      case, the server-side controls both the subset list and load-
      splitting across its members.  The client-side can use RLOCs
      outside of the subset list if it determines that the subset list
      is unreachable (unless RLOCs are set to a Priority of 255).  Some
      sharing of control exists: the server-side determines the
      destination RLOC list and load distribution while the client-side
      has the option of using alternatives to this list if RLOCs in the
      list are unreachable.

   o  Server-side sets weight of 0 for the RLOC subset list.  In this
      case, the client-side can choose how the traffic load is spread
      across the subset list.  Control is shared by the server-side
      determining the list and the client determining load distribution.
      Again, the client can use alternative RLOCs if the server-provided
      list of RLOCs are unreachable.

   o  Either side (more likely on the server-side ETR) decides not to
      send a Map-Request.  For example, if the server-side ETR does not
      send Map-Requests, it gleans RLOCs from the client-side ITR,
      giving the client-side ITR responsibility for bidirectional RLOC
      reachability and preferability.  Server-side ETR gleaning of the
      client-side ITR RLOC is done by caching the inner header source
      EID and the outer header source RLOC of received packets.  The
      client-side ITR controls how traffic is returned and can alternate
      using an outer header source RLOC, which then can be added to the
      list the server-side ETR uses to return traffic.  Since no
      Priority or Weights are provided using this method, the server-
      side ETR MUST assume each client-side ITR RLOC uses the same best
      Priority with a Weight of zero.  In addition, since EID-prefix
      encoding cannot be conveyed in data packets, the EID-to-RLOC cache
      on tunnel routers can grow to be very large.

   o  A "gleaned" map-cache entry, one learned from the source RLOC of a
      received encapsulated packet, is only stored and used for a few
      seconds, pending verification.  Verification is performed by
      sending a Map-Request to the source EID (the inner header IP
      source address) of the received encapsulated packet.  A reply to
      this "verifying Map-Request" is used to fully populate the map-
      cache entry for the "gleaned" EID and is stored and used for the
      time indicated from the TTL field of a received Map-Reply.  When a
      verified map-cache entry is stored, data gleaning no longer occurs
      for subsequent packets which have a source EID that matches the
      EID-prefix of the verified entry.

   RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be
   reachable when the R-bit for the locator record is set to 1.  When
   the R-bit is set to 0, an ITR or PITR MUST not encapsulate to the
   RLOC.  Neither the information contained in a Map-Reply or that
   stored in the mapping database system provides reachability
   information for RLOCs.  Note that reachability is not part of the
   mapping system and is determined using one or more of the Routing
   Locator Reachability Algorithms described in the next section.

6.3.  Routing Locator Reachability

   Several mechanisms for determining RLOC reachability are currently
   defined:

   1.  An ETR may examine the Loc-Status-Bits in the LISP header of an
       encapsulated data packet received from an ITR.  If the ETR is
       also acting as an ITR and has traffic to return to the original
       ITR site, it can use this status information to help select an
       RLOC.

   2.  An ITR may receive an ICMP Network or ICMP Host Unreachable
       message for an RLOC it is using.  This indicates that the RLOC is
       likely down.

   3.  An ITR which participates in the global routing system can
       determine that an RLOC is down if no BGP RIB route exists that
       matches the RLOC IP address.

   4.  An ITR may receive an ICMP Port Unreachable message from a
       destination host.  This occurs if an ITR attempts to use
       interworking [INTERWORK] and LISP-encapsulated data is sent to a
       non-LISP-capable site.

   5.  An ITR may receive a Map-Reply from a ETR in response to a
       previously sent Map-Request.  The RLOC source of the Map-Reply is
       likely up since the ETR was able to send the Map-Reply to the
       ITR.

   6.  When an ETR receives an encapsulated packet from an ITR, the
       source RLOC from the outer header of the packet is likely up.

   7.  An ITR/ETR pair can use the Locator Reachability Algorithms
       described in this section, namely Echo-Noncing or RLOC-Probing.

   When determining Locator up/down reachability by examining the Loc-
   Status-Bits from the LISP encapsulated data packet, an ETR will
   receive up to date status from an encapsulating ITR about
   reachability for all ETRs at the site.  CE-based ITRs at the source
   site can determine reachability relative to each other using the site
   IGP as follows:

   o  Under normal circumstances, each ITR will advertise a default
      route into the site IGP.

   o  If an ITR fails or if the upstream link to its PE fails, its
      default route will either time-out or be withdrawn.

   Each ITR can thus observe the presence or lack of a default route
   originated by the others to determine the Locator Status Bits it sets
   for them.

   RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1.  The
   Loc-Status-Bits in a LISP encapsulated packet are numbered from 0 to
   n-1 starting with the least significant bit.  For example, if an RLOC
   listed in the 3rd position of the Map-Reply goes down (ordinal value
   2), then all ITRs at the site will clear the 3rd least significant
   bit (xxxx x0xx) of the Loc-Status-Bits field for the packets they
   encapsulate.

   When an ETR decapsulates a packet, it will check for any change in
   the Loc-Status-Bits field.  When a bit goes from 1 to 0, the ETR will
   refrain from encapsulating packets to an RLOC that is indicated as
   down.  It will only resume using that RLOC if the corresponding Loc-
   Status-Bit returns to a value of 1.  Loc-Status-Bits are associated
   with a locator-set per EID-prefix.  Therefore, when a locator becomes
   unreachable, the Loc-Status-Bit that corresponds to that locator's
   position in the list returned by the last Map-Reply will be set to
   zero for that particular EID-prefix.

   When ITRs at the site are not deployed in CE routers, the IGP can
   still be used to determine the reachability of Locators provided they
   are injected into the IGP.  This is typically done when a /32 address
   is configured on a loopback interface.

   When ITRs receive ICMP Network or Host Unreachable messages as a
   method to determine unreachability, they will refrain from using
   Locators which are described in Locator lists of Map-Replies.
   However, using this approach is unreliable because many network
   operators turn off generation of ICMP Unreachable messages.

   If an ITR does receive an ICMP Network or Host Unreachable message,
   it MAY originate its own ICMP Unreachable message destined for the
   host that originated the data packet the ITR encapsulated.

   Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a
   locator address from a locator-set in a mapping entry matches a
   prefix.  If it does not find one and BGP is running in the Default
   Free Zone (DFZ), it can decide to not use the locator even though the
   Loc-Status-Bits indicate the locator is up.  In this case, the path
   from the ITR to the ETR that is assigned the locator is not
   available.  More details are in [LOC-ID-ARCH].

   Optionally, an ITR can send a Map-Request to a Locator and if a Map-
   Reply is returned, reachability of the Locator has been determined.
   Obviously, sending such probes increases the number of control
   messages originated by tunnel routers for active flows, so Locators
   are assumed to be reachable when they are advertised.

   This assumption does create a dependency: Locator unreachability is
   detected by the receipt of ICMP Host Unreachable messages.  When an
   Locator has been determined to be unreachable, it is not used for
   active traffic; this is the same as if it were listed in a Map-Reply
   with priority 255.

   The ITR can test the reachability of the unreachable Locator by
   sending periodic Requests.  Both Requests and Replies MUST be rate-
   limited.  Locator reachability testing is never done with data
   packets since that increases the risk of packet loss for end-to-end
   sessions.

   When an ETR decapsulates a packet, it knows that it is reachable from
   the encapsulating ITR because that is how the packet arrived.  In
   most cases, the ETR can also reach the ITR but cannot assume this to
   be true due to the possibility of path asymmetry.  In the presence of
   unidirectional traffic flow from an ITR to an ETR, the ITR SHOULD NOT
   use the lack of return traffic as an indication that the ETR is
   unreachable.  Instead, it MUST use an alternate mechanisms to
   determine reachability.

6.3.1.  Echo Nonce Algorithm

   When data flows bidirectionally between locators from different
   sites, a data-plane mechanism called "nonce echoing" can be used to
   determine reachability between an ITR and ETR.  When an ITR wants to
   solicit a nonce echo, it sets the N and E bits and places a 24-bit
   nonce in the LISP header of the next encapsulated data packet.

   When this packet is received by the ETR, the encapsulated packet is
   forwarded as normal.  When the ETR next sends a data packet to the
   ITR, it includes the nonce received earlier with the N bit set and E
   bit cleared.  The ITR sees this "echoed nonce" and knows the path to
   and from the ETR is up.

   The ITR will set the E-bit and N-bit for every packet it sends while
   in echo-nonce-request state.  The time the ITR waits to process the
   echoed nonce before it determines the path is unreachable is variable
   and a choice left for the implementation.

   If the ITR is receiving packets from the ETR but does not see the
   nonce echoed while being in echo-nonce-request state, then the path
   to the ETR is unreachable.  This decision may be overridden by other
   locator reachability algorithms.  Once the ITR determines the path to
   the ETR is down it can switch to another locator for that EID-prefix.

   Note that "ITR" and "ETR" are relative terms here.  Both devices MUST
   be implementing both ITR and ETR functionality for the echo nonce
   mechanism to operate.

   The ITR and ETR may both go into echo-nonce-request state at the same
   time.  The number of packets sent or the time during which echo nonce
   requests are sent is an implementation specific setting.  However,
   when an ITR is in echo-nonce-request state, it can echo the ETR's
   nonce in the next set of packets that it encapsulates and then
   subsequently, continue sending echo-nonce-request packets.

   This mechanism does not completely solve the forward path
   reachability problem as traffic may be unidirectional.  That is, the
   ETR receiving traffic at a site may not be the same device as an ITR
   which transmits traffic from that site or the site to site traffic is
   unidirectional so there is no ITR returning traffic.

   The echo-nonce algorithm is bilateral.  That is, if one side sets the
   E-bit and the other side is not enabled for echo-noncing, then the
   echoing of the nonce does not occur and the requesting side may
   regard the locator unreachable erroneously.  An ITR SHOULD only set
   the E-bit in a encapsulated data packet when it knows the ETR is
   enabled for echo-noncing.  This is conveyed by the E-bit in the Map-
   Reply message.

   Note that other locator reachability mechanisms are being researched
   and can be used to compliment or even override the Echo Nonce
   Algorithm.  See next section for an example of control-plane probing.

6.3.2.  RLOC Probing Algorithm

   RLOC Probing is a method that an ITR or PTR can use to determine the
   reachability status of one or more locators that it has cached in a
   map-cache entry.  The probe-bit of the Map-Request and Map-Reply
   messages are used for RLOC Probing.

   RLOC probing is done in the control-plane on a timer basis where an
   ITR or PTR will originate a Map-Request destined to a locator address
   from one of its own locator addresses.  A Map-Request used as an
   RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or on the
   ALT like one would when soliciting mapping data.  The EID record
   encoded in the Map-Request is the EID-prefix of the map-cache entry
   cached by the ITR or PTR.  The ITR may include a mapping data record
   for its own database mapping information which contains the local
   EID-prefixes and RLOCs for its site.

   When an ETR receives a Map-Request message with the probe-bit set, it
   returns a Map-Reply with the probe-bit set.  The source address of
   the Map-Reply is set from the destination address of the Map-Request
   and the destination address of the Map-Reply is set from the source
   address of the Map-Request.  The Map-Reply SHOULD contain mapping
   data for the EID-prefix contained in the Map-Request.  This provides
   the opportunity for the ITR or PTR, which sent the RLOC-probe to get
   mapping updates if there were changes to the ETR's database mapping
   entries.

   There are advantages and disadvantages of RLOC Probing.  The greatest
   benefit of RLOC Probing is that it can handle many failure scenarios
   allowing the ITR to determine when the path to a specific locator is
   reachable or has become unreachable, thus providing a robust
   mechanism for switching to using another locator from the cached
   locator.  RLOC Probing can also provide rough RTT estimates between a
   pair of locators which can be useful for network management purposes
   as well as for selecting low delay paths.  The major disadvantage of
   RLOC Probing is in the number of control messages required and the
   amount of bandwidth used to obtain those benefits, especially if the
   requirement for failure detection times are very small.

   Continued research and testing will attempt to characterize the
   tradeoffs of failure detection times versus message overhead.

6.4.  EID Reachability within a LISP Site

   A site may be multihomed using two or more ETRs.  The hosts and
   infrastructure within a site will be addressed using one or more EID
   prefixes that are mapped to the RLOCs of the relevant ETRs in the
   mapping system.  One possible failure mode is for an ETR to lose
   reachability to one or more of the EID prefixes within its own site.
   When this occurs when the ETR sends Map-Replies, it can clear the
   R-bit associated with its own locator.  And when the ETR is also an
   ITR, it can clear its locator-status-bit in the encapsulation data
   header.

   It is recognized there are no simple solutions to the site
   partitioning problem because it is hard to know which part of the
   EID-prefix range is partitioned.  And which locators can reach any
   sub-ranges of the EID-prefixes.  This problem is under investigation
   with the expectation that experiments will tell us more.  Note, this
   is not a new problem introduced by the LISP architecture.  The
   problem exists today when a multi-homed site uses BGP to advertise
   its reachability upstream.

6.5.  Routing Locator Hashing

   When an ETR provides an EID-to-RLOC mapping in a Map-Reply message to
   a requesting ITR, the locator-set for the EID-prefix may contain
   different priority values for each locator address.  When more than
   one best priority locator exists, the ITR can decide how to load
   share traffic against the corresponding locators.

   The following hash algorithm may be used by an ITR to select a
   locator for a packet destined to an EID for the EID-to-RLOC mapping:

   1.  Either a source and destination address hash can be used or the
       traditional 5-tuple hash which includes the source and
       destination addresses, source and destination TCP, UDP, or SCTP
       port numbers and the IP protocol number field or IPv6 next-
       protocol fields of a packet a host originates from within a LISP
       site.  When a packet is not a TCP, UDP, or SCTP packet, the
       source and destination addresses only from the header are used to
       compute the hash.

   2.  Take the hash value and divide it by the number of locators
       stored in the locator-set for the EID-to-RLOC mapping.

   3.  The remainder will be yield a value of 0 to "number of locators
       minus 1".  Use the remainder to select the locator in the
       locator-set.

   Note that when a packet is LISP encapsulated, the source port number
   in the outer UDP header needs to be set.  Selecting a hashed value
   allows core routers which are attached to Link Aggregation Groups
   (LAGs) to load-split the encapsulated packets across member links of
   such LAGs.  Otherwise, core routers would see a single flow, since
   packets have a source address of the ITR, for packets which are
   originated by different EIDs at the source site.  A suggested setting
   for the source port number computed by an ITR is a 5-tuple hash
   function on the inner header, as described above.

   Many core router implementations use a 5-tuple hash to decide how to
   balance packet load across members of a LAG.  The 5-tuple hash
   includes the source and destination addresses of the packet and the
   source and destination ports when the protocol number in the packet
   is TCP or UDP.  For this reason, UDP encoding is used for LISP
   encapsulation.

6.6.  Changing the Contents of EID-to-RLOC Mappings

   Since the LISP architecture uses a caching scheme to retrieve and
   store EID-to-RLOC mappings, the only way an ITR can get a more up-to-
   date mapping is to re-request the mapping.  However, the ITRs do not
   know when the mappings change and the ETRs do not keep track of which
   ITRs requested its mappings.  For scalability reasons, we want to
   maintain this approach but need to provide a way for ETRs change
   their mappings and inform the sites that are currently communicating
   with the ETR site using such mappings.

   When adding a new locator record in lexicographic order to the end of
   a locator-set, it is easy to update mappings.  We assume new mappings
   will maintain the same locator ordering as the old mapping but just
   have new locators appended to the end of the list.  So some ITRs can
   have a new mapping while other ITRs have only an old mapping that is
   used until they time out.  When an ITR has only an old mapping but
   detects bits set in the loc-status-bits that correspond to locators
   beyond the list it has cached, it simply ignores them.  However, this
   can only happen for locator addresses that are lexicographically
   greater than the locator addresses in the existing locator-set.

   When a locator record is inserted in the middle of a locator-set, to
   maintain lexicographic order, the SMR procedure in Section 6.6.2 is
   used to inform ITRs and PTRs of the new locator-status-bit mappings.

   When a locator record is removed from a locator-set, ITRs that have
   the mapping cached will not use the removed locator because the xTRs
   will set the loc-status-bit to 0.  So even if the locator is in the
   list, it will not be used.  For new mapping requests, the xTRs can
   set the locator AFI to 0 (indicating an unspecified address), as well
   as setting the corresponding loc-status-bit to 0.  This forces ITRs
   with old or new mappings to avoid using the removed locator.

   If many changes occur to a mapping over a long period of time, one
   will find empty record slots in the middle of the locator-set and new
   records appended to the locator-set.  At some point, it would be
   useful to compact the locator-set so the loc-status-bit settings can
   be efficiently packed.

   We propose here three approaches for locator-set compaction, one
   operational and two protocol mechanisms.  The operational approach
   uses a clock sweep method.  The protocol approaches use the concept
   of Solicit-Map-Requests and Map-Versioning.

6.6.1.  Clock Sweep

   The clock sweep approach uses planning in advance and the use of
   count-down TTLs to time out mappings that have already been cached.
   The default setting for an EID-to-RLOC mapping TTL is 24 hours.  So
   there is a 24 hour window to time out old mappings.  The following
   clock sweep procedure is used:

   1.  24 hours before a mapping change is to take effect, a network
       administrator configures the ETRs at a site to start the clock
       sweep window.

   2.  During the clock sweep window, ETRs continue to send Map-Reply
       messages with the current (unchanged) mapping records.  The TTL
       for these mappings is set to 1 hour.

   3.  24 hours later, all previous cache entries will have timed out,
       and any active cache entries will time out within 1 hour.  During
       this 1 hour window the ETRs continue to send Map-Reply messages
       with the current (unchanged) mapping records with the TTL set to
       1 minute.

   4.  At the end of the 1 hour window, the ETRs will send Map-Reply
       messages with the new (changed) mapping records.  So any active
       caches can get the new mapping contents right away if not cached,
       or in 1 minute if they had the mapping cached.  The new mappings
       are cached with a time to live equal to the TTL in the Map-Reply.

6.6.2.  Solicit-Map-Request (SMR)

   Soliciting a Map-Request is a selective way for ETRs, at the site
   where mappings change, to control the rate they receive requests for
   Map-Reply messages.  SMRs are also used to tell remote ITRs to update
   the mappings they have cached.

   Since the ETRs don't keep track of remote ITRs that have cached their
   mappings, they do not know which ITRs need to have their mappings
   updated.  As a result, an ETR will solicit Map-Requests (called an
   SMR message) from those sites to which it has been sending
   encapsulated data to for the last minute.  In particular, an ETR will
   send an SMR an ITR to which it has recently sent encapsulated data.

   An SMR message is simply a bit set in a Map-Request message.  An ITR
   or PTR will send a Map-Request when they receive an SMR message.
   Both the SMR sender and the Map-Request responder MUST rate-limited
   these messages.  Rate-limiting can be implemented as a global rate-
   limiter or one rate-limiter per SMR destination.

   The following procedure shows how a SMR exchange occurs when a site
   is doing locator-set compaction for an EID-to-RLOC mapping:

   1.  When the database mappings in an ETR change, the ETRs at the site
       begin to send Map-Requests with the SMR bit set for each locator
       in each map-cache entry the ETR caches.

   2.  A remote ITR which receives the SMR message will schedule sending
       a Map-Request message to the source locator address of the SMR
       message or to the mapping database system.  A newly allocated
       random nonce is selected and the EID-prefix used is the one
       copied from the SMR message.  If the source locator is the only
       locator in the cached locator-set, the remote ITR SHOULD send a
       Map-Request to the database mapping system just in case the
       single locator has changed and may no longer be reachable to
       accept the Map-Request.

   3.  The remote ITR MUST rate-limit the Map-Request until it gets a
       Map-Reply while continuing to use the cached mapping.  When Map
       Versioning is used, described in Section 6.6.3, an SMR sender can
       detect if an ITR is using the most up to date database mapping.

   4.  The ETRs at the site with the changed mapping will reply to the
       Map-Request with a Map-Reply message that has a nonce from the
       SMR-invoked Map-Request.  The Map-Reply messages SHOULD be rate
       limited.  This is important to avoid Map-Reply implosion.

   5.  The ETRs, at the site with the changed mapping, record the fact
       that the site that sent the Map-Request has received the new
       mapping data in the mapping cache entry for the remote site so
       the loc-status-bits are reflective of the new mapping for packets
       going to the remote site.  The ETR then stops sending SMR
       messages.

   For security reasons an ITR MUST NOT process unsolicited Map-Replies.
   To avoid map-cache entry corruption by a third-party, a sender of an
   SMR-based Map-Request MUST be verified.  If an ITR receives an SMR-
   based Map-Request and the source is not in the locator-set for the
   stored map-cache entry, then the responding Map-Request MUST be sent
   with an EID destination to the mapping database system.  Since the
   mapping database system is more secure to reach an authoritative ETR,
   it will deliver the Map-Request to the authoritative source of the
   mapping data.

   When an ITR receives an SMR-based Map-Request for which it does not
   have a cached mapping for the EID in the SMR message, it MAY not send
   a SMR-invoked Map-Request.  This scenario can occur when an ETR sends
   SMR messages to all locators in the locator-set it has stored in its
   map-cache but the remote ITRs that receive the SMR may not be sending
   packets to the site.  There is no point in updating the ITRs until
   they need to send, in which case, they will send Map-Requests to
   obtain a map-cache entry.

6.6.3.  Database Map Versioning

   When there is unidirectional packet flow between an ITR and ETR, and
   the EID-to-RLOC mappings change on the ETR, it needs to inform the
   ITR so encapsulation can stop to a removed locator and start to a new
   locator in the locator-set.

   An ETR, when it sends Map-Reply messages, conveys its own Map-Version
   number.  This is known as the Destination Map-Version Number.  ITRs
   include the Destination Map-Version Number in packets they
   encapsulate to the site.  When an ETR decapsulates a packet and
   detects the Destination Map-Version Number is less than the current
   version for its mapping, the SMR procedure described in Section 6.6.2
   occurs.

   An ITR, when it encapsulates packets to ETRs, can convey its own Map-
   Version number.  This is known as the Source Map-Version Number.
   When an ETR decapsulates a packet and detects the Source Map-Version
   Number is greater than the last Map-Version Number sent in a Map-
   Reply from the ITR's site, the ETR will send a Map-Request to one of
   the ETRs for the source site.

   A Map-Version Number is used as a sequence number per EID-prefix.  So
   values that are greater, are considered to be more recent.  A value
   of 0 for the Source Map-Version Number or the Destination Map-Version
   Number conveys no versioning information and an ITR does no
   comparison with previously received Map-Version Numbers.

   A Map-Version Number can be included in Map-Register messages as
   well.  This is a good way for the Map-Server can assure that all ETRs
   for a site registering to it will be Map-Version number synchronized.

   See [VERSIONING] for a more detailed analysis and description of
   Database Map Versioning.

7.  Router Performance Considerations

   LISP is designed to be very hardware-based forwarding friendly.  A
   few implementation techniques can be used to incrementally implement
   LISP:

   o  When a tunnel encapsulated packet is received by an ETR, the outer
      destination address may not be the address of the router.  This
      makes it challenging for the control plane to get packets from the
      hardware.  This may be mitigated by creating special FIB entries
      for the EID-prefixes of EIDs served by the ETR (those for which
      the router provides an RLOC translation).  These FIB entries are
      marked with a flag indicating that control plane processing should
      be performed.  The forwarding logic of testing for particular IP
      protocol number value is not necessary.  There are a few proven
      cases where no changes to existing deployed hardware were needed
      to support the LISP data-plane.

   o  On an ITR, prepending a new IP header consists of adding more
      bytes to a MAC rewrite string and prepending the string as part of
      the outgoing encapsulation procedure.  Routers that support GRE
      tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already
      support this action.

   o  A packet's source address or interface the packet was received on
      can be used to select a VRF (Virtual Routing/Forwarding).  The
      VRF's routing table can be used to find EID-to-RLOC mappings.

8.  Deployment Scenarios

   This section will explore how and where ITRs and ETRs can be deployed
   and will discuss the pros and cons of each deployment scenario.  For
   a more detailed deployment recommendation, refer to [LISP-DEPLOY].

   There are two basic deployment trade-offs to consider: centralized
   versus distributed caches and flat, recursive, or re-encapsulating
   tunneling.  When deciding on centralized versus distributed caching,
   the following issues should be considered:

   o  Are the tunnel routers spread out so that the caches are spread
      across all the memories of each router?

   o  Should management "touch points" be minimized by choosing few
      tunnel routers, just enough for redundancy?

   o  In general, using more ITRs doesn't increase management load,
      since caches are built and stored dynamically.  On the other hand,
      more ETRs does require more management since EID-prefix-to-RLOC
      mappings need to be explicitly configured.

   When deciding on flat, recursive, or re-encapsulation tunneling, the
   following issues should be considered:

   o  Flat tunneling implements a single tunnel between source site and
      destination site.  This generally offers better paths between
      sources and destinations with a single tunnel path.

   o  Recursive tunneling is when tunneled traffic is again further
      encapsulated in another tunnel, either to implement VPNs or to
      perform Traffic Engineering.  When doing VPN-based tunneling, the
      site has some control since the site is prepending a new tunnel
      header.  In the case of TE-based tunneling, the site may have
      control if it is prepending a new tunnel header, but if the site's
      ISP is doing the TE, then the site has no control.  Recursive
      tunneling generally will result in suboptimal paths but at the
      benefit of steering traffic to resource available parts of the
      network.

   o  The technique of re-encapsulation ensures that packets only
      require one tunnel header.  So if a packet needs to be rerouted,
      it is first decapsulated by the ETR and then re-encapsulated with
      a new tunnel header using a new RLOC.

   The next sub-sections will survey where tunnel routers can reside in
   the network.

8.1.  First-hop/Last-hop Tunnel Routers

   By locating tunnel routers close to hosts, the EID-prefix set is at
   the granularity of an IP subnet.  So at the expense of more EID-
   prefix-to-RLOC sets for the site, the caches in each tunnel router
   can remain relatively small.  But caches always depend on the number
   of non-aggregated EID destination flows active through these tunnel
   routers.

   With more tunnel routers doing encapsulation, the increase in control
   traffic grows as well: since the EID-granularity is greater, more
   Map-Requests and Map-Replies are traveling between more routers.

   The advantage of placing the caches and databases at these stub
   routers is that the products deployed in this part of the network
   have better price-memory ratios then their core router counterparts.
   Memory is typically less expensive in these devices and fewer routes
   are stored (only IGP routes).  These devices tend to have excess
   capacity, both for forwarding and routing state.

   LISP functionality can also be deployed in edge switches.  These
   devices generally have layer-2 ports facing hosts and layer-3 ports
   facing the Internet.  Spare capacity is also often available in these
   devices as well.

8.2.  Border/Edge Tunnel Routers

   Using customer-edge (CE) routers for tunnel endpoints allows the EID
   space associated with a site to be reachable via a small set of RLOCs
   assigned to the CE routers for that site.  This is the default
   behavior envisioned in the rest of this specification.

   This offers the opposite benefit of the first-hop/last-hop tunnel
   router scenario: the number of mapping entries and network management
   touch points are reduced, allowing better scaling.

   One disadvantage is that less of the network's resources are used to
   reach host endpoints thereby centralizing the point-of-failure domain
   and creating network choke points at the CE router.

   Note that more than one CE router at a site can be configured with
   the same IP address.  In this case an RLOC is an anycast address.
   This allows resilience between the CE routers.  That is, if a CE
   router fails, traffic is automatically routed to the other routers
   using the same anycast address.  However, this comes with the
   disadvantage where the site cannot control the entrance point when
   the anycast route is advertised out from all border routers.  Another
   disadvantage of using anycast locators is the limited advertisement
   scope of /32 (or /128 for IPv6) routes.

8.3.  ISP Provider-Edge (PE) Tunnel Routers

   Use of ISP PE routers as tunnel endpoint routers is not the typical
   deployment scenario envisioned in the specification.  This section
   attempts to capture some of reasoning behind this preference of
   implementing LISP on CE routers.

   Use of ISP PE routers as tunnel endpoint routers gives an ISP, rather
   than a site, control over the location of the egress tunnel
   endpoints.  That is, the ISP can decide if the tunnel endpoints are
   in the destination site (in either CE routers or last-hop routers
   within a site) or at other PE edges.  The advantage of this case is
   that two tunnel headers can be avoided.  By having the PE be the
   first router on the path to encapsulate, it can choose a TE path
   first, and the ETR can decapsulate and re-encapsulate for a tunnel to
   the destination end site.

   An obvious disadvantage is that the end site has no control over
   where its packets flow or the RLOCs used.  Other disadvantages
   include the difficulty in synchronizing path liveness updates between
   CE and PE routers.

   As mentioned in earlier sections a combination of these scenarios is
   possible at the expense of extra packet header overhead, if both site
   and provider want control, then recursive or re-encapsulating tunnels
   are used.

8.4.  LISP Functionality with Conventional NATs

   LISP routers can be deployed behind Network Address Translator (NAT)
   devices to provide the same set of packet services hosts have today
   when they are addressed out of private address space.

   It is important to note that a locator address in any LISP control
   message MUST be a globally routable address and therefore SHOULD NOT
   contain [RFC1918] addresses.  If a LISP router is configured with
   private addresses, they MUST be used only in the outer IP header so
   the NAT device can translate properly.  Otherwise, EID addresses MUST
   be translated before encapsulation is performed.  Both NAT
   translation and LISP encapsulation functions could be co-located in
   the same device.

   More details on LISP address translation can be found in [INTERWORK].

8.5.  Packets Egressing a LISP Site

   When a LISP site is using two ITRs for redundancy, the failure of one
   ITR will likely shift outbound traffic to the second.  This second
   ITR's cache may not not be populated with the same EID-to-RLOC
   mapping entries as the first.  If this second ITR does not have these
   mappings, traffic will be dropped while the mappings are retrieved
   from the mapping system.  The retrieval of these messages may
   increase the load of requests being sent into the mapping system.
   Deployment and experimentation will determine whether this issue
   requires more attention.

9.  Traceroute Considerations

   When a source host in a LISP site initiates a traceroute to a
   destination host in another LISP site, it is highly desirable for it
   to see the entire path.  Since packets are encapsulated from ITR to
   ETR, the hop across the tunnel could be viewed as a single hop.
   However, LISP traceroute will provide the entire path so the user can
   see 3 distinct segments of the path from a source LISP host to a
   destination LISP host:

      Segment 1 (in source LISP site based on EIDs):

          source-host ---> first-hop ... next-hop ---> ITR

      Segment 2 (in the core network based on RLOCs):

          ITR ---> next-hop ... next-hop ---> ETR

      Segment 3 (in the destination LISP site based on EIDs):

          ETR ---> next-hop ... last-hop ---> destination-host

   For segment 1 of the path, ICMP Time Exceeded messages are returned
   in the normal matter as they are today.  The ITR performs a TTL
   decrement and test for 0 before encapsulating.  So the ITR hop is
   seen by the traceroute source has an EID address (the address of
   site-facing interface).

   For segment 2 of the path, ICMP Time Exceeded messages are returned
   to the ITR because the TTL decrement to 0 is done on the outer
   header, so the destination of the ICMP messages are to the ITR RLOC
   address, the source RLOC address of the encapsulated traceroute
   packet.  The ITR looks inside of the ICMP payload to inspect the
   traceroute source so it can return the ICMP message to the address of
   the traceroute client as well as retaining the core router IP address
   in the ICMP message.  This is so the traceroute client can display
   the core router address (the RLOC address) in the traceroute output.
   The ETR returns its RLOC address and responds to the TTL decrement to
   0 like the previous core routers did.

   For segment 3, the next-hop router downstream from the ETR will be
   decrementing the TTL for the packet that was encapsulated, sent into
   the core, decapsulated by the ETR, and forwarded because it isn't the
   final destination.  If the TTL is decremented to 0, any router on the
   path to the destination of the traceroute, including the next-hop
   router or destination, will send an ICMP Time Exceeded message to the
   source EID of the traceroute client.  The ICMP message will be
   encapsulated by the local ITR and sent back to the ETR in the
   originated traceroute source site, where the packet will be delivered
   to the host.

9.1.  IPv6 Traceroute

   IPv6 traceroute follows the procedure described above since the
   entire traceroute data packet is included in ICMP Time Exceeded
   message payload.  Therefore, only the ITR needs to pay special
   attention for forwarding ICMP messages back to the traceroute source.

9.2.  IPv4 Traceroute

   For IPv4 traceroute, we cannot follow the above procedure since IPv4
   ICMP Time Exceeded messages only include the invoking IP header and 8
   bytes that follow the IP header.  Therefore, when a core router sends
   an IPv4 Time Exceeded message to an ITR, all the ITR has in the ICMP
   payload is the encapsulated header it prepended followed by a UDP
   header.  The original invoking IP header, and therefore the identity
   of the traceroute source is lost.

   The solution we propose to solve this problem is to cache traceroute
   IPv4 headers in the ITR and to match them up with corresponding IPv4
   Time Exceeded messages received from core routers and the ETR.  The
   ITR will use a circular buffer for caching the IPv4 and UDP headers
   of traceroute packets.  It will select a 16-bit number as a key to
   find them later when the IPv4 Time Exceeded messages are received.
   When an ITR encapsulates an IPv4 traceroute packet, it will use the
   16-bit number as the UDP source port in the encapsulating header.
   When the ICMP Time Exceeded message is returned to the ITR, the UDP
   header of the encapsulating header is present in the ICMP payload
   thereby allowing the ITR to find the cached headers for the
   traceroute source.  The ITR puts the cached headers in the payload
   and sends the ICMP Time Exceeded message to the traceroute source
   retaining the source address of the original ICMP Time Exceeded
   message (a core router or the ETR of the site of the traceroute
   destination).

   The signature of a traceroute packet comes in two forms.  The first
   form is encoded as a UDP message where the destination port is
   inspected for a range of values.  The second form is encoded as an
   ICMP message where the IP identification field is inspected for a
   well-known value.

9.3.  Traceroute using Mixed Locators

   When either an IPv4 traceroute or IPv6 traceroute is originated and
   the ITR encapsulates it in the other address family header, you
   cannot get all 3 segments of the traceroute.  Segment 2 of the
   traceroute can not be conveyed to the traceroute source since it is
   expecting addresses from intermediate hops in the same address format
   for the type of traceroute it originated.  Therefore, in this case,
   segment 2 will make the tunnel look like one hop.  All the ITR has to
   do to make this work is to not copy the inner TTL to the outer,
   encapsulating header's TTL when a traceroute packet is encapsulated
   using an RLOC from a different address family.  This will cause no
   TTL decrement to 0 to occur in core routers between the ITR and ETR.

10.  Mobility Considerations

   There are several kinds of mobility of which only some might be of
   concern to LISP.  Essentially they are as follows.

10.1.  Site Mobility

   A site wishes to change its attachment points to the Internet, and
   its LISP Tunnel Routers will have new RLOCs when it changes upstream
   providers.  Changes in EID-RLOC mappings for sites are expected to be
   handled by configuration, outside of the LISP protocol.

10.2.  Slow Endpoint Mobility

   An individual endpoint wishes to move, but is not concerned about
   maintaining session continuity.  Renumbering is involved.  LISP can
   help with the issues surrounding renumbering [RFC4192] [LISA96] by
   decoupling the address space used by a site from the address spaces
   used by its ISPs.  [RFC4984]

10.3.  Fast Endpoint Mobility

   Fast endpoint mobility occurs when an endpoint moves relatively
   rapidly, changing its IP layer network attachment point.  Maintenance
   of session continuity is a goal.  This is where the Mobile IPv4
   [RFC3344bis] and Mobile IPv6 [RFC3775] [RFC4866] mechanisms are used,
   and primarily where interactions with LISP need to be explored.

   The problem is that as an endpoint moves, it may require changes to
   the mapping between its EID and a set of RLOCs for its new network
   location.  When this is added to the overhead of mobile IP binding
   updates, some packets might be delayed or dropped.

   In IPv4 mobility, when an endpoint is away from home, packets to it
   are encapsulated and forwarded via a home agent which resides in the
   home area the endpoint's address belongs to.  The home agent will
   encapsulate and forward packets either directly to the endpoint or to
   a foreign agent which resides where the endpoint has moved to.
   Packets from the endpoint may be sent directly to the correspondent
   node, may be sent via the foreign agent, or may be reverse-tunneled
   back to the home agent for delivery to the mobile node.  As the
   mobile node's EID or available RLOC changes, LISP EID-to-RLOC
   mappings are required for communication between the mobile node and
   the home agent, whether via foreign agent or not.  As a mobile
   endpoint changes networks, up to three LISP mapping changes may be
   required:

   o  The mobile node moves from an old location to a new visited
      network location and notifies its home agent that it has done so.
      The Mobile IPv4 control packets the mobile node sends pass through
      one of the new visited network's ITRs, which needs a EID-RLOC
      mapping for the home agent.

   o  The home agent might not have the EID-RLOC mappings for the mobile
      node's "care-of" address or its foreign agent in the new visited
      network, in which case it will need to acquire them.

   o  When packets are sent directly to the correspondent node, it may
      be that no traffic has been sent from the new visited network to
      the correspondent node's network, and the new visited network's
      ITR will need to obtain an EID-RLOC mapping for the correspondent
      node's site.

   In addition, if the IPv4 endpoint is sending packets from the new
   visited network using its original EID, then LISP will need to
   perform a route-returnability check on the new EID-RLOC mapping for
   that EID.

   In IPv6 mobility, packets can flow directly between the mobile node
   and the correspondent node in either direction.  The mobile node uses
   its "care-of" address (EID).  In this case, the route-returnability
   check would not be needed but one more LISP mapping lookup may be
   required instead:

   o  As above, three mapping changes may be needed for the mobile node
      to communicate with its home agent and to send packets to the
      correspondent node.

   o  In addition, another mapping will be needed in the correspondent
      node's ITR, in order for the correspondent node to send packets to
      the mobile node's "care-of" address (EID) at the new network
      location.

   When both endpoints are mobile the number of potential mapping
   lookups increases accordingly.

   As a mobile node moves there are not only mobility state changes in
   the mobile node, correspondent node, and home agent, but also state
   changes in the ITRs and ETRs for at least some EID-prefixes.

   The goal is to support rapid adaptation, with little delay or packet
   loss for the entire system.  Also IP mobility can be modified to
   require fewer mapping changes.  In order to increase overall system
   performance, there may be a need to reduce the optimization of one
   area in order to place fewer demands on another.

   In LISP, one possibility is to "glean" information.  When a packet
   arrives, the ETR could examine the EID-RLOC mapping and use that
   mapping for all outgoing traffic to that EID.  It can do this after
   performing a route-returnability check, to ensure that the new
   network location does have a internal route to that endpoint.
   However, this does not cover the case where an ITR (the node assigned
   the RLOC) at the mobile-node location has been compromised.

   Mobile IP packet exchange is designed for an environment in which all
   routing information is disseminated before packets can be forwarded.
   In order to allow the Internet to grow to support expected future
   use, we are moving to an environment where some information may have
   to be obtained after packets are in flight.  Modifications to IP
   mobility should be considered in order to optimize the behavior of
   the overall system.  Anything which decreases the number of new EID-
   RLOC mappings needed when a node moves, or maintains the validity of
   an EID-RLOC mapping for a longer time, is useful.

10.4.  Fast Network Mobility

   In addition to endpoints, a network can be mobile, possibly changing
   xTRs.  A "network" can be as small as a single router and as large as
   a whole site.  This is different from site mobility in that it is
   fast and possibly short-lived, but different from endpoint mobility
   in that a whole prefix is changing RLOCs.  However, the mechanisms
   are the same and there is no new overhead in LISP.  A map request for
   any endpoint will return a binding for the entire mobile prefix.

   If mobile networks become a more common occurrence, it may be useful
   to revisit the design of the mapping service and allow for dynamic
   updates of the database.

   The issue of interactions between mobility and LISP needs to be
   explored further.  Specific improvements to the entire system will
   depend on the details of mapping mechanisms.  Mapping mechanisms
   should be evaluated on how well they support session continuity for
   mobile nodes.

10.5.  LISP Mobile Node Mobility

   A mobile device can use the LISP infrastructure to achieve mobility
   by implementing the LISP encapsulation and decapsulation functions
   and acting as a simple ITR/ETR.  By doing this, such a "LISP mobile
   node" can use topologically-independent EID IP addresses that are not
   advertised into and do not impose a cost on the global routing
   system.  These EIDs are maintained at the edges of the mapping system
   (in LISP Map-Servers and Map-Resolvers) and are provided on demand to
   only the correspondents of the LISP mobile node.

   Refer to the LISP Mobility Architecture specification [LISP-MN] for
   more details.

11.  Multicast Considerations

   A multicast group address, as defined in the original Internet
   architecture is an identifier of a grouping of topologically
   independent receiver host locations.  The address encoding itself
   does not determine the location of the receiver(s).  The multicast
   routing protocol, and the network-based state the protocol creates,
   determines where the receivers are located.

   In the context of LISP, a multicast group address is both an EID and
   a Routing Locator.  Therefore, no specific semantic or action needs
   to be taken for a destination address, as it would appear in an IP
   header.  Therefore, a group address that appears in an inner IP
   header built by a source host will be used as the destination EID.
   The outer IP header (the destination Routing Locator address),
   prepended by a LISP router, will use the same group address as the
   destination Routing Locator.

   Having said that, only the source EID and source Routing Locator
   needs to be dealt with.  Therefore, an ITR merely needs to put its
   own IP address in the source Routing Locator field when prepending
   the outer IP header.  This source Routing Locator address, like any
   other Routing Locator address MUST be globally routable.

   Therefore, an EID-to-RLOC mapping does not need to be performed by an
   ITR when a received data packet is a multicast data packet or when
   processing a source-specific Join (either by IGMPv3 or PIM).  But the
   source Routing Locator is decided by the multicast routing protocol
   in a receiver site.  That is, an EID to Routing Locator translation
   is done at control-time.

   Another approach is to have the ITR not encapsulate a multicast
   packet and allow the host built packet to flow into the core even if
   the source address is allocated out of the EID namespace.  If the
   RPF-Vector TLV [RFC5496] is used by PIM in the core, then core
   routers can RPF to the ITR (the Locator address which is injected
   into core routing) rather than the host source address (the EID
   address which is not injected into core routing).

   To avoid any EID-based multicast state in the network core, the first
   approach is chosen for LISP-Multicast.  Details for LISP-Multicast
   and Interworking with non-LISP sites is described in specification
   [MLISP].

12.  Security Considerations

   It is believed that most of the security mechanisms will be part of
   the mapping database service when using control plane procedures for
   obtaining EID-to-RLOC mappings.  For data plane triggered mappings,
   as described in this specification, protection is provided against
   ETR spoofing by using Return- Routability mechanisms evidenced by the
   use of a 24-bit Nonce field in the LISP encapsulation header and a
   64-bit Nonce field in the LISP control message.  The nonce, coupled
   with the ITR accepting only solicited Map-Replies goes a long way
   toward providing decent authentication.

   LISP does not rely on a PKI infrastructure or a more heavy weight
   authentication system.  These systems challenge the scalability of
   LISP which was a primary design goal.

   DoS attack prevention will depend on implementations rate-limiting
   Map-Requests and Map-Replies to the control plane as well as rate-
   limiting the number of data-triggered Map-Replies.

   An incorrectly implemented or malicious ITR might choose to ignore
   the priority and weights provided by the ETR in its Map-Reply.  This
   traffic steering would be limited to the traffic that is sent by this
   ITR's site, and no more severe than if the site initiated a bandwidth
   DoS attack on (one of) the ETR's ingress links.  The ITR's site would
   typically gain no benefit from not respecting the weights, and would
   likely to receive better service by abiding by them.

   To deal with map-cache exhaustion attempts in an ITR/PTR, the
   implementation should consider putting a maximum cap on the number of
   entries stored with a reserve list for special or frequently accessed
   sites.  This should be a configuration policy control set by the
   network administrator who manages ITRs and PTRs.  When overlapping
   EID-prefixes occur across multiple map-cache entries, the integrity
   of the set must be wholly maintained.  So if a more-specific entry
   cannot be added due to reaching the maximum cap, then none of the
   less specifics should be stored in the map-cache.

   Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings,
   cache sizing and maintenance is an issue to be kept in mind during
   implementation.  It is a good idea to have instrumentation in place
   to detect thrashing of the cache.  Implementation experimentation
   will be used to determine which cache management strategies work
   best.  It should be noted that an undersized cache in an ITR/PTR not
   only causes adverse affect on the site or region they support, but
   may also cause increased Map-Request load on the mapping system.

   There is a security risk implicit in the fact that ETRs generate the
   EID prefix to which they are responding.  An ETR can claim a shorter
   prefix than it is actually responsible for.  Various mechanisms to
   ameliorate or resolve this issue will be examined in the future,
   [LISP-SEC].

   Spoofing of inner header addresses of LISP encapsulated packets is
   possible like with any tunneling mechanism.  ITRs MUST verify the
   source address of a packet to be an EID that belongs to the site's
   EID-prefix range prior to encapsulation.  ETRs MUST NOT  An ETR must only
   decapsulate and forward packets into their site where the datagrams with an inner header destination
   that matches one of its EID-prefix ranges.  If, upon receipt and
   decapsulation, the destination EID of a datagram does not belong to match one
   of the ETR's EID-prefix range for configured EID-prefixes, the
   site. ETR MUST drop the
   datragram.  If a LISP encapsulated packet arrives at an ETR, it MAY
   compare the inner header source EID address and the outer header
   source RLOC address with the mapping that exists in the mapping
   database.  Then when spoofing attacks occur, the outer header source
   RLOC address can be used to trace back the attack to the source site,
   using existing operational tools.

   This experimental specification does not address automated key
   management (AKM).  BCP 107 provides guidance in this area.  In
   addition, at the time of this writing, substantial work is being
   undertaken to improve security of the routing system [KARP], [RPKI],
   [BGP-SEC], [LISP-SEC], Future work on LISP should address BCP-107 as
   well as other open security considerations, which may require changes
   to this specification.

13.  Network Management Considerations

   Considerations for Network Management tools exist so the LISP
   protocol suite can be operationally managed.  The mechanisms can be
   found in [LISP-MIB] and [LISP-LIG].

14.  IANA Considerations

   This section provides guidance to the Internet Assigned Numbers
   Authority (IANA) regarding registration of values related to the LISP
   specification, in accordance with BCP 26 and RFC 5226 [RFC5226].

   There are two name spaces in LISP that require registration:

   o  LISP IANA registry allocations should not be made for purposes
      unrelated to LISP routing or transport protocols.

   o  The following policies are used here with the meanings defined in
      BCP 26: "Specification Required", "IETF Consensus", "Experimental
      Use", "First Come First Served".

14.1.  LISP Address Type Codes

   Instance ID type codes have a range from 0 to 15, of which 0 and 1
   have been allocated [LCAF].  New Type Codes MUST be allocated
   starting at 2.  Type Codes 2 - 10 are to be assigned by IETF Review.
   Type Codes 11 - 15 are available on a First Come First Served policy.

   The following codes have been allocated:

   Type 0:  Null Body Type

   Type 1:  AFI List Type

   See [LCAF] for details for other possible unapproved address
   encodings.  The unapproved LCAF encodings are an area for further
   study and experimentation.

14.2.  LISP UDP Port Numbers

   The IANA registry has allocated UDP port numbers 4341 and 4342 for
   LISP data-plane and control-plane operation, respectively.

15.  References

15.1.  Normative References

   [BGP-SEC]  Lepinski, M., "An Overview of BGPSEC",
              draft-lepinski-bgpsec-overview-00.txt (work in progress),
              March 2011.

   [KARP]     Lebovitz, G. and M. Bhatia, "Keying and Authentication for
              Routing Protocols (KARP)Design Guidelines",
              draft-ietf-karp-design-guide-02.txt (work in progress),
              March 2011.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1700]  Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
              October 1994.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2404]  Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
              ESP and AH", RFC 2404, November 1998.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.

   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, September 2001.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

   [RFC4632]  Fuller, V. and T. Li, "Classless Inter-domain Routing
              (CIDR): The Internet Address Assignment and Aggregation
              Plan", BCP 122, RFC 4632, August 2006.

   [RFC4634]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and HMAC-SHA)", RFC 4634, July 2006.

   [RFC4866]  Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
              Optimization for Mobile IPv6", RFC 4866, May 2007.

   [RFC4984]  Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
              Workshop on Routing and Addressing", RFC 4984,
              September 2007.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5496]  Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
              Forwarding (RPF) Vector TLV", RFC 5496, March 2009.

   [RPKI]     Lepinski, M., "An Infrastructure to Support Secure
              Internet Routing", draft-ietf-sidr-arch-12.txt (work in
              progress), February 2011.

   [UDP-TUNNELS]
              Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled
              Packets", draft-eubanks-chimento-6man-01.txt (work in
              progress), October 2010.

15.2.  Informative References

   [AFI]      IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
              NUMBERS
              http://www.iana.org/assignments/address-family-numbers,
              January 2011.

   [AFI-REGISTRY]
              IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
              NUMBER registry http://www.iana.org/assignments/
              address-family-numbers/
              address-family-numbers.xml#address-family-numbers-1,
              January 2011.

   [ALT]      Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
              Alternative Topology (LISP-ALT)",
              draft-ietf-lisp-alt-07.txt (work in progress), June 2011.

   [CHIAPPA]  Chiappa, J., "Endpoints and Endpoint names: A Proposed
              Enhancement to the Internet Architecture", Internet-
              Draft http://www.chiappa.net/~jnc/tech/endpoints.txt,
              1999.

   [CONS]     Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A
              Content distribution Overlay Network  Service for LISP",
              draft-meyer-lisp-cons-03.txt (work in progress),
              November 2007.

   [EMACS]    Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID
              Mappings Multicast Across Cooperating Systems for LISP",
              draft-curran-lisp-emacs-00.txt (work in progress),
              November 2007.

   [INTERWORK]
              Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
              "Interworking LISP with IPv4 and IPv6",
              draft-ietf-lisp-interworking-02.txt (work in progress),
              June 2011.

   [LCAF]     Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
              Address Format", draft-farinacci-lisp-lcaf-04.txt (work in
              progress), October 2010.

   [LISA96]   Lear, E., Katinsky, J., Coffin, J., and D. Tharp,
              "Renumbering: Threat or Menace?", Usenix , September 1996.

   [LISP-DEPLOY]
              Jakab, L., Coras, F., Domingo-Pascual, J., and D. Lewis,
              "LISP Network Element Deployment Considerations",
              draft-jakab-lisp-deployment-02.txt (work in progress),
              February 2011.

   [LISP-LIG]
              Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)",
              draft-ietf-lisp-lig-01.txt (work in progress),
              October 2010.

   [LISP-MAIN]
              Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-farinacci-lisp-12.txt (work in progress),
              March 2009.

   [LISP-MIB]
              Schudel, G., Jain, A., and V. Moreno, "LISP MIB",
              draft-ietf-lisp-mib-01.txt (work in progress), March 2011.

   [LISP-MN]  Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP
              Mobility Architecture", draft-meyer-lisp-mn-04.txt (work
              in progress), October 2010.

   [LISP-MS]  Farinacci, D. and V. Fuller, "LISP Map Server",
              draft-ietf-lisp-ms-09.txt (work in progress), June 2011.

   [LISP-SEC]
              Maino, F., Ermagon, V., Cabellos, A., Sausez, D., and O.
              Bonaventure, "LISP-Security (LISP-SEC)",
              draft-ietf-lisp-sec-00.txt (work in progress), June 2011.

   [LOC-ID-ARCH]
              Meyer, D. and D. Lewis, "Architectural Implications of
              Locator/ID  Separation",
              draft-meyer-loc-id-implications-01.txt (work in progress),
              Januaryr 2009.

   [MLISP]    Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
              "LISP for Multicast Environments",
              draft-ietf-lisp-multicast-06.txt (work in progress),
              June 2011.

   [NERD]     Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
              draft-lear-lisp-nerd-08.txt (work in progress),
              March 2010.

   [OPENLISP]
              Iannone, L. and O. Bonaventure, "OpenLISP Implementation
              Report", draft-iannone-openlisp-implementation-01.txt
              (work in progress), July 2008.

   [RADIR]    Narten, T., "Routing and Addressing Problem Statement",
              draft-narten-radir-problem-statement-00.txt (work in
              progress), July 2007.

   [RFC3344bis]
              Perkins, C., "IP Mobility Support for IPv4, revised",
              draft-ietf-mip4-rfc3344bis-05 (work in progress),
              July 2007.

   [RFC4192]  Baker, F., Lear, E., and R. Droms, "Procedures for
              Renumbering an IPv6 Network without a Flag Day", RFC 4192,
              September 2005.

   [RPMD]     Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol
              for Routing Protocol Meta-data  Dissemination",
              draft-handley-p2ppush-unpublished-2007726.txt (work in
              progress), July 2007.

   [VERSIONING]
              Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping
              Versioning", draft-ietf-lisp-map-versioning-01.txt (work
              in progress), March 2011.

Appendix A.  Acknowledgments

   An initial thank you goes to Dave Oran for planting the seeds for the
   initial ideas for LISP.  His consultation continues to provide value
   to the LISP authors.

   A special and appreciative thank you goes to Noel Chiappa for
   providing architectural impetus over the past decades on separation
   of location and identity, as well as detailed review of the LISP
   architecture and documents, coupled with enthusiasm for making LISP a
   practical and incremental transition for the Internet.

   The authors would like to gratefully acknowledge many people who have
   contributed discussion and ideas to the making of this proposal.
   They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller,
   Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston,
   David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley,
   Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler,
   Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi
   Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Terry
   Manderson, Roger Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van
   Beijnum, Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien
   Saucez, Damian Lezama, Attilla De Groot, Parantap Lahiri, David
   Black, Roque Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin,
   Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari
   Arkko, Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu,
   Dhirendra Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri
   Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina
   Ermagan, Albert Cabellos, Fabio Maino, Victor Moreno, Chris White,
   Clarence Filsfils, and Alia Atlas.

   This work originated in the Routing Research Group (RRG) of the IRTF.
   The individual submission [LISP-MAIN] was converted into this IETF
   LISP working group draft.

Appendix B.  Document Change Log

B.1.  Changes to draft-ietf-lisp-14.txt

   o  Post working group last call and pre-IESG last call review.

   o  Indicate that an ICMP Unreachable message should be sent when a
      packet matches a drop-based negative map-cache entry.

   o  Indicate how a map-cache set of overlapping EID-prefixes must
      maintian integrity when the map-cache maximum cap is reached.

   o  Add Joel's description for the definition of an EID, that the bit
      string value can be an RLOC for another device in abstract but the
      architecture allows it to be an EID of one device and the same
      value as an RLOC for another device.

   o  In the "Tunnel Encapsulation Details" section, indicate that 4
      combinations of encapsulation are supported.

   o  Add what ETR should do for a Data-Probe when received for a
      destination EID outside of its EID-prefix range.  This was added
      in the Data Probe definition section.

   o  Added text indicating that more-specific EID-prefixes must not be
      removed when less-specific entries stay in the map-cache.  This is
      to preserve the integrity of the EID-prefix set.

   o  Add clarifying text in the Security Considerations section about
      how an ETR must not decapsulate and forward a packet that is not
      for its configured EID-prefix range.

B.2.  Changes to draft-ietf-lisp-13.txt

   o  Posted June 2011 to complete working group last call.

   o  Tracker item 87.  Put Yakov suggested wording in the EID-prefix
      definition section to reference [INTERWORK] and [LISP-DEPLOY]
      about discussion on transition and access mechanisms.

   o  Change "ITRs" to "ETRs" in the Locator Status Bit definition
      section and data packet description section per Damien's comment.

   o  Remove the normative reference to [LISP-SEC] when describing the
      S-bit in the ECM and Map-Reply headers.

   o  Tracker item 54.  Added text from John Scudder in the "Packets
      Egressing a LISP Site" section.

   o  Add sentence to the "Reencapsulating Tunnel" definition about how
      reencapsulation loops can occur when not coordinating among
      multiple mapping database systems.

   o  Remove "In theory" from a sentence in the Security Considerations
      section.

   o  Remove Security Area Statement title and reword section with
      Eliot's provided text.  The text was agreed upon by LISP-WG chairs
      and Security ADs.

   o  Remove word "potential" from the over-claiming paragraph of the
      Security Considerations section per Stephen's request.

   o  Wordsmithing and other editorial comments from Alia.

B.2.

B.3.  Changes to draft-ietf-lisp-12.txt

   o  Posted April 2011.

   o  Tracker item 87.  Provided rewording how an EID-prefix can be
      resued in the definition section of "EID-prefix".

   o  Tracker item 95.  Change "eliminate" to "defer" in section 4.1.

   o  Tracker item 110.  Added that the Mapping Protocol Data field in
      the Map-Reply message is only used when needed by the particular
      Mapping Database System.

   o  Tracker item 111.  Indicate that if an LSB that is assocaited with
      an anycast address, that there is at least one RLOC that is up.

   o  Tracker item 108.  Make clear the R-bit does not define RLOC path
      reachability.

   o  Tracker item 107.  Indicate that weights are relative to each
      other versus requiring an addition of up to 100%.

   o  Tracker item 46.  Add a sentence how LISP products should be sized
      for the appropriate demand so cache thrashing is avoided.

   o  Change some references of RFC 5226 to [AFI] per Luigi.

   o  Per Luigi, make reference to "EID-AFI" consistent to "EID-prefix-
      AFI".

   o  Tracker item 66.  Indicate that appending locators to a locator-
      set is done when the added locators are lexicographically greater
      than the previous ones in the set.

   o  Tracker item 87.  Once again reword the definition of the EID-
      prefix to reflect recent comments.

   o  Tracker item 70.  Added text to security section on what the
      implications could be if an ITR does not obey priority and weights
      from a Map-Reply message.

   o  Tracker item 54.  Added text to the new section titled "Packets
      Egressing a LISP Site" to describe the implications when two or
      more ITRs exist at a site where only one ITR is used for egress
      traffic and when there is a shift of traffic to the others, how
      the map-cache will need to be populated in those new egress ITRs.

   o  Tracker item 33.  Make more clear in the Routing Locator Selection
      section what an ITR should do when it sees an R-bit of 0 in a
      locator-record of a Map-Reply.

   o  Tracker item 33.  Add paragraph to the EID Reachability section
      indicating that site parittioning is under investigation.

   o  Tracker item 58.  Added last paragraph of Security Considerations
      section about how to protect inner header EID address spoofing
      attacks.

   o  Add suggested Sam text to indicate that all security concerns need
      not be addressed for moving document to Experimental RFC status.
      Put this in a subsection of the Secuirty Considerations section.

B.3.

B.4.  Changes to draft-ietf-lisp-11.txt

   o  Posted March 30, 2011.

   o  Change IANA URL.  The URL we had pointed to a general protocol
      numbers page.

   o  Added the "s" bit to the Map-Request to allow SMR-invoked Map-
      Requests to be sent to a MN ETR via the map-server.

   o  Generalize text for the defintion of Reencapsuatling tunnels.

   o  Add pargraph suggested by Joel to explain how implementation
      experimentation will be used to determine the proper cache
      management techniques.

   o  Add Yakov provided text for the definition of "EID-to-RLOC
      "Database".

   o  Add reference in Section 8, Deployment Scenarios, to the
      draft-jakab-lisp-deploy-02.txt draft.

   o  Clarify sentence about no hardware changes needed to support LISP
      encapsulation.

   o  Add paragraph about what is the procedure when a locator is
      inserted in the middle of a locator-set.

   o  Add a definition for Locator-Status-Bits so we can emphasize they
      are used as a hint for router up/down status and not path
      reachability.

   o  Change "BGP RIB" to "RIB" per Clarence's comment.

   o  Fixed complaints by IDnits.

   o  Add subsection to Security Considerations section indicating how
      EID-prefix overclaiming in Map-Replies is for further study and
      add a reference to LISP-SEC.

B.4.

B.5.  Changes to draft-ietf-lisp-10.txt

   o  Posted March 2011.

   o  Add p-bit to Map-Request so there is documentary reasons to know
      when a PITR has sent a Map-Request to an ETR.

   o  Add Map-Notify message which is used to acknowledge a Map-Register
      message sent to a Map-Server.

   o  Add M-bit to the Map-Register message so an ETR that wants an
      acknowledgment for the Map-Register can request one.

   o  Add S-bit to the ECM and Map-Reply messages to describe security
      data that can be present in each message.  Then refer to
      [LISP-SEC] for expansive details.

   o  Add Network Management Considerations section and point to the MIB
      and LIG drafts.

   o  Remove the word "simple" per Yakov's comments.

B.5.

B.6.  Changes to draft-ietf-lisp-09.txt

   o  Posted October 2010.

   o  Add to IANA Consideration section about the use of LCAF Type
      values that accepted and maintained by the IANA registry and not
      the LCAF specification.

   o  Indicate that implementations should be able to receive LISP
      control messages when either UDP port is 4342, so they can be
      robust in the face of intervening NAT boxes.

   o  Add paragraph to SMR section to indicate that an ITR does not need
      to respond to an SMR-based Map-Request when it has no map-cache
      entry for the SMR source's EID-prefix.

B.6.

B.7.  Changes to draft-ietf-lisp-08.txt

   o  Posted August 2010.

   o  In section 6.1.6, remove statement about setting TTL to 0 in Map-
      Register messages.

   o  Clarify language in section 6.1.5 about Map-Replying to Data-
      Probes or Map-Requests.

   o  Indicate that outer TTL should only be copied to inner TTL when it
      is less than inner TTL.

   o  Indicate a source-EID for RLOC-probes are encoded with an AFI
      value of 0.

   o  Indicate that SMRs can have a global or per SMR destination rate-
      limiter.

   o  Add clarifications to the SMR procedures.

   o  Add definitions for "client-side" and 'server-side" terms used in
      this specification.

   o  Clear up language in section 6.4, last paragraph.

   o  Change ACT of value 0 to "no-action".  This is so we can RLOC-
      probe a PETR and have it return a Map-Reply with a locator-set of
      size 0.  The way it is spec'ed the map-cache entry has action
      "dropped".  Drop-action is set to 3.

   o  Add statement about normalizing locator weights.

   o  Clarify R-bit definition in the Map-Reply locator record.

   o  Add section on EID Reachability within a LISP site.

   o  Clarify another disadvantage of using anycast locators.

   o  Reworded Abstract.

   o  Change section 2.0 Introduction to remove obsolete information
      such as the LISP variant definitions.

   o  Change section 5 title from "Tunneling Details" to "LISP
      Encapsulation Details".

   o  Changes to section 5 to include results of network deployment
      experience with MTU.  Recommend that implementations use either
      the stateful or stateless handling.

   o  Make clarification wordsmithing to Section 7 and 8.

   o  Identify that if there is one locator in the locator-set of a map-
      cache entry, that an SMR from that locator should be responded to
      by sending the the SMR-invoked Map-Request to the database mapping
      system rather than to the RLOC itself (which may be unreachable).

   o  When describing Unicast and Multicast Weights indicate the the
      values are relative weights rather than percentages.  So it
      doesn't imply the sum of all locator weights in the locator-set
      need to be 100.

   o  Do some wordsmithing on copying TTL and TOS fields.

   o  Numerous wordsmithing changes from Dave Meyer.  He fine toothed
      combed the spec.

   o  Removed Section 14 "Prototype Plans and Status".  We felt this
      type of section is no longer appropriate for a protocol
      specification.

   o  Add clarification text for the IRC description per Damien's
      commentary.

   o  Remove text on copying nonce from SMR to SMR-invoked Map- Request
      per Vina's comment about a possible DoS vector.

   o  Clarify (S/2 + H) in the stateless MTU section.

   o  Add text to reflect Damien's comment about the description of the
      "ITR-RLOC Address" field in the Map-Request. that the list of RLOC
      addresses are local addresses of the Map-Requester.

B.7.

B.8.  Changes to draft-ietf-lisp-07.txt

   o  Posted April 2010.

   o  Added I-bit to data header so LSB field can also be used as an
      Instance ID field.  When this occurs, the LSB field is reduced to
      8-bits (from 32-bits).

   o  Added V-bit to the data header so the 24-bit nonce field can also
      be used for source and destination version numbers.

   o  Added Map-Version 12-bit value to the EID-record to be used in all
      of Map-Request, Map-Reply, and Map-Register messages.

   o  Added multiple ITR-RLOC fields to the Map-Request packet so an ETR
      can decide what address to select for the destination of a Map-
      Reply.

   o  Added L-bit (Local RLOC bit) and p-bit (Probe-Reply RLOC bit) to
      the Locator-Set record of an EID-record for a Map-Reply message.
      The L-bit indicates which RLOCs in the locator-set are local to
      the sender of the message.  The P-bit indicates which RLOC is the
      source of a RLOC-probe Reply (Map-Reply) message.

   o  Add reference to the LISP Canonical Address Format [LCAF] draft.

   o  Made editorial and clarification changes based on comments from
      Dhirendra Trivedi.

   o  Added wordsmithing comments from Joel Halpern on DF=1 setting.

   o  Add John Zwiebel clarification to Echo Nonce Algorithm section
      6.3.1.

   o  Add John Zwiebel comment about expanding on proxy-map-reply bit
      for Map-Register messages.

   o  Add NAT section per Ron Bonica comments.

   o  Fix IDnits issues per Ron Bonica.

   o  Added section on Virtualization and Segmentation to explain the
      use if the Instance ID field in the data header.

   o  There are too many P-bits, keep their scope to the packet format
      description and refer to them by name every where else in the
      spec.

   o  Scanned all occurrences of "should", "should not", "must" and
      "must not" and uppercased them.

   o  John Zwiebel offered text for section 4.1 to modernize the
      example.  Thanks Z!

   o  Make it more clear in the definition of "EID-to-RLOC Database"
      that all ETRs need to have the same database mapping.  This
      reflects a comment from John Scudder.

   o  Add a definition "Route-returnability" to the Definition of Terms
      section.

   o  In section 9.2, add text to describe what the signature of
      traceroute packets can look like.

   o  Removed references to Data Probe for introductory example.  Data-
      probes are still part of the LISP design but not encouraged.

   o  Added the definition for "LISP site" to the Definition of Terms"
      section.

B.8.

B.9.  Changes to draft-ietf-lisp-06.txt

   Editorial based changes:

   o  Posted December 2009.

   o  Fix typo for flags in LISP data header.  Changed from "4" to "5".

   o  Add text to indicate that Map-Register messages must contain a
      computed UDP checksum.

   o  Add definitions for PITR and PETR.

   o  Indicate an AFI value of 0 is an unspecified address.

   o  Indicate that the TTL field of a Map-Register is not used and set
      to 0 by the sender.  This change makes this spec consistent with
      [LISP-MS].

   o  Change "... yield a packet size of L bytes" to "... yield a packet
      size greater than L bytes".

   o  Clarify section 6.1.5 on what addresses and ports are used in Map-
      Reply messages.

   o  Clarify that LSBs that go beyond the number of locators do not to
      be SMRed when the locator addresses are greater lexicographically
      than the locator in the existing locator-set.

   o  Add Gregg, Srini, and Amit to acknowledgment section.

   o  Clarify in the definition of a LISP header what is following the
      UDP header.

   o  Clarify "verifying Map-Request" text in section 6.1.3.

   o  Add Xu Xiaohu to the acknowledgment section for introducing the
      problem of overlapping EID-prefixes among multiple sites in an RRG
      email message.

   Design based changes:

   o  Use stronger language to have the outer IPv4 header set DF=1 so we
      can avoid fragment reassembly in an ETR or PETR.  This will also
      make IPv4 and IPv6 encapsulation have consistent behavior.

   o  Map-Requests should not be sent in ECM with the Probe bit is set.
      These type of Map-Requests are used as RLOC-probes and are sent
      directly to locator addresses in the underlying network.

   o  Add text in section 6.1.5 about returning all EID-prefixes in a
      Map-Reply sent by an ETR when there are overlapping EID-prefixes
      configure.

   o  Add text in a new subsection of section 6.1.5 about dealing with
      Map-Replies with coarse EID-prefixes.

B.9.

B.10.  Changes to draft-ietf-lisp-05.txt

   o  Posted September 2009.

   o  Added this Document Change Log appendix.

   o  Added section indicating that encapsulated Map-Requests must use
      destination UDP port 4342.

   o  Don't use AH in Map-Registers.  Put key-id, auth-length, and auth-
      data in Map-Register payload.

   o  Added Jari to acknowledgment section.

   o  State the source-EID is set to 0 when using Map-Requests to
      refresh or RLOC-probe.

   o  Make more clear what source-RLOC should be for a Map-Request.

   o  The LISP-CONS authors thought that the Type definitions for CONS
      should be removed from this specification.

   o  Removed nonce from Map-Register message, it wasn't used so no need
      for it.

   o  Clarify what to do for unspecified Action bits for negative Map-
      Replies.  Since No Action is a drop, make value 0 Drop.

B.10.

B.11.  Changes to draft-ietf-lisp-04.txt

   o  Posted September 2009.

   o  How do deal with record count greater than 1 for a Map-Request.
      Damien and Joel comment.  Joel suggests: 1) Specify that senders
      compliant with the current document will always set the count to
      1, and note that the count is included for future extensibility.
      2) Specify what a receiver compliant with the draft should do if
      it receives a request with a count greater than 1.  Presumably, it
      should send some error back?

   o  Add Fred Templin in acknowledgment section.

   o  Add Margaret and Sam to the acknowledgment section for their great
      comments.

   o  Say more about LAGs in the UDP section per Sam Hartman's comment.

   o  Sam wants to use MAY instead of SHOULD for ignoring checksums on
      ETR.  From the mailing list: "You'd need to word it as an ITR MAY
      send a zero checksum, an ETR MUST accept a 0 checksum and MAY
      ignore the checksum completely.  And of course we'd need to
      confirm that can actually be implemented.  In particular, hardware
      that verifies UDP checksums on receive needs to be checked to make
      sure it permits 0 checksums."

   o  Margaret wants a reference to
      http://www.ietf.org/id/draft-eubanks-chimento-6man-00.txt.

   o  Fix description in Map-Request section.  Where we describe Map-
      Reply Record, change "R-bit" to "M-bit".

   o  Add the mobility bit to Map-Replies.  So PTRs don't probe so often
      for MNs but often enough to get mapping updates.

   o  Indicate SHA1 can be used as well for Map-Registers.

   o  More Fred comments on MTU handling.

   o  Isidor comment about spec'ing better periodic Map-Registers.  Will
      be fixed in draft-ietf-lisp-ms-02.txt.

   o  Margaret's comment on gleaning: "The current specification does
      not make it clear how long gleaned map entries should be retained
      in the cache, nor does it make it clear how/ when they will be
      validated.  The LISP spec should, at the very least, include a
      (short) default lifetime for gleaned entries, require that they be
      validated within a short period of time, and state that a new
      gleaned entry should never overwrite an entry that was obtained
      from the mapping system.  The security implications of storing
      "gleaned" entries should also be explored in detail."

   o  Add section on RLOC-probing per working group feedback.

   o  Change "loc-reach-bits" to "loc-status-bits" per comment from
      Noel.

   o  Remove SMR-bit from data-plane.  Dino prefers to have it in the
      control plane only.

   o  Change LISP header to allow a "Research Bit" so the Nonce and LSB
      fields can be turned off and used for another future purpose.  For
      Luigi et al versioning convergence.

   o  Add a N-bit to the data header suggested by Noel.  Then the nonce
      field could be used when N is not 1.

   o  Clarify that when E-bit is 0, the nonce field can be an echoed
      nonce or a random nonce.  Comment from Jesper.

   o  Indicate when doing data-gleaning that a verifying Map-Request is
      sent to the source-EID of the gleaned data packet so we can avoid
      map-cache corruption by a 3rd party.  Comment from Pedro.

   o  Indicate that a verifying Map-Request, for accepting mapping data,
      should be sent over the ALT (or to the EID).

   o  Reference IPsec RFC 4302.  Comment from Sam and Brian Weis.

   o  Put E-bit in Map-Reply to tell ITRs that the ETR supports echo-
      noncing.  Comment by Pedro and Dino.

   o  Jesper made a comment to loosen the language about requiring the
      copy of inner TTL to outer TTL since the text to get mixed-AF
      traceroute to work would violate the "MUST" clause.  Changed from
      MUST to SHOULD in section 5.3.

B.11.

B.12.  Changes to draft-ietf-lisp-03.txt

   o  Posted July 2009.

   o  Removed loc-reach-bits longword from control packets per Damien
      comment.

   o  Clarifications in MTU text from Roque.

   o  Added text to indicate that the locator-set be sorted by locator
      address from Isidor.

   o  Clarification text from John Zwiebel in Echo-Nonce section.

B.12.

B.13.  Changes to draft-ietf-lisp-02.txt

   o  Posted July 2009.

   o  Encapsulation packet format change to add E-bit and make loc-
      reach-bits 32-bits in length.

   o  Added Echo-Nonce Algorithm section.

   o  Clarification how ECN bits are copied.

   o  Moved S-bit in Map-Request.

   o  Added P-bit in Map-Request and Map-Reply messages to anticipate
      RLOC-Probe Algorithm.

   o  Added to Mobility section to reference [LISP-MN].

B.13.

B.14.  Changes to draft-ietf-lisp-01.txt

   o  Posted 2 days after draft-ietf-lisp-00.txt in May 2009.

   o  Defined LEID to be a "LISP EID".

   o  Indicate encapsulation use IPv4 DF=0.

   o  Added negative Map-Reply messages with drop, native-forward, and
      send-map-request actions.

   o  Added Proxy-Map-Reply bit to Map-Register.

B.14.

B.15.  Changes to draft-ietf-lisp-00.txt

   o  Posted May 2009.

   o  Rename of draft-farinacci-lisp-12.txt.

   o  Acknowledgment to RRG.

Authors' Addresses

   Dino Farinacci
   cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: dino@cisco.com

   Vince Fuller
   cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: vaf@cisco.com

   Dave Meyer
   cisco Systems
   170 Tasman Drive
   San Jose, CA
   USA

   Email: dmm@cisco.com

   Darrel Lewis
   cisco Systems
   170 Tasman Drive
   San Jose, CA
   USA

   Email: darlewis@cisco.com
--Apple-Mail-116-364858833 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-116-364858833 Content-Disposition: attachment; filename=draft-ietf-lisp-14.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-lisp-14.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Experimental D. Meyer Expires: December 31, 2011 D. Lewis cisco Systems June 29, 2011 Locator/ID Separation Protocol (LISP) draft-ietf-lisp-14 Abstract This draft describes a network-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. LISP can be incrementally deployed, without a "flag day", and offers traffic engineering, multi-homing, and mobility benefits even to early adopters, when there are relatively few LISP- capable sites. Design and development of LISP was largely motivated by the problem statement produced by the October, 2006 IAB Routing and Addressing Workshop. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 31, 2011. Farinacci, et al. Expires December 31, 2011 [Page 1] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 Copyright Notice Copyright (c) 2011 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 BSD License. Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 7 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14 5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . . 16 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 17 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 17 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 19 5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 22 5.4.1. A Stateless Solution to MTU Handling . . . . . . . . . 23 5.4.2. A Stateful Solution to MTU Handling . . . . . . . . . 24 5.5. Using Virtualization and Segmentation with LISP . . . . . 24 6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 26 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 26 6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 28 6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 28 6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 31 6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 32 6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 36 6.1.6. Map-Register Message Format . . . . . . . . . . . . . 38 6.1.7. Map-Notify Message Format . . . . . . . . . . . . . . 40 6.1.8. Encapsulated Control Message Format . . . . . . . . . 41 6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 43 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 45 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 47 6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 48 6.4. EID Reachability within a LISP Site . . . . . . . . . . . 49 6.5. Routing Locator Hashing . . . . . . . . . . . . . . . . . 50 6.6. Changing the Contents of EID-to-RLOC Mappings . . . . . . 50 Farinacci, et al. Expires December 31, 2011 [Page 2] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 6.6.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 51 6.6.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 52 6.6.3. Database Map Versioning . . . . . . . . . . . . . . . 54 7. Router Performance Considerations . . . . . . . . . . . . . . 55 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 56 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 57 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 57 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 58 8.4. LISP Functionality with Conventional NATs . . . . . . . . 58 8.5. Packets Egressing a LISP Site . . . . . . . . . . . . . . 59 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 60 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 61 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 61 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 61 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 63 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 63 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 63 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 63 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 65 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 65 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 67 12. Security Considerations . . . . . . . . . . . . . . . . . . . 68 13. Network Management Considerations . . . . . . . . . . . . . . 70 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 14.1. LISP Address Type Codes . . . . . . . . . . . . . . . . . 71 14.2. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . . 71 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72 15.1. Normative References . . . . . . . . . . . . . . . . . . . 72 15.2. Informative References . . . . . . . . . . . . . . . . . . 73 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 77 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 78 B.1. Changes to draft-ietf-lisp-14.txt . . . . . . . . . . . . 78 B.2. Changes to draft-ietf-lisp-13.txt . . . . . . . . . . . . 78 B.3. Changes to draft-ietf-lisp-12.txt . . . . . . . . . . . . 79 B.4. Changes to draft-ietf-lisp-11.txt . . . . . . . . . . . . 80 B.5. Changes to draft-ietf-lisp-10.txt . . . . . . . . . . . . 81 B.6. Changes to draft-ietf-lisp-09.txt . . . . . . . . . . . . 81 B.7. Changes to draft-ietf-lisp-08.txt . . . . . . . . . . . . 82 B.8. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 84 B.9. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 85 B.10. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 86 B.11. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 87 B.12. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 89 B.13. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 89 B.14. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 89 B.15. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 91 Farinacci, et al. Expires December 31, 2011 [Page 3] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Farinacci, et al. Expires December 31, 2011 [Page 4] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 2. Introduction This document describes the Locator/Identifier Separation Protocol (LISP), which provides a set of functions for routers to exchange information used to map from non-routeable Endpoint Identifiers (EIDs) to routeable Routing Locators (RLOCs). It also defines a mechanism for these LISP routers to encapsulate IP packets addressed with EIDs for transmission across an Internet that uses RLOCs for routing and forwarding. Creation of LISP was initially motivated by discussions during the IAB-sponsored Routing and Addressing Workshop held in Amsterdam in October, 2006 (see [RFC4984]). A key conclusion of the workshop was that the Internet routing and addressing system was not scaling well in the face of the explosive growth of new sites; one reason for this poor scaling is the increasing number of multi-homed and other sites that cannot be addressed as part of topologically- or provider-based aggregated prefixes. Additional work that more completely described the problem statement may be found in [RADIR]. A basic observation, made many years ago in early networking research such as that documented in [CHIAPPA] and [RFC4984], is that using a single address field for both identifying a device and for determining where it is topologically located in the network requires optimization along two conflicting axes: for routing to be efficient, the address must be assigned topologically; for collections of devices to be easily and effectively managed, without the need for renumbering in response to topological change (such as that caused by adding or removing attachment points to the network or by mobility events), the address must explicitly not be tied to the topology. The approach that LISP takes to solving the routing scalability problem is to replace IP addresses with two new types of numbers: Routing Locators (RLOCs), which are topologically assigned to network attachment points (and are therefore amenable to aggregation) and used for routing and forwarding of packets through the network; and Endpoint Identifiers (EIDs), which are assigned independently from the network topology, are used for numbering devices, and are aggregated along administrative boundaries. LISP then defines functions for mapping between the two numbering spaces and for encapsulating traffic originated by devices using non-routeable EIDs for transport across a network infrastructure that routes and forwards using RLOCs. Both RLOCs and EIDs are syntactically- identical to IP addresses; it is the semantics of how they are used that differs. This document describes the protocol that implements these functions. The database which stores the mappings between EIDs and RLOCs is Farinacci, et al. Expires December 31, 2011 [Page 5] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 explicitly a separate "module" to facilitate experimentation with a variety of approaches. One database design that is being developed and prototyped as part of the LISP working group work is [ALT]. Others that have been described but not implemented include [CONS], [EMACS], [RPMD], [NERD]. Finally, [LISP-MS], documents a general- purpose service interface for accessing a mapping database; this interface is intended to make the mapping database modular so that different approaches can be tried without the need to modify installed xTRs. This experimental specification does not address automated key management. Addressing automated key management is necessary for Internet standards. See Section 12 for further security details. Farinacci, et al. Expires December 31, 2011 [Page 6] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 3. Definition of Terms Provider Independent (PI) Addresses: PI addresses are an address block assigned from a pool where blocks are not associated with any particular location in the network (e.g. from a particular service provider), and is therefore not topologically aggregatable in the routing system. Provider Assigned (PA) Addresses: PA addresses are an a address block assigned to a site by each service provider to which a site connects. Typically, each block is sub-block of a service provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and is aggregated into the larger block before being advertised into the global Internet. Traditionally, IP multihoming has been implemented by each multi-homed site acquiring its own, globally- visible prefix. LISP uses only topologically-assigned and aggregatable address blocks for RLOCs, eliminating this demonstrably non-scalable practice. Routing Locator (RLOC): A RLOC is an IPv4 or IPv6 address of an egress tunnel router (ETR). A RLOC is the output of a EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically-aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as PA addresses. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site. Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. The host obtains a destination EID the same way it obtains an destination address today, for example through a Domain Name System (DNS) [RFC1034] lookup or Session Invitation Protocol (SIP) [RFC3261] exchange. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID is allocated to a host from an EID-prefix block associated with the site where the host is located. An EID can be used by a host to refer to other hosts. EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be assigned in a hierarchical manner, independent of the network topology, to facilitate scaling of the mapping database. In addition, an EID block assigned to a site may have site-local structure (subnetting) for routing within the site; this structure is not visible to the global routing system. In theory, the bit string that represents an EID for one device can represent an RLOC for a different device. As the architecture is realized, if a given bit string is both an RLOC and an EID, it must refer to the Farinacci, et al. Expires December 31, 2011 [Page 7] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 same entity in both cases. When used in discussions with other Locator/ID separation proposals, a LISP EID will be called a "LEID". Throughout this document, any references to "EID" refers to an LEID. EID-prefix: An EID-prefix is a power-of-two block of EIDs which are allocated to a site by an address allocation authority. EID- prefixes are associated with a set of RLOC addresses which make up a "database mapping". EID-prefix allocations can be broken up into smaller blocks when an RLOC set is to be associated with the smaller EID-prefix. A globally routed address block (whether PI or PA) is not inherently an EID-prefix. A globally routed address block may be used by its assignee as an EID block. The converse is not supported. That is, a site which receives an explicitly allocated EID-prefix may not use that EID-prefix as a globally prefix. This would require coordination and cooperation with the entities managing the mapping infrastructure. Once this has been done, that block could be removed from the globally routed IP system, if other suitable transition and access mechanisms are in place. Discussion of such transition and access mechanisms can be found in [INTERWORK] and [LISP-DEPLOY]. End-system: An end-system is an IPv4 or IPv6 device that originates packets with a single IPv4 or IPv6 header. The end-system supplies an EID value for the destination address field of the IP header when communicating globally (i.e. outside of its routing domain). An end-system can be a host computer, a switch or router device, or any network appliance. Ingress Tunnel Router (ITR): An ITR is a router which accepts an IP packet with a single IP header (more precisely, an IP packet that does not contain a LISP header). The router treats this "inner" IP destination address as an EID and performs an EID-to-RLOC mapping lookup. The router then prepends an "outer" IP header with one of its globally-routable RLOCs in the source address field and the result of the mapping lookup in the destination address field. Note that this destination RLOC may be an intermediate, proxy device that has better knowledge of the EID- to-RLOC mapping closer to the destination EID. In general, an ITR receives IP packets from site end-systems on one side and sends LISP-encapsulated IP packets toward the Internet on the other side. Specifically, when a service provider prepends a LISP header for Traffic Engineering purposes, the router that does this is also regarded as an ITR. The outer RLOC the ISP ITR uses can be based on the outer destination address (the originating ITR's supplied RLOC) or the inner destination address (the originating hosts Farinacci, et al. Expires December 31, 2011 [Page 8] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 supplied EID). TE-ITR: A TE-ITR is an ITR that is deployed in a service provider network that prepends an additional LISP header for Traffic Engineering purposes. Egress Tunnel Router (ETR): An ETR is a router that accepts an IP packet where the destination address in the "outer" IP header is one of its own RLOCs. The router strips the "outer" header and forwards the packet based on the next IP header found. In general, an ETR receives LISP-encapsulated IP packets from the Internet on one side and sends decapsulated IP packets to site end-systems on the other side. ETR functionality does not have to be limited to a router device. A server host can be the endpoint of a LISP tunnel as well. TE-ETR: A TE-ETR is an ETR that is deployed in a service provider network that strips an outer LISP header for Traffic Engineering purposes. xTR: A xTR is a reference to an ITR or ETR when direction of data flow is not part of the context description. xTR refers to the router that is the tunnel endpoint. Used synonymously with the term "Tunnel Router". For example, "An xTR can be located at the Customer Edge (CE) router", meaning both ITR and ETR functionality is at the CE router. EID-to-RLOC Cache: The EID-to-RLOC cache is a short-lived, on- demand table in an ITR that stores, tracks, and is responsible for timing-out and otherwise validating EID-to-RLOC mappings. This cache is distinct from the full "database" of EID-to-RLOC mappings, it is dynamic, local to the ITR(s), and relatively small while the database is distributed, relatively static, and much more global in scope. EID-to-RLOC Database: The EID-to-RLOC database is a global distributed database that contains all known EID-prefix to RLOC mappings. Each potential ETR typically contains a small piece of the database: the EID-to-RLOC mappings for the EID prefixes "behind" the router. These map to one of the router's own, globally-visible, IP addresses. The same database mapping entries MUST be configured on all ETRs for a given site. In a steady state the EID-prefixes for the site and the locator-set for each EID-prefix MUST be the same on all ETRs. Procedures to enforce and/or verify this are outside the scope of this document. Note that there may be transient conditions when the EID-prefix for the site and locator-set for each EID-prefix may not be the same on all ETRs. This has no negative implications. Farinacci, et al. Expires December 31, 2011 [Page 9] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 Recursive Tunneling: Recursive tunneling occurs when a packet has more than one LISP IP header. Additional layers of tunneling may be employed to implement traffic engineering or other re-routing as needed. When this is done, an additional "outer" LISP header is added and the original RLOCs are preserved in the "inner" header. Any references to tunnels in this specification refers to dynamic encapsulating tunnels and never are they statically configured. Reencapsulating Tunnels: Reencapsulating tunneling occurs when an ETR removes a LISP header, then acts as an ITR to prepend another LISP header. Doing this allows a packet to be re-routed by the re-encapsulating router without adding the overhead of additional tunnel headers. Any references to tunnels in this specification refers to dynamic encapsulating tunnels and never are they statically configured. When using multiple mapping database systems, care must be taken to not create reencapsulation loops. LISP Header: a term used in this document to refer to the outer IPv4 or IPv6 header, a UDP header, and a LISP-specific 8-byte header that follows the UDP header, an ITR prepends or an ETR strips. Address Family Identifier (AFI): a term used to describe an address encoding in a packet. An address family currently pertains to an IPv4 or IPv6 address. See [AFI]/[AFI-REGISTRY] and [RFC1700] for details. An AFI value of 0 used in this specification indicates an unspecified encoded address where the length of the address is 0 bytes following the 16-bit AFI value of 0. Negative Mapping Entry: A negative mapping entry, also known as a negative cache entry, is an EID-to-RLOC entry where an EID-prefix is advertised or stored with no RLOCs. That is, the locator-set for the EID-to-RLOC entry is empty or has an encoded locator count of 0. This type of entry could be used to describe a prefix from a non-LISP site, which is explicitly not in the mapping database. There are a set of well defined actions that are encoded in a Negative Map-Reply. Data Probe: A data-probe is a LISP-encapsulated data packet where the inner header destination address equals the outer header destination address used to trigger a Map-Reply by a decapsulating ETR. In addition, the original packet is decapsulated and delivered to the destination host if the destination EID is in the EID-prefix range configured on the ETR. Otherwise, the packet is discarded. A Data Probe is used in some of the mapping database designs to "probe" or request a Map-Reply from an ETR; in other cases, Map-Requests are used. See each mapping database design Farinacci, et al. Expires December 31, 2011 [Page 10] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 for details. Proxy ITR (PITR): A PITR is also known as a PTR is defined and described in [INTERWORK], a PITR acts like an ITR but does so on behalf of non-LISP sites which send packets to destinations at LISP sites. Proxy ETR (PETR): A PETR is defined and described in [INTERWORK], a PETR acts like an ETR but does so on behalf of LISP sites which send packets to destinations at non-LISP sites. Route-returnability: is an assumption that the underlying routing system will deliver packets to the destination. When combined with a nonce that is provided by a sender and returned by a receiver limits off-path data insertion. LISP site: is a set of routers in an edge network that are under a single technical administration. LISP routers which reside in the edge network are the demarcation points to separate the edge network from the core network. Client-side: a term used in this document to indicate a connection initiation attempt by an EID. The ITR(s) at the LISP site are the first to get involved in obtaining database map cache entries by sending Map-Request messages. Server-side: a term used in this document to indicate a connection initiation attempt is being accepted for a destination EID. The ETR(s) at the destination LISP site are the first to send Map- Replies to the source site initiating the connection. The ETR(s) at this destination site can obtain mappings by gleaning information from Map-Requests, Data-Probes, or encapsulated packets. Locator-Status-Bits (LSBs): Locator status bits are present in the LISP header. They are used by ITRs to inform ETRs about the up/ down status of all ETRs at the local site. These bits are used as a hint to convey up/down router status and not path reachability status. The LSBs can be verified by use of one of the Locator Reachability Algoriths described in Section 6.3. Farinacci, et al. Expires December 31, 2011 [Page 11] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 4. Basic Overview One key concept of LISP is that end-systems (hosts) operate the same way they do today. The IP addresses that hosts use for tracking sockets, connections, and for sending and receiving packets do not change. In LISP terminology, these IP addresses are called Endpoint Identifiers (EIDs). Routers continue to forward packets based on IP destination addresses. When a packet is LISP encapsulated, these addresses are referred to as Routing Locators (RLOCs). Most routers along a path between two hosts will not change; they continue to perform routing/ forwarding lookups on the destination addresses. For routers between the source host and the ITR as well as routers from the ETR to the destination host, the destination address is an EID. For the routers between the ITR and the ETR, the destination address is an RLOC. Another key LISP concept is the "Tunnel Router". A tunnel router prepends LISP headers on host-originated packets and strip them prior to final delivery to their destination. The IP addresses in this "outer header" are RLOCs. During end-to-end packet exchange between two Internet hosts, an ITR prepends a new LISP header to each packet and an egress tunnel router strips the new header. The ITR performs EID-to-RLOC lookups to determine the routing path to the ETR, which has the RLOC as one of its IP addresses. Some basic rules governing LISP are: o End-systems (hosts) only send to addresses which are EIDs. They don't know addresses are EIDs versus RLOCs but assume packets get to LISP routers, which in turn, deliver packets to the destination the end-system has specified. o EIDs are always IP addresses assigned to hosts. o LISP routers mostly deal with Routing Locator addresses. See details later in Section 4.1 to clarify what is meant by "mostly". o RLOCs are always IP addresses assigned to routers; preferably, topologically-oriented addresses from provider CIDR blocks. o When a router originates packets it may use as a source address either an EID or RLOC. When acting as a host (e.g. when terminating a transport session such as SSH, TELNET, or SNMP), it may use an EID that is explicitly assigned for that purpose. An EID that identifies the router as a host MUST NOT be used as an RLOC; an EID is only routable within the scope of a site. A typical BGP configuration might demonstrate this "hybrid" EID/RLOC Farinacci, et al. Expires December 31, 2011 [Page 12] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 usage where a router could use its "host-like" EID to terminate iBGP sessions to other routers in a site while at the same time using RLOCs to terminate eBGP sessions to routers outside the site. o EIDs are not expected to be usable for global end-to-end communication in the absence of an EID-to-RLOC mapping operation. They are expected to be used locally for intra-site communication. o EID prefixes are likely to be hierarchically assigned in a manner which is optimized for administrative convenience and to facilitate scaling of the EID-to-RLOC mapping database. The hierarchy is based on a address allocation hierarchy which is independent of the network topology. o EIDs may also be structured (subnetted) in a manner suitable for local routing within an autonomous system. An additional LISP header may be prepended to packets by a TE-ITR when re-routing of the path for a packet is desired. A potential use-case for this would be an ISP router that needs to perform traffic engineering for packets flowing through its network. In such a situation, termed Recursive Tunneling, an ISP transit acts as an additional ingress tunnel router and the RLOC it uses for the new prepended header would be either a TE-ETR within the ISP (along intra-ISP traffic engineered path) or a TE-ETR within another ISP (an inter-ISP traffic engineered path, where an agreement to build such a path exists). In order to avoid excessive packet overhead as well as possible encapsulation loops, this document mandates that a maximum of two LISP headers can be prepended to a packet. For initial LISP deployments, it is assumed two headers is sufficient, where the first prepended header is used at a site for Location/Identity separation and second prepended header is used inside a service provider for Traffic Engineering purposes. Tunnel Routers can be placed fairly flexibly in a multi-AS topology. For example, the ITR for a particular end-to-end packet exchange might be the first-hop or default router within a site for the source host. Similarly, the egress tunnel router might be the last-hop router directly-connected to the destination host. Another example, perhaps for a VPN service out-sourced to an ISP by a site, the ITR could be the site's border router at the service provider attachment point. Mixing and matching of site-operated, ISP-operated, and other tunnel routers is allowed for maximum flexibility. See Section 8 for more details. Farinacci, et al. Expires December 31, 2011 [Page 13] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 4.1. Packet Flow Sequence This section provides an example of the unicast packet flow with the following conditions: o Source host "host1.abc.com" is sending a packet to "host2.xyz.com", exactly what host1 would do if the site was not using LISP. o Each site is multi-homed, so each tunnel router has an address (RLOC) assigned from the service provider address block for each provider to which that particular tunnel router is attached. o The ITR(s) and ETR(s) are directly connected to the source and destination, respectively, but the source and destination can be located anywhere in LISP site. o Map-Requests can be sent on the underlying routing system topology or over an alternative topology [ALT]. o Map-Replies are sent on the underlying routing system topology. Client host1.abc.com wants to communicate with server host2.xyz.com: 1. host1.abc.com wants to open a TCP connection to host2.xyz.com. It does a DNS lookup on host2.xyz.com. An A/AAAA record is returned. This address is the destination EID. The locally- assigned address of host1.abc.com is used as the source EID. An IPv4 or IPv6 packet is built and forwarded through the LISP site as a normal IP packet until it reaches a LISP ITR. 2. The LISP ITR must be able to map the EID destination to an RLOC of one of the ETRs at the destination site. The specific method used to do this is not described in this example. See [ALT] or [CONS] for possible solutions. 3. The ITR will send a LISP Map-Request. Map-Requests SHOULD be rate-limited. 4. When an alternate mapping system is not in use, the Map-Request packet is routed through the underlying routing system. Otherwise, the Map-Request packet is routed on an alternate logical topology. In either case, when the Map-Request arrives at one of the ETRs at the destination site, it will process the packet as a control message. 5. The ETR looks at the destination EID of the Map-Request and matches it against the prefixes in the ETR's configured EID-to- Farinacci, et al. Expires December 31, 2011 [Page 14] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 RLOC mapping database. This is the list of EID-prefixes the ETR is supporting for the site it resides in. If there is no match, the Map-Request is dropped. Otherwise, a LISP Map-Reply is returned to the ITR. 6. The ITR receives the Map-Reply message, parses the message (to check for format validity) and stores the mapping information from the packet. This information is stored in the ITR's EID-to- RLOC mapping cache. Note that the map cache is an on-demand cache. An ITR will manage its map cache in such a way that optimizes for its resource constraints. 7. Subsequent packets from host1.abc.com to host2.xyz.com will have a LISP header prepended by the ITR using the appropriate RLOC as the LISP header destination address learned from the ETR. Note the packet may be sent to a different ETR than the one which returned the Map-Reply due to the source site's hashing policy or the destination site's locator-set policy. 8. The ETR receives these packets directly (since the destination address is one of its assigned IP addresses), strips the LISP header and forwards the packets to the attached destination host. In order to defer the need for a mapping lookup in the reverse direction, an ETR MAY create a cache entry that maps the source EID (inner header source IP address) to the source RLOC (outer header source IP address) in a received LISP packet. Such a cache entry is termed a "gleaned" mapping and only contains a single RLOC for the EID in question. More complete information about additional RLOCs SHOULD be verified by sending a LISP Map-Request for that EID. Both ITR and the ETR may also influence the decision the other makes in selecting an RLOC. See Section 6 for more details. Farinacci, et al. Expires December 31, 2011 [Page 15] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 5. LISP Encapsulation Details Since additional tunnel headers are prepended, the packet becomes larger and can exceed the MTU of any link traversed from the ITR to the ETR. It is recommended in IPv4 that packets do not get fragmented as they are encapsulated by the ITR. Instead, the packet is dropped and an ICMP Too Big message is returned to the source. This specification recommends that implementations support for one of the proposed fragmentation and reassembly schemes. These two existing schemes are detailed in Section 5.4. Since IPv4 or IPv6 addresses can be either EIDs or RLOCs, the LISP architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner header is in IPv4 packet format and the other header is in IPv6 packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header is in IPv6 packet format and the other header is in IPv4 packet format). The next sub-sections illustrate packet formats for the homogenous case (IPv4-in-IPv4 and IPv6-in-IPv6) but all 4 combinations SHOULD be supported. Farinacci, et al. Expires December 31, 2011 [Page 16] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 5.1. LISP IPv4-in-IPv4 Header Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| IHL |Type of Service| Total Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identification |Flags| Fragment Offset | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OH | Time to Live | Protocol =3D 17 | Header Checksum = | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source Routing Locator | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E|V|I|flags| Nonce/Map-Version | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | Instance ID/Locator Status Bits | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| IHL |Type of Service| Total Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identification |Flags| Fragment Offset | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IH | Time to Live | Protocol | Header Checksum | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source EID | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination EID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2. LISP IPv6-in-IPv6 Header Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| Traffic Class | Flow Label | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires December 31, 2011 [Page 17] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 | | Payload Length | Next Header=3D17| Hop Limit = | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | O + + u | | t + Source Routing Locator + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | ^ + Destination Routing Locator + | | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4341 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E|V|I|flags| Nonce/Map-Version | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | Instance ID/Locator Status Bits | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| Traffic Class | Flow Label | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Payload Length | Next Header | Hop Limit | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | I + + n | | n + Source EID + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | ^ + Destination EID + \ | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires December 31, 2011 [Page 18] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 5.3. Tunnel Header Field Descriptions Inner Header: The inner header is the header on the datagram received from the originating host. The source and destination IP addresses are EIDs. Outer Header: The outer header is a new header prepended by an ITR. The address fields contain RLOCs obtained from the ingress router's EID-to-RLOC cache. The IP protocol number is "UDP (17)" from [RFC0768]. The DF bit of the Flags field is set to 0 when the method in Section 5.4.1 is used and set to 1 when the method in Section 5.4.2 is used. UDP Header: The UDP header contains a ITR selected source port when encapsulating a packet. See Section 6.5 for details on the hash algorithm used to select a source port based on the 5-tuple of the inner header. The destination port MUST be set to the well-known IANA assigned port value 4341. UDP Checksum: The UDP checksum field SHOULD be transmitted as zero by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS]. When a packet with a zero UDP checksum is received by an ETR, the ETR MUST accept the packet for decapsulation. When an ITR transmits a non-zero value for the UDP checksum, it MUST send a correctly computed value in this field. When an ETR receives a packet with a non-zero UDP checksum, it MAY choose to verify the checksum value. If it chooses to perform such verification, and the verification fails, the packet MUST be silently dropped. If the ETR chooses not to perform the verification, or performs the verification successfully, the packet MUST be accepted for decapsulation. The handling of UDP checksums for all tunneling protocols, including LISP, is under active discussion within the IETF. When that discussion concludes, any necessary changes will be made to align LISP with the outcome of the broader discussion. UDP Length: The UDP length field is for an IPv4 encapsulated packet, the inner header Total Length plus the UDP and LISP header lengths are used. For an IPv6 encapsulated packet, the inner header Payload Length plus the size of the IPv6 header (40 bytes) plus the size of the UDP and LISP headers are used. The UDP header length is 8 bytes. N: The N bit is the nonce-present bit. When this bit is set to 1, the low-order 24-bits of the first 32-bits of the LISP header contains a Nonce. See Section 6.3.1 for details. Both N and V bits MUST NOT be set in the same packet. If they are, a decapsulating ETR MUST treat the "Nonce/Map-Version" field as Farinacci, et al. Expires December 31, 2011 [Page 19] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 having a Nonce value present. L: The L bit is the Locator-Status-Bits field enabled bit. When this bit is set to 1, the Locator-Status-Bits in the second 32-bits of the LISP header are in use. x 1 x x 0 x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|flags| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator Status Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E: The E bit is the echo-nonce-request bit. When this bit is set to 1, the N bit MUST be 1. This bit SHOULD be ignored and has no meaning when the N bit is set to 0. See Section 6.3.1 for details. V: The V bit is the Map-Version present bit. When this bit is set to 1, the N bit MUST be 0. Refer to Section 6.6.3 for more details. This bit indicates that the first 4 bytes of the LISP header is encoded as: 0 x 0 1 x x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|flags| Source Map-Version | Dest Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator Status Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I: The I bit is the Instance ID bit. See Section 5.5 for more details. When this bit is set to 1, the Locator Status Bits field is reduced to 8-bits and the high-order 24-bits are used as an Instance ID. If the L-bit is set to 0, then the low-order 8 bits are transmitted as zero and ignored on receipt. The format of the last 4 bytes of the LISP header would look like: Farinacci, et al. Expires December 31, 2011 [Page 20] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 x x x x 1 x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|flags| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID | LSBs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ flags: The flags field is a 3-bit field is reserved for future flag use. It MUST be set to 0 on transmit and MUST be ignored on receipt. LISP Nonce: The LISP nonce field is a 24-bit value that is randomly generated by an ITR when the N-bit is set to 1. The nonce is also used when the E-bit is set to request the nonce value to be echoed by the other side when packets are returned. When the E-bit is clear but the N-bit is set, a remote ITR is either echoing a previously requested echo-nonce or providing a random nonce. See Section 6.3.1 for more details. LISP Locator Status Bits: The locator status bits field in the LISP header is set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. Each RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator Status Bits are numbered from 0 to n-1 from the least significant bit of field. The field is 32-bits when the I-bit is set to 0 and is 8 bits when the I-bit is set to 1. When a Locator Status Bit is set to 1, the ITR is indicating to the ETR the RLOC associated with the bit ordinal has up status. See Section 6.3 for details on how an ITR can determine the status of the ETRs at the same site. When a site has multiple EID- prefixes which result in multiple mappings (where each could have a different locator-set), the Locator Status Bits setting in an encapsulated packet MUST reflect the mapping for the EID-prefix that the inner-header source EID address matches. If the LSB for an anycast locator is set to 1, then there is at least one RLOC with that address the ETR is considered 'up'. When doing ITR/PITR encapsulation: o The outer header Time to Live field (or Hop Limit field, in case of IPv6) SHOULD be copied from the inner header Time to Live field. o The outer header Type of Service field (or the Traffic Class field, in the case of IPv6) SHOULD be copied from the inner header Type of Service field (with one caveat, see below). When doing ETR/PETR decapsulation: Farinacci, et al. Expires December 31, 2011 [Page 21] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 o The inner header Time to Live field (or Hop Limit field, in case of IPv6) SHOULD be copied from the outer header Time to Live field, when the Time to Live field of the outer header is less than the Time to Live of the inner header. Failing to perform this check can cause the Time to Live of the inner header to increment across encapsulation/decapsulation cycle. This check is also performed when doing initial encapsulation when a packet comes to an ITR or PITR destined for a LISP site. o The inner header Type of Service field (or the Traffic Class field, in the case of IPv6) SHOULD be copied from the outer header Type of Service field (with one caveat, see below). Note if an ETR/PETR is also an ITR/PITR and choose to reencapsulate after decapsulating, the net effect of this is that the new outer header will carry the same Time to Live as the old outer header. Copying the TTL serves two purposes: first, it preserves the distance the host intended the packet to travel; second, and more importantly, it provides for suppression of looping packets in the event there is a loop of concatenated tunnels due to misconfiguration. See Section 9.3 for TTL exception handling for traceroute packets. The ECN field occupies bits 6 and 7 of both the IPv4 Type of Service field and the IPv6 Traffic Class field [RFC3168]. The ECN field requires special treatment in order to avoid discarding indications of congestion [RFC3168]. ITR encapsulation MUST copy the 2-bit ECN field from the inner header to the outer header. Re-encapsulation MUST copy the 2-bit ECN field from the stripped outer header to the new outer header. If the ECN field contains a congestion indication codepoint (the value is '11', the Congestion Experienced (CE) codepoint), then ETR decapsulation MUST copy the 2-bit ECN field from the stripped outer header to the surviving inner header that is used to forward the packet beyond the ETR. These requirements preserve Congestion Experienced (CE) indications when a packet that uses ECN traverses a LISP tunnel and becomes marked with a CE indication due to congestion between the tunnel endpoints. 5.4. Dealing with Large Encapsulated Packets This section proposes two mechanisms to deal with packets that exceed the path MTU between the ITR and ETR. It is left to the implementor to decide if the stateless or stateful mechanism should be implemented. Both or neither can be used since it is a local decision in the ITR regarding how to deal with MTU issues, and sites can interoperate with differing mechanisms. Farinacci, et al. Expires December 31, 2011 [Page 22] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 Both stateless and stateful mechanisms also apply to Reencapsulating and Recursive Tunneling. So any actions below referring to an ITR also apply to an TE-ITR. 5.4.1. A Stateless Solution to MTU Handling An ITR stateless solution to handle MTU issues is described as follows: 1. Define an architectural constant S for the maximum size of a packet, in bytes, an ITR would like to receive from a source inside of its site. 2. Define L to be the maximum size, in bytes, a packet of size S would be after the ITR prepends the LISP header, UDP header, and outer network layer header of size H. 3. Calculate: S + H =3D L. When an ITR receives a packet from a site-facing interface and adds H bytes worth of encapsulation to yield a packet size greater than L bytes, it resolves the MTU issue by first splitting the original packet into 2 equal-sized fragments. A LISP header is then prepended to each fragment. The size of the encapsulated fragments is then (S/2 + H), which is less than the ITR's estimate of the path MTU between the ITR and its correspondent ETR. When an ETR receives encapsulated fragments, it treats them as two individually encapsulated packets. It strips the LISP headers then forwards each fragment to the destination host of the destination site. The two fragments are reassembled at the destination host into the single IP datagram that was originated by the source host. This behavior is performed by the ITR when the source host originates a packet with the DF field of the IP header is set to 0. When the DF field of the IP header is set to 1, or the packet is an IPv6 packet originated by the source host, the ITR will drop the packet when the size is greater than L, and sends an ICMP Too Big message to the source with a value of S, where S is (L - H). When the outer header encapsulation uses an IPv4 header, an implementation SHOULD set the DF bit to 1 so ETR fragment reassembly can be avoided. An implementation MAY set the DF bit in such headers to 0 if it has good reason to believe there are unresolvable path MTU issues between the sending ITR and the receiving ETR. This specification recommends that L be defined as 1500. Farinacci, et al. Expires December 31, 2011 [Page 23] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 5.4.2. A Stateful Solution to MTU Handling An ITR stateful solution to handle MTU issues is described as follows and was first introduced in [OPENLISP]: 1. The ITR will keep state of the effective MTU for each locator per mapping cache entry. The effective MTU is what the core network can deliver along the path between ITR and ETR. 2. When an IPv6 encapsulated packet or an IPv4 encapsulated packet with DF bit set to 1, exceeds what the core network can deliver, one of the intermediate routers on the path will send an ICMP Too Big message to the ITR. The ITR will parse the ICMP message to determine which locator is affected by the effective MTU change and then record the new effective MTU value in the mapping cache entry. 3. When a packet is received by the ITR from a source inside of the site and the size of the packet is greater than the effective MTU stored with the mapping cache entry associated with the destination EID the packet is for, the ITR will send an ICMP Too Big message back to the source. The packet size advertised by the ITR in the ICMP Too Big message is the effective MTU minus the LISP encapsulation length. Even though this mechanism is stateful, it has advantages over the stateless IP fragmentation mechanism, by not involving the destination host with reassembly of ITR fragmented packets. 5.5. Using Virtualization and Segmentation with LISP When multiple organizations inside of a LISP site are using private addresses [RFC1918] as EID-prefixes, their address spaces MUST remain segregated due to possible address duplication. An Instance ID in the address encoding can aid in making the entire AFI based address unique. See IANA Considerations Section 14.1 for details for possible address encodings. An Instance ID can be carried in a LISP encapsulated packet. An ITR that prepends a LISP header, will copy a 24-bit value, used by the LISP router to uniquely identify the address space. The value is copied to the Instance ID field of the LISP header and the I-bit is set to 1. When an ETR decapsulates a packet, the Instance ID from the LISP header is used as a table identifier to locate the forwarding table to use for the inner destination EID lookup. Farinacci, et al. Expires December 31, 2011 [Page 24] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 For example, a 802.1Q VLAN tag or VPN identifier could be used as a 24-bit Instance ID. Farinacci, et al. Expires December 31, 2011 [Page 25] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 6. EID-to-RLOC Mapping 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats The following UDP packet formats are used by the LISP control-plane. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol =3D 17 | Header Checksum = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port | Dest Port | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | LISP Message | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header=3D17| Hop Limit = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Routing Locator + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | Farinacci, et al. Expires December 31, 2011 [Page 26] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 + Destination Routing Locator + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port | Dest Port | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | LISP Message | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LISP UDP-based messages are the Map-Request and Map-Reply messages. When a UDP Map-Request is sent, the UDP source port is chosen by the sender and the destination UDP port number is set to 4342. When a UDP Map-Reply is sent, the source UDP port number is set to 4342 and the destination UDP port number is copied from the source port of either the Map-Request or the invoking data packet. Implementations MUST be prepared to accept packets when either the source port or destination UDP port is set to 4342 due to NATs changing port number values. The UDP Length field will reflect the length of the UDP header and the LISP Message payload. The UDP Checksum is computed and set to non-zero for Map-Request, Map-Reply, Map-Register and ECM control messages. It MUST be checked on receipt and if the checksum fails, the packet MUST be dropped. LISP-CONS [CONS] uses TCP to send LISP control messages. The format of control messages includes the UDP header so the checksum and length fields can be used to protect and delimit message boundaries. This main LISP specification is the authoritative source for message format definitions for the Map-Request and Map-Reply messages. Farinacci, et al. Expires December 31, 2011 [Page 27] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 6.1.1. LISP Packet Type Allocations This section will be the authoritative source for allocating LISP Type values. Current allocations are: Reserved: 0 b'0000' LISP Map-Request: 1 b'0001' LISP Map-Reply: 2 b'0010' LISP Map-Register: 3 b'0011' LISP Map-Notify: 4 b'0100' LISP Encapsulated Control Message: 8 b'1000' 6.1.2. Map-Request Message Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=3D1 |A|M|P|S|p|s| Reserved | IRC | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source-EID-AFI | Source EID Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ITR-RLOC-AFI n | ITR-RLOC Address n ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Reserved | EID mask-len | EID-prefix-AFI | Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | EID-prefix ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Map-Reply Record ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mapping Protocol Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet field descriptions: Farinacci, et al. Expires December 31, 2011 [Page 28] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 Type: 1 (Map-Request) A: This is an authoritative bit, which is set to 0 for UDP-based Map- Requests sent by an ITR. M: When set, it indicates a Map-Reply Record segment is included in the Map-Request. P: This is the probe-bit which indicates that a Map-Request SHOULD be treated as a locator reachability probe. The receiver SHOULD respond with a Map-Reply with the probe-bit set, indicating the Map-Reply is a locator reachability probe reply, with the nonce copied from the Map-Request. See Section 6.3.2 for more details. S: This is the SMR bit. See Section 6.6.2 for details. p: This is the PITR bit. This bit is set to 1 when a PITR sends a Map-Request. s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is sending a Map-Request in response to a received SMR-based Map- Request. Reserved: It MUST be set to 0 on transmit and MUST be ignored on receipt. IRC: This 5-bit field is the ITR-RLOC Count which encodes the additional number of (ITR-RLOC-AFI, ITR-RLOC Address) fields present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC- Address) pair must always be encoded. Multiple ITR-RLOC Address fields are used so a Map-Replier can select which destination address to use for a Map-Reply. The IRC value ranges from 0 to 31, and for a value of 1, there are 2 ITR-RLOC addresses encoded and so on up to 31 which encodes a total of 32 ITR-RLOC addresses. Record Count: The number of records in this Map-Request message. A record is comprised of the portion of the packet that is labeled 'Rec' above and occurs the number of times equal to Record Count. For this version of the protocol, a receiver MUST accept and process Map-Requests that contain one or more records, but a sender MUST only send Map-Requests containing one record. Support for requesting multiple EIDs in a single Map-Request message will be specified in a future version of the protocol. Nonce: An 8-byte random value created by the sender of the Map- Request. This nonce will be returned in the Map-Reply. The security of the LISP mapping protocol depends critically on the strength of the nonce in the Map-Request message. The nonce Farinacci, et al. Expires December 31, 2011 [Page 29] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 SHOULD be generated by a properly seeded pseudo-random (or strong random) source. See [RFC4086] for advice on generating security- sensitive random data. Source-EID-AFI: Address family of the "Source EID Address" field. Source EID Address: This is the EID of the source host which originated the packet which is invoking this Map-Request. When Map-Requests are used for refreshing a map-cache entry or for RLOC-probing, an AFI value 0 is used and this field is of zero length. ITR-RLOC-AFI: Address family of the "ITR-RLOC Address" field that follows this field. ITR-RLOC Address: Used to give the ETR the option of selecting the destination address from any address family for the Map-Reply message. This address MUST be a routable RLOC address of the sender of the Map-Request message. EID mask-len: Mask length for EID prefix. EID-prefix-AFI: Address family of EID-prefix according to [AFI] EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 address-family. When a Map-Request is sent by an ITR because a data packet is received for a destination where there is no mapping entry, the EID-prefix is set to the destination IP address of the data packet. And the 'EID mask-len' is set to 32 or 128 for IPv4 or IPv6, respectively. When an xTR wants to query a site about the status of a mapping it already has cached, the EID- prefix used in the Map-Request has the same mask-length as the EID-prefix returned from the site when it sent a Map-Reply message. Map-Reply Record: When the M bit is set, this field is the size of a single "Record" in the Map-Reply format. This Map-Reply record contains the EID-to-RLOC mapping entry associated with the Source EID. This allows the ETR which will receive this Map-Request to cache the data if it chooses to do so. Mapping Protocol Data: See [CONS] for details. This field is optional and present when the UDP length indicates there is enough space in the packet to include it. Farinacci, et al. Expires December 31, 2011 [Page 30] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 6.1.3. EID-to-RLOC UDP Map-Request Message A Map-Request is sent from an ITR when it needs a mapping for an EID, wants to test an RLOC for reachability, or wants to refresh a mapping before TTL expiration. For the initial case, the destination IP address used for the Map-Request is the destination-EID from the packet which had a mapping cache lookup failure. For the latter 2 cases, the destination IP address used for the Map-Request is one of the RLOC addresses from the locator-set of the map cache entry. The source address is either an IPv4 or IPv6 RLOC address depending if the Map-Request is using an IPv4 versus IPv6 header, respectively. In all cases, the UDP source port number for the Map-Request message is an ITR/PITR selected 16-bit value and the UDP destination port number is set to the well-known destination port number 4342. A successful Map-Reply updates the cached set of RLOCs associated with the EID prefix range. One or more Map-Request (ITR-RLOC-AFI, ITR-RLOC-Address) fields MUST be filled in by the ITR. The number of fields (minus 1) encoded MUST be placed in the IRC field. The ITR MAY include all locally configured locators in this list or just provide one locator address from each address family it supports. If the ITR erroneously provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map- Request. Map-Requests can also be LISP encapsulated using UDP destination port 4342 with a LISP type value set to "Encapsulated Control Message", when sent from an ITR to a Map-Resolver. Likewise, Map-Requests are LISP encapsulated the same way from a Map-Server to an ETR. Details on encapsulated Map-Requests and Map-Resolvers can be found in [LISP-MS]. Map-Requests MUST be rate-limited. It is recommended that a Map- Request for the same EID-prefix be sent no more than once per second. An ITR that is configured with mapping database information (i.e. it is also an ETR) may optionally include those mappings in a Map- Request. When an ETR configured to accept and verify such "piggybacked" mapping data receives such a Map-Request and it does not have this mapping in the map-cache, it may originate a "verifying Map-Request", addressed to the map-requesting ITR. If the ETR has a map-cache entry that matches the "piggybacked" EID and the RLOC is in the locator-set for the entry, then it may send the "verifying Map- Request" directly to the originating Map-Request source. If the RLOC is not in the locator-set, then the ETR MUST send the "verifying Map- Request" to the "piggybacked" EID. Doing this forces the "verifying Map-Request" to go through the mapping database system to reach the authoritative source of information about that EID, guarding against Farinacci, et al. Expires December 31, 2011 [Page 31] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 RLOC-spoofing in in the "piggybacked" mapping data. 6.1.4. Map-Reply Message Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=3D2 |P|E|S| Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | ACT |A| Reserved | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c | Rsvd | Map-Version Number | EID-prefix-AFI | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | EID-prefix | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| Priority | Weight | M Priority | M Weight | | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o | Unused Flags |L|p|R| Loc-AFI | | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| Locator | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mapping Protocol Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet field descriptions: Type: 2 (Map-Reply) P: This is the probe-bit which indicates that the Map-Reply is in response to a locator reachability probe Map-Request. The nonce field MUST contain a copy of the nonce value from the original Map-Request. See Section 6.3.2 for more details. E: Indicates that the ETR which sends this Map-Reply message is advertising that the site is enabled for the Echo-Nonce locator reachability algorithm. See Section 6.3.1 for more details. Farinacci, et al. Expires December 31, 2011 [Page 32] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 S: This is the Security bit. When set to 1 the field following the Mapping Protocol Data field will have the following format. The detailed format of the Authentication Data Content is for further study. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AD Type | Authentication Data Content . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved: It MUST be set to 0 on transmit and MUST be ignored on receipt. Record Count: The number of records in this reply message. A record is comprised of that portion of the packet labeled 'Record' above and occurs the number of times equal to Record count. Nonce: A 24-bit value set in a Data-Probe packet or a 64-bit value from the Map-Request is echoed in this Nonce field of the Map- Reply. Record TTL: The time in minutes the recipient of the Map-Reply will store the mapping. If the TTL is 0, the entry SHOULD be removed from the cache immediately. If the value is 0xffffffff, the recipient can decide locally how long to store the mapping. Locator Count: The number of Locator entries. A locator entry comprises what is labeled above as 'Loc'. The locator count can be 0 indicating there are no locators for the EID-prefix. EID mask-len: Mask length for EID prefix. ACT: This 3-bit field describes negative Map-Reply actions. These bits are used only when the 'Locator Count' field is set to 0. The action bits are encoded only in Map-Reply messages. The actions defined are used by an ITR or PTR when a destination EID matches a negative mapping cache entry. Unassigned values should cause a map-cache entry to be created and, when packets match this negative cache entry, they will be dropped. The current assigned values are: Farinacci, et al. Expires December 31, 2011 [Page 33] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 (0) No-Action: The map-cache is kept alive and no packet encapsulation occurs. (1) Natively-Forward: The packet is not encapsulated or dropped but natively forwarded. (2) Send-Map-Request: The packet invokes sending a Map-Request. (3) Drop: A packet that matches this map-cache entry is dropped. An ICMP Unreachable message SHOULD be sent. A: The Authoritative bit, when sent by a UDP-based message is always set to 1 by an ETR. See [CONS] for TCP-based Map-Replies. When a Map-Server is proxy Map-Replying [LISP-MS] for a LISP site, the Authoritative bit is set to 0. This indicates to requesting ITRs that the Map-Reply was not originated by a LISP node managed at the site that owns the EID-prefix. Map-Version Number: When this 12-bit value is non-zero the Map-Reply sender is informing the ITR what the version number is for the EID-record contained in the Map-Reply. The ETR can allocate this number internally but MUST coordinate this value with other ETRs for the site. When this value is 0, there is no versioning information conveyed. The Map-Version Number can be included in Map-Request and Map-Register messages. See Section 6.6.3 for more details. EID-prefix-AFI: Address family of EID-prefix according to [AFI]. EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 address-family. Priority: each RLOC is assigned a unicast priority. Lower values are more preferable. When multiple RLOCs have the same priority, they may be used in a load-split fashion. A value of 255 means the RLOC MUST NOT be used for unicast forwarding. Weight: when priorities are the same for multiple RLOCs, the weight indicates how to balance unicast traffic between them. Weight is encoded as a relative weight of total unicast packets that match the mapping entry. For example if there are 4 locators in a locator set, where the weights assigned are 30, 20, 20, and 10, the first locator will get 37.5% of the traffic, the 2nd and 3rd locators will get 25% of traffic and the 4th locator will get 12.5% of the traffic. If all weights for a locator-set are equal, receiver of the Map-Reply will decide how to load-split traffic. See Section 6.5 for a suggested hash algorithm to distribute load across locators with same priority and equal weight values. Farinacci, et al. Expires December 31, 2011 [Page 34] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 M Priority: each RLOC is assigned a multicast priority used by an ETR in a receiver multicast site to select an ITR in a source multicast site for building multicast distribution trees. A value of 255 means the RLOC MUST NOT be used for joining a multicast distribution tree. M Weight: when priorities are the same for multiple RLOCs, the weight indicates how to balance building multicast distribution trees across multiple ITRs. The weight is encoded as a relative weight (similar to the unicast Weights) of total number of trees built to the source site identified by the EID-prefix. If all weights for a locator-set are equal, the receiver of the Map-Reply will decide how to distribute multicast state across ITRs. Unused Flags: set to 0 when sending and ignored on receipt. L: when this bit is set, the locator is flagged as a local locator to the ETR that is sending the Map-Reply. When a Map-Server is doing proxy Map-Replying [LISP-MS] for a LISP site, the L bit is set to 0 for all locators in this locator-set. p: when this bit is set, an ETR informs the RLOC-probing ITR that the locator address, for which this bit is set, is the one being RLOC- probed and may be different from the source address of the Map- Reply. An ITR that RLOC-probes a particular locator, MUST use this locator for retrieving the data structure used to store the fact that the locator is reachable. The "p" bit is set for a single locator in the same locator set. If an implementation sets more than one "p" bit erroneously, the receiver of the Map-Reply MUST select the first locator. The "p" bit MUST NOT be set for locator-set records sent in Map-Request and Map-Register messages. R: set when the sender of a Map-Reply has a route to the locator in the locator data record. This receiver may find this useful to know if the locator is up but not necessarily reachable from the receiver's point of view. See also Section 6.4 for another way the R-bit may be used. Locator: an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field) assigned to an ETR. Note that the destination RLOC address MAY be an anycast address. A source RLOC can be an anycast address as well. The source or destination RLOC MUST NOT be the broadcast address (255.255.255.255 or any subnet broadcast address known to the router), and MUST NOT be a link-local multicast address. The source RLOC MUST NOT be a multicast address. The destination RLOC SHOULD be a multicast address if it is being mapped from a multicast destination EID. Farinacci, et al. Expires December 31, 2011 [Page 35] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 Mapping Protocol Data: See [CONS] for details. This field is optional and present when the UDP length indicates there is enough space in the packet to include it. The Mapping Protocol Data is used when needed by the particular mapping system. 6.1.5. EID-to-RLOC UDP Map-Reply Message A Map-Reply returns an EID-prefix with a prefix length that is less than or equal to the EID being requested. The EID being requested is either from the destination field of an IP header of a Data-Probe or the EID record of a Map-Request. The RLOCs in the Map-Reply are globally-routable IP addresses of all ETRs for the LISP site. Each RLOC conveys status reachability but does not convey path reachability from a requesters perspective. Separate testing of path reachability is required, See Section 6.3 for details. Note that a Map-Reply may contain different EID-prefix granularity (prefix + length) than the Map-Request which triggers it. This might occur if a Map-Request were for a prefix that had been returned by an earlier Map-Reply. In such a case, the requester updates its cache with the new prefix information and granularity. For example, a requester with two cached EID-prefixes that are covered by a Map- Reply containing one, less-specific prefix, replaces the entry with the less-specific EID-prefix. Note that the reverse, replacement of one less-specific prefix with multiple more-specific prefixes, can also occur but not by removing the less-specific prefix rather by adding the more-specific prefixes which during a lookup will override the less-specific prefix. When an ETR is configured with overlapping EID-prefixes, a Map- Request with an EID that longest matches any EID-prefix MUST be returned in a single Map-Reply message. For instance, if an ETR had database mapping entries for EID-prefixes: 10.0.0.0/8 10.1.0.0/16 10.1.1.0/24 10.1.2.0/24 A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record count of 1 to be returned with a mapping record EID-prefix of 10.1.1.0/24. A Map-Request for EID 10.1.5.5, would cause a Map-Reply with a record count of 3 to be returned with mapping records for EID-prefixes 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24. Note that not all overlapping EID-prefixes need to be returned, only Farinacci, et al. Expires December 31, 2011 [Page 36] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 the more specifics (note in the second example above 10.0.0.0/8 was not returned for requesting EID 10.1.5.5) entries for the matching EID-prefix of the requesting EID. When more than one EID-prefix is returned, all SHOULD use the same Time-to-Live value so they can all time out at the same time. When a more specific EID-prefix is received later, its Time-to-Live value in the Map-Reply record can be stored even when other less specifics exist. When a less specific EID-prefix is received later, its map-cache expiration time SHOULD be set to the minimum expiration time of any more specific EID-prefix in the map-cache. This is done so the integrity of the EID-prefix set is wholly maintained so no more-specific entries are removed from the map-cache while keeping less-specific entries. Map-Replies SHOULD be sent for an EID-prefix no more often than once per second to the same requesting router. For scalability, it is expected that aggregation of EID addresses into EID-prefixes will allow one Map-Reply to satisfy a mapping for the EID addresses in the prefix range thereby reducing the number of Map-Request messages. Map-Reply records can have an empty locator-set. A negative Map- Reply is a Map-Reply with an empty locator-set. Negative Map-Replies convey special actions by the sender to the ITR or PTR which have solicited the Map-Reply. There are two primary applications for Negative Map-Replies. The first is for a Map-Resolver to instruct an ITR or PTR when a destination is for a LISP site versus a non-LISP site. And the other is to source quench Map-Requests which are sent for non-allocated EIDs. For each Map-Reply record, the list of locators in a locator-set MUST appear in the same order for each ETR that originates a Map-Reply message. The locator-set MUST be sorted in order of ascending IP address where an IPv4 locator address is considered numerically 'less than' an IPv6 locator address. When sending a Map-Reply message, the destination address is copied from the one of the ITR-RLOC fields from the Map-Request. The ETR can choose a locator address from one of the address families it supports. For Data-Probes, the destination address of the Map-Reply is copied from the source address of the Data-Probe message which is invoking the reply. The source address of the Map-Reply is one of the local IP addresses chosen to allow uRPF checks to succeed in the upstream service provider. The destination port of a Map-Reply message is copied from the source port of the Map-Request or Data- Probe and the source port of the Map-Reply message is set to the well-known UDP port 4342. Farinacci, et al. Expires December 31, 2011 [Page 37] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 6.1.5.1. Traffic Redirection with Coarse EID-Prefixes When an ETR is misconfigured or compromised, it could return coarse EID-prefixes in Map-Reply messages it sends. The EID-prefix could cover EID-prefixes which are allocated to other sites redirecting their traffic to the locators of the compromised site. To solve this problem, there are two basic solutions that could be used. The first is to have Map-Servers proxy-map-reply on behalf of ETRs so their registered EID-prefixes are the ones returned in Map- Replies. Since the interaction between an ETR and Map-Server is secured with shared-keys, it is more difficult for an ETR to misbehave. The second solution is to have ITRs and PTRs cache EID- prefixes with mask-lengths that are greater than or equal to a configured prefix length. This limits the damage to a specific width of any EID-prefix advertised, but needs to be coordinated with the allocation of site prefixes. These solutions can be used independently or at the same time. At the time of this writing, other approaches are being considered and researched. 6.1.6. Map-Register Message Format The usage details of the Map-Register message can be found in specification [LISP-MS]. This section solely defines the message format. The message is sent in UDP with a destination UDP port of 4342 and a randomly selected UDP source port number. The Map-Register message format is: Farinacci, et al. Expires December 31, 2011 [Page 38] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=3D3 |P| Reserved |M| Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key ID | Authentication Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Authentication Data ~ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | ACT |A| Reserved | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c | Rsvd | Map-Version Number | EID-prefix-AFI | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | EID-prefix | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| Priority | Weight | M Priority | M Weight | | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o | Unused Flags |L|p|R| Loc-AFI | | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| Locator | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet field descriptions: Type: 3 (Map-Register) P: This is the proxy-map-reply bit, when set to 1 an ETR sends a Map- Register message requesting for the Map-Server to proxy Map-Reply. The Map-Server will send non-authoritative Map-Replies on behalf of the ETR. Details on this usage will be provided in a future version of this draft. Reserved: It MUST be set to 0 on transmit and MUST be ignored on receipt. M: This is the want-map-notify bit, when set to 1 an ETR is requesting for a Map-Notify message to be returned in response to sending a Map-Register message. The Map-Notify message sent by a Map-Server is used to an acknowledge receipt of a Map-Register message. Farinacci, et al. Expires December 31, 2011 [Page 39] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 Record Count: The number of records in this Map-Register message. A record is comprised of that portion of the packet labeled 'Record' above and occurs the number of times equal to Record count. Nonce: This 8-byte Nonce field is set to 0 in Map-Register messages. Key ID: A configured ID to find the configured Message Authentication Code (MAC) algorithm and key value used for the authentication function. Authentication Data Length: The length in bytes of the Authentication Data field that follows this field. The length of the Authentication Data field is dependent on the Message Authentication Code (MAC) algorithm used. The length field allows a device that doesn't know the MAC algorithm to correctly parse the packet. Authentication Data: The message digest used from the output of the Message Authentication Code (MAC) algorithm. The entire Map- Register payload is authenticated with this field preset to 0. After the MAC is computed, it is placed in this field. Implementations of this specification MUST include support for HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256 [RFC4634] is recommended. The definition of the rest of the Map-Register can be found in the Map-Reply section. 6.1.7. Map-Notify Message Format The usage details of the Map-Notify message can be found in specification [LISP-MS]. This section solely defines the message format. The message is sent inside a UDP packet with a source UDP port equal to 4342 and a destination port equal to the source port from the Map- Register message this Map-Notify message is responding to. The Map-Notify message format is: Farinacci, et al. Expires December 31, 2011 [Page 40] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=3D4 | Reserved | Record Count = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key ID | Authentication Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Authentication Data ~ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | ACT |A| Reserved | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c | Rsvd | Map-Version Number | EID-prefix-AFI | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | EID-prefix | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| Priority | Weight | M Priority | M Weight | | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o | Unused Flags |L|p|R| Loc-AFI | | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| Locator | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet field descriptions: Type: 4 (Map-Notify) The Map-Notify message has the same contents as a Map-Register message. See Map-Register section for field descriptions. 6.1.8. Encapsulated Control Message Format An Encapsulated Control Message is used to encapsulate control packets sent between xTRs and the mapping database system described in [LISP-MS]. Farinacci, et al. Expires December 31, 2011 [Page 41] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | IPv4 or IPv6 Header | OH | (uses RLOC addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D 4342 = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LH |Type=3D8 |S| Reserved = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | IPv4 or IPv6 Header | IH | (uses RLOC or EID addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port =3D xxxx | Dest Port =3D yyyy = | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LCM | LISP Control Message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet header descriptions: OH: The outer IPv4 or IPv6 header which uses RLOC addresses in the source and destination header address fields. UDP: The outer UDP header with destination port 4342. The source port is randomly allocated. The checksum field MUST be non-zero. LH: Type 8 is defined to be a "LISP Encapsulated Control Message" and what follows is either an IPv4 or IPv6 header as encoded by the first 4 bits after the reserved field. S: This is the Security bit. When set to 1 the field following the Reserved field will have the following format. The detailed format of the Authentication Data Content is for further study. Farinacci, et al. Expires December 31, 2011 [Page 42] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AD Type | Authentication Data Content . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IH: The inner IPv4 or IPv6 header which can use either RLOC or EID addresses in the header address fields. When a Map-Request is encapsulated in this packet format the destination address in this header is an EID. UDP: The inner UDP header where the port assignments depends on the control packet being encapsulated. When the control packet is a Map-Request or Map-Register, the source port is ITR/PITR selected and the destination port is 4342. When the control packet is a Map-Reply, the source port is 4342 and the destination port is assigned from the source port of the invoking Map-Request. Port number 4341 MUST NOT be assigned to either port. The checksum field MUST be non-zero. LCM: The format is one of the control message formats described in this section. At this time, only Map-Request messages and PIM Join-Prune messages [MLISP] are allowed to be encapsulated. Encapsulating other types of LISP control messages are for further study. When Map-Requests are sent for RLOC-probing purposes (i.e the probe-bit is set), they MUST NOT be sent inside Encapsulated Control Messages. 6.2. Routing Locator Selection Both client-side and server-side may need control over the selection of RLOCs for conversations between them. This control is achieved by manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply messages. Alternatively, RLOC information may be gleaned from received tunneled packets or EID-to-RLOC Map-Request messages. The following enumerates different scenarios for choosing RLOCs and the controls that are available: o Server-side returns one RLOC. Client-side can only use one RLOC. Server-side has complete control of the selection. o Server-side returns a list of RLOC where a subset of the list has the same best priority. Client can only use the subset list according to the weighting assigned by the server-side. In this case, the server-side controls both the subset list and load- splitting across its members. The client-side can use RLOCs outside of the subset list if it determines that the subset list Farinacci, et al. Expires December 31, 2011 [Page 43] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 is unreachable (unless RLOCs are set to a Priority of 255). Some sharing of control exists: the server-side determines the destination RLOC list and load distribution while the client-side has the option of using alternatives to this list if RLOCs in the list are unreachable. o Server-side sets weight of 0 for the RLOC subset list. In this case, the client-side can choose how the traffic load is spread across the subset list. Control is shared by the server-side determining the list and the client determining load distribution. Again, the client can use alternative RLOCs if the server-provided list of RLOCs are unreachable. o Either side (more likely on the server-side ETR) decides not to send a Map-Request. For example, if the server-side ETR does not send Map-Requests, it gleans RLOCs from the client-side ITR, giving the client-side ITR responsibility for bidirectional RLOC reachability and preferability. Server-side ETR gleaning of the client-side ITR RLOC is done by caching the inner header source EID and the outer header source RLOC of received packets. The client-side ITR controls how traffic is returned and can alternate using an outer header source RLOC, which then can be added to the list the server-side ETR uses to return traffic. Since no Priority or Weights are provided using this method, the server- side ETR MUST assume each client-side ITR RLOC uses the same best Priority with a Weight of zero. In addition, since EID-prefix encoding cannot be conveyed in data packets, the EID-to-RLOC cache on tunnel routers can grow to be very large. o A "gleaned" map-cache entry, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner header IP source address) of the received encapsulated packet. A reply to this "verifying Map-Request" is used to fully populate the map- cache entry for the "gleaned" EID and is stored and used for the time indicated from the TTL field of a received Map-Reply. When a verified map-cache entry is stored, data gleaning no longer occurs for subsequent packets which have a source EID that matches the EID-prefix of the verified entry. RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be reachable when the R-bit for the locator record is set to 1. When the R-bit is set to 0, an ITR or PITR MUST not encapsulate to the RLOC. Neither the information contained in a Map-Reply or that stored in the mapping database system provides reachability information for RLOCs. Note that reachability is not part of the mapping system and is determined using one or more of the Routing Farinacci, et al. Expires December 31, 2011 [Page 44] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 Locator Reachability Algorithms described in the next section. 6.3. Routing Locator Reachability Several mechanisms for determining RLOC reachability are currently defined: 1. An ETR may examine the Loc-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC. 2. An ITR may receive an ICMP Network or ICMP Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. 3. An ITR which participates in the global routing system can determine that an RLOC is down if no BGP RIB route exists that matches the RLOC IP address. 4. An ITR may receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [INTERWORK] and LISP-encapsulated data is sent to a non-LISP-capable site. 5. An ITR may receive a Map-Reply from a ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up since the ETR was able to send the Map-Reply to the ITR. 6. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up. 7. An ITR/ETR pair can use the Locator Reachability Algorithms described in this section, namely Echo-Noncing or RLOC-Probing. When determining Locator up/down reachability by examining the Loc- Status-Bits from the LISP encapsulated data packet, an ETR will receive up to date status from an encapsulating ITR about reachability for all ETRs at the site. CE-based ITRs at the source site can determine reachability relative to each other using the site IGP as follows: o Under normal circumstances, each ITR will advertise a default route into the site IGP. Farinacci, et al. Expires December 31, 2011 [Page 45] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 o If an ITR fails or if the upstream link to its PE fails, its default route will either time-out or be withdrawn. Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator Status Bits it sets for them. RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The Loc-Status-Bits in a LISP encapsulated packet are numbered from 0 to n-1 starting with the least significant bit. For example, if an RLOC listed in the 3rd position of the Map-Reply goes down (ordinal value 2), then all ITRs at the site will clear the 3rd least significant bit (xxxx x0xx) of the Loc-Status-Bits field for the packets they encapsulate. When an ETR decapsulates a packet, it will check for any change in the Loc-Status-Bits field. When a bit goes from 1 to 0, the ETR will refrain from encapsulating packets to an RLOC that is indicated as down. It will only resume using that RLOC if the corresponding Loc- Status-Bit returns to a value of 1. Loc-Status-Bits are associated with a locator-set per EID-prefix. Therefore, when a locator becomes unreachable, the Loc-Status-Bit that corresponds to that locator's position in the list returned by the last Map-Reply will be set to zero for that particular EID-prefix. When ITRs at the site are not deployed in CE routers, the IGP can still be used to determine the reachability of Locators provided they are injected into the IGP. This is typically done when a /32 address is configured on a loopback interface. When ITRs receive ICMP Network or Host Unreachable messages as a method to determine unreachability, they will refrain from using Locators which are described in Locator lists of Map-Replies. However, using this approach is unreliable because many network operators turn off generation of ICMP Unreachable messages. If an ITR does receive an ICMP Network or Host Unreachable message, it MAY originate its own ICMP Unreachable message destined for the host that originated the data packet the ITR encapsulated. Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a locator address from a locator-set in a mapping entry matches a prefix. If it does not find one and BGP is running in the Default Free Zone (DFZ), it can decide to not use the locator even though the Loc-Status-Bits indicate the locator is up. In this case, the path from the ITR to the ETR that is assigned the locator is not available. More details are in [LOC-ID-ARCH]. Farinacci, et al. Expires December 31, 2011 [Page 46] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 Optionally, an ITR can send a Map-Request to a Locator and if a Map- Reply is returned, reachability of the Locator has been determined. Obviously, sending such probes increases the number of control messages originated by tunnel routers for active flows, so Locators are assumed to be reachable when they are advertised. This assumption does create a dependency: Locator unreachability is detected by the receipt of ICMP Host Unreachable messages. When an Locator has been determined to be unreachable, it is not used for active traffic; this is the same as if it were listed in a Map-Reply with priority 255. The ITR can test the reachability of the unreachable Locator by sending periodic Requests. Both Requests and Replies MUST be rate- limited. Locator reachability testing is never done with data packets since that increases the risk of packet loss for end-to-end sessions. When an ETR decapsulates a packet, it knows that it is reachable from the encapsulating ITR because that is how the packet arrived. In most cases, the ETR can also reach the ITR but cannot assume this to be true due to the possibility of path asymmetry. In the presence of unidirectional traffic flow from an ITR to an ETR, the ITR SHOULD NOT use the lack of return traffic as an indication that the ETR is unreachable. Instead, it MUST use an alternate mechanisms to determine reachability. 6.3.1. Echo Nonce Algorithm When data flows bidirectionally between locators from different sites, a data-plane mechanism called "nonce echoing" can be used to determine reachability between an ITR and ETR. When an ITR wants to solicit a nonce echo, it sets the N and E bits and places a 24-bit nonce in the LISP header of the next encapsulated data packet. When this packet is received by the ETR, the encapsulated packet is forwarded as normal. When the ETR next sends a data packet to the ITR, it includes the nonce received earlier with the N bit set and E bit cleared. The ITR sees this "echoed nonce" and knows the path to and from the ETR is up. The ITR will set the E-bit and N-bit for every packet it sends while in echo-nonce-request state. The time the ITR waits to process the echoed nonce before it determines the path is unreachable is variable and a choice left for the implementation. If the ITR is receiving packets from the ETR but does not see the nonce echoed while being in echo-nonce-request state, then the path Farinacci, et al. Expires December 31, 2011 [Page 47] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 to the ETR is unreachable. This decision may be overridden by other locator reachability algorithms. Once the ITR determines the path to the ETR is down it can switch to another locator for that EID-prefix. Note that "ITR" and "ETR" are relative terms here. Both devices MUST be implementing both ITR and ETR functionality for the echo nonce mechanism to operate. The ITR and ETR may both go into echo-nonce-request state at the same time. The number of packets sent or the time during which echo nonce requests are sent is an implementation specific setting. However, when an ITR is in echo-nonce-request state, it can echo the ETR's nonce in the next set of packets that it encapsulates and then subsequently, continue sending echo-nonce-request packets. This mechanism does not completely solve the forward path reachability problem as traffic may be unidirectional. That is, the ETR receiving traffic at a site may not be the same device as an ITR which transmits traffic from that site or the site to site traffic is unidirectional so there is no ITR returning traffic. The echo-nonce algorithm is bilateral. That is, if one side sets the E-bit and the other side is not enabled for echo-noncing, then the echoing of the nonce does not occur and the requesting side may regard the locator unreachable erroneously. An ITR SHOULD only set the E-bit in a encapsulated data packet when it knows the ETR is enabled for echo-noncing. This is conveyed by the E-bit in the Map- Reply message. Note that other locator reachability mechanisms are being researched and can be used to compliment or even override the Echo Nonce Algorithm. See next section for an example of control-plane probing. 6.3.2. RLOC Probing Algorithm RLOC Probing is a method that an ITR or PTR can use to determine the reachability status of one or more locators that it has cached in a map-cache entry. The probe-bit of the Map-Request and Map-Reply messages are used for RLOC Probing. RLOC probing is done in the control-plane on a timer basis where an ITR or PTR will originate a Map-Request destined to a locator address from one of its own locator addresses. A Map-Request used as an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or on the ALT like one would when soliciting mapping data. The EID record encoded in the Map-Request is the EID-prefix of the map-cache entry cached by the ITR or PTR. The ITR may include a mapping data record for its own database mapping information which contains the local Farinacci, et al. Expires December 31, 2011 [Page 48] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 EID-prefixes and RLOCs for its site. When an ETR receives a Map-Request message with the probe-bit set, it returns a Map-Reply with the probe-bit set. The source address of the Map-Reply is set from the destination address of the Map-Request and the destination address of the Map-Reply is set from the source address of the Map-Request. The Map-Reply SHOULD contain mapping data for the EID-prefix contained in the Map-Request. This provides the opportunity for the ITR or PTR, which sent the RLOC-probe to get mapping updates if there were changes to the ETR's database mapping entries. There are advantages and disadvantages of RLOC Probing. The greatest benefit of RLOC Probing is that it can handle many failure scenarios allowing the ITR to determine when the path to a specific locator is reachable or has become unreachable, thus providing a robust mechanism for switching to using another locator from the cached locator. RLOC Probing can also provide rough RTT estimates between a pair of locators which can be useful for network management purposes as well as for selecting low delay paths. The major disadvantage of RLOC Probing is in the number of control messages required and the amount of bandwidth used to obtain those benefits, especially if the requirement for failure detection times are very small. Continued research and testing will attempt to characterize the tradeoffs of failure detection times versus message overhead. 6.4. EID Reachability within a LISP Site A site may be multihomed using two or more ETRs. The hosts and infrastructure within a site will be addressed using one or more EID prefixes that are mapped to the RLOCs of the relevant ETRs in the mapping system. One possible failure mode is for an ETR to lose reachability to one or more of the EID prefixes within its own site. When this occurs when the ETR sends Map-Replies, it can clear the R-bit associated with its own locator. And when the ETR is also an ITR, it can clear its locator-status-bit in the encapsulation data header. It is recognized there are no simple solutions to the site partitioning problem because it is hard to know which part of the EID-prefix range is partitioned. And which locators can reach any sub-ranges of the EID-prefixes. This problem is under investigation with the expectation that experiments will tell us more. Note, this is not a new problem introduced by the LISP architecture. The problem exists today when a multi-homed site uses BGP to advertise its reachability upstream. Farinacci, et al. Expires December 31, 2011 [Page 49] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 6.5. Routing Locator Hashing When an ETR provides an EID-to-RLOC mapping in a Map-Reply message to a requesting ITR, the locator-set for the EID-prefix may contain different priority values for each locator address. When more than one best priority locator exists, the ITR can decide how to load share traffic against the corresponding locators. The following hash algorithm may be used by an ITR to select a locator for a packet destined to an EID for the EID-to-RLOC mapping: 1. Either a source and destination address hash can be used or the traditional 5-tuple hash which includes the source and destination addresses, source and destination TCP, UDP, or SCTP port numbers and the IP protocol number field or IPv6 next- protocol fields of a packet a host originates from within a LISP site. When a packet is not a TCP, UDP, or SCTP packet, the source and destination addresses only from the header are used to compute the hash. 2. Take the hash value and divide it by the number of locators stored in the locator-set for the EID-to-RLOC mapping. 3. The remainder will be yield a value of 0 to "number of locators minus 1". Use the remainder to select the locator in the locator-set. Note that when a packet is LISP encapsulated, the source port number in the outer UDP header needs to be set. Selecting a hashed value allows core routers which are attached to Link Aggregation Groups (LAGs) to load-split the encapsulated packets across member links of such LAGs. Otherwise, core routers would see a single flow, since packets have a source address of the ITR, for packets which are originated by different EIDs at the source site. A suggested setting for the source port number computed by an ITR is a 5-tuple hash function on the inner header, as described above. Many core router implementations use a 5-tuple hash to decide how to balance packet load across members of a LAG. The 5-tuple hash includes the source and destination addresses of the packet and the source and destination ports when the protocol number in the packet is TCP or UDP. For this reason, UDP encoding is used for LISP encapsulation. 6.6. Changing the Contents of EID-to-RLOC Mappings Since the LISP architecture uses a caching scheme to retrieve and store EID-to-RLOC mappings, the only way an ITR can get a more up-to- Farinacci, et al. Expires December 31, 2011 [Page 50] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 date mapping is to re-request the mapping. However, the ITRs do not know when the mappings change and the ETRs do not keep track of which ITRs requested its mappings. For scalability reasons, we want to maintain this approach but need to provide a way for ETRs change their mappings and inform the sites that are currently communicating with the ETR site using such mappings. When adding a new locator record in lexicographic order to the end of a locator-set, it is easy to update mappings. We assume new mappings will maintain the same locator ordering as the old mapping but just have new locators appended to the end of the list. So some ITRs can have a new mapping while other ITRs have only an old mapping that is used until they time out. When an ITR has only an old mapping but detects bits set in the loc-status-bits that correspond to locators beyond the list it has cached, it simply ignores them. However, this can only happen for locator addresses that are lexicographically greater than the locator addresses in the existing locator-set. When a locator record is inserted in the middle of a locator-set, to maintain lexicographic order, the SMR procedure in Section 6.6.2 is used to inform ITRs and PTRs of the new locator-status-bit mappings. When a locator record is removed from a locator-set, ITRs that have the mapping cached will not use the removed locator because the xTRs will set the loc-status-bit to 0. So even if the locator is in the list, it will not be used. For new mapping requests, the xTRs can set the locator AFI to 0 (indicating an unspecified address), as well as setting the corresponding loc-status-bit to 0. This forces ITRs with old or new mappings to avoid using the removed locator. If many changes occur to a mapping over a long period of time, one will find empty record slots in the middle of the locator-set and new records appended to the locator-set. At some point, it would be useful to compact the locator-set so the loc-status-bit settings can be efficiently packed. We propose here three approaches for locator-set compaction, one operational and two protocol mechanisms. The operational approach uses a clock sweep method. The protocol approaches use the concept of Solicit-Map-Requests and Map-Versioning. 6.6.1. Clock Sweep The clock sweep approach uses planning in advance and the use of count-down TTLs to time out mappings that have already been cached. The default setting for an EID-to-RLOC mapping TTL is 24 hours. So there is a 24 hour window to time out old mappings. The following clock sweep procedure is used: Farinacci, et al. Expires December 31, 2011 [Page 51] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 1. 24 hours before a mapping change is to take effect, a network administrator configures the ETRs at a site to start the clock sweep window. 2. During the clock sweep window, ETRs continue to send Map-Reply messages with the current (unchanged) mapping records. The TTL for these mappings is set to 1 hour. 3. 24 hours later, all previous cache entries will have timed out, and any active cache entries will time out within 1 hour. During this 1 hour window the ETRs continue to send Map-Reply messages with the current (unchanged) mapping records with the TTL set to 1 minute. 4. At the end of the 1 hour window, the ETRs will send Map-Reply messages with the new (changed) mapping records. So any active caches can get the new mapping contents right away if not cached, or in 1 minute if they had the mapping cached. The new mappings are cached with a time to live equal to the TTL in the Map-Reply. 6.6.2. Solicit-Map-Request (SMR) Soliciting a Map-Request is a selective way for ETRs, at the site where mappings change, to control the rate they receive requests for Map-Reply messages. SMRs are also used to tell remote ITRs to update the mappings they have cached. Since the ETRs don't keep track of remote ITRs that have cached their mappings, they do not know which ITRs need to have their mappings updated. As a result, an ETR will solicit Map-Requests (called an SMR message) from those sites to which it has been sending encapsulated data to for the last minute. In particular, an ETR will send an SMR an ITR to which it has recently sent encapsulated data. An SMR message is simply a bit set in a Map-Request message. An ITR or PTR will send a Map-Request when they receive an SMR message. Both the SMR sender and the Map-Request responder MUST rate-limited these messages. Rate-limiting can be implemented as a global rate- limiter or one rate-limiter per SMR destination. The following procedure shows how a SMR exchange occurs when a site is doing locator-set compaction for an EID-to-RLOC mapping: 1. When the database mappings in an ETR change, the ETRs at the site begin to send Map-Requests with the SMR bit set for each locator in each map-cache entry the ETR caches. Farinacci, et al. Expires December 31, 2011 [Page 52] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 2. A remote ITR which receives the SMR message will schedule sending a Map-Request message to the source locator address of the SMR message or to the mapping database system. A newly allocated random nonce is selected and the EID-prefix used is the one copied from the SMR message. If the source locator is the only locator in the cached locator-set, the remote ITR SHOULD send a Map-Request to the database mapping system just in case the single locator has changed and may no longer be reachable to accept the Map-Request. 3. The remote ITR MUST rate-limit the Map-Request until it gets a Map-Reply while continuing to use the cached mapping. When Map Versioning is used, described in Section 6.6.3, an SMR sender can detect if an ITR is using the most up to date database mapping. 4. The ETRs at the site with the changed mapping will reply to the Map-Request with a Map-Reply message that has a nonce from the SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate limited. This is important to avoid Map-Reply implosion. 5. The ETRs, at the site with the changed mapping, record the fact that the site that sent the Map-Request has received the new mapping data in the mapping cache entry for the remote site so the loc-status-bits are reflective of the new mapping for packets going to the remote site. The ETR then stops sending SMR messages. For security reasons an ITR MUST NOT process unsolicited Map-Replies. To avoid map-cache entry corruption by a third-party, a sender of an SMR-based Map-Request MUST be verified. If an ITR receives an SMR- based Map-Request and the source is not in the locator-set for the stored map-cache entry, then the responding Map-Request MUST be sent with an EID destination to the mapping database system. Since the mapping database system is more secure to reach an authoritative ETR, it will deliver the Map-Request to the authoritative source of the mapping data. When an ITR receives an SMR-based Map-Request for which it does not have a cached mapping for the EID in the SMR message, it MAY not send a SMR-invoked Map-Request. This scenario can occur when an ETR sends SMR messages to all locators in the locator-set it has stored in its map-cache but the remote ITRs that receive the SMR may not be sending packets to the site. There is no point in updating the ITRs until they need to send, in which case, they will send Map-Requests to obtain a map-cache entry. Farinacci, et al. Expires December 31, 2011 [Page 53] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 6.6.3. Database Map Versioning When there is unidirectional packet flow between an ITR and ETR, and the EID-to-RLOC mappings change on the ETR, it needs to inform the ITR so encapsulation can stop to a removed locator and start to a new locator in the locator-set. An ETR, when it sends Map-Reply messages, conveys its own Map-Version number. This is known as the Destination Map-Version Number. ITRs include the Destination Map-Version Number in packets they encapsulate to the site. When an ETR decapsulates a packet and detects the Destination Map-Version Number is less than the current version for its mapping, the SMR procedure described in Section 6.6.2 occurs. An ITR, when it encapsulates packets to ETRs, can convey its own Map- Version number. This is known as the Source Map-Version Number. When an ETR decapsulates a packet and detects the Source Map-Version Number is greater than the last Map-Version Number sent in a Map- Reply from the ITR's site, the ETR will send a Map-Request to one of the ETRs for the source site. A Map-Version Number is used as a sequence number per EID-prefix. So values that are greater, are considered to be more recent. A value of 0 for the Source Map-Version Number or the Destination Map-Version Number conveys no versioning information and an ITR does no comparison with previously received Map-Version Numbers. A Map-Version Number can be included in Map-Register messages as well. This is a good way for the Map-Server can assure that all ETRs for a site registering to it will be Map-Version number synchronized. See [VERSIONING] for a more detailed analysis and description of Database Map Versioning. Farinacci, et al. Expires December 31, 2011 [Page 54] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 7. Router Performance Considerations LISP is designed to be very hardware-based forwarding friendly. A few implementation techniques can be used to incrementally implement LISP: o When a tunnel encapsulated packet is received by an ETR, the outer destination address may not be the address of the router. This makes it challenging for the control plane to get packets from the hardware. This may be mitigated by creating special FIB entries for the EID-prefixes of EIDs served by the ETR (those for which the router provides an RLOC translation). These FIB entries are marked with a flag indicating that control plane processing should be performed. The forwarding logic of testing for particular IP protocol number value is not necessary. There are a few proven cases where no changes to existing deployed hardware were needed to support the LISP data-plane. o On an ITR, prepending a new IP header consists of adding more bytes to a MAC rewrite string and prepending the string as part of the outgoing encapsulation procedure. Routers that support GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already support this action. o A packet's source address or interface the packet was received on can be used to select a VRF (Virtual Routing/Forwarding). The VRF's routing table can be used to find EID-to-RLOC mappings. Farinacci, et al. Expires December 31, 2011 [Page 55] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 8. Deployment Scenarios This section will explore how and where ITRs and ETRs can be deployed and will discuss the pros and cons of each deployment scenario. For a more detailed deployment recommendation, refer to [LISP-DEPLOY]. There are two basic deployment trade-offs to consider: centralized versus distributed caches and flat, recursive, or re-encapsulating tunneling. When deciding on centralized versus distributed caching, the following issues should be considered: o Are the tunnel routers spread out so that the caches are spread across all the memories of each router? o Should management "touch points" be minimized by choosing few tunnel routers, just enough for redundancy? o In general, using more ITRs doesn't increase management load, since caches are built and stored dynamically. On the other hand, more ETRs does require more management since EID-prefix-to-RLOC mappings need to be explicitly configured. When deciding on flat, recursive, or re-encapsulation tunneling, the following issues should be considered: o Flat tunneling implements a single tunnel between source site and destination site. This generally offers better paths between sources and destinations with a single tunnel path. o Recursive tunneling is when tunneled traffic is again further encapsulated in another tunnel, either to implement VPNs or to perform Traffic Engineering. When doing VPN-based tunneling, the site has some control since the site is prepending a new tunnel header. In the case of TE-based tunneling, the site may have control if it is prepending a new tunnel header, but if the site's ISP is doing the TE, then the site has no control. Recursive tunneling generally will result in suboptimal paths but at the benefit of steering traffic to resource available parts of the network. o The technique of re-encapsulation ensures that packets only require one tunnel header. So if a packet needs to be rerouted, it is first decapsulated by the ETR and then re-encapsulated with a new tunnel header using a new RLOC. The next sub-sections will survey where tunnel routers can reside in the network. Farinacci, et al. Expires December 31, 2011 [Page 56] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 8.1. First-hop/Last-hop Tunnel Routers By locating tunnel routers close to hosts, the EID-prefix set is at the granularity of an IP subnet. So at the expense of more EID- prefix-to-RLOC sets for the site, the caches in each tunnel router can remain relatively small. But caches always depend on the number of non-aggregated EID destination flows active through these tunnel routers. With more tunnel routers doing encapsulation, the increase in control traffic grows as well: since the EID-granularity is greater, more Map-Requests and Map-Replies are traveling between more routers. The advantage of placing the caches and databases at these stub routers is that the products deployed in this part of the network have better price-memory ratios then their core router counterparts. Memory is typically less expensive in these devices and fewer routes are stored (only IGP routes). These devices tend to have excess capacity, both for forwarding and routing state. LISP functionality can also be deployed in edge switches. These devices generally have layer-2 ports facing hosts and layer-3 ports facing the Internet. Spare capacity is also often available in these devices as well. 8.2. Border/Edge Tunnel Routers Using customer-edge (CE) routers for tunnel endpoints allows the EID space associated with a site to be reachable via a small set of RLOCs assigned to the CE routers for that site. This is the default behavior envisioned in the rest of this specification. This offers the opposite benefit of the first-hop/last-hop tunnel router scenario: the number of mapping entries and network management touch points are reduced, allowing better scaling. One disadvantage is that less of the network's resources are used to reach host endpoints thereby centralizing the point-of-failure domain and creating network choke points at the CE router. Note that more than one CE router at a site can be configured with the same IP address. In this case an RLOC is an anycast address. This allows resilience between the CE routers. That is, if a CE router fails, traffic is automatically routed to the other routers using the same anycast address. However, this comes with the disadvantage where the site cannot control the entrance point when the anycast route is advertised out from all border routers. Another disadvantage of using anycast locators is the limited advertisement Farinacci, et al. Expires December 31, 2011 [Page 57] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 scope of /32 (or /128 for IPv6) routes. 8.3. ISP Provider-Edge (PE) Tunnel Routers Use of ISP PE routers as tunnel endpoint routers is not the typical deployment scenario envisioned in the specification. This section attempts to capture some of reasoning behind this preference of implementing LISP on CE routers. Use of ISP PE routers as tunnel endpoint routers gives an ISP, rather than a site, control over the location of the egress tunnel endpoints. That is, the ISP can decide if the tunnel endpoints are in the destination site (in either CE routers or last-hop routers within a site) or at other PE edges. The advantage of this case is that two tunnel headers can be avoided. By having the PE be the first router on the path to encapsulate, it can choose a TE path first, and the ETR can decapsulate and re-encapsulate for a tunnel to the destination end site. An obvious disadvantage is that the end site has no control over where its packets flow or the RLOCs used. Other disadvantages include the difficulty in synchronizing path liveness updates between CE and PE routers. As mentioned in earlier sections a combination of these scenarios is possible at the expense of extra packet header overhead, if both site and provider want control, then recursive or re-encapsulating tunnels are used. 8.4. LISP Functionality with Conventional NATs LISP routers can be deployed behind Network Address Translator (NAT) devices to provide the same set of packet services hosts have today when they are addressed out of private address space. It is important to note that a locator address in any LISP control message MUST be a globally routable address and therefore SHOULD NOT contain [RFC1918] addresses. If a LISP router is configured with private addresses, they MUST be used only in the outer IP header so the NAT device can translate properly. Otherwise, EID addresses MUST be translated before encapsulation is performed. Both NAT translation and LISP encapsulation functions could be co-located in the same device. More details on LISP address translation can be found in [INTERWORK]. Farinacci, et al. Expires December 31, 2011 [Page 58] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 8.5. Packets Egressing a LISP Site When a LISP site is using two ITRs for redundancy, the failure of one ITR will likely shift outbound traffic to the second. This second ITR's cache may not not be populated with the same EID-to-RLOC mapping entries as the first. If this second ITR does not have these mappings, traffic will be dropped while the mappings are retrieved from the mapping system. The retrieval of these messages may increase the load of requests being sent into the mapping system. Deployment and experimentation will determine whether this issue requires more attention. Farinacci, et al. Expires December 31, 2011 [Page 59] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 9. Traceroute Considerations When a source host in a LISP site initiates a traceroute to a destination host in another LISP site, it is highly desirable for it to see the entire path. Since packets are encapsulated from ITR to ETR, the hop across the tunnel could be viewed as a single hop. However, LISP traceroute will provide the entire path so the user can see 3 distinct segments of the path from a source LISP host to a destination LISP host: Segment 1 (in source LISP site based on EIDs): source-host ---> first-hop ... next-hop ---> ITR Segment 2 (in the core network based on RLOCs): ITR ---> next-hop ... next-hop ---> ETR Segment 3 (in the destination LISP site based on EIDs): ETR ---> next-hop ... last-hop ---> destination-host For segment 1 of the path, ICMP Time Exceeded messages are returned in the normal matter as they are today. The ITR performs a TTL decrement and test for 0 before encapsulating. So the ITR hop is seen by the traceroute source has an EID address (the address of site-facing interface). For segment 2 of the path, ICMP Time Exceeded messages are returned to the ITR because the TTL decrement to 0 is done on the outer header, so the destination of the ICMP messages are to the ITR RLOC address, the source RLOC address of the encapsulated traceroute packet. The ITR looks inside of the ICMP payload to inspect the traceroute source so it can return the ICMP message to the address of the traceroute client as well as retaining the core router IP address in the ICMP message. This is so the traceroute client can display the core router address (the RLOC address) in the traceroute output. The ETR returns its RLOC address and responds to the TTL decrement to 0 like the previous core routers did. For segment 3, the next-hop router downstream from the ETR will be decrementing the TTL for the packet that was encapsulated, sent into the core, decapsulated by the ETR, and forwarded because it isn't the final destination. If the TTL is decremented to 0, any router on the path to the destination of the traceroute, including the next-hop router or destination, will send an ICMP Time Exceeded message to the source EID of the traceroute client. The ICMP message will be Farinacci, et al. Expires December 31, 2011 [Page 60] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 encapsulated by the local ITR and sent back to the ETR in the originated traceroute source site, where the packet will be delivered to the host. 9.1. IPv6 Traceroute IPv6 traceroute follows the procedure described above since the entire traceroute data packet is included in ICMP Time Exceeded message payload. Therefore, only the ITR needs to pay special attention for forwarding ICMP messages back to the traceroute source. 9.2. IPv4 Traceroute For IPv4 traceroute, we cannot follow the above procedure since IPv4 ICMP Time Exceeded messages only include the invoking IP header and 8 bytes that follow the IP header. Therefore, when a core router sends an IPv4 Time Exceeded message to an ITR, all the ITR has in the ICMP payload is the encapsulated header it prepended followed by a UDP header. The original invoking IP header, and therefore the identity of the traceroute source is lost. The solution we propose to solve this problem is to cache traceroute IPv4 headers in the ITR and to match them up with corresponding IPv4 Time Exceeded messages received from core routers and the ETR. The ITR will use a circular buffer for caching the IPv4 and UDP headers of traceroute packets. It will select a 16-bit number as a key to find them later when the IPv4 Time Exceeded messages are received. When an ITR encapsulates an IPv4 traceroute packet, it will use the 16-bit number as the UDP source port in the encapsulating header. When the ICMP Time Exceeded message is returned to the ITR, the UDP header of the encapsulating header is present in the ICMP payload thereby allowing the ITR to find the cached headers for the traceroute source. The ITR puts the cached headers in the payload and sends the ICMP Time Exceeded message to the traceroute source retaining the source address of the original ICMP Time Exceeded message (a core router or the ETR of the site of the traceroute destination). The signature of a traceroute packet comes in two forms. The first form is encoded as a UDP message where the destination port is inspected for a range of values. The second form is encoded as an ICMP message where the IP identification field is inspected for a well-known value. 9.3. Traceroute using Mixed Locators When either an IPv4 traceroute or IPv6 traceroute is originated and the ITR encapsulates it in the other address family header, you Farinacci, et al. Expires December 31, 2011 [Page 61] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 cannot get all 3 segments of the traceroute. Segment 2 of the traceroute can not be conveyed to the traceroute source since it is expecting addresses from intermediate hops in the same address format for the type of traceroute it originated. Therefore, in this case, segment 2 will make the tunnel look like one hop. All the ITR has to do to make this work is to not copy the inner TTL to the outer, encapsulating header's TTL when a traceroute packet is encapsulated using an RLOC from a different address family. This will cause no TTL decrement to 0 to occur in core routers between the ITR and ETR. Farinacci, et al. Expires December 31, 2011 [Page 62] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 10. Mobility Considerations There are several kinds of mobility of which only some might be of concern to LISP. Essentially they are as follows. 10.1. Site Mobility A site wishes to change its attachment points to the Internet, and its LISP Tunnel Routers will have new RLOCs when it changes upstream providers. Changes in EID-RLOC mappings for sites are expected to be handled by configuration, outside of the LISP protocol. 10.2. Slow Endpoint Mobility An individual endpoint wishes to move, but is not concerned about maintaining session continuity. Renumbering is involved. LISP can help with the issues surrounding renumbering [RFC4192] [LISA96] by decoupling the address space used by a site from the address spaces used by its ISPs. [RFC4984] 10.3. Fast Endpoint Mobility Fast endpoint mobility occurs when an endpoint moves relatively rapidly, changing its IP layer network attachment point. Maintenance of session continuity is a goal. This is where the Mobile IPv4 [RFC3344bis] and Mobile IPv6 [RFC3775] [RFC4866] mechanisms are used, and primarily where interactions with LISP need to be explored. The problem is that as an endpoint moves, it may require changes to the mapping between its EID and a set of RLOCs for its new network location. When this is added to the overhead of mobile IP binding updates, some packets might be delayed or dropped. In IPv4 mobility, when an endpoint is away from home, packets to it are encapsulated and forwarded via a home agent which resides in the home area the endpoint's address belongs to. The home agent will encapsulate and forward packets either directly to the endpoint or to a foreign agent which resides where the endpoint has moved to. Packets from the endpoint may be sent directly to the correspondent node, may be sent via the foreign agent, or may be reverse-tunneled back to the home agent for delivery to the mobile node. As the mobile node's EID or available RLOC changes, LISP EID-to-RLOC mappings are required for communication between the mobile node and the home agent, whether via foreign agent or not. As a mobile endpoint changes networks, up to three LISP mapping changes may be required: Farinacci, et al. Expires December 31, 2011 [Page 63] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 o The mobile node moves from an old location to a new visited network location and notifies its home agent that it has done so. The Mobile IPv4 control packets the mobile node sends pass through one of the new visited network's ITRs, which needs a EID-RLOC mapping for the home agent. o The home agent might not have the EID-RLOC mappings for the mobile node's "care-of" address or its foreign agent in the new visited network, in which case it will need to acquire them. o When packets are sent directly to the correspondent node, it may be that no traffic has been sent from the new visited network to the correspondent node's network, and the new visited network's ITR will need to obtain an EID-RLOC mapping for the correspondent node's site. In addition, if the IPv4 endpoint is sending packets from the new visited network using its original EID, then LISP will need to perform a route-returnability check on the new EID-RLOC mapping for that EID. In IPv6 mobility, packets can flow directly between the mobile node and the correspondent node in either direction. The mobile node uses its "care-of" address (EID). In this case, the route-returnability check would not be needed but one more LISP mapping lookup may be required instead: o As above, three mapping changes may be needed for the mobile node to communicate with its home agent and to send packets to the correspondent node. o In addition, another mapping will be needed in the correspondent node's ITR, in order for the correspondent node to send packets to the mobile node's "care-of" address (EID) at the new network location. When both endpoints are mobile the number of potential mapping lookups increases accordingly. As a mobile node moves there are not only mobility state changes in the mobile node, correspondent node, and home agent, but also state changes in the ITRs and ETRs for at least some EID-prefixes. The goal is to support rapid adaptation, with little delay or packet loss for the entire system. Also IP mobility can be modified to require fewer mapping changes. In order to increase overall system performance, there may be a need to reduce the optimization of one area in order to place fewer demands on another. Farinacci, et al. Expires December 31, 2011 [Page 64] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 In LISP, one possibility is to "glean" information. When a packet arrives, the ETR could examine the EID-RLOC mapping and use that mapping for all outgoing traffic to that EID. It can do this after performing a route-returnability check, to ensure that the new network location does have a internal route to that endpoint. However, this does not cover the case where an ITR (the node assigned the RLOC) at the mobile-node location has been compromised. Mobile IP packet exchange is designed for an environment in which all routing information is disseminated before packets can be forwarded. In order to allow the Internet to grow to support expected future use, we are moving to an environment where some information may have to be obtained after packets are in flight. Modifications to IP mobility should be considered in order to optimize the behavior of the overall system. Anything which decreases the number of new EID- RLOC mappings needed when a node moves, or maintains the validity of an EID-RLOC mapping for a longer time, is useful. 10.4. Fast Network Mobility In addition to endpoints, a network can be mobile, possibly changing xTRs. A "network" can be as small as a single router and as large as a whole site. This is different from site mobility in that it is fast and possibly short-lived, but different from endpoint mobility in that a whole prefix is changing RLOCs. However, the mechanisms are the same and there is no new overhead in LISP. A map request for any endpoint will return a binding for the entire mobile prefix. If mobile networks become a more common occurrence, it may be useful to revisit the design of the mapping service and allow for dynamic updates of the database. The issue of interactions between mobility and LISP needs to be explored further. Specific improvements to the entire system will depend on the details of mapping mechanisms. Mapping mechanisms should be evaluated on how well they support session continuity for mobile nodes. 10.5. LISP Mobile Node Mobility A mobile device can use the LISP infrastructure to achieve mobility by implementing the LISP encapsulation and decapsulation functions and acting as a simple ITR/ETR. By doing this, such a "LISP mobile node" can use topologically-independent EID IP addresses that are not advertised into and do not impose a cost on the global routing system. These EIDs are maintained at the edges of the mapping system (in LISP Map-Servers and Map-Resolvers) and are provided on demand to only the correspondents of the LISP mobile node. Farinacci, et al. Expires December 31, 2011 [Page 65] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 Refer to the LISP Mobility Architecture specification [LISP-MN] for more details. Farinacci, et al. Expires December 31, 2011 [Page 66] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 11. Multicast Considerations A multicast group address, as defined in the original Internet architecture is an identifier of a grouping of topologically independent receiver host locations. The address encoding itself does not determine the location of the receiver(s). The multicast routing protocol, and the network-based state the protocol creates, determines where the receivers are located. In the context of LISP, a multicast group address is both an EID and a Routing Locator. Therefore, no specific semantic or action needs to be taken for a destination address, as it would appear in an IP header. Therefore, a group address that appears in an inner IP header built by a source host will be used as the destination EID. The outer IP header (the destination Routing Locator address), prepended by a LISP router, will use the same group address as the destination Routing Locator. Having said that, only the source EID and source Routing Locator needs to be dealt with. Therefore, an ITR merely needs to put its own IP address in the source Routing Locator field when prepending the outer IP header. This source Routing Locator address, like any other Routing Locator address MUST be globally routable. Therefore, an EID-to-RLOC mapping does not need to be performed by an ITR when a received data packet is a multicast data packet or when processing a source-specific Join (either by IGMPv3 or PIM). But the source Routing Locator is decided by the multicast routing protocol in a receiver site. That is, an EID to Routing Locator translation is done at control-time. Another approach is to have the ITR not encapsulate a multicast packet and allow the host built packet to flow into the core even if the source address is allocated out of the EID namespace. If the RPF-Vector TLV [RFC5496] is used by PIM in the core, then core routers can RPF to the ITR (the Locator address which is injected into core routing) rather than the host source address (the EID address which is not injected into core routing). To avoid any EID-based multicast state in the network core, the first approach is chosen for LISP-Multicast. Details for LISP-Multicast and Interworking with non-LISP sites is described in specification [MLISP]. Farinacci, et al. Expires December 31, 2011 [Page 67] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 12. Security Considerations It is believed that most of the security mechanisms will be part of the mapping database service when using control plane procedures for obtaining EID-to-RLOC mappings. For data plane triggered mappings, as described in this specification, protection is provided against ETR spoofing by using Return- Routability mechanisms evidenced by the use of a 24-bit Nonce field in the LISP encapsulation header and a 64-bit Nonce field in the LISP control message. The nonce, coupled with the ITR accepting only solicited Map-Replies goes a long way toward providing decent authentication. LISP does not rely on a PKI infrastructure or a more heavy weight authentication system. These systems challenge the scalability of LISP which was a primary design goal. DoS attack prevention will depend on implementations rate-limiting Map-Requests and Map-Replies to the control plane as well as rate- limiting the number of data-triggered Map-Replies. An incorrectly implemented or malicious ITR might choose to ignore the priority and weights provided by the ETR in its Map-Reply. This traffic steering would be limited to the traffic that is sent by this ITR's site, and no more severe than if the site initiated a bandwidth DoS attack on (one of) the ETR's ingress links. The ITR's site would typically gain no benefit from not respecting the weights, and would likely to receive better service by abiding by them. To deal with map-cache exhaustion attempts in an ITR/PTR, the implementation should consider putting a maximum cap on the number of entries stored with a reserve list for special or frequently accessed sites. This should be a configuration policy control set by the network administrator who manages ITRs and PTRs. When overlapping EID-prefixes occur across multiple map-cache entries, the integrity of the set must be wholly maintained. So if a more-specific entry cannot be added due to reaching the maximum cap, then none of the less specifics should be stored in the map-cache. Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings, cache sizing and maintenance is an issue to be kept in mind during implementation. It is a good idea to have instrumentation in place to detect thrashing of the cache. Implementation experimentation will be used to determine which cache management strategies work best. It should be noted that an undersized cache in an ITR/PTR not only causes adverse affect on the site or region they support, but may also cause increased Map-Request load on the mapping system. There is a security risk implicit in the fact that ETRs generate the Farinacci, et al. Expires December 31, 2011 [Page 68] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 EID prefix to which they are responding. An ETR can claim a shorter prefix than it is actually responsible for. Various mechanisms to ameliorate or resolve this issue will be examined in the future, [LISP-SEC]. Spoofing of inner header addresses of LISP encapsulated packets is possible like with any tunneling mechanism. ITRs MUST verify the source address of a packet to be an EID that belongs to the site's EID-prefix range prior to encapsulation. An ETR must only decapsulate and forward datagrams with an inner header destination that matches one of its EID-prefix ranges. If, upon receipt and decapsulation, the destination EID of a datagram does not match one of the ETR's configured EID-prefixes, the ETR MUST drop the datragram. If a LISP encapsulated packet arrives at an ETR, it MAY compare the inner header source EID address and the outer header source RLOC address with the mapping that exists in the mapping database. Then when spoofing attacks occur, the outer header source RLOC address can be used to trace back the attack to the source site, using existing operational tools. This experimental specification does not address automated key management (AKM). BCP 107 provides guidance in this area. In addition, at the time of this writing, substantial work is being undertaken to improve security of the routing system [KARP], [RPKI], [BGP-SEC], [LISP-SEC], Future work on LISP should address BCP-107 as well as other open security considerations, which may require changes to this specification. Farinacci, et al. Expires December 31, 2011 [Page 69] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 13. Network Management Considerations Considerations for Network Management tools exist so the LISP protocol suite can be operationally managed. The mechanisms can be found in [LISP-MIB] and [LISP-LIG]. Farinacci, et al. Expires December 31, 2011 [Page 70] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 14. IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the LISP specification, in accordance with BCP 26 and RFC 5226 [RFC5226]. There are two name spaces in LISP that require registration: o LISP IANA registry allocations should not be made for purposes unrelated to LISP routing or transport protocols. o The following policies are used here with the meanings defined in BCP 26: "Specification Required", "IETF Consensus", "Experimental Use", "First Come First Served". 14.1. LISP Address Type Codes Instance ID type codes have a range from 0 to 15, of which 0 and 1 have been allocated [LCAF]. New Type Codes MUST be allocated starting at 2. Type Codes 2 - 10 are to be assigned by IETF Review. Type Codes 11 - 15 are available on a First Come First Served policy. The following codes have been allocated: Type 0: Null Body Type Type 1: AFI List Type See [LCAF] for details for other possible unapproved address encodings. The unapproved LCAF encodings are an area for further study and experimentation. 14.2. LISP UDP Port Numbers The IANA registry has allocated UDP port numbers 4341 and 4342 for LISP data-plane and control-plane operation, respectively. Farinacci, et al. Expires December 31, 2011 [Page 71] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 15. References 15.1. Normative References [BGP-SEC] Lepinski, M., "An Overview of BGPSEC", draft-lepinski-bgpsec-overview-00.txt (work in progress), March 2011. [KARP] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP)Design Guidelines", draft-ietf-karp-design-guide-02.txt (work in progress), March 2011. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. Farinacci, et al. Expires December 31, 2011 [Page 72] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006. [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006. [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, May 2007. [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, March 2009. [RPKI] Lepinski, M., "An Infrastructure to Support Secure Internet Routing", draft-ietf-sidr-arch-12.txt (work in progress), February 2011. [UDP-TUNNELS] Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled Packets", draft-eubanks-chimento-6man-01.txt (work in progress), October 2010. 15.2. Informative References [AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY NUMBERS http://www.iana.org/assignments/address-family-numbers, January 2011. [AFI-REGISTRY] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY NUMBER registry http://www.iana.org/assignments/ address-family-numbers/ address-family-numbers.xml#address-family-numbers-1, Farinacci, et al. Expires December 31, 2011 [Page 73] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 January 2011. [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP Alternative Topology (LISP-ALT)", draft-ietf-lisp-alt-07.txt (work in progress), June 2011. [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed Enhancement to the Internet Architecture", Internet- Draft http://www.chiappa.net/~jnc/tech/endpoints.txt, 1999. [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A Content distribution Overlay Network Service for LISP", draft-meyer-lisp-cons-03.txt (work in progress), November 2007. [EMACS] Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID Mappings Multicast Across Cooperating Systems for LISP", draft-curran-lisp-emacs-00.txt (work in progress), November 2007. [INTERWORK] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking LISP with IPv4 and IPv6", draft-ietf-lisp-interworking-02.txt (work in progress), June 2011. [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format", draft-farinacci-lisp-lcaf-04.txt (work in progress), October 2010. [LISA96] Lear, E., Katinsky, J., Coffin, J., and D. Tharp, "Renumbering: Threat or Menace?", Usenix , September 1996. [LISP-DEPLOY] Jakab, L., Coras, F., Domingo-Pascual, J., and D. Lewis, "LISP Network Element Deployment Considerations", draft-jakab-lisp-deployment-02.txt (work in progress), February 2011. [LISP-LIG] Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)", draft-ietf-lisp-lig-01.txt (work in progress), October 2010. [LISP-MAIN] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", Farinacci, et al. Expires December 31, 2011 [Page 74] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 draft-farinacci-lisp-12.txt (work in progress), March 2009. [LISP-MIB] Schudel, G., Jain, A., and V. Moreno, "LISP MIB", draft-ietf-lisp-mib-01.txt (work in progress), March 2011. [LISP-MN] Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP Mobility Architecture", draft-meyer-lisp-mn-04.txt (work in progress), October 2010. [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", draft-ietf-lisp-ms-09.txt (work in progress), June 2011. [LISP-SEC] Maino, F., Ermagon, V., Cabellos, A., Sausez, D., and O. Bonaventure, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-00.txt (work in progress), June 2011. [LOC-ID-ARCH] Meyer, D. and D. Lewis, "Architectural Implications of Locator/ID Separation", draft-meyer-loc-id-implications-01.txt (work in progress), Januaryr 2009. [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "LISP for Multicast Environments", draft-ietf-lisp-multicast-06.txt (work in progress), June 2011. [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", draft-lear-lisp-nerd-08.txt (work in progress), March 2010. [OPENLISP] Iannone, L. and O. Bonaventure, "OpenLISP Implementation Report", draft-iannone-openlisp-implementation-01.txt (work in progress), July 2008. [RADIR] Narten, T., "Routing and Addressing Problem Statement", draft-narten-radir-problem-statement-00.txt (work in progress), July 2007. [RFC3344bis] Perkins, C., "IP Mobility Support for IPv4, revised", draft-ietf-mip4-rfc3344bis-05 (work in progress), July 2007. Farinacci, et al. Expires December 31, 2011 [Page 75] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005. [RPMD] Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol for Routing Protocol Meta-data Dissemination", draft-handley-p2ppush-unpublished-2007726.txt (work in progress), July 2007. [VERSIONING] Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping Versioning", draft-ietf-lisp-map-versioning-01.txt (work in progress), March 2011. Farinacci, et al. Expires December 31, 2011 [Page 76] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 Appendix A. Acknowledgments An initial thank you goes to Dave Oran for planting the seeds for the initial ideas for LISP. His consultation continues to provide value to the LISP authors. A special and appreciative thank you goes to Noel Chiappa for providing architectural impetus over the past decades on separation of location and identity, as well as detailed review of the LISP architecture and documents, coupled with enthusiasm for making LISP a practical and incremental transition for the Internet. The authors would like to gratefully acknowledge many people who have contributed discussion and ideas to the making of this proposal. They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller, Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston, David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Terry Manderson, Roger Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari Arkko, Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu, Dhirendra Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina Ermagan, Albert Cabellos, Fabio Maino, Victor Moreno, Chris White, Clarence Filsfils, and Alia Atlas. This work originated in the Routing Research Group (RRG) of the IRTF. The individual submission [LISP-MAIN] was converted into this IETF LISP working group draft. Farinacci, et al. Expires December 31, 2011 [Page 77] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 Appendix B. Document Change Log B.1. Changes to draft-ietf-lisp-14.txt o Post working group last call and pre-IESG last call review. o Indicate that an ICMP Unreachable message should be sent when a packet matches a drop-based negative map-cache entry. o Indicate how a map-cache set of overlapping EID-prefixes must maintian integrity when the map-cache maximum cap is reached. o Add Joel's description for the definition of an EID, that the bit string value can be an RLOC for another device in abstract but the architecture allows it to be an EID of one device and the same value as an RLOC for another device. o In the "Tunnel Encapsulation Details" section, indicate that 4 combinations of encapsulation are supported. o Add what ETR should do for a Data-Probe when received for a destination EID outside of its EID-prefix range. This was added in the Data Probe definition section. o Added text indicating that more-specific EID-prefixes must not be removed when less-specific entries stay in the map-cache. This is to preserve the integrity of the EID-prefix set. o Add clarifying text in the Security Considerations section about how an ETR must not decapsulate and forward a packet that is not for its configured EID-prefix range. B.2. Changes to draft-ietf-lisp-13.txt o Posted June 2011 to complete working group last call. o Tracker item 87. Put Yakov suggested wording in the EID-prefix definition section to reference [INTERWORK] and [LISP-DEPLOY] about discussion on transition and access mechanisms. o Change "ITRs" to "ETRs" in the Locator Status Bit definition section and data packet description section per Damien's comment. o Remove the normative reference to [LISP-SEC] when describing the S-bit in the ECM and Map-Reply headers. o Tracker item 54. Added text from John Scudder in the "Packets Egressing a LISP Site" section. Farinacci, et al. Expires December 31, 2011 [Page 78] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 o Add sentence to the "Reencapsulating Tunnel" definition about how reencapsulation loops can occur when not coordinating among multiple mapping database systems. o Remove "In theory" from a sentence in the Security Considerations section. o Remove Security Area Statement title and reword section with Eliot's provided text. The text was agreed upon by LISP-WG chairs and Security ADs. o Remove word "potential" from the over-claiming paragraph of the Security Considerations section per Stephen's request. o Wordsmithing and other editorial comments from Alia. B.3. Changes to draft-ietf-lisp-12.txt o Posted April 2011. o Tracker item 87. Provided rewording how an EID-prefix can be resued in the definition section of "EID-prefix". o Tracker item 95. Change "eliminate" to "defer" in section 4.1. o Tracker item 110. Added that the Mapping Protocol Data field in the Map-Reply message is only used when needed by the particular Mapping Database System. o Tracker item 111. Indicate that if an LSB that is assocaited with an anycast address, that there is at least one RLOC that is up. o Tracker item 108. Make clear the R-bit does not define RLOC path reachability. o Tracker item 107. Indicate that weights are relative to each other versus requiring an addition of up to 100%. o Tracker item 46. Add a sentence how LISP products should be sized for the appropriate demand so cache thrashing is avoided. o Change some references of RFC 5226 to [AFI] per Luigi. o Per Luigi, make reference to "EID-AFI" consistent to "EID-prefix- AFI". o Tracker item 66. Indicate that appending locators to a locator- set is done when the added locators are lexicographically greater Farinacci, et al. Expires December 31, 2011 [Page 79] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 than the previous ones in the set. o Tracker item 87. Once again reword the definition of the EID- prefix to reflect recent comments. o Tracker item 70. Added text to security section on what the implications could be if an ITR does not obey priority and weights from a Map-Reply message. o Tracker item 54. Added text to the new section titled "Packets Egressing a LISP Site" to describe the implications when two or more ITRs exist at a site where only one ITR is used for egress traffic and when there is a shift of traffic to the others, how the map-cache will need to be populated in those new egress ITRs. o Tracker item 33. Make more clear in the Routing Locator Selection section what an ITR should do when it sees an R-bit of 0 in a locator-record of a Map-Reply. o Tracker item 33. Add paragraph to the EID Reachability section indicating that site parittioning is under investigation. o Tracker item 58. Added last paragraph of Security Considerations section about how to protect inner header EID address spoofing attacks. o Add suggested Sam text to indicate that all security concerns need not be addressed for moving document to Experimental RFC status. Put this in a subsection of the Secuirty Considerations section. B.4. Changes to draft-ietf-lisp-11.txt o Posted March 30, 2011. o Change IANA URL. The URL we had pointed to a general protocol numbers page. o Added the "s" bit to the Map-Request to allow SMR-invoked Map- Requests to be sent to a MN ETR via the map-server. o Generalize text for the defintion of Reencapsuatling tunnels. o Add pargraph suggested by Joel to explain how implementation experimentation will be used to determine the proper cache management techniques. o Add Yakov provided text for the definition of "EID-to-RLOC "Database". Farinacci, et al. Expires December 31, 2011 [Page 80] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 o Add reference in Section 8, Deployment Scenarios, to the draft-jakab-lisp-deploy-02.txt draft. o Clarify sentence about no hardware changes needed to support LISP encapsulation. o Add paragraph about what is the procedure when a locator is inserted in the middle of a locator-set. o Add a definition for Locator-Status-Bits so we can emphasize they are used as a hint for router up/down status and not path reachability. o Change "BGP RIB" to "RIB" per Clarence's comment. o Fixed complaints by IDnits. o Add subsection to Security Considerations section indicating how EID-prefix overclaiming in Map-Replies is for further study and add a reference to LISP-SEC. B.5. Changes to draft-ietf-lisp-10.txt o Posted March 2011. o Add p-bit to Map-Request so there is documentary reasons to know when a PITR has sent a Map-Request to an ETR. o Add Map-Notify message which is used to acknowledge a Map-Register message sent to a Map-Server. o Add M-bit to the Map-Register message so an ETR that wants an acknowledgment for the Map-Register can request one. o Add S-bit to the ECM and Map-Reply messages to describe security data that can be present in each message. Then refer to [LISP-SEC] for expansive details. o Add Network Management Considerations section and point to the MIB and LIG drafts. o Remove the word "simple" per Yakov's comments. B.6. Changes to draft-ietf-lisp-09.txt o Posted October 2010. Farinacci, et al. Expires December 31, 2011 [Page 81] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 o Add to IANA Consideration section about the use of LCAF Type values that accepted and maintained by the IANA registry and not the LCAF specification. o Indicate that implementations should be able to receive LISP control messages when either UDP port is 4342, so they can be robust in the face of intervening NAT boxes. o Add paragraph to SMR section to indicate that an ITR does not need to respond to an SMR-based Map-Request when it has no map-cache entry for the SMR source's EID-prefix. B.7. Changes to draft-ietf-lisp-08.txt o Posted August 2010. o In section 6.1.6, remove statement about setting TTL to 0 in Map- Register messages. o Clarify language in section 6.1.5 about Map-Replying to Data- Probes or Map-Requests. o Indicate that outer TTL should only be copied to inner TTL when it is less than inner TTL. o Indicate a source-EID for RLOC-probes are encoded with an AFI value of 0. o Indicate that SMRs can have a global or per SMR destination rate- limiter. o Add clarifications to the SMR procedures. o Add definitions for "client-side" and 'server-side" terms used in this specification. o Clear up language in section 6.4, last paragraph. o Change ACT of value 0 to "no-action". This is so we can RLOC- probe a PETR and have it return a Map-Reply with a locator-set of size 0. The way it is spec'ed the map-cache entry has action "dropped". Drop-action is set to 3. o Add statement about normalizing locator weights. o Clarify R-bit definition in the Map-Reply locator record. Farinacci, et al. Expires December 31, 2011 [Page 82] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 o Add section on EID Reachability within a LISP site. o Clarify another disadvantage of using anycast locators. o Reworded Abstract. o Change section 2.0 Introduction to remove obsolete information such as the LISP variant definitions. o Change section 5 title from "Tunneling Details" to "LISP Encapsulation Details". o Changes to section 5 to include results of network deployment experience with MTU. Recommend that implementations use either the stateful or stateless handling. o Make clarification wordsmithing to Section 7 and 8. o Identify that if there is one locator in the locator-set of a map- cache entry, that an SMR from that locator should be responded to by sending the the SMR-invoked Map-Request to the database mapping system rather than to the RLOC itself (which may be unreachable). o When describing Unicast and Multicast Weights indicate the the values are relative weights rather than percentages. So it doesn't imply the sum of all locator weights in the locator-set need to be 100. o Do some wordsmithing on copying TTL and TOS fields. o Numerous wordsmithing changes from Dave Meyer. He fine toothed combed the spec. o Removed Section 14 "Prototype Plans and Status". We felt this type of section is no longer appropriate for a protocol specification. o Add clarification text for the IRC description per Damien's commentary. o Remove text on copying nonce from SMR to SMR-invoked Map- Request per Vina's comment about a possible DoS vector. o Clarify (S/2 + H) in the stateless MTU section. o Add text to reflect Damien's comment about the description of the "ITR-RLOC Address" field in the Map-Request. that the list of RLOC addresses are local addresses of the Map-Requester. Farinacci, et al. Expires December 31, 2011 [Page 83] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 B.8. Changes to draft-ietf-lisp-07.txt o Posted April 2010. o Added I-bit to data header so LSB field can also be used as an Instance ID field. When this occurs, the LSB field is reduced to 8-bits (from 32-bits). o Added V-bit to the data header so the 24-bit nonce field can also be used for source and destination version numbers. o Added Map-Version 12-bit value to the EID-record to be used in all of Map-Request, Map-Reply, and Map-Register messages. o Added multiple ITR-RLOC fields to the Map-Request packet so an ETR can decide what address to select for the destination of a Map- Reply. o Added L-bit (Local RLOC bit) and p-bit (Probe-Reply RLOC bit) to the Locator-Set record of an EID-record for a Map-Reply message. The L-bit indicates which RLOCs in the locator-set are local to the sender of the message. The P-bit indicates which RLOC is the source of a RLOC-probe Reply (Map-Reply) message. o Add reference to the LISP Canonical Address Format [LCAF] draft. o Made editorial and clarification changes based on comments from Dhirendra Trivedi. o Added wordsmithing comments from Joel Halpern on DF=3D1 setting. o Add John Zwiebel clarification to Echo Nonce Algorithm section 6.3.1. o Add John Zwiebel comment about expanding on proxy-map-reply bit for Map-Register messages. o Add NAT section per Ron Bonica comments. o Fix IDnits issues per Ron Bonica. o Added section on Virtualization and Segmentation to explain the use if the Instance ID field in the data header. o There are too many P-bits, keep their scope to the packet format description and refer to them by name every where else in the spec. Farinacci, et al. Expires December 31, 2011 [Page 84] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 o Scanned all occurrences of "should", "should not", "must" and "must not" and uppercased them. o John Zwiebel offered text for section 4.1 to modernize the example. Thanks Z! o Make it more clear in the definition of "EID-to-RLOC Database" that all ETRs need to have the same database mapping. This reflects a comment from John Scudder. o Add a definition "Route-returnability" to the Definition of Terms section. o In section 9.2, add text to describe what the signature of traceroute packets can look like. o Removed references to Data Probe for introductory example. Data- probes are still part of the LISP design but not encouraged. o Added the definition for "LISP site" to the Definition of Terms" section. B.9. Changes to draft-ietf-lisp-06.txt Editorial based changes: o Posted December 2009. o Fix typo for flags in LISP data header. Changed from "4" to "5". o Add text to indicate that Map-Register messages must contain a computed UDP checksum. o Add definitions for PITR and PETR. o Indicate an AFI value of 0 is an unspecified address. o Indicate that the TTL field of a Map-Register is not used and set to 0 by the sender. This change makes this spec consistent with [LISP-MS]. o Change "... yield a packet size of L bytes" to "... yield a packet size greater than L bytes". o Clarify section 6.1.5 on what addresses and ports are used in Map- Reply messages. Farinacci, et al. Expires December 31, 2011 [Page 85] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 o Clarify that LSBs that go beyond the number of locators do not to be SMRed when the locator addresses are greater lexicographically than the locator in the existing locator-set. o Add Gregg, Srini, and Amit to acknowledgment section. o Clarify in the definition of a LISP header what is following the UDP header. o Clarify "verifying Map-Request" text in section 6.1.3. o Add Xu Xiaohu to the acknowledgment section for introducing the problem of overlapping EID-prefixes among multiple sites in an RRG email message. Design based changes: o Use stronger language to have the outer IPv4 header set DF=3D1 so = we can avoid fragment reassembly in an ETR or PETR. This will also make IPv4 and IPv6 encapsulation have consistent behavior. o Map-Requests should not be sent in ECM with the Probe bit is set. These type of Map-Requests are used as RLOC-probes and are sent directly to locator addresses in the underlying network. o Add text in section 6.1.5 about returning all EID-prefixes in a Map-Reply sent by an ETR when there are overlapping EID-prefixes configure. o Add text in a new subsection of section 6.1.5 about dealing with Map-Replies with coarse EID-prefixes. B.10. Changes to draft-ietf-lisp-05.txt o Posted September 2009. o Added this Document Change Log appendix. o Added section indicating that encapsulated Map-Requests must use destination UDP port 4342. o Don't use AH in Map-Registers. Put key-id, auth-length, and auth- data in Map-Register payload. o Added Jari to acknowledgment section. o State the source-EID is set to 0 when using Map-Requests to refresh or RLOC-probe. Farinacci, et al. Expires December 31, 2011 [Page 86] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 o Make more clear what source-RLOC should be for a Map-Request. o The LISP-CONS authors thought that the Type definitions for CONS should be removed from this specification. o Removed nonce from Map-Register message, it wasn't used so no need for it. o Clarify what to do for unspecified Action bits for negative Map- Replies. Since No Action is a drop, make value 0 Drop. B.11. Changes to draft-ietf-lisp-04.txt o Posted September 2009. o How do deal with record count greater than 1 for a Map-Request. Damien and Joel comment. Joel suggests: 1) Specify that senders compliant with the current document will always set the count to 1, and note that the count is included for future extensibility. 2) Specify what a receiver compliant with the draft should do if it receives a request with a count greater than 1. Presumably, it should send some error back? o Add Fred Templin in acknowledgment section. o Add Margaret and Sam to the acknowledgment section for their great comments. o Say more about LAGs in the UDP section per Sam Hartman's comment. o Sam wants to use MAY instead of SHOULD for ignoring checksums on ETR. =46rom the mailing list: "You'd need to word it as an ITR = MAY send a zero checksum, an ETR MUST accept a 0 checksum and MAY ignore the checksum completely. And of course we'd need to confirm that can actually be implemented. In particular, hardware that verifies UDP checksums on receive needs to be checked to make sure it permits 0 checksums." o Margaret wants a reference to http://www.ietf.org/id/draft-eubanks-chimento-6man-00.txt. o Fix description in Map-Request section. Where we describe Map- Reply Record, change "R-bit" to "M-bit". o Add the mobility bit to Map-Replies. So PTRs don't probe so often for MNs but often enough to get mapping updates. Farinacci, et al. Expires December 31, 2011 [Page 87] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 o Indicate SHA1 can be used as well for Map-Registers. o More Fred comments on MTU handling. o Isidor comment about spec'ing better periodic Map-Registers. Will be fixed in draft-ietf-lisp-ms-02.txt. o Margaret's comment on gleaning: "The current specification does not make it clear how long gleaned map entries should be retained in the cache, nor does it make it clear how/ when they will be validated. The LISP spec should, at the very least, include a (short) default lifetime for gleaned entries, require that they be validated within a short period of time, and state that a new gleaned entry should never overwrite an entry that was obtained from the mapping system. The security implications of storing "gleaned" entries should also be explored in detail." o Add section on RLOC-probing per working group feedback. o Change "loc-reach-bits" to "loc-status-bits" per comment from Noel. o Remove SMR-bit from data-plane. Dino prefers to have it in the control plane only. o Change LISP header to allow a "Research Bit" so the Nonce and LSB fields can be turned off and used for another future purpose. For Luigi et al versioning convergence. o Add a N-bit to the data header suggested by Noel. Then the nonce field could be used when N is not 1. o Clarify that when E-bit is 0, the nonce field can be an echoed nonce or a random nonce. Comment from Jesper. o Indicate when doing data-gleaning that a verifying Map-Request is sent to the source-EID of the gleaned data packet so we can avoid map-cache corruption by a 3rd party. Comment from Pedro. o Indicate that a verifying Map-Request, for accepting mapping data, should be sent over the ALT (or to the EID). o Reference IPsec RFC 4302. Comment from Sam and Brian Weis. o Put E-bit in Map-Reply to tell ITRs that the ETR supports echo- noncing. Comment by Pedro and Dino. Farinacci, et al. Expires December 31, 2011 [Page 88] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 o Jesper made a comment to loosen the language about requiring the copy of inner TTL to outer TTL since the text to get mixed-AF traceroute to work would violate the "MUST" clause. Changed from MUST to SHOULD in section 5.3. B.12. Changes to draft-ietf-lisp-03.txt o Posted July 2009. o Removed loc-reach-bits longword from control packets per Damien comment. o Clarifications in MTU text from Roque. o Added text to indicate that the locator-set be sorted by locator address from Isidor. o Clarification text from John Zwiebel in Echo-Nonce section. B.13. Changes to draft-ietf-lisp-02.txt o Posted July 2009. o Encapsulation packet format change to add E-bit and make loc- reach-bits 32-bits in length. o Added Echo-Nonce Algorithm section. o Clarification how ECN bits are copied. o Moved S-bit in Map-Request. o Added P-bit in Map-Request and Map-Reply messages to anticipate RLOC-Probe Algorithm. o Added to Mobility section to reference [LISP-MN]. B.14. Changes to draft-ietf-lisp-01.txt o Posted 2 days after draft-ietf-lisp-00.txt in May 2009. o Defined LEID to be a "LISP EID". o Indicate encapsulation use IPv4 DF=3D0. o Added negative Map-Reply messages with drop, native-forward, and send-map-request actions. Farinacci, et al. Expires December 31, 2011 [Page 89] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 o Added Proxy-Map-Reply bit to Map-Register. B.15. Changes to draft-ietf-lisp-00.txt o Posted May 2009. o Rename of draft-farinacci-lisp-12.txt. o Acknowledgment to RRG. Farinacci, et al. Expires December 31, 2011 [Page 90] =0C Internet-Draft Locator/ID Separation Protocol (LISP) June 2011 Authors' Addresses Dino Farinacci cisco Systems Tasman Drive San Jose, CA 95134 USA Email: dino@cisco.com Vince Fuller cisco Systems Tasman Drive San Jose, CA 95134 USA Email: vaf@cisco.com Dave Meyer cisco Systems 170 Tasman Drive San Jose, CA USA Email: dmm@cisco.com Darrel Lewis cisco Systems 170 Tasman Drive San Jose, CA USA Email: darlewis@cisco.com Farinacci, et al. Expires December 31, 2011 [Page 91] =0C --Apple-Mail-116-364858833 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-116-364858833-- From internet-drafts@ietf.org Thu Jun 30 13:16:55 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FF411E81C0; Thu, 30 Jun 2011 13:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBW0XAhAzzW6; Thu, 30 Jun 2011 13:16:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44BC611E80A7; Thu, 30 Jun 2011 13:16:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110630201655.32567.82143.idtracker@ietfa.amsl.com> Date: Thu, 30 Jun 2011 13:16:55 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-alt-07.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jun 2011 20:16:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP Alternative Topology (LISP+ALT) Author(s) : Vince Fuller Dino Farinacci Dave Meyer Darrel Lewis Filename : draft-ietf-lisp-alt-07.txt Pages : 29 Date : 2011-06-30 This document describes a simple distributed index system to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router (ITR) or Map Resolver (MR) to find the Egress Tunnel Router (ETR) which holds the mapping information for a particular Endpoint Identifier (EID). The MR can then query that ETR to obtain the actual mapping information, which consists of a list of Routing Locators (RLOCs) for the EID. Termed the Alternative Logical Topology (ALT), the index is built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and the Generic Routing Encapsulation (GRE). Using these proven protocols, the ALT can be built and deployed relatively quickly without any changes to the existing routing infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-alt-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-alt-07.txt From internet-drafts@ietf.org Thu Jun 30 13:17:47 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7398D11E81F8; Thu, 30 Jun 2011 13:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jab3yOII8xh8; Thu, 30 Jun 2011 13:17:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149A711E80A7; Thu, 30 Jun 2011 13:17:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110630201747.656.54574.idtracker@ietfa.amsl.com> Date: Thu, 30 Jun 2011 13:17:47 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-ms-09.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jun 2011 20:17:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP Map Server Author(s) : Vince Fuller Dino Farinacci Filename : draft-ietf-lisp-ms-09.txt Pages : 19 Date : 2011-06-30 This draft describes the LISP Map Server (LISP-MS), a computing system which provides a simplified LISP protocol interface as a "front end" to the Endpoint-ID (EID) to Routing Locator (RLOC) mapping database and associated virtual network of LISP protocol elements. The purpose of the Map Server is to reduce implementation and operational complexity of LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs), the devices that implement the "edge&= quot; of the LISP infrastructure and which connect directly to LISP-capable Internet end sites. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-ms-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-ms-09.txt From vaf@cisco.com Thu Jun 30 13:22:00 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B7F21F859C for ; Thu, 30 Jun 2011 13:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.498 X-Spam-Level: X-Spam-Status: No, score=-10.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pP2KSSonqgN for ; Thu, 30 Jun 2011 13:21:58 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 62E1A21F85FE for ; Thu, 30 Jun 2011 13:21:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=29839; q=dns/txt; s=iport; t=1309465287; x=1310674887; h=date:from:to:subject:message-id:mime-version; bh=k08ILJ68VqsgdGUZptvuFibP1K449nHBsZKue430W1g=; b=eYeMB5hvG3l+7nn/klf94v2cSdjVFChotqs3p009JHM5Ras2l1QZCcLI rqKxUX0N0nxmfbqGI0HcSG9QmjjGHNTLs/DT/Op+qQ5P86Y4USFK6N5J4 BPrmE3Q1OXzJwnQphwJcaYx/LCHzltQ89T+anadJFnVY67j1jse/k2Yc7 I=; X-Files: rfcdiff-alt-06-to-07.html : 26294 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQFAJjaDE6rRDoJ/2dsb2JhbABSglGWC4ZqAYgVd6hRgSKdb4YxBIdAmz0 X-IronPort-AV: E=Sophos;i="4.65,454,1304294400"; d="html'217?scan'217,208,217";a="389542491" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 30 Jun 2011 20:21:26 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5UKLQjM013643 for ; Thu, 30 Jun 2011 20:21:26 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 7FFCB12A8869; Thu, 30 Jun 2011 13:21:25 -0700 (PDT) Date: Thu, 30 Jun 2011 13:21:25 -0700 From: Vince Fuller To: lisp@ietf.org Message-ID: <20110630202124.GA16816@vaf-mac1.cisco.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: [lisp] Fwd: I-D Action: draft-ietf-lisp-alt-07.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jun 2011 20:22:00 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This version contains only one significant semantic change: eliminating the sentence that says that ITRs can discard more-specific map cache entries. Several typo/grammar problems were also fixed. rfcdiff results are attached below. Thanks go to Alia for finding all of these problems. --Vince and Dino ----- Forwarded message from internet-drafts@ietf.org ----- Date: Thu, 30 Jun 2011 13:16:55 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-alt-07.txt X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYCADPZDE5AqmIekmdsb2JhbABSmGuOcRQBAQEBCQsLBxInqXSdboYxBIdAim+QTg X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol Errors-To: lisp-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Alternative Topology (LISP+ALT) Author(s) : Vince Fuller Dino Farinacci Dave Meyer Darrel Lewis Filename : draft-ietf-lisp-alt-07.txt Pages : 29 Date : 2011-06-30 This document describes a simple distributed index system to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router (ITR) or Map Resolver (MR) to find the Egress Tunnel Router (ETR) which holds the mapping information for a particular Endpoint Identifier (EID). The MR can then query that ETR to obtain the actual mapping information, which consists of a list of Routing Locators (RLOCs) for the EID. Termed the Alternative Logical Topology (ALT), the index is built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and the Generic Routing Encapsulation (GRE). Using these proven protocols, the ALT can be built and deployed relatively quickly without any changes to the existing routing infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-alt-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-alt-07.txt _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp ----- End forwarded message ----- --OXfL5xGRrasGEqWY Content-Type: text/html; charset=us-ascii Content-Disposition: attachment; filename="rfcdiff-alt-06-to-07.html" rfcdiff
 
IETF Home
About Tools
Tools:
diffs spell
xml2rfc idnits
tracker src
News
Get Passwd
IETF-81:
Rooms
Agenda
Calendar
Documents
RFCs
Doc fetch:
Wikis:
IESG IRTF
IAOC RSOC
Chairs Edu
Tools BOFs Development
NomCom
Areas
WGs:
concluded…
6lowpan
6man*
6renum
Abfab
Adslmib
Alto*
Ancp
Appsawg*
Armd
Atoca
Autoconf
Avtcore*
Avtext
Behave*
Bfd
Bliss
Bmwg
Ccamp*
Cdni
Clue
Codec
Conex
Core
Csi
Cuss
Dane*
Dccp
Decade
Dhc
Dime*
Dispatch
Dkim
Dnsext
Dnsop
Drinks
Eai
Ecrit
Eman*
Emu
Fecframe
Forces
Ftpext2*
Geopriv
Grow*
Hip
Hokey
Httpbis
Hybi
Idr*
Intarea*
Ipdvb
Ipfix
Ippm*
Ipsecme
Iri
Isis
Isms
Karp*
Kitten
Krb-wg*
L2tpext
L2vpn
L3vpn
Ledbat*
Lisp*
Ltans
Lwig
Manet
Marf*
Mboned
Mediactrl
Mext
Mif
Mip4
Mmusic
Mpls*
Mptcp
Msec
Multimob
Nea
Netconf
Netext*
Netmod
Nfsv4
Ntp
Oauth
Opsawg
Opsec
Ospf
P2psip
Paws
Payload
Pce
Pcn
Pcp
Pim
Pkix*
Pmol
Pppext
Ppsp
Precis
Pwe3*
Radext
Rmt
Roll
Rtcweb*
Rtgwg
Salud
Savi
Shim6
Sidr*
Sieve
Simple
Sipclf
Sipcore
Siprec
Soc
Softwire
Speechsc
Speermint*
Splices
Storm
Tcpm*
Tictoc
Tls
Trill
Tsvwg*
Urnbis
V6ops
Vcarddav
Vipr
Websec
Xcon
Xmpp
Xrblock
Yam

* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Rfcdiff Tool
Version: 0.11
Author:

Rfcdiff Web Service

File 1 -   Upload file:  
or enter URL:  
 
File 2 -   Upload file:  
or enter URL:  
 
Output format: Side-by-side diff
Before-after diff
Changebars
Html wdiff
Html Wdiff Options:
Colour of old text:
Colour of new text:
Larger diff text:
Column width:

You can also use this web-service with an URL query-string of the form:

http://tools.ietf.org//rfcdiff?url1=http-url-to-doc-1&url2=http-url-to-doc-2

which makes it possible to send around links to diffs between document versions withouth actually generating the diff yourself, as long as the two document versions are available by http.

Example (yes, it is long - no way to get around that... - but you could use tinyurl.com to get a short alias to one of these):

http://tools.ietf.org/rfcdiff?
  url1=http://tools.ietf.org/id/draft-ietf-atompub-format-10.txt
  &url2=http://tools.ietf.org/id/draft-ietf-atompub-format-11.txt




Generated from PyHt script /rfcdiff Latest update: 24 May 2011 09:22 GMT -
--OXfL5xGRrasGEqWY-- From vaf@cisco.com Thu Jun 30 13:23:04 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E8721F85D1 for ; Thu, 30 Jun 2011 13:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kML3h2xsodtS for ; Thu, 30 Jun 2011 13:23:02 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3A07121F859A for ; Thu, 30 Jun 2011 13:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=29473; q=dns/txt; s=iport; t=1309465382; x=1310674982; h=date:from:to:subject:message-id:mime-version; bh=ORwME1Ils6oIImCGPYGSlAPRaxaIodeir5aNBwfTalo=; b=S4nrWmZEROny6mABqQM9EkIfLNYkdoJCtHc8Z9kOzTNru43ax+F7XmtW btIcvVPyIuTvioqcc7XLCv95QcLbdkIoN5YLckm7w3YiMBjbDG75FTiEy XS9ut79x7iADFLLi+0WI9Spcu9F4Xs9vaMBgICepFpsoM9i9p4DTQkUXf E=; X-Files: rfcdiff-ms-08-to-09.html : 26294 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQFAFzaDE6rRDoI/2dsb2JhbABSglGWC4ZqAYgVd6hQgSKdboYxBIdAmz0 X-IronPort-AV: E=Sophos;i="4.65,454,1304294400"; d="html'217?scan'217,208,217";a="350876966" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 30 Jun 2011 20:23:01 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5UKN1rZ006804 for ; Thu, 30 Jun 2011 20:23:01 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 002A412A88A6; Thu, 30 Jun 2011 13:23:00 -0700 (PDT) Date: Thu, 30 Jun 2011 13:23:00 -0700 From: Vince Fuller To: lisp@ietf.org Message-ID: <20110630202300.GA16986@vaf-mac1.cisco.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: [lisp] Fwd: I-D Action: draft-ietf-lisp-ms-09.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jun 2011 20:23:04 -0000 --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This version includes a few typo/grammar fixes plus some new text clarifying issues raised during last call. Thanks go to Alia for bringing these to the attention of the authors. rfcdiff results attached below. --Vince (for the co-authors) ----- Forwarded message from internet-drafts@ietf.org ----- Date: Thu, 30 Jun 2011 13:17:47 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-ms-09.txt X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYCAGnZDE5AqmIekmdsb2JhbABSmGuOcRQBAQEBCQsLBxInqW2dboYxBIdAim+QTg X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol Errors-To: lisp-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Map Server Author(s) : Vince Fuller Dino Farinacci Filename : draft-ietf-lisp-ms-09.txt Pages : 19 Date : 2011-06-30 This draft describes the LISP Map Server (LISP-MS), a computing system which provides a simplified LISP protocol interface as a "front end" to the Endpoint-ID (EID) to Routing Locator (RLOC) mapping database and associated virtual network of LISP protocol elements. The purpose of the Map Server is to reduce implementation and operational complexity of LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs), the devices that implement the "edge" of the LISP infrastructure and which connect directly to LISP-capable Internet end sites. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-ms-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-ms-09.txt _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp ----- End forwarded message ----- --45Z9DzgjV8m4Oswq Content-Type: text/html; charset=us-ascii Content-Disposition: attachment; filename="rfcdiff-ms-08-to-09.html" rfcdiff
 
IETF Home
About Tools
Tools:
diffs spell
xml2rfc idnits
tracker src
News
Get Passwd
IETF-81:
Rooms
Agenda
Calendar
Documents
RFCs
Doc fetch:
Wikis:
IESG IRTF
IAOC RSOC
Chairs Edu
Tools BOFs Development
NomCom
Areas
WGs:
concluded…
6lowpan
6man*
6renum
Abfab
Adslmib
Alto*
Ancp
Appsawg*
Armd
Atoca
Autoconf
Avtcore*
Avtext
Behave*
Bfd
Bliss
Bmwg
Ccamp*
Cdni
Clue
Codec
Conex
Core
Csi
Cuss
Dane*
Dccp
Decade
Dhc
Dime*
Dispatch
Dkim
Dnsext
Dnsop
Drinks
Eai
Ecrit
Eman*
Emu
Fecframe
Forces
Ftpext2*
Geopriv
Grow*
Hip
Hokey
Httpbis
Hybi
Idr*
Intarea*
Ipdvb
Ipfix
Ippm*
Ipsecme
Iri
Isis
Isms
Karp*
Kitten
Krb-wg*
L2tpext
L2vpn
L3vpn
Ledbat*
Lisp*
Ltans
Lwig
Manet
Marf*
Mboned
Mediactrl
Mext
Mif
Mip4
Mmusic
Mpls*
Mptcp
Msec
Multimob
Nea
Netconf
Netext*
Netmod
Nfsv4
Ntp
Oauth
Opsawg
Opsec
Ospf
P2psip
Paws
Payload
Pce
Pcn
Pcp
Pim
Pkix*
Pmol
Pppext
Ppsp
Precis
Pwe3*
Radext
Rmt
Roll
Rtcweb*
Rtgwg
Salud
Savi
Shim6
Sidr*
Sieve
Simple
Sipclf
Sipcore
Siprec
Soc
Softwire
Speechsc
Speermint*
Splices
Storm
Tcpm*
Tictoc
Tls
Trill
Tsvwg*
Urnbis
V6ops
Vcarddav
Vipr
Websec
Xcon
Xmpp
Xrblock
Yam

* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Rfcdiff Tool
Version: 0.11
Author:

Rfcdiff Web Service

File 1 -   Upload file:  
or enter URL:  
 
File 2 -   Upload file:  
or enter URL:  
 
Output format: Side-by-side diff
Before-after diff
Changebars
Html wdiff
Html Wdiff Options:
Colour of old text:
Colour of new text:
Larger diff text:
Column width:

You can also use this web-service with an URL query-string of the form:

http://tools.ietf.org//rfcdiff?url1=http-url-to-doc-1&url2=http-url-to-doc-2

which makes it possible to send around links to diffs between document versions withouth actually generating the diff yourself, as long as the two document versions are available by http.

Example (yes, it is long - no way to get around that... - but you could use tinyurl.com to get a short alias to one of these):

http://tools.ietf.org/rfcdiff?
  url1=http://tools.ietf.org/id/draft-ietf-atompub-format-10.txt
  &url2=http://tools.ietf.org/id/draft-ietf-atompub-format-11.txt




Generated from PyHt script /rfcdiff Latest update: 24 May 2011 09:22 GMT -
--45Z9DzgjV8m4Oswq-- From internet-drafts@ietf.org Thu Jun 30 22:41:10 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0DBB21F884A; Thu, 30 Jun 2011 22:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIZlHSPkmbtQ; Thu, 30 Jun 2011 22:41:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4522D21F8807; Thu, 30 Jun 2011 22:41:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110701054110.30938.31633.idtracker@ietfa.amsl.com> Date: Thu, 30 Jun 2011 22:41:10 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-interworking-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 05:41:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : Interworking LISP with IPv4 and IPv6 Author(s) : Darrel Lewis David Meyer Dino Farinacci Vince Fuller Filename : draft-ietf-lisp-interworking-02.txt Pages : 24 Date : 2011-06-30 This document describes techniques for allowing sites running the Locator/ID Separation Protocol (LISP) to interoperate with Internet sites (which may be using either IPv4, IPv6, or both) but which are not running LISP. A fundamental property of LISP speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IPv4 or IPv6 addresses, normally routes to them are not carried in the global routing system so an interoperability mechanism is needed for non- LISP-speaking sites to exchange traffic with LISP-speaking sites. This document introduces three such mechanisms. The first uses a new network element, the LISP Proxy Ingress Tunnel Routers (PITR) (Section 5) to act as a intermediate LISP Ingress Tunnel Router (ITR) for non-LISP-speaking hosts. Second the document adds Network Address Translation (NAT) functionality to LISP Ingress and LISP Egress Tunnel Routers (xTRs) to substitute routable IP addresses for non-routable EIDs. Finally, this document introduces a Proxy Egress Tunnel Router (PETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-interworking-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-interworking-02.txt From darlewis@cisco.com Thu Jun 30 22:50:43 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60FD621F85D3 for ; Thu, 30 Jun 2011 22:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.692 X-Spam-Level: X-Spam-Status: No, score=-7.692 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_HTML_SINGLETS=1.666, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRGKXGANH+VI for ; Thu, 30 Jun 2011 22:50:40 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4930321F85AC for ; Thu, 30 Jun 2011 22:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=darlewis@cisco.com; l=54667; q=dns/txt; s=iport; t=1309499440; x=1310709040; h=from:mime-version:subject:date:references:cc:to: message-id; bh=lj9xoRd15JDVkBNrGuCQrnBmCe/v1rxJ4YT6WdF78Ys=; b=a0w8gL1ddZM783qvufV73L+dfeY7ArUXF/IMOzu+o/e30PE92YP1R1fg AvrWDjhWG3ECaLdlQlKTWNKjj35X8WOjwQI90jqmtaaCj3wz7pw6+p9k9 /RW8Gsmzx8uKvfSE73FVc2iRokUkJyY9wONRcaobl0NhbptC6TeXmO8Lk Y=; X-Files: draft-ietf-lisp-interworking-01-to-02-diff.html : 50331 X-IronPort-AV: E=Sophos;i="4.65,456,1304294400"; d="html'217?scan'217,208,217";a="351138987" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 01 Jul 2011 05:50:40 +0000 Received: from sjc-vpn3-971.cisco.com (sjc-vpn3-971.cisco.com [10.21.67.203]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p615odRD021172; Fri, 1 Jul 2011 05:50:39 GMT From: Darrel Lewis Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/mixed; boundary=Apple-Mail-7-479757899 Date: Thu, 30 Jun 2011 22:50:39 -0700 References: <20110701054110.30938.31633.idtracker@ietfa.amsl.com> To: lisp@ietf.org Message-Id: X-Mailer: Apple Mail (2.1084) Subject: [lisp] Fwd: I-D Action: draft-ietf-lisp-interworking-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 05:50:43 -0000 --Apple-Mail-7-479757899 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This version includes a several typo/grammar fixes plus some new text = clarifying minor issues raised during last call. Thanks go to Hannu, Alia, Luigi and others for bringing these to the = attention of the authors. rfcdiff results attached below. --Darrel (for the co-authors) --Apple-Mail-7-479757899 Content-Disposition: attachment; filename=draft-ietf-lisp-interworking-01-to-02-diff.html Content-Type: text/html; x-unix-mode=0644; name="draft-ietf-lisp-interworking-01-to-02-diff.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-interworking-01.txt draft-ietf-lisp-interworking-02.txt 
Network Working Group                                           D. Lewis
Internet-Draft                                                  D. Meyer
Intended status: Experimental                               D. Farinacci
Expires: February 27, 2011 January 2, 2012                                       V. Fuller
                                                     Cisco Systems, Inc.
                                                         August 26, 2010
                                                           June 30, 2011

                  Interworking LISP with IPv4 and IPv6
                  draft-ietf-lisp-interworking-01.txt
                  draft-ietf-lisp-interworking-02.txt

Abstract

   This document describes techniques for allowing sites running the
   Locator/ID Separation Protocol (LISP) to interoperate with Internet
   sites (which may be using either IPv4, IPv6, or both) but which are
   not running LISP.  A fundamental property of LISP speaking sites is
   that they use Endpoint Identifiers (EIDs), rather than traditional IP
   addresses, in the source and destination fields of all traffic they
   emit or receive.  While EIDs are syntactically identical to IPv4 or
   IPv6 addresses, normally routes to them are not carried in the global
   routing system so an interoperability mechanism is needed for non-
   LISP-speaking sites to exchange traffic with LISP-speaking sites.
   This document introduces three such mechanisms.  The first uses a new
   network element, the LISP Proxy Ingress Tunnel Routers (PITR)
   (Section 5) to act as a intermediate LISP Ingress Tunnel Router (ITR)
   for non-LISP-speaking hosts.  Second the document adds Network
   Address Translation (NAT) functionality to LISP Ingress and LISP
   Egress Tunnel Routers (xTRs) to substitute routable IP addresses for
   non-routable EIDs.  Finally, this document introduces a Proxy Egress
   Tunnel Router (PETR) to handle cases where a LISP ITR cannot send
   packets to non-LISP sites without encapsulation.

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 at http://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 February 27, 2011. January 2, 2012.

Copyright Notice

   Copyright (c) 2010 2011 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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  LISP Interworking Models . . . . . . . . . . . . . . . . . . .  6
   3.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  8
   4.  Routable EIDs  . . . . . . . . . . . . . . . . . . . . . . . . 11  9
     4.1.  Impact on Routing Table  . . . . . . . . . . . . . . . . . 11  9
     4.2.  Requirement for using BGP  . . . . . . . . . . . . . . . . 11  9
     4.3.  Limiting the Impact of Routable EIDs . . . . . . . . . . . 11  9
     4.4.  Use of Routable EIDs for sites transitioning to LISP . . . 11  9
   5.  Proxy Ingress Tunnel Routers . . . . . . . . . . . . . . . . . 13 11
     5.1.  PITR EID announcements . . . . . . . . . . . . . . . . . . 13 11
     5.2.  Packet Flow with PITRs . . . . . . . . . . . . . . . . . . 13 11
     5.3.  Scaling PITRs  . . . . . . . . . . . . . . . . . . . . . . 14 12
     5.4.  Impact of the PITRs placement in the network . . . . . . . 15 13
     5.5.  Benefit to Networks Deploying PITRs  . . . . . . . . . . . 15 13
   6.  LISP-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 14
     6.1.  Using LISP-NAT with LISP-NR EIDs . . . . . . . . . . . . . 16 14
     6.2.  LISP Sites with Hosts using RFC 1918 Addresses Sending
           to non-LISP Sites  . . . . . . . . . . . . . . . . . . . . 17 15
     6.3.  LISP Sites with Hosts using RFC 1918 Addresses
           Sending Packets to Other LISP Sites  . . . . . . . . . . . 17 15
     6.4.  LISP-NAT and multiple EIDs . . . . . . . . . . . . . . . . 18 16
     6.5.  When LISP-NAT and PITRs used by the same LISP Site . . . . 18 16
   7.  Proxy Egress Tunnel Routers  . . . . . . . . . . . . . . . . . 19 17
     7.1.  Packet Flow with Proxy Egress Tunnel Routers . . . . . . . 19 17
   8.  Discussion of Proxy ITRs (PITRs), LISP-NAT, and Proxy-ETRs
       (PETRs)  . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 19
     8.1.  How Proxy-ITRs and Proxy-ETRs Interact . . . . . . . . . . 21 19
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22 20
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 23 21
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24 22
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 23
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 25 23
     12.2. Informative References . . . . . . . . . . . . . . . . . . 25 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 24

1.  Introduction

   This document describes interoperation between LISP [LISP] sites
   which use non-globally-routed EIDs, and non-LISP sites.  The first is
   the use of Proxy Ingress Tunnel router (PITRs), which originate
   highly-aggregated routes to EID prefixes for non-LISP sites to use.
   It also describes the use of NAT by LISP ITRs when sending packets to
   non-LISP hosts.  Finally, it describes Proxy Egress Tunnel routers
   (PETRs) LISP for sites relying on PITRs, and which are faced with
   certain restrictions.

   A key behavior of the separation of Locators and End-Point-IDs is
   that EID prefixes are normally not advertised into the Internet's
   Default Free Zone (DFZ).  Specifically, only RLOCs are carried in the
   Internet's DFZ.  Existing Internet sites (and their hosts) which do
   not run in the LISP protocol must still be able to reach sites
   numbered from LISP EID space.  This draft describes three mechanisms
   that can be used to provide reachability between sites that are LISP-
   capable and those that are not.

   The first mechanism uses a new network element, the LISP Proxy
   Ingress Tunnel Router (PITR) to act as a intermediate LISP Ingress
   Tunnel Router (ITR) for non-LISP-speaking hosts.  The second
   mechanism adds a form of Network Address Translation (NAT)
   functionality to Tunnel Routers (xTRs), to substitute routable IP
   addresses for non-routable EIDs.  The final network element is the
   LISP Proxy Egress Tunnel Routers (PETR), which act as an intermediate
   Egress Tunnel Router (ETR) for LISP sites which need to encapsulate
   packets LISP packets destined to non-LISP sites.

   More detailed descriptions of these mechanisms and the network
   elements involved may be found in the following sections:

   - Section 2 describes the different cases where interworking
   mechanisms are needed

   - Section 3 defines terms used throughout the document

   - Section 4 describes the relationship between the new EID prefix
   space and the IP address space used by the current Internet

   - Section 5 introduces and describes the operation of Proxy-ITRs

   - Section 6 defines how NAT is used by ETRs to translate non-routable
   EIDs into routable IP addresses.

   - Section 7 introduces and describes the operations of Proxy-ETRs
   - Section 8 describes the relationship between asymmetric and
   Symmetric interworking mechanisms (Proxy-ITRs and Proxy-ETRs vs LISP-
   NAT)

   Note that any successful interworking model should be independent of
   any particular EID-to-RLOC mapping algorithm.  This document does not
   comment on the value of any of the particular LISP mapping systems.

2.  LISP Interworking Models

   There are 4 unicast connectivity cases which describe how sites can
   send packets to each other:

   1.  Non-LISP site to Non-LISP site

   2.  LISP site to LISP site

   3.  LISP site to Non-LISP site

   4.  Non-LISP site to LISP site

   Note that while Cases 3 and 4 seem similar, there are subtle
   differences due to the way packets are originated.

   The first case is the Internet as we know it today and as such will
   not be discussed further here.  The second case is documented in
   [LISP] and there are no new interworking requirements because there
   are no new protocol requirements placed on intermediate non- LISP
   routers.

   In case 3, LISP site to Non-LISP site, a LISP site can (in most
   cases) send packets to a non-LISP site because the non-LISP site
   prefixes are routable.  The non-LISP site need not do anything new to
   receive packets.  The only action the LISP site needs (with two
   possible caveats introduced below) to take is to know when not to
   LISP-encapsulate packets.  This can be achieved by using one of two
   mechanisms:

   1.  At the ITR in the source site, if the destination of an IP packet
       is found to match a prefix from the BGP routing table, then the
       site is directly reachable by the BGP core that exists and
       operates today.

   2.  Second, if (from the perspective of the ITR at the source site)
       the packet's destination address of an IP address is not found in the EID-
       to-RLOC EID-to-
       RLOC mapping database, then the ITR could infer that it is not a
       LISP-capable site, and decide to not LISP-encapsulate site.  An ITR can also know explicitly that the packet.
       destination is non-LISP if the destination IP address matches a
       Negative Map Reply found in its Map Cache.

   3.  In either of the two exceptions mentioned above there could be
       some situations where (unencapsualted) packets originated by a
       LISP site may not be forwarded to a non-LISP site.  These cases
       are reviewed in section 7, (Proxy-Egress Tunnel Routers).

   Case 4, typically the most challenging, occurs when a host at a non-
   LISP site wishes to send traffic to a host at a LISP site.  If the
   source host uses a (non-globally-routable) EID as the destination IP
   address, the packet is forwarded inside the source site until it
   reaches a router which cannot forward tin (due to lack of a default
   route), at which point the traffic is dropped.  For traffic not to be
   dropped, either some some mechanism to make this destination EID
   routable must be in place.  Section 5 (PITRs) and Section 6 (LISP-
   NAT) describe two such mechanisms.

   Case 4 also applies to packets returning to the LISP site, in Case 3.

3.  Definition of Terms

   Endpoint ID (EID):  Endpoint ID (EID): A 32-bit (for IPv4) or 128-bit
      (for IPv6) value used in the source and destination address fields
      of the first (most inner) IP header of a packet.  The host obtains
      a destination EID the same way it obtains an destination address
      today, for example through a DNS lookup or SIP exchange.  The
      source EID is obtained via existing mechanisms used to set a
      host's "local" IP address.  An EID is allocated to a host from an
      EID-prefix block associated with the site where the host is
      located.  An EID can be used by a host to refer to other hosts.
      EIDs MUST NOT be used as LISP RLOCs.  Note that EID blocks may be
      assigned in a hierarchical manner, independent of the network
      topology, to facilitate scaling of the mapping database.  In
      addition, an EID block assigned to a site may have site-local
      structure (subnetting) for routing within the site; this structure
      is not visible to the global routing system.  When used in
      discussions with other Locator/ID separation proposals, a LISP EID
      will be called a "LEID".  Throughout this document, any references
      to "EID" refers to an LEID.

   EID-Prefix:  A power-of-2 block of EIDs which are allocated to a site
      by an address allocation authority.  EID-prefixes are associated
      with a set of RLOC addresses which make up a "database mapping".
      EID-prefix allocations can be broken up into smaller blocks when
      an RLOC set is to be associated with the smaller EID- prefix.  A
      globally routed address block (whether PI or PA) is not an EID-
      prefix.  However, a globally routed address block may be removed
      from global routing and reused as an EID-prefix.  A site that
      receives an explicitly allocated EID-prefix may not use that EID-
      prefix as a globally routed prefix assigned to RLOCs

   EID-Prefix Aggregate:  A set of EID-prefixes said to be aggregatable
      in the [RFC4632] sense.  That is, an EID-Prefix aggregate is
      defined to be a single contiguous power-of-two EID-prefix block.
      Such a block is characterized by a prefix and a length.  Provider
      Independent (PI) Addresses: an address block assigned from a pool
      where blocks are not associated with any particular location in
      the network (e.g. from a particular service provider), and is
      therefore not topologically aggregatable in the routing system.

   Routing Locator (RLOC):  The IPv4 or IPv6 address of an egress tunnel
      router (ETR).  It is the output of a EID-to-RLOC mapping lookup.
      An EID maps to one or more RLOCs.  Typically, RLOCs are numbered
      from topologically-aggregatable blocks that are assigned to a site
      at each point to which it attaches to the global Internet; where
      the topology is defined by the connectivity of provider networks,
      RLOCs can be thought of as PA addresses.  Multiple RLOCs can be
      assigned
       some situations where (unencapsulated) packets originated by a
       LISP site may not be forwarded to a non-LISP site.  These cases
       are reviewed in section 7, (Proxy-Egress Tunnel Routers).

   Case 4, typically the same ETR device or most challenging, occurs when a host at a non-
   LISP site wishes to multiple ETR devices send traffic to a host at a LISP site.

   EID-to-RLOC Mapping:  A binding between an  If the
   source host uses a (non-globally-routable) EID and as the RLOC-set that
      can be used to reach destination IP
   address, the EID.  We use packet is forwarded inside the term "mapping" in this
      document to refer to source site until it
   reaches a EID-to-RLOC mapping.

   EID Prefix Reachability:  An EID prefix is said router which cannot forward it (due to be "reachable" if
      one or more lack of its locators are reachable.  That is, an EID prefix
      is reachable if a default
   route), at which point the ETR (or its proxy) is reachable.

   Default Mapping:  A Default Mapping traffic is a mapping entry for EID-prefix
      0.0.0.0/0.  It maps dropped.  For traffic not to a locator-set used for all EIDs be
   dropped, either some mechanism to make this destination EID routable
   must be in place.  Section 5 (PITRs) and Section 6 (LISP-NAT)
   describe two such mechanisms.

   Case 4 also applies to packets returning to the
      Internet.  If there is a more specific EID-prefix LISP site, in the mapping
      cache it overrides the Default Mapping entry.  The Default Mapping
      route can be learned by configuration or from a Map-Reply message
      [LISP]. Case 3.

3.  Definition of Terms

   LISP Routable (LISP-R) Site:  A LISP site whose addresses are used as
      both globally routable IP addresses and LISP EIDs.

   LISP Non-Routable (LISP-NR) Site:  A LISP site whose addresses are
      EIDs only, these EIDs are not found in the legacy Internet routing
      table.

   LISP Proxy Ingress Tunnel Router (PITR):  PITRs are used to provide
      interconnectivity between sites which use LISP EIDs and those
      which do not.  They act as gateways between those parts of the
      Internet which are not using LISP (the legacy Internet) A given
      PITR advertises one or more highly aggregated EID prefixes into
      the public Internet and acts as the ITR for traffic received from
      the public Internet.  LISP Proxy Ingress Tunnel Routers are
      described in Section 5.

   LISP Network Address Translation (LISP-NAT):  Network Address
      Translation between EID space assigned to a site and RLOC space
      also assigned to that site.  LISP Network Address Translation is
      described in Section 6.

   LISP Proxy Egress Tunnel Router (PETR):  PETRs provide a LISP
      (Routable or Non-Routable EID) site's ITRs the ability to send
      packets to non-LISP sites in cases where unencapsualted packets
      (the default mechanism) would fail to be delivered.  PETRs are
      function by having an ITR encapsulate all non-LISP destined
      traffic to a pre-configured PETR.  LISP Proxy Egress Tunnel
      Routers are described in Section 7.

    EID Sub Namespace:  A power-of-two block of aggregatable locators
      set aside for LISP interworking.

   For definitions of other terms, notably Map-Request, Map-Reply,
   Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), please
   consult the LISP specification [LISP].

4.  Routable EIDs

   An obvious way to achieve interworking between LISP and non-LISP
   hosts is for a LISP site to simply announce EID prefixes into the
   DFZ, much like the current routing system, effectively treating them
   as "Provider Independent (PI)" prefixes.  Having a site do this is
   undesirable as it defeats one of the primary goals of LISP - to
   reduce global routing system state.

4.1.  Impact on Routing Table

   If EID prefixes are announced into the DFZ, the impact is similar to
   the case in which LISP has not been deployed, because these EID
   prefixes will be no more aggregatable than existing PI addressing.
   Such a mechanism is not viewed as a viable long term solution, but
   may be a viable short term way for a site to transition a portion of
   its address space to EID space without changing its existing routing
   policy.

4.2.  Requirement for using BGP

   Non-LISP sites today use BGP to, among other things, enable ingress
   traffic engineering.  Relaxing this requirement is another primary
   design goal of LISP.

4.3.  Limiting the Impact of Routable EIDs

   Two schemes are proposed to limit the impact of having EIDs announced
   in the current global Internet routing table:

   1.  Section 5 discusses the LISP Proxy Tunnel Router, an approach
       that provides ITR functionality to bridge LISP-capable and non-
       LISP-capable sites.

   2.  Section 6 discusses another approach, LISP-NAT, in which NAT
       [RFC2993] is combined with ITR functionality to limit the the impact
       of routable EIDs on the Internet routing infrastructure.

4.4.  Use of Routable EIDs for sites transitioning to LISP

   A primary design goal for LISP (and other Locator/ID separation
   proposals) is to facilitate topological aggregation of namespace used
   by the path computation, and, thus, decrease global routing system
   overhead.  Another goal is to achieve the benefits of improved
   aggregation as soon as possible.  Individual sites advertising their
   own routes for LISP EID prefixes into the global routing system is
   therefore not recommended.

   That being said, single homed sites (or multi-homed sites that are
   not leaking more specific exceptions) and that are already using
   provider-aggregated prefixes can use these prefixes as LISP EIDs
   without adding state to the routing system.  In other words, such
   sites do not cause additional prefixes to be advertised.  For such
   sites, connectivity to a non-LISP sites does not require interworking
   machinery because the "PA" EIDs are already routable (they are
   effectively LISP-R type sites).  Their EIDs are found in the LISP
   mapping system, and their (aggregate) PA prefix(es) are found in the
   DFZ Internet.

   The continued announcements of an existing site's Provider
   Independent (or "PI") prefix(es) is of course under control of that
   site.  Some period of transition, where a site is is found both in the
   LISP mapping system, and as a discrete prefix in the Internet routing
   system, may be a viable transition strategy.  Care should be taken
   not to advertise additional more specific LISP EID prefixes into the
   DFZ.

5.  Proxy Ingress Tunnel Routers

   Proxy Ingress Tunnel Routers (PITRs) allow for non-LISP sites to send
   packets to LISP-NR sites.  A PITR is a new network element that
   shares many characteristics with the LISP ITR.  PITRs allow non-LISP
   sites to send packets to LISP-NR sites without any changes to
   protocols or equipment at the non-LISP site.  PITRs have two primary
   functions:

   Originating EID Advertisements:  PITRs advertise highly aggregated
      EID-prefix space on behalf of LISP sites to so that non-LISP sites
      can reach them.

   Encapsulating Legacy Internet Traffic:  PITRs also encapsulate non-
      LISP Internet traffic into LISP packets and route them towards
      their destination RLOCs.

5.1.  PITR EID announcements

   A key part of PITR functionality is to advertise routes for highly-
   aggregated EID prefixes into part of the global routing system.
   Aggressive aggregation is performed to minimize the number of new
   announced routes.  In addition, careful placement of PITRs can
   greatly reduce the advertised scope of these new routes.  To this
   end, PITRs should be deployed close to non-LISP-speaking rather than
   close to LISP sites.  Such deployment not only limits the scope of
   EID-prefix route advertisements, it also also allows traffic forwarding
   load to be spread among many PITRs.

5.2.  Packet Flow with PITRs

   What follows is an example of the path a packet would take when using
   a PITR.  In this example, the LISP-NR site is given the EID prefix
   240.0.0.0/24.  For the purposes of this example, this prefix and no
   covering aggregate is present in the global routing system.  In other
   words, without the Proxy-ITR announcing 240.0.0.0/24, a packet with
   this destination were to reach a router in the "Default Free Zone",
   it would be dropped.

   A full protocol exchange example follows:

   1.  The source host makes a DNS lookup EID for destination, and gets
       240.1.1.1 in return.

   2.  The source host has a default route to customer Edge (CE) router
       and forwards the packet to the CE.

   3.  The CE has a default route to its Provider Edge (PE) router, and
       forwards the packet to the PE.

   4.  The PE has route to 240.0.0.0/24 and the next hop is the PITR.

   5.  The PITR has or acquires a mapping for 240.1.1.1 and LISP
       encapsulates the packet.  The outer IP header now has a
       destination address of one of the destination EID's RLOCs.  The
       outer source address of this encapsulated packet is the PITR's
       RLOC.

   6.  The PITR looks up the RLOC, and forwards LISP packet to the next
       hop, after which, it is forwarded by other routers to the ETR's
       RLOC.

   7.  The ETR decapsulates the packet and delivers the packet to the
       240.1.1.1 host in the destination LISP site.

   8.  Packets from host 240.1.1.1 will flow back through the LISP
       site's ITR.  Such packets are not encapsulated because the ITR
       knows that the destination (the original source) is a non-LISP
       site.  The ITR knows this because it can check the LISP mapping
       database for the destination EID, and on a failure determine that
       the destination site is not LISP enabled.

   9.  Packets are then routed natively and directly to the destination
       (original source) site.

   Note that in this example the return path is asymmetric, so return
   traffic will not go back through the PITR.  This is because the
   LISP-NR site's ITR will discover that the originating site is not a
   LISP site, and not encapsulate the returning packet (see [LISP] for
   details of ITR behavior).

   The asymmetric nature of traffic flows allows the PITR to be
   relatively simple - it will only have to encapsulate LISP packets.

5.3.  Scaling PITRs

   PITRs attract traffic by announcing the LISP EID namespace into parts
   of the non-LISP-speaking global routing system.  There are several
   ways that a network could control how traffic reaches a particular
   PITR to prevent it from receiving more traffic than it can handle:

   1.  The PITR's aggregate routes might be selectively announced,
       giving a coarse way to control the quantity of traffic attracted
       by that PITR.  For example, some of the routes being announced
       might be tagged with a BGP community and their scope of
       announcement limited by the routing policy of the provider.

   2.  The same address might be announced by multiple PITRs in order to
       share the traffic using IP Anycast.  The asymmetric nature of
       traffic flows through the Proxy ITR means that operationally,
       deploying a set PITRs would be very similar to existing Anycasted
       services like DNS caches.  Multiple Proxy ITRs could advertise
       the same BGP Next Hop IP address as their RLOC, and traffic would
       be attracted to the nearest Next Hop according to the the network's
       IGP.

5.4.  Impact of the PITRs placement in the network

   There are several approaches that a network could take in placing
   PITRs.  Placing the PITR near the source of traffic allows for the
   communication between the non-LISP site and the LISP site to have the
   least "stretch" (i.e. the least number of forwarding hops when
   compared to an optimal path between the sites).

   Some proposals, for example CRIO [CRIO], have suggested grouping
   PITRs near an arbitrary subset of ETRs and announcing a 'local'
   subset of EID space.  This model cannot guarantee minimum stretch if
   the EID prefix route advertisement points are changed (such a change
   might occur if a site adds, removes, or replaces one or more of its
   ISP connections).

5.5.  Benefit to Networks Deploying PITRs

   When packets destined for LISP-NR sites arrive and are encapsulated
   at a Proxy-ITR, a new LISP packet header is pre-pended.  This causes
   the packet's destination to be set to the destination ETRs RLOC.
   Because packets are thus routed towards RLOCs, it can potentially
   better follow the Proxy-ITR network's traffic engineering policies
   (such as closest exit routing).  This also means that providers which
   are not default-free and do not deploy Proxy-ITRs end up sending more
   traffic to expensive transit links (assuming their upstreams have
   deployed Proxy-ITRs) rather than to the ETR's RLOC addresses, to
   which they may well have cheaper and closer connectivity to (via, for
   example, settlement-free peering).  A corollary to this would be that
   large transit providers, deploying PITRs may attract more traffic,
   and therefore more revenue, from their customers.

6.  LISP-NAT

   LISP Network Address Translation (LISP-NAT) is a limited form of NAT
   [RFC2993].  LISP-NAT is designed to enable the interworking of non-
   LISP sites and LISP-NR sites by ensuring that the LISP-NR's site
   addresses are always routable.  LISP-NAT accomplishes this by
   translating a host's source address from an 'inner' (LISP-NR EID)
   value to an 'outer' (LISP-R) value and keeping this translation in a
   table that it can reference for subsequent packets.

   In addition, existing RFC 1918 [RFC1918] sites can use LISP-NAT to
   talk to both LISP or non-LISP sites.

   The basic concept of LISP-NAT is that when transmitting a packet, the
   ITR replaces a non-routable EID source address with a routable source
   address, which enables packets to return to the site.

   There are two main cases that involve LISP-NAT:

   1.  Hosts at LISP sites that use non-routable global EIDs speaking to
       non-LISP sites using global addresses.

   2.  Hosts at LISP sites that use RFC 1918 private EIDs speaking to
       other sites, who may be either LISP or non-LISP.

   Note that LISP-NAT is not needed in the case of LISP-R (routable
   global EIDs) sources.  This case occurs when a site is announcing its
   prefix into both the LISP mapping system as well as the Internet DFZ.
   This is because the LISP-R source's address is routable, and return
   packets will be able to natively reach the site.

6.1.  Using LISP-NAT with LISP-NR EIDs

   LISP-NAT allows a host with a LISP-NR EID to send packets to non-LISP
   hosts by translating the LISP-NR EID to a globally unique address (a
   LISP-R EID).  This globally unique address may be a either a PI or PA
   address.

   An example of this translation follows.  For this example, a site has
   been assigned a LISP-NR EID of 220.1.1.0/24.  In order to utilize
   LISP-NAT, the site has also been provided the PA EID of
   128.200.1.0/24, and uses the first address (128.200.1.1) as the
   site's RLOC.  The rest of this PA space (128.200.1.2 to
   128.200.1.254) is used as a translation pool for this site's hosts
   who need to send packets to non-LISP hosts.

   The translation table might look like the following:

          Site NR-EID    Site R-EID      Site's RLOC    Translation Pool
          ==============================================================
          220.1.1.0/24   128.200.1.0/24  128.200.1.1    128.200.1.2-254

                    Figure 1: Example Translation Table

   The Host 220.1.1.2 sends a packet (which, for the purposes of this
   example is destined for a non-LISP site site) to its default route (the
   ITR).  The ITR receives the packet, and determines that the
   destination is not a LISP site.  How the ITR makes this determination
   is up to the ITRs implementation of the EID-to-RLOC mapping system
   used (see, for example [LISP-ALT]).

   The ITR then rewrites the source address of the packet from 220.1.1.2
   to 128.200.1.2, which is the first available address in the LISP-R
   EID space available to it.  The ITR keeps this translation in a table
   in order to reverse this process when receiving packets destined to
   128.200.1.2.

   Finally, when the ITR forwards this packet without encapsulating it,
   it uses the entry in its LISP-NAT table to translate the returning
   packets' destination IPs to the proper host.

6.2.  LISP Sites with Hosts using RFC 1918 Addresses Sending to non-LISP
      Sites

   In the case where hosts using RFC 1918 addresses desire to send
   packets to non-LISP hosts, the LISP-NAT implementation acts much like
   an existing IPv4 NAT device.  The ITR providing the NAT service must
   use LISP-R EIDs for its global address pool as well as providing all
   the standard NAT functions required today.

   The source of the packet must be translated to a LISP-R EID in a
   manner similar to Section 6, and this packet must be forwarded to the
   ITR's next hop for the destination, without LISP encapsulation.

6.3.  LISP Sites with Hosts using RFC 1918 Addresses   Sending Packets
      to Other LISP Sites

   LISP-NAT allows a host with an RFC 1918 address to send packets to
   LISP hosts by translating the RFC 1918 address to a LISP EID.  After
   translation, the communication between source and destination ITR and
   ETRs continues as described in [LISP].

   An example of this translation and encapsulation follows.  For this
   example, a host has been assigned a RFC 1918 address of 192.168.1.2.
   In order to utilize LISP-NAT, the site also has been provided the
   LISP-R EID prefix of 192.0.2.0/24, and uses the first address
   (192.0.2.1) as the site's RLOC.  The rest of this PA space (192.0.2.2
   to 192.0.2.254) is used as a translation pool for this site's hosts
   who need to send packets to both non-LISP and LISP hosts.

   The Host 192.168.1.2 sends a packet destined for a non-LISP site to
   its default route (the ITR).  The ITR receives the packet and
   determines that the destination is a LISP site.  How the ITR makes
   this determination is up to the ITRs implementation of the EID/RLOC
   mapping system.

   The ITR then rewrites the source address of the packet from
   192.168.1.2 to 192.0.2.2, which is the first available address in the
   LISP EID space available to it.  The ITR keeps this translation in a
   table in order to reverse this process when receiving packets
   destined to 192.0.2.2.

   The ITR then LISP encapsulates this packet (see [LISP] for details).
   The ITR uses the site's RLOC as the LISP outer header's source and
   the translation address as the LISP inner header's source.  Once it
   decapsulates returning traffic, it uses the entry in its LISP-NAT
   table to translate the returning packet's destination IP address and
   then forward to the proper host.

6.4.  LISP-NAT and multiple EIDs

   When a site has two addresses that a host might use for global
   reachability, care must be chosen on which EID is found in DNS.  For
   example, whether applications such as DNS use the LISP-R EID or the
   LISP-NR EID.  This problem exists for NAT in general, but the
   specific issue described above is unique to LISP.  Using PITRs can
   mitigate this problem, since the LISP-NR EID can be reached in all
   cases.

6.5.  When LISP-NAT and PITRs used by the same LISP Site

   With LISP-NAT, there are two EIDs possible for a given host, the
   LISP-R EID and the LISP-NR EID.  When a site has two addresses that a
   host might use for global reachability, name-to-address directories
   may need to be modified.

   This problem, global vs. local addressability, exists for NAT in
   general, but the specific issue described above is unique to
   location/identity separation schemes.  Some of these have suggested
   running a separate DNS instance for new types of EIDs.  This solves
   the problem but introduces complexity for the site.  Alternatively,
   using PITRs can mitigate this problem, because the LISP-NR EID can be
   reached in all cases.

7.  Proxy Egress Tunnel Routers

   Proxy Egress Tunnel Routers (PETRs) allow for LISP sites to send
   packets to non-LISP sites in the case where the access network does
   not allow for the LISP site send packets with the source address of
   the site's EID(s).  A PETR is a new network element that,
   conceptually, acts as an ETR for traffic destined to non-LISP sites.
   This also has the effect of allowing an ITR avoid having to decide
   whether to encapsulate packets or not - it can always encapsulate
   packets.  An ITR would encapsulate packets destined for LISP sites
   (no change here) and these would be routed directly to the
   corespondent site's ETR.  All other packets (those destined to non-
   LISP sites) will be sent to the originating site's PETR.

   There are two primary reasons why sites would want to utilize a PETR:

   Avoiding strict uRPF failures:  Some provider's access networks
      require the source of the packets emitted to be within the
      addressing scope of the access networks. (see section 9)

   Traversing a different IP Protocol:  A LISP site may want to transmit
      packets to a non-LISP site where the some of the intermediate network
      does not support the particular IP protocol desired (v4 or v6).
      PETRs can allow this LISP site's data to 'hop over' this by
      utilizing LISP's support for mixed protocol encapsulation.

7.1.  Packet Flow with Proxy Egress Tunnel Routers

   Packets from a LISP site can reach a non-LISP site with the aid of a
   Proxy-ETR (or PETR).  An ITR is simply configured to send all non-
   LISP traffic, which it normally would have forwarded natively (non-
   encapsulated), to a PETR.  In the case where the ITR uses the a Map-
   Resolver interface
   Resolver(s), the ITR will encapsulate packets that match its the received
   Negative Map-Cache to the configured Proxy-ETR(s).  In the case where
   the ITR is connected to the mapping system directly it would
   encapsulate all packets to the configured Proxy-ETR that are cache
   misses.  Note that this outer encapsulation to the Proxy-ETR may be
   in an IP protocol other than the (inner) encapsulated data.  Routers
   then use the LISP (outer) header's destination address to route the
   packets toward the configured Proxy-ETR.

   A PETR should verify the (inner) source EID of the packet at time of
   decapsulation in order to verify that this is from a configured LISP
   site.  This is to prevent spoofed inner sources from being
   encapsulated through the Proxy-ETR.

   What follows is an example of the path a packet would take when using
   a PETR.  In this example, the LISP-NR (or LISP-R) site is given the
   EID prefix 240.2.0.0/24, and it is trying to reach host at a non-LISP
   site with the IP prefix of 192.0.2.0/24.  For the purposes of this
   example, the destination is a non-LISP site and 192.0.2.0/24 is found
   in the Internet's routing system.

   A full protocol exchange example follows:

   1.  The source host makes a DNS lookup for the destination, and gets
       192.0.2.100 (a host in a non-LISP site) in return.

   2.  The source host has a default route to customer Edge (CE) router
       and forwards the packet towards the CE.

   3.  The CE is a LISP ITR, and is configured to encapsulate traffic
       destined for non-LISP sites to a Proxy-ETR.

   4.  The Proxy ETR decapsulates the LISP packet and forwards the
       original packet to its next hop.

   5.  The packet is then routed natively and directly to the
       destination (non-LISP) site 192.0.2.0/24.

   Note that in this example the return path is asymmetric, so return
   traffic will not go back through the Proxy-ETR.  This means that in
   order to reach LISP-NR sites, non-LISP sites must still use Proxy
   ITRs.

8.  Discussion of Proxy ITRs (PITRs), LISP-NAT, and Proxy-ETRs (PETRs)

   In summary, there are three mechanisms for interworking LISP with
   non-LISP Sites (for both IPv4 and IPv6).  In the LISP-NAT option the
   LISP site can manage and control the interworking on its own.  In the
   PITR case, we the site is not required to manage the advertisement of
   it's EID prefix into the DFZ, with the cost of potentially adding
   stretch to the connections of non-LISP sites sending packets to the
   LISP site.  The third option is Proxy-ETRs, which are optionally used
   by sites relying on PITRs case to mitigate two caveats for LISP sites
   sending packets to non-LISP sites.  This means Proxy-ETRs are not
   usually expected to be deployed by themselves, rather they will be
   used to assist LISP-NR sites which are already using PITRs.

8.1.  How Proxy-ITRs and Proxy-ETRs Interact

   There is a subtle difference between Symmetrical (LISP-NAT) vs
   Asymmetrical (Proxy-ITR and Proxy-ETR) Interworking techniques.
   Operationally, Proxy-ITRs (PITRs) and Proxy-ETRs (PETRs) can (and
   likely should) be decoupled since Proxy-ITRs are best deployed
   closest to non-LISP sites, and Proxy-ETRs are best located close to
   the LISP sites they are decapsulating for.  This asymmetric placement
   of the two network elements minimizes the stretch imposed on each
   direction of the packet flow, while still allowing for coarsely
   aggregated announcements of EIDs into the Internet's routing table.

9.  Security Considerations

   Like any router or LISP ITR, PITRs will have the opportunity to
   inspect traffic at the time that they encapsulate.  The location of
   these devices in the network can have implications for discarding
   malicious traffic on behalf of ETRs which request this behavior (via
   the drop action bit in Map-Reply packets for an EID or EID prefix).

   As with traditional NAT, LISP-NAT will obscure the actual host
   LISP-NR EID behind the LISP-R addresses used as the NAT pool.

   When LISP sites send packets to non-LISP sites (these non-LISP sites
   rely on PITRs to enable Interworking), packets will have the Site's
   EID as its source IP address.  These EIDs may not be recognized by
   their Internet Service Provider's Unicast Reverse Path Forwarding
   (uRPF) rules enabled on the Provider Edge Router.  Several options
   are available to the service provider.  For example they could enable
   a less strict version of uRPF, where they only look for the existence
   of the the EID prefix in the routing table.  Another, more secure, option
   is to add a static route for the customer on the PE router, but not
   redistribute this route into the provider's routing table.  Finally,
   Proxy-ETRs can enable LISP sites to bypass this uRPF check by
   encapsulating all of their egressing traffic destined to non-LISP
   sites to the Proxy-ETR (thus ensuring the outer IP source address is
   the site's RLOC).

10.  Acknowledgments

   Thanks goes to Christian Vogt, Lixia Zhang, Robin Whittle, Michael
   Menth, and Xuewei Wang, and Noel Chiappa who have made insightful
   comments with respect to LISP Interworking and transition mechanisms.

   A special thanks goes to Scott Brim for his initial brainstorming of
   these ideas and also for his careful review.

11.  IANA Considerations

   This document creates no new requirements on IANA namespaces
   [RFC2434].

12.  References

12.1.  Normative References

   [LISP]     Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-06
              draft-ietf-lisp-14 (work in progress), January 2010. June 2011.

   [LISP-ALT]
              Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
              Alternative Topology (LISP+ALT)",
              draft-ietf-lisp-alt-03.txt
              draft-ietf-lisp-alt-07.txt (work in progress),
              Febuary 2010. June 2011.

   [LISP-MS]  Farinacci, D. and V. Fuller, "LISP Map Server",
              draft-ietf-lisp-ms-03.txt
              draft-ietf-lisp-ms-09.txt (work in progress), Feb 2010. June 2011.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC4632]  Fuller, V. and T. Li, "Classless Inter-domain Routing
              (CIDR): The Internet Address Assignment and Aggregation
              Plan", BCP 122, RFC 4632, August 2006.

12.2.  Informative References

   [CRIO]     Zhang, X., Francis, P., Wang, J., and K. Yoshida, "CRIO:
              Scaling IP Routing with the Core Router-Integrated
              Overlay".
              Overlay", January 2006.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC2993]  Hain, T., "Architectural Implications of NAT", RFC 2993,
              November 2000.

Authors' Addresses

   Darrel Lewis
   Cisco Systems, Inc.

   Email: darlewis@cisco.com

   David Meyer
   Cisco Systems, Inc.

   Email: dmm@cisco.com

   Dino Farinacci
   Cisco Systems, Inc.

   Email: dino@cisco.com

   Vince Fuller
   Cisco Systems, Inc.

   Email: vaf@cisco.com
--Apple-Mail-7-479757899 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Begin forwarded message: > From: internet-drafts@ietf.org > Date: June 30, 2011 10:41:10 PM PDT > To: i-d-announce@ietf.org > Cc: lisp@ietf.org > Subject: [lisp] I-D Action: draft-ietf-lisp-interworking-02.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Locator/ID Separation = Protocol Working Group of the IETF. >=20 > Title : Interworking LISP with IPv4 and IPv6 > Author(s) : Darrel Lewis > David Meyer > Dino Farinacci > Vince Fuller > Filename : draft-ietf-lisp-interworking-02.txt > Pages : 24 > Date : 2011-06-30 >=20 > This document describes techniques for allowing sites running the > Locator/ID Separation Protocol (LISP) to interoperate with Internet > sites (which may be using either IPv4, IPv6, or both) but which are > not running LISP. A fundamental property of LISP speaking sites is > that they use Endpoint Identifiers (EIDs), rather than traditional = IP > addresses, in the source and destination fields of all traffic they > emit or receive. While EIDs are syntactically identical to IPv4 or > IPv6 addresses, normally routes to them are not carried in the = global > routing system so an interoperability mechanism is needed for non- > LISP-speaking sites to exchange traffic with LISP-speaking sites. > This document introduces three such mechanisms. The first uses a = new > network element, the LISP Proxy Ingress Tunnel Routers (PITR) > (Section 5) to act as a intermediate LISP Ingress Tunnel Router = (ITR) > for non-LISP-speaking hosts. Second the document adds Network > Address Translation (NAT) functionality to LISP Ingress and LISP > Egress Tunnel Routers (xTRs) to substitute routable IP addresses for > non-routable EIDs. Finally, this document introduces a Proxy Egress > Tunnel Router (PETR) to handle cases where a LISP ITR cannot send > packets to non-LISP sites without encapsulation. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-lisp-interworking-02.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-interworking-02.txt > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail-7-479757899--