Subject: [Int-area] 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.

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

---

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

---

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.

>> introduce global state.

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

(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: "Templin, Fred L" <[email-masked]>
Date: Thu, 22 Mar 2007 14:24:19 -0700

I made a rather strong statement with an individual during a
meeting this week that really should more appropriately have
been vetted with the rest of the community instead - so, here
I am.

In the classic model, we have traditionally considered the layer
immediately below IP (L3) as the link layer (L2). But, in some
common scenarios there is actually quite a lot that goes on below
IP but above the datalink. Some have called this "L2.5", but I
find that term to be misleading because it seems to imply that
there is one and only one functional layer between L3 and L2 and
that does not accurately capture all scenarios.

I wrote a draft that tried to address this by re-introducing the
legacy OSI terminology which specified a 3 sublayer decomposition
of L3 (the internet sublayer (L3c), the subnet enhancement sublayer
(L3b) and the subnet access sublayer (L3a)). But, even this more
specific terminology suffers from hazy distinctions between what
belongs in one of the sublayers as opposed to another.

So, can we simply call it the "sub-IP layer" as opposed to the
other alternatives? "Sub-IP" makes no statement about any layering
structure that may occur immediately below IP, and as such it
allows for any level of mechanisms that may need to be implemented
below IP down to and including the (classical) link layer. The term
can also be used even if there is no intermediate mechanism at all,
since L2 is by definition a "sub-IP" layer.

In summary, I belive there is no one precise way to call the
mechanisms that might occur immediatley below IP so can we
just collectively call them:

   The "sub-IP layer"

Thanks - Fred
[email-masked]

---

From: <[email-masked]>
Date: Thu, 22 Mar 2007 16:50:51 -0500

Fred,

There used to be the Sub IP area in the IETF, see
http://www.ietf.org/IESG/STATEMENTS/sub_area.txt

Is something like this what you are talking about, or are you talking
something more about the
l2-l3 interface on end points?

I think there is some baggage with the term Sub-IP, so I wouldn't
recommend using this term.

John 

>-----Original Message-----
>From: ext Templin, Fred L [mailto:[email-masked]] 
>Sent: 22 March, 2007 14:24
>To: [email-masked]
>Cc: [email-masked]
>Subject: [Int-area] the layer below IP
>
>been vetted with the rest of the community instead - so, here I am.
>
>In the classic model, we have traditionally considered the 
>layer immediately below IP (L3) as the link layer (L2). But, 
>in some common scenarios there is actually quite a lot that 
>goes on below IP but above the datalink. Some have called this 
>"L2.5", but I find that term to be misleading because it seems 
>to imply that there is one and only one functional layer 
>between L3 and L2 and that does not accurately capture all scenarios.
>
>I wrote a draft that tried to address this by re-introducing 
>the legacy OSI terminology which specified a 3 sublayer 
>decomposition of L3 (the internet sublayer (L3c), the subnet 
>enhancement sublayer
>(L3b) and the subnet access sublayer (L3a)). But, even this 
>more specific terminology suffers from hazy distinctions 
>between what belongs in one of the sublayers as opposed to another.
>
>other alternatives? "Sub-IP" makes no statement about any 
>layering structure that may occur immediately below IP, and as 
>such it allows for any level of mechanisms that may need to be 
>implemented below IP down to and including the (classical) 
>link layer. The term can also be used even if there is no 
>intermediate mechanism at all, since L2 is by definition a 
>"sub-IP" layer.
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 22 Mar 2007 22:31:48 -0700

> recommend using this term.

Clearly there is also baggage with the terms L3a/b/c, and L2.5
does not capture it because there is not any one clearly defined
layer that occurs between L3 and L2.

What would your suggestion would be?

Fred

---

From: Fred Baker <[email-masked]>
Date: Fri, 23 Mar 2007 07:32:08 +0100

On Mar 23, 2007, at 6:31 AM, Templin, Fred L wrote:

> Clearly there is also baggage with the terms L3a/b/c, and L2.5 does  
> not capture it because there is not any one clearly defined layer  
> that occurs between L3 and L2.

they didn't describe that because of the concept of sub-layering,  
which was summarily tossed on its ear when IEEE 802 decided that it  
could work on what we now call 'ethernet switching' when all  
technologies that form networks were supposed to move to ANSI (early  
1980's) if it worried about what header was used when forming the  
network.

L2 in the OSI model takes the signal delivered by the physical layer  
(the wire, fiber, or other channel, and the means by which data is  
encoded there) and interprets it into messages at that layer,  
permitting two devices that are physically connected to exchange  
information. L3 in the OSI model allows such L2 connections to be  
relayed to form networks. So from that perspective (duh) an ethernet- 
switched LAN is a network, and Ethernet is being used as an L3-of-sorts.

from my perspective, it is more useful to consider the network layer  
sub-layered into an intranet layer and an internet layer. X.25, ATM,  
Frame Relay, Ethernet Switching, MPLS, and so on have the  
characteristic that the use the lowest communication layer's header  
to form a network (what I call intranetworking), and IP transcends  
that to concatenate intra-networks to form the Internet. That is of  
course simplistic in the sense that ip-in-ip is used in various ways,  
so IP can also be an intranet of sorts. But it at least gives the  
bits rational descriptions.

The layer you're looking for is a sublayer of the network layer.

---

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]

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: "Templin, Fred L" <[email-masked]>
Date: Fri, 23 Mar 2007 19:20:12 -0700

Fred, 
 
> sub-layered into an intranet layer and an internet layer.

You have said a word here that I know well from other contexts
(as I think you know) but did not know we could speak of openly.
In fact, I probably would have suggested these terms if I thought
I could. So, are we both in trouble now?

Thanks - Fred

---

From: Fred Baker <[email-masked]>
Date: Sat, 24 Mar 2007 03:36:03 +0100

"intranet" or "sublayer"? Certainly not "internet", which is  
explicitly used in exactly this way in RFC 791

   The internet protocol is specifically limited in scope to provide the
   functions necessary to deliver a package of bits (an internet
   datagram) from a source to a destination over an interconnected  
system
   of networks...

   This protocol is called on by host-to-host protocols in an internet
   environment.  This protocol calls on local network protocols to carry
   the internet datagram to the next gateway or destination host.

For the record, I have used this concept and called it that since I  
worked at CDC in 1978-1983. That was how we drew our pictures of the  
network we were building. I have always thought we in fact had it  
right and wondered why everyone else seemed to have it wrong. I'll  
also refer you to http://www.eecis.udel.edu/~amer/PEL/estelle/pdf/ 
cpwsce.concordia.2001.pdf (which google just found for me); search  
for the word "intranet".

I don't know whose confidence you're concerned about me betraying,  
honest. This is the architectural model and terminology I have used  
for nearly 30 years.

On Mar 24, 2007, at 3:20 AM, Templin, Fred L wrote:

> Fred,
>
>> from my perspective, it is more useful to consider the network  
>> layer sub-layered into an intranet layer and an internet layer.
>
> You have said a word here that I know well from other contexts (as  
> I think you know) but did not know we could speak of openly. In  
> fact, I probably would have suggested these terms if I thought I  
> could. So, are we both in trouble now?
>
> Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Sat, 24 Mar 2007 08:06:02 -0700

Fred,

OK, I did a search for the term and came up with many millions
of hits so I see your point. But, I'm still not sure this quite
captures it because there could be many things going on beneath
the Internet layer yet above L2. Take for example multiple levels
of IP-in-IP encapsulation, link-specific adaptation (per Daniel's
message), link-specific ARP cache manipulations, etc.

So, what I'm looking for is a single term to refer to everything
that occurs below the IP layer down to and including L2. (The
reason I say "including L2" is that these fuzzy mid-layers may
be NULL in some instances.)

Does "sub-IP layer" work for you?

Thanks - Fred

> From: Fred Baker [mailto:[email-masked]] 
> Sent: Friday, March 23, 2007 7:36 PM
> To: Templin, Fred L
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Int-area] the layer below IP
>

