Re: [lisp] draft-ietf-lisp-introduction-05

While the RLOC is usually IP, the approach being taken does not preclude 
other uses.  And there explicit deployed use cases for EIDs which are 
not IP (for example, ones that are MAC addresses.)

The point is that the current understanding of the archtiecture allows 
for this range of cases.  The fact that the original RFC did not discuss 
them, but is format-compatible with the range, does NOT mean that we can 
not allow for those in the architectural introduction or in other future 
documents which update the work.

My concern was specifically your assertion that the RFC prohibited those 
uses.  We generally operate on the basis that anything not prohibited is 
permitted, rather than the obverse.  This enables innovation.  (It also 
leads to a quote from one of my Cisco colleagues at a meeting "That's 
what routers do, the lie, cheat, and mangle packets.")

Yours,
Joel

On 10/11/14, 8:03 PM, Ronald Bonica wrote:
> Joel,
>
> If you put something that isn't syntactically identical to an IPv4/IPv6 address in the destination field of the outer header, how will it get to ETR?
>
>                                                                                  Ron
>
>
>> -----Original Message-----
>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>> Sent: Saturday, October 11, 2014 7:35 PM
>> To: Ronald Bonica; lisp@ietf.org
>> Subject: Re: [lisp] draft-ietf-lisp-introduction-05 - EID/RLOC Syntax
>>
>> The working group has other documents that define other formats for EIDs
>> and RLOCs.  These are defined with AFIs.  In fact, AFIs are used in 6830 so as
>> to allow compatible extension of the work.  At the time 6830 was published,
>> those were the two defined forms.
>>
>> Suggesting taht an extensible RFC prevents us from extending the work
>> would be odd.  Since we do have work under way (the LCAF draft) which
>> defines many other forms, it is quite appropriate to for the introduction to
>> indicate that a broader range is possible.
>>
>> Yours,
>> Joel
>>
>> On 10/11/14, 7:17 PM, Ronald Bonica wrote:
>>> Folks,
>>>
>>> Section 1 of draft-ietf-lisp-introduction-05 says:
>>>
>>> "This document describes the LISP architecture, its main operational
>>> mechanisms as its design rationale.  It is important to note that this
>>> document does not specify or complement the LISP protocol.  The
>>> interested reader should refer to the main LISP specifications
>>> [RFC6830] and the complementary documents [RFC6831],[RFC6832],
>>> [RFC6833],[RFC6834],[RFC6835], [RFC6836] for the protocol
>>> specifications along with the LISP deployment guidelines [RFC7215]."
>>>
>>> I interpret this as meaning that draft-ietf-lisp-introduction-05 MUST
>>> not contradict RFC 6830.
>>>
>>> However, Section 1 of draft-ietf-lisp-introduction-05 also says:
>>>
>>> "LISP creates two separate namespaces, EIDs (End-host IDentifiers) and
>>> RLOCs (Routing LOCators), both are -typically, but not limited
>>> to- syntactically identical to the current IPv4 and IPv6 addresses."
>>>
>>> However, RFC 6830 says:
>>>
>>> "An RLOC is an IPv4 [RFC0791] or IPv6  [RFC2460] address of an Egress
>>> Tunnel Router (ETR)."
>>>
>>> It also says:
>>>
>>> "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."
>>>
>>> Given these statements, how can the RLOC or EID by syntactically
>>> different from an IPv4 or IPv6 address?
>>>
>>> Ron Bonica
>>>
>>> _______________________________________________ lisp mailing
>> list
>>> lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
>>>