[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: about draft-baker-v6ops-l3-multihoming-analysis-00
Moving this from v6ops to ram, and for this email copying both lists.
On Dec 1, 2006, at 8:56 AM, marcelo bagnulo braun wrote:
actually, my question was more precisely, if a multiple PA prefixes
approach is suitable for a multihomed soho network? from reading
the paragraph below, i understand that you think that it might, is
this correct?
shim6 says it is, and would have each ISP provide its own prefix.
GSE says it is, but leaves the hosts effectively ignorant of the
prefixes assigned (within the enterprise network, the routers only
look at the subnet number, and the hosts only look at the host
identifier, and the border routers rewrite the part used by the
ISPs). A variation on GSE would have the border router ICMP back
to the host indicating that it should be using a certain "routing
goop", and have the host resend using that. Metro and PI would
simply have a single prefix on the edge network in the first
place. If the distance and complexity questions are those of a
typical home (see slides 3 and 4 of ftp://ftpeng.cisco.com/fred/
v6ops/Fred_network_paths.pdf for what I think a typical home looks
like; the slide needs some updating now and in the coming years
will have various large datarate home appliances added to it, but
I suspect it's close) I can't imagine any of those having real
operational problems. The big issue with multiple prefixes that I
see are related to the hiccups around network changes.
In the paragraph, I report what various proposals think, not so much
what I think.
shim6 has some real issues related to RFC 3582, IMHO, as discussed in
the draft. That said, it technically works (or at least can work),
which is my first criterion. As to whether users will find it
acceptable, I don't know, but I can tell you that some are saying
fairly loudly that they don't. They aren't SOHO customers, though;
the ones I am hearing are coming at it from a medium-to-large
enterprise or an ISP perspective.
GSE is not published as an RFC because its author, Mike O'Dell,
considers it half-baked. That said, it resolves a number of issues
with the multi-addressing model that shim6 has to work a lot harder
to solve, and has less issues related to RFC 3582. It requires a
fundamental change to the way we view the IPv6 address, which has
some issues, as I commented on yesterday and others have commented on
in the past. I can tell you that in many respects it reflects the
Xerox Network Systems Internet Transport architecture, aka Novell
Netware at the Network layer, and not only works but works well. I
don't see any reason it would be unacceptable in a SOHO environment.
Let me hasten to say that I have a number of issues with Novell
Netware, but they are at the transport layer and above. The XNS
architecture (including a TCP-like transport, and UDP-like transport,
a simple routing protocol, a separate network layer and an ICMP-like
response protocol, and the Courier RPC application) was pretty well
thought through, and my observation of the Internet is that every day
we seem to become a little more like it. IDP/IPX's limitations, such
as the hop count and the flat network number, were fine in 1980 and
we know how to overcome now.
The GSE variant I mention was first proposed, IIRC, a year or more
ago by someone else. GSE supposes that what it calls the "routing
goop" (the most significant 48 bits of the address) are completely
fungible, and can be overwritten by the border routers at will. But
the originator of a datagram does indeed set them to something. This
proposal, instead of saying "when you see this the wrong routing goop
in a source address outbound, overwrite it" or (RFC 3704) "route it
to the right egress", says "when you see the wrong routing goop in a
source address outbound, send an ICMP back indicating the routing
goop that the originator should be using and drop the packet". The
originator resends the datagram accordingly. That works technically
as well, and perhaps does less violence to the address, but at the
cost of an RTT. An RTT on a LAN (SOHO) isn't much; an RTT in a multi-
continent corporate network might be a problem.
PI is what we have now for ISPs and a few large companies; PA is what
we have now for everyone else. PA works if you are not multihomed;
the issues that arise in multihoming are why we are doing shim6. As I
note in the draft, both have serious scaling problems if applied to
the SOHO environment and (PA) the prefix assigned to the SOHO is
advertised through multiple providers. Would they be acceptable to
SOHO networks? If they have one address, I don't think they care what
happens outside any more than the ISPs care if they get overloaded
with multi-addressing.
I keep Metro on the table because, while it is a change to the
business model, it allows the SOHO to have something akin to a
portable PI prefix and the advantages that come with that, but in a
far more scalable network architecture for the businesses in the so-
called default-free zone. It implies some form of value exchange
among ISPs, which I tend to think is unavoidable in the long term. In
the final analysis, I think that the companies that instigated the
Net Neutrality debate were in fact asking for some form of settlement
procedure, both with those who think they already pay for service and
shouldn't have to directly pay companies they view as monopolists,
and the companies that are saying that over-the-top services should
be paying them for transport. Without going into a long dissertation
about volume charging, if one buys that the business is *going* to
change (has been changing, perhaps in some respects is already
changed) in that direction, changing it in a way that makes metro
play is not all that hard. Since it looks like PI addressing to the
SOHO (and as observed, the SOHO doesn't care what goes on elsewhere),
I don't see any reason that the SOHO wouldn't be willing to do it.
What I think about the acceptability to SOHOs:
In each case, the question of viability in the SOHO environment is
pretty straightforward. If it has to be manually configured by an
expert, it is a non-starter, and if it is simply a fact of life the
SOHO doesn't care. For any of these to be deployable at all, CPE
routers like Linksys, Windows, Linux, MacOSX, and so all have to do
them "out of the box", and the SOHO is going to deploy whatever comes
out of the box. The folks that are going to care about the details of
what is implemented are the medium and larger companies and the ISPs,
who having larger networks are going to have to understand the
implications of the choices.
i also think that having means to centrally enforce TE policies
(which is not in the goals document is also a very valid requirement)
In that sentence, the word "central" kind of glows and vibrates.
Elaborate?
Are we considering a multihoming solution for ISPs or for end sites?
I think the discussion has to take into account both ISPs and
their customers, which might very well mean that it needs to be
divided into separate discussions. For example, I have been told
by some ISPs that they want PA addressing because it gives them a
market lock, and by some of their customers that they don't want
PA addressing because it gives ISPs a market lock. That kind of
divide is a place where a single consensus is simply not going to
form.
agree, who should we listen to?
Both. Yes, that's hard. In the end, though, the solution we come up
with needs to enable ISPs to run their businesses according to rules
they are comfortable with and edge networks to be able to run theirs
in ways they are comfortable with. Giving them a solution that meets
only one set of requirements guarantees that the other will be
unhappy and will continue to agitate for something different.
well, i think we could start by dividing the types of multihoming
scenarios as you did in your draft (maybe include other scenarios
as well) and try to identify the requirements for these scenarios.
We can start with the list of goals described in the rfc3582 and we
can add other requirements that you and Marla have identified
talking to the operational community, makes sense?
If you're offering to post a draft with some thoughts, that sounds
like a reasonable place to start.
the obvious candidate would be centrally managed ULAs (i know they
don't existe, but seems the easiest way to get unique identifiers)
We have centrally-managed ULAs now. You get them from IANA through
the registries. They are called "global addresses".
big sites, have more requirements of functionality but less
scalability requirements. PI should be ok for them
small sites, completely different game. Probably less
functionality, easier to manage, easier to renumber but much more
scalability is required.
Yes.