headers
Tony Hain | 1 Nov 01:59

RE: PI/metro/geo [Re: The state of IPv6 multihoming development]

Tony Li wrote:
> ...
> We need to decide which is more important: the scalability 
> and durability
> of the routing subsystem or the convenience of non-connection based 
> addressing.  When we have consensus on this point, then all else will
> follow.
> 

The answer to the question depends on which side of the table you are
sitting on. 

> ...
> The fact that there are already 11,000 today should concern 
> us greatly.
> If the rate of such sites continues to grow proportionally to the size
> of the network, we'd be looking at unsustainable exponential growth in
> the DFZ.  If it helps, you might recall that the DFZ about 10 
> years ago
> was only about 5K routes.  Multiplying by 20X has been painful.

Yes, but much of that is self inflicted for TE. Of the ~11,000, ~7,000
inject a single prefix, while the next ~3,000 inject 2-4. In other
words, 4/5 of the growth can be directly traced to 1/10 of the
participants.

> 
> For organizations that are looking for better/cheaper or (more likely)
> diverse service, I think that you'll agree that we do want to find
> a way to provide them service.  If we simply try to constrain the
(Continue reading)

Permalink | Reply |
headers
Randy Bush | 1 Nov 07:13

RE: PI/metro/geo [Re: The state of IPv6 multihoming development]

</ad hat>
>> We need to decide which is more important: the scalability and durability
>> of the routing subsystem or the convenience of non-connection based
>> addressing.  When we have consensus on this point, then all else will
>> follow.
> The answer to the question depends on which side of the table you are
> sitting on. 

there is little doubt in my mind which side i sit on.  interesting that
tli seems to be on the same side.  but then he always kinda groked the
operational issues.

randy
Permalink | Reply |
headers
Masataka Ohta | 1 Nov 09:15
Picon

Re: PI/metro/geo [Re: The state of IPv6 multihoming development]

Randy;

> </ad hat>
> >> We need to decide which is more important: the scalability and durability
> >> of the routing subsystem or the convenience of non-connection based
> >> addressing.  When we have consensus on this point, then all else will
> >> follow.
> > The answer to the question depends on which side of the table you are
> > sitting on. 
> 
> there is little doubt in my mind which side i sit on.

Which?

Routing subsystem is for single homing only that there is no table.

						Masataka Ohta
Permalink | Reply |
headers
Tony Hain | 1 Nov 08:06

RE: PI/metro/geo [Re: The state of IPv6 multihoming development]

Randy Bush wrote:
> </ad hat>
> >> We need to decide which is more important: the scalability and 
> >> durability of the routing subsystem or the convenience of 
> >> non-connection based addressing.  When we have consensus on this 
> >> point, then all else will follow.
> > The answer to the question depends on which side of the 
> table you are 
> > sitting on.
> 
> there is little doubt in my mind which side i sit on.  
> interesting that tli seems to be on the same side.  but then 
> he always kinda groked the operational issues.

Operational issues in the ISP space have always favored restricting
topology or the knowledge about unaggregated parts thereof. At the same
time, operational issues in the edge enterprise space favor provider
independence for maximum flexibility. We have representative voices for
the ISP issues, where are the comparable voices for the enterprise
issues? The ISP focus carried round 1, so the allocation policy only
allows for strict aggregation via provider blocks. The enterprise demand
for multi-homing is the fundamental issue this WG is supposed to
address, but the primary voices are those insisting on maximal
aggregation for the ISP routing system. It is hard to believe this will
end up with a well balanced result that considers all the requirements. 

Speaking of, we have a requirements doc that needs to get published. 

Tony
(Continue reading)

Permalink | Reply |
headers
Randy Bush | 1 Nov 16:06

RE: PI/metro/geo [Re: The state of IPv6 multihoming development]

</ad hat>

> Operational issues in the ISP space have always favored restricting
> topology or the knowledge about unaggregated parts thereof.

not at all.  they have merely been focused on maintaining the
knowledge of topology by keeping routers from melting down.  and
this is not theory, we lived it.

that most schemes folk have for new topologies have not been
realistic in terms of routing table expansion, should not be taken
as isps wanting to suppress information.  that you can't holiday on
mars this weekend is not my fault.

information reduction has been is the only tool the isps have to
deal with routing bloat and weak vendor hardware.  if you would
care to suggest others, i am all ears.

randy
Permalink | Reply |
headers
RJ Atkinson | 2 Nov 13:16
Favicon

Re: PI/metro/geo [Re: The state of IPv6 multihoming development]


On Friday, Nov 1, 2002, at 10:06 America/Montreal, Randy Bush wrote:
> information reduction has been is the only tool the isps have to
> deal with routing bloat and weak vendor hardware.  if you would
> care to suggest others, i am all ears.

