headers
Kurt Erik Lindqvist | 2 Dec 11:01
Picon

Re: Multihoming and what we discussed in Atlanta

>
> - it's = "it is", its = "owned by it"

Thanks!

> - maybe leave the first few sections out until you're ready to find a
>   wider audience as this is extremely familiar...

True but I prefer to give some background.

> - better explain what you mean by not aggregate in 5.1. Do you mean 
> they
>   shouldn't announce a less specific, or that they should announce the
>   /48? Or both?

I actually mean both. I will update that.

>> Browsing through mail I though I saw something similar from Iljitsch.
>> If that is the case let's see if we can merge something.
>
> I discuss several other methods to achieve the same thing. Let me know
> which one you think can be included in this draft. If that's all or
> nearly all of them, it makes sense to merge.
>

See comments on your email.

Best regards,

- kurtis -
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aldrin Isaac | 2 Dec 16:33
Favicon

RE: Multihoming and what we discussed in Atlanta

% draft-kurtis-multihoming-longprefix-00
% 6.1 Aggregation effects with the current allocation policies
%   ....
%   improved.  With the proposal for multihoming IPv6 as described in
%   this document, the potential for the same routing table growth
%   explosion as we have today exists.  However, given that the
current
%   allocation blocks to ISPs are blocks with 32 bit long prefixes,
one
%   of these blocks will fit the current address assignments of most
%   ISPs.  This means that the routing table will be inherently small
to
%   start with.  Even if all ASes that are active today where to
announce
%   IPv6 address space, it would only be around 14 000 routes.  Almost
%   90% less of the current routing table.  This means that we have
quite
%   a lot of breathing space before we starting running into the same
%   scalability problems as today.  This is due to the current
%   allocations.  Doing multihoming by announcing longer prefixes out
of
%   allocated blocks will make the routing larger but looking at the
%   current amount of multihomed networks, this should not pose a
%   problem.

IMHO, for this form of multihoming, multihomers should *not* use
prefixes that that are part of the allocation of any of the ISPs over
which it multihomes.  A multihomers address should come from
well-known managed PI blocks.  Using part of an ISPs allocation
results in inefficient routing, unneccessary fragmentation of ISP
(Continue reading)

Permalink | Reply | 4 comments |
headers
Tony Hain | 3 Dec 19:27

RE: Next question...

Tony Li wrote:
> Folks,
> 
> Have we reached consensus that we need to deal with 
> multihoming policies?  

I thought that was one of the goals of the requirements document...

> And do we agree that doing so at the 
> per-host level doesn't scale?
> 

My interpretation of 'doesn't scale' in this case is that the host
policies are not managed by the network infrastructure team, therefore
per-host can't be part of the multi-homing solution using current
management tools and divisions of labor. If that interpretation is
correct, a simple non-technical approach like having the host and
network management teams actually talk to each other would remove the
scaling issue. Other approaches like better management tools would also
help. Removing per-host from the solution set may make it easier for the
network focused participants to reach consensus, but it blinds the host
& applications from the alternatives. Scaling in this case depends on
your perspective. From the app point of view, a network that does not
react appropriately is useless for anything more than a bit-pipe and
will be routed around or tunneled over (re: POTS, ATM, ...). Managing
fine-grained TE aspects of uncoordinated traffic sources with an IGP
sounds like a nice research topic.

Tony
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tony Hain | 3 Dec 19:34

RE: Consensus check

marcelo bagnulo wrote:
> ...
> I mean, the main objection that i have heard is that 
> providers would have to carry packets for non customers, but 
> in your case (if i understand the scenario correctly) it 
> seems like a cooperative environement, so i would say that 
> this is acceptable, rigth?
> 

This depends on the relationship of the exchange to the transit
provider. If the exchange is just a netural interconnect, you are
correct, a transit provider could end up carrying traffic for a
non-customer. BUT if the exchange were a customer of the transit
providers, the non-customer problem disappears.

Tony
Permalink | Reply | 0 comments |
headers
Kurt Erik Lindqvist | 3 Dec 14:04
Picon

Re: Site local

>> ..I am behind on email due to flu but one thing I haven't figured out
>> in this "GUPI" thread....what would be the difference to the PIs we
>> have today? Aren't we trying to work around RIR policy with address
>> architecture?
>
> Firstly, we have no PIs today in IPv6. If you're referring to pre-CIDR
> IPv4 prefixes, I think the difference is that people believe the 
> scaling
> issues with the DFZ will severely limit the ISP's ability to route
> non-aggregatable IPv6 prefixes, however much money they are paid to do
> so

I was actually referring to IPv4 PI space. That is not necessarily 
pre-CIDR, you can still get it.

You are right in saying that it will affect the DFZ size, but that is a 
problem we are dealing with today as well. Notice that there are around 
14000 ASes, assume they are all LIRs they will all get a /32, that 
gives us 14000 routes. Then we have a scaling factor of ten to start 
with there already. More, I don't think that any of these solutions 
with PIs that are routed will come for free. There will be a cost from 
the operators for routing any of this.

- kurtis -
Permalink | Reply | 0 comments |
headers
Kurt Erik Lindqvist | 4 Dec 05:58
Picon

