(multi6) requirements draft comments

["Michel Py" <michel@arneill-py.sacramento.ca.us>]

Multi6 folk,

I guess this counts towards the WG last call....

Tony Hain wrote
>> 3.1.2
>>   By multihoming, a site MUST be able to distribute both inbound and
>>   outbound traffic between multiple transit providers.  This
>>   requirement is for concurrent use of the multiple transit
providers,
>>   not just the usage of one provider over one interval of time and
>>   another provider over a different interval.
>> The outbound case is local policy within the site, and has nothing to

>> do with a global multihoming routing architecture. For the inbound 
>> case, a site only has as much control as their policy aligns with the

>> remote site. For example: SiteA and SiteB are each attached to both 
>> ISPc and ISPd. It is SiteA's policy to direct inbound traffic through

>> ISPc, but it is SiteB's policy to send everything to ISPd, and ISPd's

>> policy to deliver bits over the direct connection rather than through

>> another ISP. Since the holder of the traffic wins, there is no way a 
>> multihoming technology can assure that SiteA will achieve the MUST 
>> written here.

I think that the original intend of 3.1.2 for inbound was to prevent
flaky destination address selection schemes such as round-robin. The way
I read it is that, if a multihomed site as multiple PA addresses but no
PI address, the address selection algorithm to pick which of the PA
address is to be used must pick the best one for a specific source,
which probably means that the address selection must know about the
network topology, which means either a hook into BGP or some other
sophisticated mechanism yet to be defined.

>> 3.1.4
>>    A new IPv6 multihoming proposal MUST provide support for
>>    site-multihoming for external policy reasons.
>> This is vague. The example is focused on applications that use a well

>> known port, but the requirement does not say that route policy be 
>> based on ports. Doing so would clearly be broken, and since people do

>> this by selecting address ranges for those applications today, why is

>> an IPv6 solution expected to be any different?

This is vague indeed and I would not mind dropping 3.1.4 although it
does not bother me.


>> 3.1.6
>>   Multihoming solutions MUST provide re-homing transparency for
>>   transport-layer sessions; i.e.  exchange of data between devices on
>>   the multihomed site and devices elsewhere on the Internet may
proceed
>>   with no greater interruption than that associated with the
transient
>>   packet loss during the re-homing event.
>> This appears to be requiring provider independence, since that is the

>> only way to do this today.

There might be other ways (TCP hacks/stack hacks), but the PI address
being the one that is configured on the hosts is the only proven one.
Note that the PI address could (although I do not recommend it) be a
site-local address with NAT.


>> 3.2.6 Cooperation between Transit Providers
>>   A multihoming strategy MAY require cooperation between a site and
its
>>   transit providers, but MUST NOT require cooperation directly
between
>>   the transit providers.

I propose to change this (from an idea originally suggested by Pekka
Savola) to:

3.2.6 Cooperation between Transit Providers
   A multihoming strategy MAY require cooperation between a site and its
|  transit providers, but MUST NOT require SITE-SPECIFIC cooperation
   directly between the transit providers.


Michel.