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 | 9 comments |
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 | 8 comments |
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 | 6 comments |
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 | 0 comments |
headers
Tony Li | 1 Nov 09:37

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


Tony,

This is blatantly unfair.  As an "arms merchant", I fully want
to sell gear to all interested parties, both ISPs and enterprise
alike.  And, as a certain AD is fond of reminding me, the enterprise
is a very big market.  Why would I want to torque the enterprise?

Instead, I want to help all parties by growing the net in a 
reasonable and scalable way.  That should be what we're all trying
to do here.

The operation issues that I know of NEVER favor restricting topology.
In fact, restricting topology is the result of geographic aggregation
as it forces providers to interconnect within the aggregation boundary.
Operational issues instead favor a haphazard, need driven, cost
optimized topology.  Yes, ok it's chaotic, but it's the result of
capitalism at its finest.

Provider independence isn't necessarily helped only by PI space.
There are other ways.  The real point is to avoid the pain and
anguish of renumbering.  If we were to go down the GSE path, for
example, changing providers simply means changing the "routing gorp".
The host identifier remains the same.  You reconfigure your border
router(s) and you're done.  Infinitely less painful than dealing with
the boring things like acutally bringing up a new tail circuit.  ;-)

You are also assuming that aggregation and multihoming are somehow 
at odds.  They are not.  All you have to do is to disconnect the
locator and the identifier as GSE does and aggregate only the
(Continue reading)

Permalink | Reply | 8 comments |
headers
Masataka Ohta | 1 Nov 10:33
Picon

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

Tony Li;

> This is blatantly unfair.  As an "arms merchant", I fully want
> to sell gear to all interested parties, both ISPs and enterprise
> alike.  And, as a certain AD is fond of reminding me, the enterprise
> is a very big market.  Why would I want to torque the enterprise?

As a person who is involved in design and operation of a nation
wide 10Gbps backbone of a commercial ISP, I can say that TE is
to have more bandwidth.

Others may have different diffinition. But, those with high cost
definition such as MPLS will, or has already, bankrupt.

It's called fair competition and is applicable to non-ISP
enterprises.

Make routers dumb and cheap.

> If we were to go down the GSE path, for
> example,

:  Note that 8+8 proposal must not be confused by latter proposal of
:  routing goof by Mike O'dell, which is a proposal to use intelligent
:  routers to rewrite source addresses to prevent source address
:  spoofing and to tunnel between intelligent routers for pseudo
:  multihoming, both of which are against the end to end principle and,
:  thus, lacks robustness and/or scalability.

						Masataka Ohta
(Continue reading)

Permalink | Reply | 0 comments |
headers
Iljitsch van Beijnum | 1 Nov 12:17
Favicon

GSE

There has been some talk about GSE in the past few days. Before anyone
gets too excited about this, let me point out some of the numerous
prolems with this approach:

- GSE doesn't provide any failover mechanisms but depends on tunnels to
  repair dead customer<->ISP links. This could be done just as easily
  with regular PA space.
- It is very unclear how GSE is supposed to work in a single host
  environment. Do hosts that don't sit behind a GSE-capable border
  router the GSE processing themselves or is this done by the ISP?
- It needs changes to transport protocols and possibly to intra-site
  routing and address discovery.
- The flat part of the identifier space makes locator discovery hard.

That being said, I think GSE could be a subset of a more general
approach. If you're going to map identifiers to locators one form of
these identifiers could have the first 48 bits set to 0, if the
identifier to locator discovery service is willing to go the extra mile
and provide mappings for individual 128 bit identifiers. Or you could
have 127 bit hashes as required by HIP. Or use an IPv4 or OSI NET
identifier with an IPv6 locator...

Being agnostic about the structure of the identifier is a good thing for
future extensibility. However, using identifiers with regular IPv6
unicast semantics will make the transition a lot easier as it allows
interoperability between multihoming-aware and non-multihoming aware
systems and/or providing the multihoming support in separate boxes.
Permalink | Reply | 8 comments |
headers
Iljitsch van Beijnum | 1 Nov 14:02
Favicon

Re: GSE

On Fri, 1 Nov 2002, Iljitsch van Beijnum wrote:

> Being agnostic about the structure of the identifier is a good thing for
> future extensibility. However, using identifiers with regular IPv6
> unicast semantics will make the transition a lot easier

Question: would it be a desireable or even required property of an
identifier to be identifiable as such by all?

Obviously, the destination site or host would know whether one of its
addresses is an identifier or a locator. But would it be important for
others to be able to make this distinction? It might be good to avoid
trying to map a locator to a new locator. On the other hand, this means
identifiers have to come from a separate block of IPv6 address space
(assuming they look like IPv6 unicast addresses). This isn't (very)
compatible with an extra address negotiation solution or with
interoperation with non-multihoming aware systems.
Permalink | Reply | 1 comment |
headers
Brian E Carpenter | 1 Nov 14:44
Picon
Favicon

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

Iljitsch van Beijnum wrote:
> 
> On Wed, 30 Oct 2002, RJ Atkinson wrote:
> 
> > > Very few non-ISP organizations do this, as it requires them to move
> > > traffic over their internal network which costs money, while receiving
> > > the traffic where it eventually needs to be usually doesn't cost more
> > > than receiving it at any other location.
> 
> > Our samples spaces must be different.  I think that many non-ISP
> > organisations
> > multi-home via different providers on either sides of North America.
> 
> It is certainly possible we're seeing different things from the places
> we're sitting. But the real question isn't whether they _connect_ on
> opposite ends of a continent or ocean, but whether they need to announce
> a globally visible route in both locations. This is only absolutely
> necessary if they prefer traffic to flow over their internal network
> rather than over an ISP network. It is also desireable for backup
> purposes but I feel this isn't an important enough reason to allow it.

Sorry, but that's not acceptable. Failover/backup is exactly why
such enterprises need this. As somebody else said, there aren't that many
multicontinental megacompanies that giving them unique prefixes is going to
significantly inflate the default table. The case we need to worry about
is hundreds of thousands of smaller, more local enterprises that
nevertheless need failover; we can't afford each of them to add a prefix.
But at current course and speed, that's where we're headed.

   Brian
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian E Carpenter | 1 Nov 14:56
Picon
Favicon

Re: draft-ietf-multi6-multihoming-requirements-04.txt

RJ Atkinson wrote:
> 
> On Wednesday, Oct 30, 2002, at 19:48 America/Montreal, Masataka Ohta
> wrote:
> > The problem is that the draft already contains mutually
> > exclusive requirements.
> 
> It would be helpful if you would list any that you find
> so any that exist can be resolved.  Details help.

I suspect you'll find that in the list archives. But I don't
think it's the point right now; I think we just need the
document off our plate, with lower or UPPER case, basically
I don't care, so that we can start exploring the solution space
in a serious way.

We could waste a lot of time making the requirements document perfect.

   Brian
Permalink | Reply | 0 comments |

Gmane