Re: [lisp] draft-ietf-lisp-introduction-05 - EID/RLOC Syntax

"Joel M. Halpern" <jmh@joelhalpern.com> Sun, 12 October 2014 02:36 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25611A875F for <lisp@ietfa.amsl.com>; Sat, 11 Oct 2014 19:36:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LSc76UHXqIT for <lisp@ietfa.amsl.com>; Sat, 11 Oct 2014 19:36:12 -0700 (PDT)
Received: from maila1.tigertech.net (maila1.tigertech.net [208.80.4.151]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 530211A0439 for <lisp@ietf.org>; Sat, 11 Oct 2014 19:36:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila1.tigertech.net (Postfix) with ESMTP id 203003659ED; Sat, 11 Oct 2014 19:36:12 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at maila1.tigertech.net
Received: from [192.168.1.90] (107-194-85-212.lightspeed.nsvltn.sbcglobal.net [107.194.85.212]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila1.tigertech.net (Postfix) with ESMTPSA id 6D13B3659EC; Sat, 11 Oct 2014 19:36:11 -0700 (PDT)
Message-ID: <5439E91A.4050701@joelhalpern.com>
Date: Sat, 11 Oct 2014 22:36:10 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ronald Bonica <rbonica@juniper.net>, Dino Farinacci <farinacci@gmail.com>
References: <fddce201eb144632a895d6c2f27bd637@CO1PR05MB442.namprd05.prod.outlook.com> <5439BE86.20302@joelhalpern.com> <1ee88b789ea2413ca5ddd6eb00a47374@CO1PR05MB442.namprd05.prod.outlook.com> <8C11EEBA-6B1C-4ED2-81F8-09C563C4CB2E@gmail.com> <8f701cb0ef564355ab865a027f2043a0@CO1PR05MB442.namprd05.prod.outlook.com> <12DD0FED-3A7C-44B6-9AA8-3F04702E7A0D@gmail.com> <66048b82c60c48dfbd35efe9a5589126@CO1PR05MB442.namprd05.prod.outlook.com>
In-Reply-To: <66048b82c60c48dfbd35efe9a5589126@CO1PR05MB442.namprd05.prod.outlook.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/h-frIVJcpZbndnOU7NR34bkZxVU
Cc: "lisp@ietf.org" <lisp@ietf.org>
Subject: Re: [lisp] draft-ietf-lisp-introduction-05 - EID/RLOC Syntax
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Oct 2014 02:36:13 -0000

We do not want to introduce a normative dependence on the LCAF draft, 
and knowing exactly how other things may be encoded in the future is not 
needed for understanding this draft.

Would it help if we said that EIDs or RLOCs may use syntaxes associated 
with other address families?

Yours,
Joel

On 10/11/14, 10:15 PM, Ronald Bonica wrote:
> Dino,
>
> The very first page of the Intro document says that RLOCs and EIDs can be syntactically different from IP addresses. However, it leaves the reader to guess what this means. So, I need to ask 20 seemingly obvious questions to ferret out the actually meaning. Believe me, it is as painful to me as it is to you!
>
> What does it mean to be "syntactically different" from an IP address? If you can explain that, we won't have to play 20 questions.
>
>                                                                                            Ron
>
>
>
>> -----Original Message-----
>> From: Dino Farinacci [mailto:farinacci@gmail.com]
>> Sent: Saturday, October 11, 2014 9:42 PM
>> To: Ronald Bonica
>> Cc: Joel M. Halpern; lisp@ietf.org
>> Subject: Re: [lisp] draft-ietf-lisp-introduction-05 - EID/RLOC Syntax
>>
>>> 1) Is it a requirement for LISP packets to be routable over the Internet?
>>
>> Well yes if you want them to get to an ETR.
>>
>>>     - If so, doesn't the outer header have to be IP?
>>
>> Not if you are trying to move packets from ITR to ETR via a layer-2 bridged
>> network or  layer-2 MPLS network.
>>
>>>     - If so, doesn't the RLOC have to be an IP address?
>>>
>>> 2) If the LISP payload is IPv4 or IPv6:
>>>     - Does the EID have to be 32 or 128 bits
>>
>> Yes because it arrives at the ITR in either an IPv4 or IPv6 packet.
>>
>>>     - If so, how is it "syntactically different" from an IP address
>>
>> It's not. But your line of questioning is both obvious and confusing.
>>
>>>     - If not, how can the outer header be either IPv4 or IPv6
>>>
>>> 3) Does the LISP payload have to be IP?
>>>     - If not, what protocols are allowed
>>>     - If not, how does the ETR know what protocol the payload is? The LISP
>> header doesn't contain a protocol id or ethertype
>>
>> Can you ask a specific question please?
>>
>> If two hosts are going to talk to each other they need to use the same
>> protocol. So the EID is relative to that protocol's address format.
>>
>> When those packets are encapsulated by an ITR to the ETR over a core
>> network the ITR, ETR, and the vote network use the same protocol. So the
>> RLOC address is relative to that protocol's address format.
>>
>> The inner and outer header can be any packet format. So the LISP mapping
>> database could support the transport of  AppleTalk packets between hosts
>> over an IPX core network between xTRs.
>>
>> Dino