[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPv6 Multi-homing BOF at NANOG 35



Hi Jason,

limited the cc list to the shim...

[Note : FWIW i think that the feedback from the ISP community is very valuable, so this is not the point that i am discussing here]

El 04/10/2005, a las 21:54, Jason Schiller (schiller@uu.net) escribió:


On Tue, 4 Oct 2005, John Payne wrote:

Date: Tue, 04 Oct 2005 14:10:27 -0400
From: John Payne <john@sackheads.org>
To: Iljitsch van Beijnum <iljitsch@muada.com>
Cc: David Meyer <dmm@1-4-5.net>, iab@ietf.org, ipv6@ietf.org, shim6@psg.com
Subject: Re: IPv6 Multi-homing BOF at NANOG 35


On Sep 25, 2005, at 12:48 PM, Iljitsch van Beijnum wrote:

NANOG = network operators in the sense of ISPs and the like. The
solution that the shim6 is working on does NOT apply to this
demographic.

Whoa there.  The NANOG community (as well as other ISP communities) is
hugely affected by shim6.

They are the ones who will be fielding customer calls about multihoming
- "why can't I just setup BGP like I always have done?".  Not everyone
at NANOG is going to be big enough to get a /32, but most of the ISPs
there are at least multihomed today.

I urge the discussion leaders to make it painfully clear to which
types of users the shim6 solution space applies and to which type of
users it doesn't.

Doesn't this apply to any orgization that doesn't have its own /32?


well, i have always read the term site multihoming as kind of opposed to two other concepts: host multihoming and ISP multihoming

So i would say that the design goal of the shim is focus in the support end-site multihoming support rather than ISP multihoming

For instance, i read the goals described in RFC 3582 are more the goals of an end-site rather than the goals of an ISP (probably the goals of an ISP would a superset of the goals of an end-site imho.) In particular, there are no references in that document in the impact of the solution in clients of the ISP (i don't know, but i guess that there should some considerations about that when considering ISP multihoming) Other assumption that may or not have impact, is that an end site seems to assume that there is a single administrative domain rather than an ISP with multiple customers where there are many administrative domains.

Perhaps a good question (at least for me) would be if you think that the goals expressed in RFC 3582 properly describe the goals for ISP multihoming or if you think that something is missing there

since those are the goals the the shim is trying to reach, this may explain what is to be expected from it.

Regards, marcelo



Doesn't this apply to any orgization that has customers that require
multihoming but lack their own /32 as John points out?

Doesn't this apply to any orgization that has it's own IPv6 aggregate,
and wants to advertise something more specific than its aggregate?

If that is the case, then it won't just apply to ISPs or multi-homed end sites who can't get a /32, it also applies to ISPs and end sites who have a /32, but need to split route announcement to share load across multiple
transit providers.

___Jason