Subject: [RAM] Destination Locator selection

From: RJ Atkinson <[email-masked]>
Date: Tue, 2 Jan 2007 17:09:05 -0500

People seem to view the alternatives as either:
	origin host selects which destination Locator to put in packet
XOR
	some router selects which destination Locator to put in packet

I respectfully submit that this is a false choice and that
this misconception is hindering the discussions here.

	Another, IMHO preferable, approach is to have the origin host
put both source Locator and destination Locator into the packet,
but do not make it illegal/impossible for some router along the
path to re-write/modify either Locator iff that router really has
enough knowledge to do so in some thoughtful way.  Not all routers
in the world might have enough knowledge to do so.  Not all routers
in the world might choose to do so.  By having the origin host put
in a valid destination Locator, but avoiding precluding routers along
the path from applying better information, we can have the best of
both worlds, IMHO.

	To some extent, any NAT-compatible approach will at least
not preclude routers on the path from updating the destination Locator.

Yours,

Ran

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

---

From: Tony Li <[email-masked]>
Date: Tue, 2 Jan 2007 14:16:45 -0800

> the path from applying better information, we can have the best of

Works for me.

Tony

---

From: Bruce Curtis <[email-masked]>
Date: Tue, 2 Jan 2007 17:17:05 -0600

> this misconception is hindering the discussions here.

   One more option for discussion might be for the origin host to put  
multiple destination locators in the packet.

   After all, it already likely has that information after a DNS  
lookup etc.

   And multiple destination locators in the packet might make it  
easier for routers to do what you mention below?

> not preclude routers on the path from updating the destination  

---
Bruce Curtis                         [email-masked]
Certified NetAnalyst II                701-231-8527
North Dakota State University

---

From: Roland Dobbins <[email-masked]>
Date: Tue, 2 Jan 2007 15:23:04 -0800

>   After all, it already likely has that information after a DNS  

A surprising amount of IP-based communication takes place without DNS  
lookups at all.

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

		All battles are perpetual.

     		   -- Milton Friedman

---

From: Bruce Curtis <[email-masked]>
Date: Tue, 2 Jan 2007 17:37:37 -0600

On Jan 2, 2007, at 5:23 PM, Roland Dobbins wrote:

> A surprising amount of IP-based communication takes place without  
> DNS lookups at all.

   But for the amount that does happen based on DNS the end host is  
more likely to already have the required information than a middle box.

   I think the most interesting case is the other side of the  
