Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering

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

> (If someone has an idea which is neither of these two...)

1. LAN = current routing
2. LAN address= /32, e.g. ::0123:EUI-64
3. WAN = hierarchy of network access points with 1 AP per e.g. 30 sq miles
4. WAN address (is created at AP) = 32-bit ASN + LAN address
5. Address = topological locator
6. Interface/node ID comes from an independent pool of numbers, e.g. RFID

Thanks,

Peter

For packet to get through WAN ASN is added into address

--- Noel Chiappa <[email-masked]> wrote:

>     > From: Roland Dobbins <[email-masked]>
> 
>     > the proposed SHIM6 solution is iatrogenic in nature due to the reasons
>     > outlined previously.
> 
> Well, perhaps it is fatally flawed, but if so, we need to figure out why, and
> then work on how to overcome those issues.
> 
> 
> Look, as far as I can work out, there are basically two classes of solution
> to providing widespread multi-homing.
> 
> The first is "let the routing do it". Alas, within the current routing
> architecture, that amounts to "forcing every router in the entire
> default-free zone to carry an advertisement for site X's PI-address", which
> is widely seen (although not universally, q.v. that address registry meeting
> where they approved the PI proposal) as non-workable.
> 
> So, that leave us with "other", which as far as I can work out, means some
> form of "multiple routing-names for each connected entity", because I can't
> think of any other. (If someone has an idea which is neither of these two,
> please speak up!) So now the only question is the engineering details: who
> picks, when they are added, where they are carried, etc, etc.
> 
> 
>     > I don't know what the right solution is, yet.
> 
> Well, a lot of people have been struggling with this for a long time. There
> is no easy solution, or somebody would probably have figured it out by now.
> 
> It's easy to sit back and say "solution A has problem X" and "solution B has
> problem Y". That sort of situation, where there is no perfect solution, is
> almost inevitable when we're trying to upgrade a large, deployed system.
> Heck, I could come up with a great design for multi-homing, *if I had a blank
> sheet of paper*.
> 
> The problem here is that if we start out with a solution-space of size A, and
> then start enumerating constraints, what happens is that each constraint
> chops off a piece of solution space, until eventually we're caught in a
> pretty small piece of solution-space. Apply enough constraints, and you're
> probably tiled the entire solution-space. Something - or somebody - has got
> to give.
> 
> 
>     > this class of proposals cannot be realistically considered for 'the
>     > IPv6 multihoming solution'.
> 
> What exactly are you including in "this class"? Because if you're including
> all solutions in which things have more than one routing-name, we've just
> ruled out the entire solution-space (other than "let the routing do it").
> 
> If you are OK with the general concept, but just think the particular details
> of SHIM6 have problems, yeah, could be. Explain what they are, and we can see
> if there's a way to change things to overcome them. TLi explained some of the
> constraints that got applied which reduced the solution-space - perhaps we
> need to go back and re-examine whether some of them need to be reconsidered.
> 
> But if you're against all solutions of the form "multiple routing-names",
> what's left, other than "let the routing do it"?
> 
> 	Noel
> 
> _______________________________________________
> RAM mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ram
> 

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

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

---

From: [email-masked]
Date: Mon, 8 Jan 2007 16:02:49 +0100

Noel,

> where they approved the PI proposal) as non-workable.

Yes, I also think the problem is the current routing architecture.
We have several thousands of autonomous systems in the Internet that
we treat all in the same way. But 1/6 of them does a crucial work:
these are the transit AS-es, which receive packets coming from one
AS and send them to anoter AS. Without transit AS-es (and with the
current routing paradigm) we would need to form a huge full-mesh
of connections between all the AS-es in the Internet.

IMHO the problem is not to force every router in the entire DFZ
to carry an advertisement for site X's PI-address. The real
problem is that it has to use it for routing, i.e. install it
in the RIB and download it in the FIB. Using some type of
hierarchy, DFZ routers could give up using PI addresses,
specifically those of non-transit AS-es.

Regards,
Juanjo

---

From: "Chris L. Morrow" <[email-masked]>
Date: Mon, 08 Jan 2007 16:50:27 +0000 (GMT)

> > where they approved the PI proposal) as non-workable.

note that the RIR meeting (ARIN) in question there were several loud
voices saying: "this is not a good plan", I think that either:
1) people refused to believe it was a problem
2) people didn't articulate that it was a problem properly
3) folks decided that to solve some immediate business problems they'd
sacrifice longer term 'security'
4) folks really want to see ipv6 'deployed' and with some of the current
stumbling blocks around ipv6 that isn't going to happen without some
incentive for enterprises (pi space was seen as one incentive)

(from a person at the meeting in question)

> specifically those of non-transit AS-es.

This seems to imply that there are only 2 types of AS's, there are in fact
mixes of the 2. Not all Transit-AS's are 'just' transit, not all leaf-ASs
are just leaves... With the current physical connectivity of the network
there exists a need to have much more information about the network as a
whole in more places than one realizes.