Re: [lisp] [Ila] LISP for ILA

"Alberto Rodriguez Natal (natal)" <> Tue, 13 March 2018 20:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ABF93126CD6; Tue, 13 Mar 2018 13:53:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.531
X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cLalyACbJ0sg; Tue, 13 Mar 2018 13:53:31 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4F546126C89; Tue, 13 Mar 2018 13:53:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2370; q=dns/txt; s=iport; t=1520974411; x=1522184011; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Zy4sMuPukqvL54x245xwNR9uLqHqeRL1Si9kgm7YPGI=; b=R8Rl8AGv0zoHC6nZElAVzhH7b/QOH1vDAOKsUjaDKApPoJXJGHaKTXG6 eDc0wx15XN+e+XptHVCehsUvYO3HCOgUNyC8Cnbdgh86Vi9fKYSQLwkBH oU0+jouB/3mpp6Tz6SRnLdvhNQNF/ZOqWCUsOZw/TlUy1LdTowtIxNzUV c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.47,466,1515456000"; d="scan'208";a="82981605"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Mar 2018 20:53:30 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w2DKrUII028543 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 13 Mar 2018 20:53:30 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 13 Mar 2018 15:53:29 -0500
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Tue, 13 Mar 2018 15:53:29 -0500
From: "Alberto Rodriguez Natal (natal)" <>
To: Dino Farinacci <>
CC: Tom Herbert <>, "Fabio Maino (fmaino)" <>, "" <>, "" <>, Albert Cabellos <>, "Vina Ermagan (vermagan)" <>
Thread-Topic: [Ila] LISP for ILA
Thread-Index: AQHTs4N8SaQwoGnN/EueWlx2YLMdsaPCxXuAgAAE/oCAC7JiAIAAesGA//+ag4A=
Date: Tue, 13 Mar 2018 20:53:29 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [lisp] [Ila] LISP for ILA
X-Mailman-Version: 2.1.22
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, 13 Mar 2018 20:53:33 -0000

´╗┐On 3/13/18, 12:56 PM, "Dino Farinacci" <> wrote:

    > Using IPv6 format is something we considered while writing the draft. We went the LCAF route to have an explicit way to (1) distinguish ILA Identifiers/Locators from other addresses in the Mapping System, (2) specify the Identifier/Locator length and (3) include metadata bits. However, for simple scenarios (only ILA domain, no overlapping with non-local addresses, no multiple SIR prefixes, fixed Identifier length, no need for metadata bits, etc) things could work with AFI=2 format. If the rough consensus from the WG(s) is that a plain AFI=2 format is sufficient, we can certainly update the draft. I would like to know the opinion of others on this. 
    Well identifiers can be encoded as ::<64-bits> and locators can be encoded as a regular prefix (leading bits and mask-length).
    I have been running with some ILA addresses in my mapping system for a while now. I wanted to show Tom that it could be done easily. What I did was register a 128-bit EID which was the SIR-prefix plus identifier which mapped to a 128-bit RLOC that contained high-order bits as the routable locator and low-order bits as the identifier. I realize this is a bit redundant, but it could be done with no protocol or implementation changes.

There is another option that we discussed when we were considering IPv6 encoding. Instead of being redundant with the low-order bits of the Locator, you could use those to encode a "special identifier" that you will use when sending control-plane messages to that Locator. This way, the ILA device at that Locator has a clear way to punt packets to control-plane processing.