connection, the host receiving the connection request won't know the  
multiple locators of the originating host unless it does a reverse  
DNS lookup and then a forward (or something similar which it likely  
doesn't do today) or the information about the originating host's  
multiple locators is also in the packet.

---

---

From: Roland Dobbins <[email-masked]>
Date: Tue, 2 Jan 2007 15:46:47 -0800

On Jan 2, 2007, at 3:37 PM, Bruce Curtis wrote:

> connection, the host receiving the connection request won't know  
> the multiple locators of the originating host unless it does a  
> reverse DNS lookup and then a forward (or something similar which  
> it likely doesn't do today) or the information about the  
> originating host's multiple locators is also in the packet.

This is a very astute observation; I don't believe we can count on  
DNS being available for a number of reasons (hosts without DNS  
mappings, broken/incomplete PTR records, DoS attacks, whatever).  I  
also don't think we can seriously consider imposing such an  
additional query-burden on the global DNS infrastructure without  
serious consideration of and discussion of the consequences thereof.

     		   -- Milton Friedman

---

From: Roland Dobbins <[email-masked]>
Date: Tue, 2 Jan 2007 15:50:43 -0800

On Jan 2, 2007, at 3:46 PM, Roland Dobbins wrote:

> I also don't think we can seriously consider imposing such an  

And per my reply to Max, I believe very strongly that IP networks,  
including multihomed ones, must be able to function in the absence of  
any naming system at all.

     		   -- Milton Friedman

---

From: David Conrad <[email-masked]>
Date: Tue, 2 Jan 2007 16:29:50 -0800

> including multihomed ones, must be able to function in the absence  
> of any naming system at all.

Why?

Thanks,
-drc

---

From: Roland Dobbins <[email-masked]>
Date: Tue, 2 Jan 2007 16:38:19 -0800

> Why?

Because we simply cannot arrogate it upon ourselves to introduce such  
a dependency.  People want and/or need the ability to run IP networks  
in environments in which no DNS is present (or perhaps some other  
naming system is in use), and we simply cannot take that choice away  
from them (or force them to use DNS in lieu of whatever else they're  
using).  And in terms of the public Internet, we simply cannot  
arbitrarily impose such a burden on the DNS infrastructure, which in  
many cases is both brittle and underprovisioned.

     		   -- Milton Friedman

---

From: David Conrad <[email-masked]>
Date: Tue, 2 Jan 2007 17:07:31 -0800

Roland,

On Jan 2, 2007, at 4:38 PM, Roland Dobbins wrote:
>> Why?
> Because we simply cannot arrogate it upon ourselves to introduce  
> such a dependency.

The dependency already exists.  If you don't believe me and you are a  
service provider, turn off your caching servers and block port 53 and  
see what happens.

> People want and/or need the ability to run IP networks in  
> environments in which no DNS is present (or perhaps some other  
> naming system is in use), and we simply cannot take that choice  
> away from them (or force them to use DNS in lieu of whatever else  
> they're using).

Can you name one that isn't within a closed network?

> And in terms of the public Internet, we simply cannot arbitrarily  
> impose such a burden on the DNS infrastructure, which in many cases  
> is both brittle and underprovisioned.

I personally believe the most likely solution that addresses the  
largest number of requirements with the lowest cost will require some  
sort of mapping between an end point identifier and a routing  
locator. There are a variety of ways to do this mapping, while the  
DNS is not ideal, it does have the advantage that it works (after a  
fashion).

I think it would be a mistake to take a large number of possible  
solutions off the table simply because we don't want to impose a  
dependency that is, in reality, already existent and satisfied.

The fact that some branches of the DNS are brittle and  
underprovisioned is not really a good argument: this problem would  
like remedy itself when people became aware of the need to have a non- 
brittle and well provisioned DNS so they could download their porn.

Rgds,
-drc

---

From: Roland Dobbins <[email-masked]>
Date: Tue, 2 Jan 2007 17:25:35 -0800

On Jan 2, 2007, at 5:07 PM, David Conrad wrote:

> The dependency already exists.  If you don't believe me and you are  
> a service provider, turn off your caching servers and block port 53  
> and see what happens.

There are a number of things which don't have this dependency,  
especially not on a 'per-transaction' basis.

> Can you name one that isn't within a closed network?

What does that matter?  The multihoming solution we come up with  
ought to work just as well on closed networks (or networks using  
alternate naming systems) as on the global Internet.

I don't think it's in anyone's best interests to tie IP networking to  
any particular naming system, for all the reasons already listed, for  
reasons of futureproofing, etc.  I believe it is in fact a Very Bad  
Idea.

> largest number of requirements with the lowest cost will require  
> some sort of mapping between an end point identifier and a routing  

Ah, but it doesn't work as quickly and reliably and dependably and  
universally as is needed for a system of the type you describe to  
count on it.  What we do here must be entirely self-contained, IMHO.

> dependency that is, in reality, already existent and satisfied.

I think taking impractical and unworkable solutions off the table is  
a great idea, because it means we don't waste any further time on  
them.  Making DNS a dependency in this instance is a layering  
violation of the first water (remember, the current paradigm for IP  
networking is a very loosely-coupled system), it is a classic  
exercise in cost-shifting, and it is just plain lazy, IMHO.

[ This is a matter of personal technical philosophy, but besides the  
architectural and operational reasons why this is a Very Bad Idea, it  
really seems wrong to try and foist our problems off on the naming- 
system people.  This is our mess; we ought to clean it up ourselves,  
IMHO. ]

> like remedy itself when people became aware of the need to have a  
> non-brittle and well provisioned DNS so they could download their  
> porn.

While I agree with your sentiment, I believe the outcome of  
introducing such a dependency would be rather different - I believe  
that when it started non-deterministically breaking because of DNS  
issues, deployment would halt and we would all be strung up from the  
nearest lampposts (and justifiably so, heh).

     		   -- Milton Friedman

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 3 Jan 2007 02:55:04 +0100

> the path from applying better information, we can have the best of

just a subtle point here....
from the way you put it, it seems to me that you would require that all 
the hosts must support whatever new thing/protocol that is necesary to 
allow this rewriting

I would argue that this would make deployment more difficult

I would then suggest that both the host or the host can do the locator 
selection and all the rest of the functions required to support this 
(allowing both routers and hosts to support the needed functions) and 
also that a host that is selecting the locators can communicate with a 
peer that is being served by a router that performs the locator 
selection and associated required features.

Hope this is minimally clear...

Regards, marcelo

---

From: Peter Sherbin <[email-masked]>
Date: Tue, 2 Jan 2007 18:13:18 -0800 (PST)

Because DNS has a very limited use where humans are involved, while the vast
majority of communicating machines need only IP numbers.

Thanks,
Peter

> > of any naming system at all.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: David Conrad <[email-masked]>
Date: Tue, 2 Jan 2007 18:22:08 -0800

Roland,

On Jan 2, 2007, at 5:25 PM, Roland Dobbins wrote:
>> DNS is not ideal, it does have the advantage that it works (after  
>> a fashion).
> count on it.

Quickly, reliably, dependably: sure it can, assuming you can tolerate  
an increased latency with the first packet of a "unidirectional  
flow".  As for universality, not every computer on the Internet  
speaks BGP, yet the Internet seems to work.

One way of solving the routing scalability problem is to create a  
layer of indirection, having routing done in one "identity universe"  
and end point identification done in another "identity universe" with  
a mapping mechanism that allows a "border device" (where 'border" can  
be anything from the site edge to the host edge and anywhere in  
between) to take the end point identifier and do a lookup to find the  
one or more routing locators currently serving as the network  
attachment point(s) for the end point identifier.  This layer of  
indirection gives you the ability to change "location" (that is,  
where the end point is attached to the network) transparently to the  
end point, permitting renumbering, mobility, and multi-homing.  The  
downside, as with all added layers of indirection, is added latency  
-- you need to do the lookup in some mapping table.  If the mapping  
table is propagated via some push mechanism (e.g., BGP attributes),  
the additional latency will be minimal albeit updates to the mapping  
table would need to be constrained.  If the mapping table is  
propagated via some pull mechanism (e.g., something like the DNS),  
the additional latency (on the initial packet, assuming you have a  
reasonable caching scheme) will be significant, but table updates are  
less of an issue.

Generalizing a bit, one could imagine layering IP headers with the  
lowest layer corresponding to end point identification and subsequent  
higher layers corresponding to traffic engineering dictated network  
topology location.  At each network attachment 'edge' the packet  
traverses, a new layer could be added to determine where the packet  
should go, e.g. (looking at a packet in the middle of a transit AS):

[src: A'', dst: B''=lookup(ISP_TE_MAP,B')]
[src: A', dst: B'=lookup(GLOBAL_MAP,B)]
[src: A, dst: B]
[payload]

where:

A is the source endpoint identifier
B is the destination endpoint identifier
A' is the globally unique locator by which you reach A
B' is the globally unique locator by which you reach B
A'' is the ISP-specific locator used to direct traffic to the  
appropriate destination to reach A' within the ISP's network
B''  is the ISP-specific locator used to direct traffic to the  
appropriate destination to reach B' within the ISP's network

This sort of scheme gives you the ability to do arbitrary traffic  
engineering, have multi-homing, renumbering (in the sense of changing  
your location in the network topology), and mobility (if the tables  
can be updated fast enough and/or you have some sort of forwarding  
mechanism), but obviously it needs a mapping mechanism.

> What we do here must be entirely self-contained, IMHO.

I remain highly skeptical we'll be able to deploy IPv7 before either  
we start prefix length filtering off significant portions of the  
Internet or NAT becomes the accepted solution to the routing  
scalability problem.  I believe an approach that leverages as much of  
the existing _deployed_ infrastructure with as few changes as  
possible is the most likely to end up actually being used.  But maybe  
I'm too pessimistic (or cynical).

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Tue, 2 Jan 2007 18:34:43 -0800

> majority of communicating machines need only IP numbers.

The DNS provides a way of mapping one string of bytes into another  
string of bytes.

While it is true that in the past the vast majority of these mappings  
were for mapping a human-intended name into an IPv4 address, I  
suspect the future will be a bit different (e.g., see the use of  
NAPTR and SRV RRs).

To be clear, I'm quite well aware of the limitations and warts the  
DNS has as well as those in mapping-based schemes in general and  
would be happy to see an alternative.  I'm just not too sure a  
reasonable alternative can be deployed in a reasonable timeframe.

Rgds,
-drc

---

From: Roland Dobbins <[email-masked]>
Date: Tue, 2 Jan 2007 19:13:19 -0800

> reasonable alternative can be deployed in a reasonable timeframe.

The DNS is eminently unsuitable for what you're proposing, because it  
wasn't designed with this sort of requirement in mind, hasn't been  
deployed with this kind of requirement in mind, and cannot be  
expected to fulfill this kind of requirement without such wide- 
reaching and fundamental changes that it would no longer be DNS, but  
Something Else.

Now, there's an argument which can be made that we need Something  
Else; I think that's perhaps a worthwhile discussion to have.   
Something decentralized, along the lines of PNRP or somesuch.  The  
question is, do we want to strap that on as part of this effort, or  
is that too far out-of-scope to even seriously discuss?

     		   -- Milton Friedman

---

From: Peter Sherbin <[email-masked]>
Date: Tue, 2 Jan 2007 19:37:41 -0800 (PST)

> would be happy to see an alternative.

IMO there are very few instances (about two) where human use of words as pointers on
the Internet is appropriate:
1. in e-mail address (for now)
2. in search engines (the route-cause driver behind the net)

E.g. a user does not even need URL. Search engine points to a site, which I can
select and store under a name I assign to it in the browser Favorites. All human
requirements can and should be resolved at application layer with no need to rely on
human language pointers for any routing task.

I.e. DNS is not a concern of the Internet architecture.

Thanks,

Peter

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 2 Jan 2007 23:12:56 -0500

> -----Original Message-----
> From: Tony Li [mailto:[email-masked]] 
> Sent: Tuesday, January 02, 2007 5:17 PM
> To: RJ Atkinson
> Cc: [email-masked]
> Subject: Re: [RAM] Destination Locator selection
> 
> 
> > 	Another, IMHO preferable, approach is to have the 
> origin host put 
> > both source Locator and destination Locator into the packet, but do 
> > not make it illegal/impossible for some router along the path to 
> > re-write/modify either Locator iff that router really has enough 
> > knowledge to do so in some thoughtful way.  Not all routers in the 
> > world might have enough knowledge to do so.  Not all routers in the 
> > world might choose to do so.  By having the origin host put 
> in a valid 
> > destination Locator, but avoiding precluding routers along the path 
> > from applying better information, we can have the best of 
> both worlds, 
> > IMHO.
> 
> 
> Works for me.

Me to with the caveat that if the dst locator is part of any security
index might not be able to rewrite that but that I think is covered
under "the router" has enough knowledge for current architecture state.

/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 2 Jan 2007 23:17:16 -0500

> From: Roland Dobbins [mailto:[email-masked]] 
> Sent: Tuesday, January 02, 2007 6:51 PM
> To: [email-masked]
> And per my reply to Max, I believe very strongly that IP 
> networks, including multihomed ones, must be able to function 
> in the absence of any naming system at all.

Putting the architecture discussion hat on only I would not entirely
agree given how we have been using the term 'namespace', but I do see
the concern and point.  To find compromise I would suggest we do need to
be concerned about the principle of "discovery" within the new
architecture model. 

Best,
/jim

---

From: Roland Dobbins <[email-masked]>
Date: Tue, 2 Jan 2007 20:20:56 -0800

> be concerned about the principle of "discovery" within the new

Thanks for the clarification; in this particular case it was a  
semantic issue, but one to which attention must be paid, lest  
(further) confusion ensue.

     		   -- Milton Friedman

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 2 Jan 2007 23:42:53 -0500

Just for thinking there is a set of principles used by U.S. DOD and NATO
and others called net centricity.  My reference to this work is the
computer science term and not applied with terms like net centric
warfare or net centric ops, but rather a set of pre-conditions to
achieve net centricity from models to implementations.  But it is
beginning to permeate out of the classic military environment and the
core principles I extrapolate and test I use for any architecture and
for implementation are does the networking result provide: connectivity,
interoperability, security, discovery, QoS, and end-to-end (meaning two
peers can communicate without middle boxes and packets could be
encrypted so only the current IP header is in the clear).  The point of
discovery is quite important as that is how the network learns of
parameters and information required.  And does need some thought while
developing an architecture. If any of these pre-conditions are missing
above (and some add others as a note) net centricity can be negatively
impacted, including discovery.  What the answer is for our work here for
discovery is entirely premature to discuss (e.g. DNS, LDAP, UDDI,
LDAP+UDDI, SLP, SOAP, etc).

Ref John Garstka : http://en.wikipedia.org/wiki/John_J._Garstka

Best,
/jim

> Sent: Tuesday, January 02, 2007 11:21 PM
> To: [email-masked]
> > the concern and point.  To find compromise I would suggest 
> we do need 
> > to be concerned about the principle of "discovery" within the new 
> > architecture model.
> 
> Thanks for the clarification; in this particular case it was 
> a semantic issue, but one to which attention must be paid, lest

---

From: Andrew McGregor <[email-masked]>
Date: Wed, 3 Jan 2007 17:50:32 +1300

While working on HIP we concluded that this all has to be explicitly  
signalled; putting it in the DNS is OK for seeding things, but all  
locators are subject to change, and the endpoint is the only place in  
the network that can be expected to have reasonably reliable  
information as to what locators work right now, let alone what are  
permitted within its knowledge of policy.

Note that policy imposed by firewalls and the like simply shows up as  
the end-host noticing that certain candidate locators don't work or  
have reduced performance.

Andrew

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 3 Jan 2007 08:10:28 +0200

> this misconception is hindering the discussions here.

I concur.

> the path from applying better information, we can have the best of

Architecturally, I agree.  But I'd also like to see the possibility  
of the origin host delegating *) the initial job to a box in the  
network.  That is, iff there is such a box in the local network, the  
end hosts would be permitted to emit packets with identifiers in the  
packet.

Anyway, the tricky things here are security and trust.  At minimum,  
we need some way to know that we continue to talk to the same host,  
even if the locators change.  Otherwise there is the possibility of a  
malicious party claiming that a host is "better" reachable through  
another locator, leading to a DoS or traffic hijacking.

In an architecturally host-centric solution (akin HIP/SHIM6), we can  
apparently rely on the hosts to present themselves as integral  
entities, i.e., asserting that a given set of locators belong to them  
**).  In an architecturally network-centric solution (akin Noel's  
"jack up"), apparently we have to somehow be able to trust the  
network, as the host has no idea of which locators it has...  (I  
smell a canned tin of worms here.)

In a host-centric architecture, the basic choices seem to be between  
return routability and something stronger.  In other words, return  
routability seems like the minimum baseline.  Personally, I'd like to  
see the possibility of using something stronger, such as hash chains  
or public keys.  If not as a mandatory-to-use feature, then at least  
as a mandatory-to-implement and optional-to-use feature.

*) Note that I really think that the right approach is for the host  
to _delegate_ the job to the network.  IMHO, a solution where the  
function is primarily performed by the network and a host can  
implement it only by "becoming" a part of the network seems to have  
more potential security problems.

**) It is not as simple as a host asserting that it has a set of  
locators, I know.  The host can lie.  But those details are well  
known and worked out at least for HIP and SHIM6, probably for a few  
other solutions, too.

--Pekka Nikander

---

From: Per Heldal <[email-masked]>
Date: Wed, 03 Jan 2007 12:24:16 +0100

> count on it.  What we do here must be entirely self-contained, IMHO.

Self-contained, to which extent?

Do you also disqualify the distributed lookup/cache that is performed in
common RIB/FIB constructs in routers today?  What if such lookups were
implemented (but invisible) and working using one of your disqualified
technologies?

What if two chassis are interconnected with a bus-extender sharing one
routing table? Is that an accepted form of resource distribution?

If the bus-extender is replaced with IP over 10GE, does that change
anything? 

My point is that I believe it is a mistake to think in terms of physical
boxes when high-level architectural principles are discussed.  Practical
constraints such as bandwidth-requirements, response-time, latency
(limited by the speed of light) etc still apply though.

//per

---

From: "Elmar K. Bins" <[email-masked]>
Date: Wed, 3 Jan 2007 12:30:55 +0100

> Self-contained, to which extent?

Having the lookup depend on the same mechanism (meaning: having DNS
requests routed over the Internet) it is a solution to is not a good
idea.

Elmar.

---

From: Per Heldal <[email-masked]>
Date: Wed, 03 Jan 2007 12:48:35 +0100

> requests routed over the Internet) it is a solution to is not a good

