Re: about draft-baker-v6ops-l3-multihoming-analysis-00

[Fred Baker <fred@cisco.com>]

On Nov 21, 2006, at 10:03 AM, marcelo bagnulo braun wrote:
> First, i think that the draft makes a good job in identifying that  
> not all multihoming sites are the same...

Thanks for your comments. I think you and I very much agree that  
there are different requirements. For example, I think that a Fortune  
100 company probably has the same address-independence requirements  
as an ISP has, while a homeowner changing his IP address when he  
moves from house to house seems very reasonable.

I went through your comments, and concluded that while you and I  
don't fully agree, our disagreements were relatively minor. For  
example, I don't think of renumbering as "costly", as it is something  
my company does from time to time and doesn't find so. But I do think  
of the complexities of remembering and managing all the places where  
one writes down an IP address. Early in the note I found myself  
arguing with you in the same direction as other comments you made  
later in the note.

What this tells me is that we haven't got a very good requirements  
document. The requirements on the table don't describe traffic  
engineering requirements at all, and the requirements in RFC 3582  
have several problems.


What might be helpful (thinking out loud here, not making a  
pronouncement; I wonder what people think) to the community at large  
would be a requirements document or set of documents that discusses  
not "requirements of a multihoming solution" but "addressing and  
routing requirements of an end to end network". It would have to  
discuss traffic engineering, from the perspective of saying what  
requirements were reasonable and solvable and what were not. It would  
have to discuss backbone and access ISPs and their business models,  
the requirements of large companies, the requirements of SOHO  
networks, and would have to at least wonder whether there was a zone  
in between. In the end, it might provide advice on AS number  
assignment among other things.

In the end, there are a small number of solutions that can be looked  
at generally to provide a scalable address management architecture.  
The one we are looking at right now suggests the numbering of ISPs  
and asking smaller edge networks to manage multiple prefixes overlaid  
within them. Looking at the discussion of address selection  
discussion that Arifumi is leading and the parallel discussion of an  
update to BCP 38, I think that has some serious questions. The  
exchange-based addressing model I mention in the draft has some  
issues in the business model and in creating what amounts to another  
kind of overlay network. GSE depends, for scalability, on rewriting  
part of the source address in a datagram, which helps with a number  
of the routing problems but begs the question of how the transport  
associates a request with a response. For example, if I use networks  
1 and 2 and you use networks 3 and 4, and I send a message from 1::me  
to 3::you and get a reply from 4::you to 2::me, how do I identify  
that the datagram I received is a reply to the same session? Doing so  
requires the Endpoint ID to truly be globally unique, which is a tall  
order, or it requires some form of dongle at the transport layer that  
addresses the issue. One could imagine the locator/id separation  
resulting in a mandate for the use of IPSEC integrity mode to inform  
the transport's multiplexor. The one thing that doesn't scale is the  
one thing we are doing now, which is having the RIRs assign prefixes  
to SOHO networks.

What we are trying to do in this is inform that discussion.