Subject: [RAM] My remarks at the microphone

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 22 Mar 2007 15:24:55 +0100

Let me repeat and expand upon my remarks just now.

-- The place --

There are three obvious places to implement the locator/identifier  
(or locator/locator) mapping:

1. in hosts
2. in site border routers / middleboxes
3. in ISP networks

In hosts is extremely problematic for a number of reasons:

- costs and benefits aren't aligned with regard to the routing table  
issue, so not enough incentive for deployment
- the number of hosts is enormous, updating them all takes  
prohibitive amounts of time
- middleboxes and the like make any kind of change, especially with  
IPv4, very hard to deploy
- there is no reason to assume that renumbering locators will be  
significantly easier than renumbering host addresses is today

On the other hand, the advantage of working in hosts is that the  
additional state is least problematic there because hosts already  
keep state for all their sessions/associations.

Site border routers or middleboxes share the economic issue and, to a  
lesser degree, the renumbering issue. Middleboxes (but not site  
border routers) also generally store state for active sessions and  
the number of sessions is still relatively limited at this point, so  
a chaching mechanism is still workable here.

Performing the mapping in ISP networks has the very important benefit  
that cost and benefit are aligned, but at this point, the number of  
sessions flowing through any individual box is almost certainly too  
large to be safely handled using caching, so flooding of at least  
some state for all possible destinations is probably required.

Additionally, it's not too problematic to push something that started  
in ISP networks to middleboxes, and something in middleboxes to  
hosts, but the other way around is often not possible or very hard.  
See the issues with shim6 proxying

-- A mapping system --

As I said, BGP and DNS can both be considered to be mapping  
protocols, and they both have some aspects that are desirable and  
some aspects that are problematic.

The DNS can carry millions of entries in a single zone (with some  
effort) and probably an unlimited number of entries given a suitable  
hierarchy. However, it requires on-demand operation, which means  
dropped packets and/or delays at session start and the risk of caches  
(see SQL slammer worm experiences). The DNS also has caching so not  
only do you not get any updates when something changes, if you (as an  
application) go out and ask again, you get a cached answer.

BGP on the other hand floods everything but has serious scaling  
issues and suffers from the problem that local optimizations  
introduce global state. Additionally, BGP is a routing protocol so it  
needs to know about paths and loops, which means that information in  
BGP must be updated at each hop.

What we need in a new mapping system is the scalability and  
parallelism of the DNS coupled with the immediacy of BGP, but where  
BGP distributes next hop information, the new mapping system should  
distribute "last hop" information.

Margaret (I think) brought up the point that if a new mapping system  
contains all the information that's now in BGP, we haven't really  
gained anything. That's not necessarily true. The problem with BGP is  
not so much the amount of information, or even the number of updates,  
but rather, the need for all this information to come together in one  
place: the RIB of every core router. If the new system is designed to  
allow the easy splitting up the full state of the entire internet  
over an arbitrary number of devices, each of those devices can live  
at the knee in the price/performance curve.

An important goal in a new mapping protocol should be the ability to  
flood updates where needed, i.e., in the case of multihoming where  
the fact that one ISP is no longer usable is important to know for  
all correspondents of the multihomed site, and the more deliberate  
propagation of information that isn't time sensitive, such as the  
movement of a single homed user of PI space. Additionally, such a  
protocol can supply hooks for obtaining more detailed information  
directly from the source. This would be useful in mobility, where a  
destination is always reachable through the home agent, and a slight  
delay in optimizing the path towards the current location of the  
mobile node isn't problematic. In the same way, the flooded mapping  
state could be highly aggregated and therefore make packets flow  
rather suboptimally, but as soon as communciation starts, better  
mappings can be negotiated end-to-end.

If we go for a "jack up" solution to the routing scalability problem,  
existing PI prefixes can be jacked up one by one, facilitating  
gradual deployment. However, the mapping mechanism could be made  
forward compatible with more advanced identifier/locator splits so  
the benefits would be in both the short-medium and long-medium terms.

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 22 Mar 2007 07:31:22 -0700

> distribute "last hop" information.

Given the state of the global DNS in terms of scaling/resiliency/ 
maintenance/patching (I'm not talking about the roots or the TLDs,  
but Everything Else), it's important to note that whatever this  
system is that you're positing probably shouldn't be a sysadmin-type  
thing that runs on general-purpose computers, but rather in-band in  
terms of the networking infrastructure itself.  This is where the  
various proposals to actually rely upon the DNS for lookups fall down.

-----------------------------------------------------------------------
Roland Dobbins <[email-masked]> // 408.527.6376 voice

         Words that come from a machine have no soul.

                       -- Duong Van Ngo

---