Did anybody suggest to remove local DNS-cache and local/internal DNS or
other local name-mapping mechanisms? The point was that not everything
has to be done within one box. Putting your DNS somewhere on the
opposite side of the globe is a whole different story.

//per

---

From: Per Heldal <[email-masked]>
Date: Wed, 03 Jan 2007 13:38:06 +0100

> opposite side of the globe is a whole different story.

Btw, why this sudden obsession with DNS? Suggested MH-solutions with
multiple addresses per host only rely on DNS for seeding. I.e. one
reachable (possible limitation) locator for the destination host must be
in DNS in order to establish a connection. Further exchange of locators
happen directly between the endpoints. Besides, there's nothing that
prevents the use of locally cached or even static information in the
absence of working global DNS. 

//per

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 3 Jan 2007 08:14:09 -0500

On  2 Jan 2007, at 20:55, marcelo bagnulo braun wrote:
> from the way you put it, it seems to me that you would require that  
> all the hosts must support whatever new thing/protocol that is  
> necesary to allow this rewriting

It is not obvious to me that your assertion is necessarily true.

> I would argue that this would make deployment more difficult

Given that no specific mechanism has been proposed,
that argument isn't very credible right now.

> I would then suggest that both the host or the host can do the  
> locator selection and all the rest of the functions required to  
> support this (allowing both routers and hosts to support the needed  
> functions) and also that a host that is selecting the locators can  
> communicate with a peer that is being served by a router that  
> performs the locator selection and associated required features.