Agree,

and some few of us suspect there might be a convergence time wall not 
very far
in front of us in IPv4-land, that is not due to "weak vendor hardware",
but instead due to inherent issues in the current Path Vector algorithms
behind BGP.  This kind of suspicion is part of why the IRTF RRG is 
examining
the broader topic of IP routing -- though that level of research is 
outside
the charter for this list....

Ran
Permalink | Reply |
headers
Iljitsch van Beijnum | 2 Nov 14:43
Favicon

Re: PI/metro/geo [Re: The state of IPv6 multihoming development]

On Sat, 2 Nov 2002, RJ Atkinson wrote:

> and some few of us suspect there might be a convergence time wall
> not very far in front of us in IPv4-land, that is not due to "weak
> vendor hardware", but instead due to inherent issues in the current
> Path Vector algorithms behind BGP.  This kind of suspicion is part
> of why the IRTF RRG is examining the broader topic of IP routing --
> though that level of research is outside the charter for this
> list....

Doing this ourselves would be stretch charter-wise, but it would be good
to be aware of what's going on, otherwise we may come up with the
perfect solution that will last three months until BGP goes down the
crapper.

In other words: any information you have on this will be appreciated.

And what I'd like to know: we're rapidly approaching the moment when
routing information about the entire internet is too much to be present
at a single point in space and time, even with provider aggregation in
place. So how will this work with a link state protocol? The advantage
of a distance path protocol is that it also works when the routing
information isn't fully converged.
Permalink | Reply |
headers
Tony Hain | 1 Nov 19:27

RE: PI/metro/geo [Re: The state of IPv6 multihoming development]

Randy Bush wrote:
> </ad hat>
> 
> > Operational issues in the ISP space have always favored restricting 
> > topology or the knowledge about unaggregated parts thereof.
> 
> not at all.  they have merely been focused on maintaining the 
> knowledge of topology by keeping routers from melting down.  
> and this is not theory, we lived it.

We are in violent agreement here... Keeping the routers from melting
down leads to favoring approaches that keep the topology or knowledge
bounded. 

> 
> that most schemes folk have for new topologies have not been 
> realistic in terms of routing table expansion, should not be 
> taken as isps wanting to suppress information.  that you 
> can't holiday on mars this weekend is not my fault.

I am not arguing that the ISP is wrong for wanting to cost optimize, or
simply stay afloat, just that there are reasons behind the demand for
the 'unrealistic topologies' and those reasons are just as valid even if
the proposed topologies are not. 

> 
> information reduction has been is the only tool the isps have 
> to deal with routing bloat and weak vendor hardware.  if you 
> would care to suggest others, i am all ears.
(Continue reading)

Permalink | Reply |
headers
Randy Bush | 1 Nov 19:31

RE: PI/metro/geo [Re: The state of IPv6 multihoming development]

>> that most schemes folk have for new topologies have not been 
>> realistic in terms of routing table expansion, should not be 
>> taken as isps wanting to suppress information.  that you 
>> can't holiday on mars this weekend is not my fault.
> I am not arguing that the ISP is wrong for wanting to cost
> optimize, or simply stay afloat

i said nothing about cost, staying afloat, ...  i did not go above
layer four.

> just that there are reasons behind the demand for the
> 'unrealistic topologies' and those reasons are just as valid even
> if the proposed topologies are not.

that's nice.  but this is the internet ENGINEERING task force.  we
have the sad problems of dealing with reality.

randy
Permalink | Reply |
headers
Tony Hain | 1 Nov 19:56

RE: PI/metro/geo [Re: The state of IPv6 multihoming development]

Randy Bush wrote:
> >> that most schemes folk have for new topologies have not been
> >> realistic in terms of routing table expansion, should not be 
> >> taken as isps wanting to suppress information.  that you 
> >> can't holiday on mars this weekend is not my fault.
> > I am not arguing that the ISP is wrong for wanting to cost 
> optimize, 
> > or simply stay afloat
> 
> i said nothing about cost, staying afloat, ...  i did not go 
> above layer four.

I don't know where you thought I was going, but I was talking about
staying afloat in the same sense as keeping the routers from melting
down, and cost optimization is a fundemental aspect of engineering.

> 
> > just that there are reasons behind the demand for the 'unrealistic 
> > topologies' and those reasons are just as valid even if the 
> proposed 
> > topologies are not.
> 
> that's nice.  but this is the internet ENGINEERING task 
> force.  we have the sad problems of dealing with reality.

My point was that the requirements of the edge sites are reality.
Ignoring them may make it easier to accomplish something, but is the
result useful?

Tony
(Continue reading)

Permalink | Reply |

Gmane