Subject: Re: [rrg] Map and Encaps

From: [email-masked] (Noel Chiappa)
Date: Wed, 10 Dec 2008 09:23:07 -0500 (EST)

> From: Scott Brim <[email-masked]>

    > A LISP EID names a network attachment point. 

Well.... sort of. (And there are two kinds, IPv4 EIDs and IPv6 EIDs.) What
the IPv4 EID really names is whatever a vanilla 'IPv4 address' names, which
is somewhat ambiguous itself.

It definitely names an entity with a collection of higher-level protocols and
their ports (UDP, ICMP, TCP, etc). It also seems to name an interface
(because to get packets to a different interface on a dual-homed host, you
need to use a different IPv4 address). This is another 'axis of confusion'
with IPv4 addresses (which are also muddied on the location/identity axis).

	Noel
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: Roland Dobbins <[email-masked]>
Date: Wed, 10 Dec 2008 22:47:33 +0800

On Dec 10, 2008, at 10:23 PM, Noel Chiappa wrote:

> It also seems to name an interface (because to get packets to a  
> different interface on a dual-homed host, you need to use a  
> different IPv4 address).

It's probably even less concrete than this; there are load-balancing  
and high-availability mechanisms/techniques which, when employed, tend  
to invalidate this premise, for various definitions of 'interface'.

-----------------------------------------------------------------------
Roland Dobbins <[email-masked]> // +852.9133.2844 mobile

      History is a great teacher, but it also lies with impunity.

                    -- John Robb

---

From: Scott Brim <[email-masked]>
Date: Wed, 10 Dec 2008 12:23:15 -0500

> with IPv4 addresses (which are also muddied on the location/identity axis).

First I admit I wrote too quickly, because an EID might be
virtualized.  We may be disentangling identifier and locator but we
still will not have disentanbled locator and "forwarding directive".

Second, the reason I said it names a network attachment point is that
from the point of view of the network -- which is what matters here --
it knows attachment points, not stacks or interfaces.  But that's a
nit.

---

From: Shane Amante <[email-masked]>
Date: Wed, 10 Dec 2008 12:35:04 -0700

Scott, All,

> it knows attachment points, not stacks or interfaces.  But that's a

Related to your second point, I've also started to ponder the longer  
term "flexibility" of a map-and-encaps approach.  More specifically:
1)  First, as time progresses, will components within/of the network  
become more virtualized?  In other words, isn't it increasingly likely  
that we'll want to "name" not only network attachment points, but also  
stacks, interfaces, virtual machines, processes, etc.?
2)  Assuming that #1 is desirable (or required), how would the current  
crop of map-and-encaps proposals (easily) accommodate that?  For  
example, are we reliant on both mapping and encapsulation (and, within  
what "scopes") to accommodate the above, or not?

In summary, I'm asking: what is the roadmap beyond this "first-gen"  
set of map-and-encaps proposals to attain those goals, (assuming  
people agree they are valid goals)?

Although there's been a lot of emphasis on the feasibility & speed of  
deployment related to specific (classes of) proposals, there doesn't  
seem to have been much, if any, detailed discussion related to their  
flexibility to accommodate, say, #1 among other things that we can  
reasonably predict might happen in the near future.  In the end, a  
"roadmap" should also be given serious consideration when evaluating  
all of the (classes of) proposals.

Thoughts?

-shane

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 10 Dec 2008 13:28:03 -0800

Brian Carpenter wrote a paper (and had some slideware) indicating how  
we can iterate the map-n-encap designs. So for each level of  
encapsulation you have another x-to-y mapping with a separate mapping  
database system.

I believe LISP can do this and is documented in the main LISP Internet  
Draft. This is how we allow Loc/ID split to be done in site-based ITRs/ 
ETRs as well as by core-based TE-ITRs/TE-ETRs for ISP based Traffic  
Engineering.

This is an example of "recursive tunneling" much like MPLS has a VC- 
label inside of a transport-label.

We also see cases for "re-encapsulate tunneling" where an ETR sits on  
a Data Center edge decapsulates for Loc/ID split purposes but is also  
an ITR to add encapsulation for ETRs that are directly connected to  
server host clusters. This is desirable for implementing server load  
balancing where a virtual IP address (i.e. known as VIPs in the SLB  
community) is used as an EID to lookup a set of RLOCs which have  
measured load against them.

Dino

On Dec 10, 2008, at 11:35 AM, Shane Amante wrote:

> become more virtualized?  In other words, isn't it increasingly  
> likely that we'll want to "name" not only network attachment points,  
> but also stacks, interfaces, virtual machines, processes, etc.?
> 2)  Assuming that #1 is desirable (or required), how would the  
> current crop of map-and-encaps proposals (easily) accommodate that?   
> For example, are we reliant on both mapping and encapsulation (and,  
> within what "scopes") to accommodate the above, or not?
>
> Although there's been a lot of emphasis on the feasibility & speed  
> of deployment related to specific (classes of) proposals, there  
> doesn't seem to have been much, if any, detailed discussion related  
> to their flexibility to accommodate, say, #1 among other things that  
> we can reasonably predict might happen in the near future.  In the  
> end, a "roadmap" should also be given serious consideration when  
> evaluating all of the (classes of) proposals.
>
> Thoughts?
>
> -shane

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 10 Dec 2008 13:41:42 -0800

Dino,

This has in fact always been an option with ISATAP, i.e.,
it is perfectly reasonable to have site-within-site nesting
with site border routers acting as ETRs on one site and ITRs
on another. This is also now documented in RANGER/VET/SEAL.

Fred
[email-masked]

>-----Original Message-----
>From: Dino Farinacci [mailto:[email-masked]]
>Sent: Wednesday, December 10, 2008 1:28 PM
>To: Shane Amante
>Cc: [email-masked]; Noel Chiappa
>Subject: Re: [rrg] Map and Encaps
>