That is not identical to the abstract concept I've suggested,
not least because it has more implementation detail than anything
I've been talking about.

Ran

---

From: "Elmar K. Bins" <[email-masked]>
Date: Wed, 3 Jan 2007 14:34:27 +0100

> opposite side of the globe is a whole different story.

I'm not sure whether or not one should decide here what one wants:

- a local lookup  (hence a local database, whatever it may be)
- a global lookup (like DNS would provide)
- something else?

The word "DNS" is loaded, and if it's being used in a discussion, it brings
a lot of implications with it.

Yours,
	Elmar.

---

From: Roland Dobbins <[email-masked]>
Date: Wed, 3 Jan 2007 05:53:29 -0800

> (limited by the speed of light) etc still apply though.

Self-contained with respect to not relying on layer-7.

I agree with your sentiment expressed here.

     		   -- Milton Friedman

---

From: Per Heldal <[email-masked]>
Date: Wed, 03 Jan 2007 14:54:56 +0100

> a lot of implications with it.

As written elsewhere in the thread: why this sudden obsession with DNS?

This thread was about the selection between multiple locators, which to
me seem to have much more in common with current router's selection of
outbound interface than name-mapping. Site-wide coordination and
policy-control (TE requirements) would require some form of
query-response service to advice/force the selection-process on
individual hosts. Implementation-details like choice of protocol for
such have not yet been discussed.

