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:[email protected]]
Sent: Saturday, October 11, 2014 7:35 PM
To: Ronald Bonica; [email protected]
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
[email protected] https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
