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

From: Ronald Bonica <[email-masked]>
Date: Sat, 11 Oct 2014 23:17:09 +0000

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 11 Oct 2014 19:34:30 -0400

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:
> "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]."
>
> "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 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."
>
> _______________________________________________ lisp mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Ronald Bonica <[email-masked]>
Date: Sun, 12 Oct 2014 00:03:11 +0000

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-masked]]
> Sent: Saturday, October 11, 2014 7:35 PM
> To: Ronald Bonica; [email-masked]
> Subject: Re: [lisp] draft-ietf-lisp-introduction-05 - EID/RLOC Syntax
> 
> 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.
> 
> defines many other forms, it is quite appropriate to for the introduction to
> indicate that a broader range is possible.
> 
> Yours,
> Joel
> 
> > mechanisms as its design rationale.  It is important to note that this
> > document does not specify or complement the LISP protocol.  The
> > "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 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."
> >

---

From: Ronald Bonica <[email-masked]>
Date: Sun, 12 Oct 2014 00:05:11 +0000

And strictly speaking, how do you reconcile your statement, below, with the following statement from RFC 6830:

                                                 Ron

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 11 Oct 2014 20:29:37 -0400

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 11 Oct 2014 20:30:47 -0400

At the time of RFC 6830 that statement was true.  Note that we did not 
write "An RLOC MUST be an IPv4 or IPv6 address."  The statement was 
descriptive, not prescriptive.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 11 Oct 2014 20:52:32 -0400

> On Oct 11, 2014, at 8:03 PM, Ronald Bonica <[email-masked]> wrote:
> 
> Joel,
> 

The question is actually malformed. If you out any address in a header (and you don't say what type of header it is), then the address is relative to that packet format. 

So what are really trying to ask?

Dino

> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Ronald Bonica <[email-masked]>
Date: Sun, 12 Oct 2014 01:23:00 +0000

Hi Dino,

True! There are actually a few questions embedded in my original comment.

1) Is it a requirement for LISP packets to be routable over the Internet?
	- If so, doesn't the outer header have to be IP?
	- 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
	- If so, how is it "syntactically different" from an IP address
	- 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.

                                                                                                          Ron

> From: Dino Farinacci [mailto:[email-masked]]
> Sent: Saturday, October 11, 2014 8:53 PM
> To: Ronald Bonica
> Cc: Joel M. Halpern; [email-masked]
> > 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?
> 
> The question is actually malformed. If you out any address in a header (and
> you don't say what type of header it is), then the address is relative to that
> packet format.
> 
> >> 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.
> >>
> >>> _______________________________________________ lisp
> mailing
> >> list

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 11 Oct 2014 21:42:29 -0400

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

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

---

From: Ronald Bonica <[email-masked]>
Date: Sun, 12 Oct 2014 02:15:43 +0000

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

> Sent: Saturday, October 11, 2014 9:42 PM
> To: Ronald Bonica
> >    - If not, how does the ETR know what protocol the payload is? The LISP
> header doesn't contain a protocol id or ethertype
> 
> 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

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 11 Oct 2014 22:23:47 -0400

> 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 see…

But it's not as complex as you may think it is.

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

It means the EIDs and RLOCs can be from any address family. 

Syntactically an AppleTalk address is different than an IPv4 address. 

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 11 Oct 2014 22:36:10 -0400

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

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 13 Oct 2014 11:07:48 +0200

Hi,

I think that Joel made a good point in a previous mail.  

RFC6830 defines EID&RLOC as IPv4 and IPv6 addresses but does not prohibit the definition of EID & RLOC in other types/form.

The intro document can simply state this fact and reference LCAF as ongoing work to add extensibility to LISP.

On the other hand, may be the LCAF document should update the definition of EID and RLOC accordingly.

ciao

Luigi

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 13 Oct 2014 14:20:31 +0200

Hi,

RFC6830 defines EID&RLOC as IPv4 and IPv6 addresses but does not prohibit
the definition of EID & RLOC in other types/form.

The intro document can simply state this fact and reference LCAF as ongoing
work to add extensibility to LISP.

On the other hand, may be the LCAF document should update the definition of
EID and RLOC accordingly.

Luigi

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.

Dino
_______________________________________________
lisp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lisp

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 13 Oct 2014 14:20:39 +0200

Hi,

Luigi

Dino

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 13 Oct 2014 14:21:46 +0200

Hi,

Luigi

Dino

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 13 Oct 2014 14:21:52 +0200

Hi,

Luigi

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 13 Oct 2014 10:34:36 -0400

> On the other hand, may be the LCAF document should update the definition of EID and RLOC accordingly.

Do you mean to explain how new address types are introduced by LCAF encoding in that EIDs and RLOCs can be multi-tuple entities and may not be used for data transport?

Dino

---

From: Albert Cabellos <[email-masked]>
Date: Mon, 13 Oct 2014 18:59:35 +0200

Hi Joel

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

What about this (second paragraph section 2.4.1)?

Typical mappings in LISP bind EIDs in the form of IP prefixes with
a set of RLOCs, also in the form of IPs.  IPv4 and IPv6 addresses are
encoded using the appropriate Address Family Identifier (AFI)
[RFC3232]. However LISP also supports more general syntaxes associated
with other address families by means of LISP Canonical Address Format (LCAF)
[I-D.ietf-lisp-lcaf].

Albert

>> ferret out the actually meaning. Believe me, it is as painful to me as it is
>> to you!
>>
>>> Not if you are trying to move packets from ITR to ETR via a layer-2
>>> bridged
>>> network or  layer-2 MPLS network.
>>>