//per

---

From: Roland Dobbins <[email-masked]>
Date: Wed, 3 Jan 2007 05:56:04 -0800

> Self-contained with respect to not relying on layer-7.

Make that, 'layer-7 things which have nothing to do with routing'.

;>

     		   -- Milton Friedman

---

From: [email-masked]
Date: Wed, 3 Jan 2007 14:06:14 +0000

> As written elsewhere in the thread: why this sudden obsession with DNS?

	don't really know.  DNS, as Mr Conrad points out, sort of works.
	In this context it does have a few warts:

	1) where do you find the DNS servers if you don't have a route?
	2) is there any value to using the same namespace, if so, where would
	   you anchor it?  (e.g.  ip6.arpa, e164.arpa, rdi.int?)
	3) given the (generally) limited number of possible forwarding paths,
	   it would seem that a localized view might be preferable...  (as you
	   mentioned)

	YMMV of course

--bill

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 3 Jan 2007 09:49:17 -0500

Folks,

Ran, Noel, Tony L., John L,  Dobbins R, and others are trying to give us
abstractions for Model and Architecture yet folks keep going down to
details and trying to pin a solution to the abstractions (e.g. DNS,
SHIM6, HIP).  We need to get beyond that to get an architecture done
here.  It is good to provide architectural tenets from ongoing IETF work
(for example I think NSIS architecture helps us with distributing
computing of knowledge for discovery requirements), but discussing
implementation details or ones favorite solution is simply going to slow
us down to move forward with archetype and abstractions to get forward
progress.

My .46 cents,
/jim

> From: RJ Atkinson [mailto:[email-masked]] 
> Sent: Wednesday, January 03, 2007 8:14 AM
> To: [email-masked]
> Given that no specific mechanism has been proposed, that 
> argument isn't very credible right now.
> 
> > (allowing both routers and hosts to support the needed
> > communicate with a peer that is being served by a router 
> that performs 
> > the locator selection and associated required features.
> 
> not least because it has more implementation detail than 
> anything I've been talking about.
> 
> Ran
> 
>

---

From: "Elmar K. Bins" <[email-masked]>
Date: Wed, 3 Jan 2007 17:46:00 +0100

[email-masked] (Per Heldal) wrote:

> Implementation-details like choice of protocol for

Then I need to ask back: Why write "DNS" in the first place?

---

From: "Elmar K. Bins" <[email-masked]>
Date: Wed, 3 Jan 2007 17:52:21 +0100

> Then I need to ask back: Why write "DNS" in the first place?

Alright, scrap that. Let's get back to architecture :)

Elmar.

---

From: Bruce Curtis <[email-masked]>
Date: Wed, 3 Jan 2007 13:19:17 -0600

On Jan 2, 2007, at 8:22 PM, David Conrad wrote:

> lowest layer corresponding to end point identification and  
> subsequent higher layers corresponding to traffic engineering  
> dictated network topology location.  At each network attachment  
> 'edge' the packet traverses, a new layer could be added to  
> determine where the packet should go, e.g. (looking at a packet in  
> the middle of a transit AS):
>
> engineering, have multi-homing, renumbering (in the sense of  
> changing your location in the network topology), and mobility (if  
> the tables can be updated fast enough and/or you have some sort of  
> forwarding mechanism), but obviously it needs a mapping mechanism.

   Do you envision the lookup and mapping happening at only the first  
ISP in the path between endpoints or potentially at every interface  
between multiple ISPs in the path?

---

---

From: [email-masked]
Date: Thu, 4 Jan 2007 10:27:41 +0100

You may be interested in reading my proposal on "Tunneled Intedomain
Routing" (TIDR), in which I proposed a way to map identifiers to
interdomain locators by means of a new transitive BGP attribute that
I've called LOCATOR:

http://www1.ietf.org/mail-archive/web/i-d-announce/current/msg13203.html

The mapping can happen in the first ISP and also in the core, using
a hierarchy of locators.

Regards,
Juanjo

---

From: Russ White <[email-masked]>
Date: Thu, 04 Jan 2007 08:23:52 -0500

> The mapping can happen in the first ISP and also in the core, using

I have a fundamental issue with overloading identifiers with
locators.... While I know that's what we are doing today, it's really
what started this whole problem, and I don't see where going farther
down this road really solves anything.

IMHO, TIDR will increase capex and opex problems, not solve them.

I'll put it another way: To scale, you must hide information. This is a
fundamental rule of all large complex systems. There are two ways to
hide information:

o Horizontal hierarchy, where you remove information at edges within the
system, topologically, if we think of routing. For instance, in your
car, your brake system is, pretty much, completely independent of your
engine. Increasing complexity in the braking system increases the system
complexity, but doesn't increase the complexity of the engine, generally
speaking. This is the theory behind OSPF areas, for instance.

o Vertical hierarchy, where you remove information at layer edges in the
system. For instance, the IGP/EGP split is vertical hierarchy.

Both of these have their problems, advantages, and disadvantages.
Underusing either one can cause a total lack of scaling. Overusing
either one can make the network completely unrepairable when it fails.
We can shove the problem onto "tools" all we want to, but we need to be
really careful before we shove too hard in that direction. Tools are
most useful when humans can understand what the tool does, are simple,
low cost, etc. Tools are not a panacea.

IMHO, TIDR is an extreme case of vertical hierarchy, just as many other
network virtualization schemes are. They look good on the map, as long
as you think you're far enough away from the little sign that says:
"Here be dragons." The question is, always, how far away is far enough away?

:-)

