RE: initial issues

[Jim.Bound@nokia.com]

this is a good start on reqs and goals.
/jim

> -----Original Message-----
> From: ext itojun@iijlab.net [mailto:itojun@iijlab.net]
> Sent: Tuesday,February 13,2001 9:57 PM
> To: smd@ebone.net
> Cc: multi6@ops.ietf.org
> Subject: Re: initial issues
> 
> 
> 
> >* There was a brief behind-the-scenes discussion, about the 
> definition
> >  of multihoming, which seemed to result in "being logically 
> connected 
> >  to more than one TLA or NLA simultaneously".
> 
> 	i guess there still are many different configurations possible.
> 	we need to define what "multihome" means in this mailing list.
> 
> 	the following tries to summarize what we discussed in the past,
> 	in couple of occasions (incl, ipngwg tokyo interim 
> meeting and japan-
> 	local multihome workshop).
> 
> itojun
> 
> 
> who are you?
> - a SLA, or a leaf site (/48)
> - an NLA, or small ISP (/n, where n < 48)
> - a TLA, or big ISP (/16, /29-35 sTLA, or /24-28 pTLA)
> 
> goals of multihoming
> - cope with L2 failures
> - cope with upstream ISP failures
> - load balancing, try to fill up two pipes we have toward upstream
> 	this needs more routing tricks.
> - whatever you name it (but shouldn't dream too much, we need 
> a workable
>   operational solution not a 20-year-to-deploy new protocol)
> 
> backbone aggregation and routing table size
> - RFC2373 and RFC2772 are pretty clear (for me) about 
> aggregation is required
>   when TLA/pTLA/sTLA site propagates their TLA/pTLA/sTLA to 
> the backbone (DFZ).
>   do we want to keep this property (pros: less specific 
> routes  cons: no
>   provider-independent, or TLA-independent address), or do we 
> want to forget
>   about it (pros: IPv4-like "i have provide-independent 
> address and advertise
>   it to both ISP" multihome possible  cons: more specific routes)
> - what is the permissible maximum # of IPv6 routes in DFZ?  
> what is the
>   limiting factor? (memory bound, CPU bound)  how can we 
> enforce the max #?
> 
> for a SLA (/48 leaf site), multihome can be:
> - connect to the same upstream ISP with multiple links
> - connect to different ISPs with multiple links.  it has two 
> axis (not very
>   independent, and there's relationship with backbone aggregation):
>   (1) ISP A and B belong to the same aggregated address block 
> (like the same
>       TLA).
>   (2) ISP A and B belong to different aggregated address 
> block (like the
>       different TLAs).
>   (a) SLA gets single /48 prefix from one of the upstreams 
> (ISP A).  advertise
>       it to both ISP A and B -> how far they will get propagated?
>   (b) SLA gets two /48 prefixes from both of the upstreams 
> (ISP A and B).
>       advertise prefix A to ISP A only, advertise prefix B to 
> ISP B only.
> 
> for an NLA?
> for a SLA which is connected to multihomed NLA?
> for a TLA?
> - TBD
> 
> tools in our hand:
> - DNS
> - RFC2260-like configuration (tunnel, redundant L2 connectivity)
> - multiple address assignment to a site
> - source address selection logic at the end node
> 	note: unlike IPv4, every IPv6 node can handle multiple 
> IP address
> 	assigned to a single interface.
> - GSE-like mechanism?
> - router renumbering protocol
> - IPv6 autoconfiguration, including "deprecated" address handling
> 
> other issues:
> - what happens to established TCP sesssions when ?
> - how an endpoint measure which address is better and which is worse?
>   (need global routing knowledge, or keep monitoring different paths)
>