Re: Multihoming and what we discussed in Atlanta

> IMHO, for this form of multihoming, multihomers should *not* use
> prefixes that that are part of the allocation of any of the ISPs over
> which it multihomes.  A multihomers address should come from
> well-known managed PI blocks.  Using part of an ISPs allocation
> results in inefficient routing, unneccessary fragmentation of ISP
> address blocks, and more complex policies for ISP peering.

What do we gain with having a dedicated PI block? Except administrative 
overhead. In what way will routing be more efficient just because the 
addresses are from a dedicated block?

Why would the the ISP peering policy become more complex? On a side 
note, I have handled peering issues on one of the Tier-1 transit free 
providers, this would not have been an issue for us.

- kurtis -
Permalink | Reply | 3 comments |
headers
Kurt Erik Lindqvist | 3 Dec 11:17
Picon

Re: Router solutions

>> I think it would be a good starting point for the WG item describing
>> how multihoming is done today (but isn't there such a document
>> already?). As for the really short term solution that Thomas described
>> in Atlanta I think we need to nail it down more and stick to one
>> solution.
>
> Maybe. But I think selecting one without even discussing it is

Ofcourse not, this is the IETF :)

> premature. Also, I don't think PA hole shooting is the best option,
> especially since it requires renumbering when changing (primary) ISPs.
>

It's not the best, but it is IMO without question the fastest way to 
get started and would already help solve several of the problems we are 
seeing and it does not require any implementation, and best of all - it 
has a back out option.

Best regards,

- kurtis -
Permalink | Reply | 0 comments |
headers
Kurt Erik Lindqvist | 3 Dec 11:03
Picon

Re: Router solutions

>> I think this is text is addressing several questions.
>>
>> I think it would be a good starting point for the WG item describing 
>> how multihoming is done today (but isn't there such a document 
>> already?).
>
> I made a first cut as such a document by ripping relevant text out of 
> the -01 requirements draft, but it was really rough and needs lots of 
> work. There were a few operators and researchers at the time who 
> offered to lend their experience to the draft to make it more useful, 
> but those offers of assistance didn't materalise at the time for one 
> reason or another (the rapid transition from room-to-think to 
> fear-of-being-laid-off at the time had more than a little to do with 
> it).
>
> I would be very happy to lend time to making that document useful, if 
> there is interest in doing so (and in contributing opinions and text 
> to it). I'm not sufficiently naive to think that consensus on such a 
> document would be a trivial thing to achieve, but I suspect it might 
> be easier to obtain than consensus on the requirements draft :)
>

I would suggest to incorporate the text from Iljitsch document if 
needed, and I would be willing to contribute as well.

BTW, what is the name of the document?

- kurtis -
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kurt Erik Lindqvist | 3 Dec 16:46
Picon

Re: Site local


On fredag, nov 29, 2002, at 05:38 Europe/Stockholm, Tony Li wrote:

>
> Hope you're feeling better.

Yupp!

> In particular, what I was suggesting was that the separation of
> locators and identifiers would greatly simplify the (perceived)
> problem that is driving site local addresses anyway.  A site would
> get global identifiers immediately and then when they connect to
> the net (or change connections), they would only change the locator
> part.
>
> By itself, that seems like a lesser win.  However, if the architecture
> is tweaked so that the site's global locators are only known to the
> site's border routers, then the only changes that need to be done
> are very trivial.
>
> In short, someone else has another motivation for the same 
> architectural
> flexibility that a group here has been asking for all along.

Ok, I am more or less with the idea of locator+identifier. What I am 
worried about is the effects of this on the applications.

My main reason for being against anything that could lead down a NAT 
road (and I am worried that any attempt besides assigning global 
addresses everywhere will lead there) is that I have seen the effects
(Continue reading)

Permalink | Reply | 502 comments |
headers
Kurt Erik Lindqvist | 3 Dec 20:22
Picon

Re: (ipv6mh) the Rebel Alliance meetings in Atlanta (long)


(I trimmed the CC list...)

On måndag, dec 2, 2002, at 13:15 Europe/Stockholm, Iljitsch van Beijnum 
wrote:

> On Thu, 28 Nov 2002, Kurt Erik Lindqvist wrote:
>
>>> The main issue is, devise an exit plan before you let stuff pollute 
>>> the
>>> routing tables: part of the consensus should be an agreement on how 
>>> the
>>> advertisements will be limited in the future, so that only very few
>>> sites get advertised that way. For example, maybe we should only 
>>> agree
>>> that a given ISP can only allocate a limited number of "routable 
>>> /48".
>>> Maybe a condition for accepting such a BGP advertisement will be that
>>> the /48 should be of the form xxxx:xxxx:000y, where xxxx:xxxx is the
>>> /32
>>> allocated to the provider -- this would limit inflation to 16 entries
>>> per provider...
>
>> I think that is to few, but the concept is actually pretty nice. Then
>> again, I am not sure it will have much effect.
>
> X per ISP is not going to work as there are global ISPs and very, very
> local ones.

Well, what I meant was that the day an ISP run out of their PI blocks
(Continue reading)

Permalink | Reply | 8 comments |

Gmane