Russ

- --
[email-masked] CCIE <>< Grace Alone

---

From: David Meyer <[email-masked]>
Date: Thu, 4 Jan 2007 08:19:23 -0800

> >the path from applying better information, we can have the best of

	Understand the idea, but it seems possible that if you
	start telling a host its locator (without any kind of
	indirection), you are well on your way toward loosing the
	ability to do topological aggregation [0].

	--dmm

[0]	You lose that ability as no one will ever renumber
	(cf. today's Internet).   
_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Tony Li <[email-masked]>
Date: Thu, 4 Jan 2007 09:48:02 -0800

> [0]	You lose that ability as no one will ever renumber

Dave,

If the locator is automagically and dynamically discovered by the  
host, do you feel that it's still an issue?
For static configuration, I would agree.

Tony

---

From: David Meyer <[email-masked]>
Date: Thu, 4 Jan 2007 09:58:03 -0800

Tony,

> For static configuration, I would agree.

	I too was considering the latter case. If there is a
	dynamic (secure, etc) mechanism, then perhaps we'd be ok
	(in this regard). My argument was more along the lines of
	the "what about routers, NATs, firewalls, appliances of
	type <X> that hold locator state, etc. arguments that
	we've seen over the years.  

	--dmm

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 4 Jan 2007 19:04:26 +0100

> that argument isn't very credible right now.

well, if a solution requires support from hosts and routers then it is 
likely to be more difficult to deploy than a solution that requires 
updating only the routers...

> not least because it has more implementation detail than anything

my question is whether you had in mind that both hosts and routers need 
to be involved in the solution (meaning that new mechanisms/protocols 
are needed to be installed in them) or that only routers are involved 
and require update (only edge routers as David C. suggests)

Regards, marcelo

---

From: [email-masked]
Date: Fri, 5 Jan 2007 11:14:25 +0100

Russ,

See below.

> down this road really solves anything.

IMHO there is a difference:
- What we have today: IP address is overloaded because the
  locator role is statically mapped to the identifier role
  and cannot be changed.  This is why with pure CIDR (i.e.
  using PA blocks) you have to renumber your network when you
  move to another ISP.
- With a mechanism like TIDR we don't overload the identifier.
  We just dynamically add a locator to the identifier. And the
  locator will be provided by your ISP.

> IMHO, TIDR will increase capex and opex problems, not solve them.

I don't know much about this. Can you explain more?. I too wonder
what is the effect of other solutions, like HIP or SHIM6, to capex
and opex.

I think we have mainly two problems to solve: (1) scalability of
the global BGP table, (2) BGP churn.

See below the latest "RIPE RIS Weekly Statistics Report"

<-----BEGIN----->
RIS Statistics Report (20061225-20070101)

This report was generated at Mon Jan  1 00:15:01 UTC 2007.

o Number of single-homed ASes.
         RIS       rrc00       rrc01
ARIN    3916        4908        4123
APNIC    761         878         896
RIPENCC 2786        3398        3558
LACNIC   116         135         141
AFRINIC   17          17          12
IANA       0           0           0
Private   43          24          17
Others     0           0           0
Total   7639        9360        8747

o Number of multi-homed ASes.
         RIS       rrc00       rrc01
ARIN    8300        7281        4684
APNIC   2035        1905        1649
RIPENCC 6268        5607        4709
LACNIC   159         139         110
AFRINIC   13          13          11
IANA       0           0           0
Private   28          25           8
Others     0           0           0
Total  16804       14971       11172

o Distribution of AS number wrt Leaf, Transit.
                 RIS     rrc00       rrc01
Leaf           20397     20454       16395
Transit         3917      3753        3244
Transit-only     135       129         282
Total          24449     24336       19921
<-----END----->

It roughly shows that 5 AS-es out of 6 are leaf AS-es. The important
point to note here is that leaf AS-es don't really participate in
true INTER-domain routing: they are just "guests" that generate a lot
of BGP updates but don't move any transit packet.

> fundamental rule of all large complex systems.
...
> system. For instance, the IGP/EGP split is vertical hierarchy.

TIDR proposes a method to base inter-domain routing on locator
prefixes generated by transit AS-es by moving identifier prefixes
from the RIB to a new table, the TIB. Therefore, rather than
removing information TIDR assigns different roles to identifier
prefixes (tunnel imposition) and locator prefixes (actual routing).

In addition to this, BGP updates for identifier prefixes will be
less important than BGP updates for locator prefixes in terms of
the Internet routing stability. So, this fact would mitigate the
effect of the BGP update churn.

> "Here be dragons." The question is, always, how far away is far enough
away?

I see some flaws with TIDR but I don't see the dragons yet.  :-)
Any clue?.

Regards,
Juanjo

---

From: Roland Dobbins <[email-masked]>
Date: Fri, 5 Jan 2007 02:21:21 -0800

On Jan 5, 2007, at 2:14 AM, [email-masked] wrote:

> I too wonder

This has been discussed at length during the last week, it's in the  
list archives.

		 Technology is legislation.

                     -- Karl Schroeder

---

From: Per Heldal <[email-masked]>
Date: Fri, 05 Jan 2007 11:49:00 +0100

> This has been discussed at length during the last week, it's in the  

Not really. We've seen a number of conclusions ("doesn't scale*, doesn't
work", "unreasonable capex/opex" etc), but very few supporting factual
arguments needed for others to make their own independent evaluation.

At this early stage of research/specification these concerns can just as
easily be interpreted as a set of requirements which have to be met for
new such technologies to succeed ... with automated site-wide
administration of  addresses/prefixes and traffic-engineering being the
2 dominating issues.

//per

---

From: Roland Dobbins <[email-masked]>
Date: Fri, 5 Jan 2007 03:02:42 -0800

On Jan 5, 2007, at 2:49 AM, Per Heldal wrote:

> but very few supporting factual

This is incorrect - very specific reasons were given in terms of  
CAPEX, OPEX and ongoing supportability.  You can of course ignore or  
discount them if you wish, but they're there.

                     -- Karl Schroeder

---

From: Per Heldal <[email-masked]>
Date: Fri, 05 Jan 2007 12:56:14 +0100

> discount them if you wish, but they're there.

I still don't understand how you can make assumptions about expenses and
workload without knowing how the complete toolchain will be implemented.
IPv4 deployment and support without DHCP and basic tools for
troubleshooting like traceroute and ping would be a pain, yet I'm not
comfortable with assumption that there will be no working equivalents
for a shim6-environment.

Anyway, this is now quite OT this list. Further discussion should happen
on the shim6-list where operational concerns are welcome. It's been
suggested to create a prioritised list of such as input to the
development-process.

//per

---

From: Roland Dobbins <[email-masked]>
Date: Fri, 5 Jan 2007 04:27:17 -0800

[removed [email-masked]]

> workload without knowing how the complete toolchain will be  

Double or treble or n^2 the amount of ACL entries, firewall rules,  
QoS matching policies, etc., is still double or treble or n^2 the  
amount of ACL entries, firewall rules, QoS matching policies, etc.   
TCAM space which is not unlimited, RAM which is not unlimited,  
processors which are not unlimited are still TCAM space which is not  
unlimited, RAM which is not unlimited, processors which are not  
unlimited.  The undesirable effects of mandating dynamic host  
selection of the initial path for egress packets are still the  
undesirable effects of mandating dynamic host selection of the  
initial path for egress packets.  The additional support burden for/ 
in addition to all of the above is still the additional support  
burden for/in addition to all of the above.

I'm also sort of confused as to how a subject which has been  
considered on-topic for the past week, with plenty of participants  
with lots of input, is now unilaterally deemed suddenly off-topic.   
Yes, it's somewhat redundant to have to read the same responses to  
the same set of questions we started with a week ago; it's also  
redundant to have to type them over again.

So, since it has already been stipulated by multiple participants in  
this discussion that these issues are in fact germane and must be  
taken into account while working towards an operationally-feasible  
multihoming solution, I would ask that a) we not attempt to undo that  
stipulation, b) folks who're coming late to this set of threads skim  
through the archives to understand the points which were raised, c)  
when folks are directed to the archives, they aren't told that these  
issues haven't been discussed, because they have been discussed, and  
d) we not cross-post between lists, as it's considered poor form.

                   -- Karl Schroeder