From: <[email-masked]>
Date: Thu, 22 Mar 2007 15:39:17 -0000

on the place:
 
isn't it possible that the solution might be implemented in different places depending on the functionality to be suported? Thus, the loc id split might go all the way to the hosts if they want in-session handover or host multi-homing, but not in other cases? 
 
performing this near the ISP edge does not feel like a problem to me - have you seen what they are doing with DPI?!
 
louise

________________________________

From: Iljitsch van Beijnum [mailto:[email-masked]]
Sent: Thu 22/03/2007 14:24
To: [email-masked]
Cc: [email-masked]
Subject: [Int-area] My remarks at the microphone

-- The place --

1. in hosts

-- A mapping system --

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 22 Mar 2007 11:02:53 -0700

> some aspects that are problematic.

After this week, I have concluded that both BGP and DNS *should not*  
be considered. However, we could model something new off of BGP and  
DNS. That is, a pull versus push model or a combination of both.

> introduce global state.

BGP does not flood everything. On eBGP peering it sends only best paths.

> distribute "last hop" information.

What is last-hop information?

Dino

---

From: "Chris L. Morrow" <[email-masked]>
Date: Thu, 22 Mar 2007 18:22:28 +0000 (GMT)

On Thu, 22 Mar 2007 [email-masked] wrote:

>  performing this near the ISP edge does not feel like a problem to me -
> have you seen what they are doing with DPI?!

have you seen the cost of the DPI boxes? :) I'm not sure I've got 500k
USD/gig of traffic, nevermind no one wants to support DPI on an
ChOC48->DS1...

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 22 Mar 2007 20:27:39 +0100

> After this week, I have concluded that both BGP and DNS *should  
> not* be considered. However, we could model something new off of  
> BGP and DNS. That is, a pull versus push model or a combination of  
> both.

Indeed.

> BGP does not flood everything. On eBGP peering it sends only best  

(iBGP does that, too.)

I mean everything in the sense of all prefixes.

>> parallelism of the DNS coupled with the immediacy of BGP, but  
>> where BGP distributes next hop information, the new mapping system  
>> should distribute "last hop" information.

> What is last-hop information?

In BGP, there is a "next hop" attribute that pretty much does what  
the name suggests, we'd expect nothing less from a routing protocol.  
However, in an id/loc (or loc/loc) mapping system, we're not coming  
dealing with the next hop the packet is sent to, but rather, the  
place where it can be decapsulated, which can be considered the "last  
hop" although that's probably not 100% accurate. The intermediate  
hops don't interest us here, either we assume that if a locator  
address is present in the mapping database it's reachable (and we  
flood unreachability information) or we put in an additional protocol  
that checks whether the decapsulation box is reachable.

---

From: JFC Morfin <[email-masked]>
Date: Fri, 23 Mar 2007 06:34:37 +0100

>2. in site border routers / middleboxes

4. through OPES

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 23 Mar 2007 10:45:31 +0100

On Mar 22, 2007, at 8:27 PM, Iljitsch van Beijnum wrote:
>>> where BGP distributes next hop information, the new mapping  
>>> system should distribute "last hop" information.
>
> the name suggests, we'd expect nothing less from a routing  
> protocol. However, in an id/loc (or loc/loc) mapping system, we're  
> not coming dealing with the next hop the packet is sent to, but  
> rather, the place where it can be decapsulated, which can be  
> considered the "last hop" although that's probably not 100%  
> accurate. The intermediate hops don't interest us here, either we  
> assume that if a locator address is present in the mapping database  
> it's reachable (and we flood unreachability information) or we put  
> in an additional protocol that checks whether the decapsulation box  
> is reachable.

I'm not sure if it's productive to get this far down into the  
minutiae of BGP, but IMO the semantics of the BGP next hop (in  
particular, that of IBGP or multihop EBGP) are closely aligned with  
what you've referred to as "last hop".  That is, the IBGP next hop  
specifies a typically distant router, and the physical next hop  
router has to be determined through further means (e.g., a lookup in  
the IGP, but also recall that for some address families the next hop  
is reached through some kind of tunnel -- think about VPNv4 or  
softwires).  The only real divergence between this and what you've  
called a "last hop" router is that it's more difficult to determine  
reachability of the "last hop" a priori than it is for a regular BGP  
next hop, since the "last hop" will typically be in some distant AS.

I don't intend to make the case one way or the other as to BGP's  
suitability as a mapping protocol, but did want to point out that  
(IMO) the "last hop" point doesn't really apply.

--John

---

From: John G. Scudder <[email-masked]>
Date: Fri, 23 Mar 2007 10:50:39 +0100

[re-sending after adding myself to int-area, sorry for the duplicate  
to ram and individuals]

--John