---

From: Fred Baker <[email-masked]>
Date: Sat, 24 Mar 2007 17:43:28 +0100

sub-IP is in fact what the IETF, which has little understanding of  
things below the internet layer, calls it. If we take the caveat that  
the extreme generality of the term is a demonstration of our lack of  
competence in the area, it's probably fine.

personally, I see a huge difference between the thing that interprets  
ones and zeroes coming off a medium into messages that can be  
understood (L2) and anything that uses concatenated L2 links to  
communicate among a selection of potentially non-neighboring systems  
(L3). Since I am actually able to distinguish them, I personally  
prefer to do so.

---

From: "Templin, Fred L" <[email-masked]>
Date: Sat, 24 Mar 2007 12:45:39 -0700

> competence in the area, it's probably fine.

Well said.

> (L3). Since I am actually able to distinguish them, I personally  

That too.

Thanks - Fred

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 26 Mar 2007 10:47:42 +0200

Since we are at it, what would the term be for that thing above IP that
makes QoS/policy/network-dynamics/-based decisions of which routing
topology to use when multiple ones are available? 

Would that be a "super-IP" layer then? 

>From the MANEMO angle, one can figure that the infrastructure is a form
of backbone area for the fringe - defined as whatever ad hoc mobile
networking takes place outside the edge of the managed Internet and with
the Internet footprint of a host; a Mobile Router can carve out a number
of Nested NEMO topologies to establish MONAMI6 overlay routes via that
backbone (see attached picture). 