---

From: Per Heldal <[email-masked]>
Date: Fri, 05 Jan 2007 14:12:29 +0100

> amount of ACL entries, firewall rules, QoS matching policies, etc.   

Correct, but assuming there will be no shim-aware middleboxes. (which I
forgot to mention in my last msg, and consider a natural development and
part of the complete tool-chain for shim6). Much of today's operational
mess is the result of questionable engineering practises rather than
architectural deficiencies. Quite a few vendors could benefit from some
redesign related to shim-support. 

> unlimited.  

Hardware limitations are real, but it may also be seen as a tradeoff to
be able to curb the ever increasing size of BGP-tables and route-churn.
I.e. a lot like discussing horisontal vs vertical scaling in the
datacenter arena. Historically it has been easier to scale at the edges
of the network than in the core as the core operates closer to the
limits of what is possible with current technology.

>
> The undesirable effects of mandating dynamic host  

Again true, and especially important to bigger sites. Yet, the picture
changes if you introduce some form of "policy director" to coordinate
and possibly centralise path- and locator-selection and thus keep
TE-management firmly in the hands of network ops.

//per

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 05 Jan 2007 14:23:03 +0100

Per,
> TE-management firmly in the hands of network ops.

I completely agree. I don't believe that enterprise networks will leave
the decision of the selection of the sourceaddress (and path) completely
to the end hosts. A better approach is to have a policy director that
suggests decision to the host (either by a query response protocol or
other means) so that all hosts in the enterprise make approriate
decisions. For a description of this approach, see :

