Subject: (multi6) requirements draft comments

From: "Michel Py" <[email-masked]>
Date: Mon, 17 Dec 2001 18:18:06 -0800

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Dec 2001 09:26:09 +0100

Michel Py wrote:
...
> This is vague indeed and I would not mind dropping 3.1.4 although it

I think it needs to stay in, but the phrase "or application, NNTP, for example, "
should be deleted. That would leave the "example" sentence as
   For example, customer C homed to ISP A may wish to shift traffic of a
   certain class to ISP B as matter of policy.  
which is necessary and sufficient IMHO.

We could refine it further by saying "shift outgoing traffic" to make it
clear that this is not policy based routing.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Dec 2001 09:34:18 +0100

Michel Py wrote:
...
> being the one that is configured on the hosts is the only proven one.

Shame we don't have a PI solution that we actually know how to deploy
and route at large scale.

This requirement could lead to several other conclusions than PI:
- need for an address-agile TCP
- need for universal use of SCTP
- need for 8+8

If it wasn't for the existence of these options as well as the illusory
PI, I would recommend simply removing requirement 3.1.6 as unrealistic.

  Brian

---

From: Joe Abley <[email-masked]>
Date: Tue, 18 Dec 2001 08:30:10 -0500

On Tue, Dec 18, 2001 at 09:26:09AM +0100, Brian E Carpenter wrote:
> > [...]

This sounds good to me.

---

From: Randy Bush <[email-masked]>
Date: Tue, 18 Dec 2001 07:07:14 -0800

> and route at large scale.

like democracy, it sucks, but less than any other way we actually have.

> the illusory PI

sadly, so far, it is the only non-illusory approach.  it is actually
deployed and being widely used, as opposed to, for example, using per-host
ping as a routing protocol.

no, we don't like it.  but, though we have fears/worries, we don't have
solid research/measurements about its actual scalability.  and far worse,
we have no alternatives which are on any platform other then powerpoint.

randy