Those topologies which establish the 'virtual links' to the 'backbone
area' can be used to provide a basic routing inside the nested NEMO as
well. Add to the picture a MANET-protocol based routing topology and the
"super-IP" layer has quite a lot to do, one of them being to control the
size of the MANET 'lobes', or should I say 'lollipops' since they might
hang out at the end of a 'virtual link'.

To be honest I do not like "super-IP" too much. Maybe I read too many
cartoons and now I'm afraid of confusion with planes and birds and
everything that flies above...

Pascal

>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Templin, Fred L
>Sent: Saturday, March 24, 2007 8:46 PM
>To: Fred Baker (fred)
>Cc: [email-masked]; [email-masked]; [email-masked]
>Subject: Re: [Manemo] [Int-area] the layer below IP
>
>Manemo mailing list
>[email-masked]
>http://www.mobileip.jp/mailman/listinfo/manemo

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Mar 2007 18:53:44 +0200

Roberto Baldessari wrote:
> Hi Fred,
> 
> Thanks for writing this down.
> 
> As I said privately, I agree. "sub-IP" is definitely more general and
> less confusing than 2.5.

I'm sometimes comfortable calling that a MAC layer instead of sub-IP.

Exceptions are some links which don't have MAC layers.

Alex

> 
> regards,
> 
> Roberto
> 
>> -----Original Message----- From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Templin, Fred L 
>> Sent: Thursday, March 22, 2007 10:24 PM To: [email-masked] Cc:
>> [email-masked] Subject: [Manemo] the layer below IP
>> 
>> meeting this week that really should more appropriately have been
>> vetted with the rest of the community instead - so, here I am.
>> 
>> IP but above the datalink. Some have called this "L2.5", but I find
>> that term to be misleading because it seems to imply that there is
>> one and only one functional layer between L3 and L2 and that does
>> not accurately capture all scenarios.
>> 
>> mechanisms that might occur immediatley below IP so can we just
>> collectively call them:
>> 
>> The "sub-IP layer"
>> 
>> Thanks - Fred [email-masked]
>> 
>> _______________________________________________ Manemo mailing list
>>  [email-masked] http://www.mobileip.jp/mailman/listinfo/manemo
>> 
> 
> _______________________________________________ Manemo mailing list 
> [email-masked] http://www.mobileip.jp/mailman/listinfo/manemo
> 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Dave Thaler <[email-masked]>
Date: Mon, 26 Mar 2007 10:10:33 -0700

>From my experience, the term "L2.5" (and "MAC layer", although MAC tends
to be a more media-specific term, and sometimes "Framing layer") is
generally used to refer to behavior that is specific to a given
_combination_ of a L2 media type and an L3 protocol.  

L2 would generally be behavior that is independent of whether the L3
protocol is IPv4, IPv6, IPX, LLDP, or whatever else.

I think this distinction is important.

-Dave

> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Monday, March 26, 2007 9:54 AM
> To: Roberto Baldessari
> Cc: Templin, Fred L; [email-masked]
> Subject: [Int-area] Re: [Manemo] the layer below IP
>