C. de Launois, O. Bonaventure, and M. Lobelle. The NAROS approach for
IPv6 multihoming with traffic engineering. In 4th COST 263 International
Workshop on Quality of Future Internet Services (QoFIS 2003), volume
LNCS 2811, pages 112-121, Stockholm, Sweden, October 1-3rd 2003.
Springer-Verlag.

Available from http://totem.info.ucl.ac.be/publications.html

This paper takes load balancing in a campus network as a case study and
shows that a policy director can easily achieve almost perfect load
balancing between its providers without an excessive load on the policy
director. The same approach could be used for other policies.

Best regards,

Olivier

-- 
CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/~obo

---

From: Russ White <[email-masked]>
Date: Fri, 05 Jan 2007 09:12:47 -0500

>   using PA blocks) you have to renumber your network when you

You're looking at it from the routing perspective--from the application
level, IP addresses are already overloaded as both. Overloading at the
routing layer doesn't really help the problem we've hit by overloading
at the application layer.

>   locator will be provided by your ISP.

You're using IP addresses for both, so you're overloading the IP address
space as both locators and identifiers.

> what is the effect of other solutions, like HIP or SHIM6, to capex

There are solutions beyond HIP, SHIM6, and TIDR. We shouldn't be in the
position of saying: "TIDR requires less opex than SHIM6, so we go with
TIDR." We should be in the position of saying: "The amount of acceptable
OPEX is X, if any solution is over X, we look for another solution."

> the global BGP table, (2) BGP churn.

TIDR "solves" both though virtualization.

My point is that while this seems attractive, we must remember that we
already have L3VPNs, which are the same sort of virtualization at a
different level, and we're getting into heavy virtualization within
enterprise networks, as well.

The question is, when you start layering virtualizations on top of one
another, what sort of mess do you create in terms of being able to
manage and troubleshoot the layers? We've already seen that hierarchical
layers of more than four or five deep can make things difficult to
troubleshoot, etc, so we tend to virtualize beyond that.

How many layers of virtualization will we hit before we run into the
same problem? And will massive virtualization also "ossify" the network,
leaving us no "out" for the next problem (not yet even imagined) we hit?

In other words, virtualization isn't a panacea, any more than
topological hierarchy is. Whatever we do needs to mix the two in a
logical way, given current deployment patterns and current designs.

> I see some flaws with TIDR but I don't see the dragons yet.  :-)

You only see the dragons if you start to look at the virtualizations
piled on top of one another. Any given virtualization might make sense,
standing on its own, but building a stack of them becomes problematic.
Think of a game of Jinga, I think it is, where you stack the wood blocks
up, and then try to pull out the bottom ones.

You can pile the blocks to make the base bigger (topological hierarchy),
but, at some point, this becomes impractical. You can also pile the
blocks in very inventive ways to make the stack taller, but, over time,
you ossify the pile, making it harder and harder to change anything
towards the bottom. At the same time, you make the stack more brittle,
more prone to catastrophic failure with a single shift in a block at the
bottom.

Balance is what's required.

:-)

Russ

- --

---

From: Max Tulyev <[email-masked]>
Date: Sun, 07 Jan 2007 00:24:23 +0200

Roland Dobbins пишет:
> reasons of futureproofing, etc.  I believe it is in fact a Very Bad Idea.

Mine proposal is not to tie IP networking to DNS, but it shows a way for 
back-up and traffic engineering FOR SOME SERVICES (not addresses!) 
without getting AS/PI working just now.

Owners of www.[verystablesite].com wish their site to be reachable if at 
least one of their N channels alive, and let customers connect 
imap.[verystablesite].com, and mailers send mail to 
mail.[verystablesite].com, and etc. Load ballancing can be done same way.

This is most common task for multihoming. It can be solved without 
wasting world route table, also cheaper way for a user, without any BGP 
router. And this task depends on DNS system by default.

-- 
WBR,
Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

---

From: JFC Morfin <[email-masked]>
Date: Sun, 07 Jan 2007 18:13:02 +0100

Jim,
Very interesting remark as permits to ask simply the very basic 
question: in your mind should we bound to a single net centricity 
technology and implementation?
Thanks.
jfc

---

From: [email-masked]
Date: Mon, 8 Jan 2007 10:46:37 +0100

Russ,

> space as both locators and identifiers.

Yes, in TIDR we use IP addresses for both BUT not at the same
time. As I have shown in the draft, we could dedicate prefix
240.0.0.0/8 for interdomain locators only. This means that
these IP addresses cannot be used but to encapsulate traffic
that will be tunneled. In other words, from the whole IP
address space a subset of addresses is just used as locators,
and locators only. You cannot telnet for example to an IP address
that is a locator.

This is more clearly seen when you think in IPv4 locators to
transport IPv6 packets: an IPv6 identifier prefix would be
announced with an IPv4 locator in the BGP update.

> troubleshoot, etc, so we tend to virtualize beyond that.

This type of virtualization layering already works in other
scenarios: think on an international parcel service company
(IPS Company). When I order a book to a bookshop in Mexico
and I request the book to be delivered by the IPS Company,
this company puts the book in a big container specifying
destination SPAIN. Once the container is received, for example
in the Barcelona Airport, they open the container and gather
all the packets with destination MADRID. All these parcels
are then put in a truck that will transport them to Madrid.
Once in Madrid the Post Office, for example, checks the
ZIP code of the parcel and proceeds to deliver the book.

Regards,
Juanjo