Subject: [RAM] Routing and Addressing discussion in v6ops

From: Fred Baker <[email-masked]>
Date: Thu, 30 Nov 2006 12:40:23 -0800

Brian has suggested that much of this discussion belongs on the ram  
list. See

	https://www1.ietf.org/mailman/listinfo/ram

and please join it if you feel it is appropriate for you to do so.

Where IPv6 Operations has a useful role here, I think, is to bring  
out internet drafts and perhaps RFCs that inform that discussion.  
That may include reposting existing internet drafts, and may include  
new ones. The key thing, though, is that the question is not "what  
are the multihoming requirements for the entire Internet", but "what  
are the end-to-end addressing and routing requirements for" what I  
will call (for lack of better terminology, not become I like it all  
that well) "Transit ISPs, Access ISPs, large edge networks, mid-sized  
edge networks, and SOHO and residential networks?" Multihoming is  
part of that, but inter-ISP traffic engineering is also part, and  
there may be other parts. If two groups of people find that they have  
differing requirement sets, the solution is not to force them to come  
to some unrecognizable consensus, but to have them describe the part  
of the Internet they are describing requirements for and then  
accurately cull out those requirements. The classic example of such a  
divide that I mentioned in another note is the idea that some ISPs  
want PA addressing as a market lock, and some edge networks detest PA  
addressing because it is one. One useful note along those lines might  
be a well researched set of expectations of the Internet, including  
each of its various ecological zones, in ten, twenty, and fifty years.

Consider a call for submissions to have been placed.

Note, by the way, that I don't automatically assume that all  
individual submissions are intended or need to become working group  
documents, or that all internet drafts are intended or should become  
RFCs. You will note that I quite happily post internet drafts to pose  
a discussion and happily let them die if the discussion completes and  
they are no longer needed. This isn't a race to get written up in the  
record books. But useful contributions to those discussions will be  
welcomed, and if the WG is of the opinion that they should be  
archived I'm all for it.

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Fred Baker <[email-masked]>
Date: Fri, 1 Dec 2006 11:09:54 -0800

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.