Subject: requirements draft comments.

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 11 Dec 2001 16:57:59 -0500

I took a look at the requirements draft; section 3.1.3 says in part:

   For example, suppose site E obtains transit from transit providers
   T1 and T2, and there is long-term congestion between T1 and T2.
   The multihoming architecture MUST allow E to ensure that in normal
   operation none of its traffic is carried over the congested
   interconnection T1-T2.  The process by which this is achieved MAY
   be a manual one.

This is very strong (lots of MUSTs, and "none") but is also vague --
what does "in normal operation" mean.. i.e., are transient failures a
"normal" part of internet operation?

"E" is just a customer and so most likely has no control over how T1
and T2 operate their networks; accordingly, "ensure" seems too strong
a word to use..

How quickly must the multihoming system respond to attempts to ensure
separation of traffic?  minutes? hours? days?  is it okay to require
manual intervention from folks at T1 and T2?

section 3.2.3 "impact on hosts":

   It would be compatible with this requirement for such a host to lose
   connectivity if a site lost connectivity to one transit provider,
   despite the fact that other transit provider connections were still
   operational.

I can read this either as allowing loss of connectivity to hosts at
external sites, or as allowing total loss of connectivity, including
to other hosts within the site.  Which was intended?

						- Bill

---

From: Joe Abley <[email-masked]>
Date: Tue, 11 Dec 2001 23:04:58 -0500

> "normal" part of internet operation?

"In normal operation" means "most of the time, when there are no
topological failure conditions". For example, if the circuit between
E and T2 was down, you would expect traffic from T2 to E to traverse
T1. That would not be "normal operation".

> and T2 operate their networks; accordingly, "ensure" seems too strong

In the IPv4 world, E is a customer and has control over the network
policies of T1 and T2 by virtue of that fact. E can be fairly sure
that T1 should prefer routes learnt from E over the same routes
learnt via T2, since there are good reasons to localpref customer
routes above peer routes.

As is commonly used in IPv4 today, so must we provide in IPv6, else
people will attempt to do the IPv4 hacks in v6 and we will not have
changed much.

> manual intervention from folks at T1 and T2?

I think it's ok not to specify that. The fact that the process MAY
be manual should imply that the requirement is for the facility to
be there, rather than the facility to exhibit a constrainted set of
characteristics.

> to other hosts within the site.  Which was intended?

Either or both, I think. But realistically, probably more likely the
former.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Dec 2001 16:26:42 +0100

> On Tue, Dec 11, 2001 at 04:57:59PM -0500, Bill Sommerfeld wrote:
...
> Either or both, I think. But realistically, probably more likely the

I agree (as the original author of these words). I don't think we can set
the bar any higher; the idea is only that legacy hosts can continue to
operate when everything is normal.

  Brian

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 17 Dec 2001 11:39:57 -0800

> This is very strong (lots of MUSTs, and "none") but is also vague --

I agree, the tone is over the top in many places, and very IPv4 centric.
I believe the intent is that the technical approach allow for specific
capabilities, though policy may not. In any case it the full set of
MUSTs are applied to a single site or service provider set, the result
is not operationally viable.

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.

3.1.3 para 3:
   A multi-homed site MUST be able to distribute inbound traffic from
   particular multiple transit providers according to the particular
   address range within their site which is sourcing or sinking the
   traffic.

As I read that every provider MUST accept my *subnet* ranges into their
routing because I as a customer have more control over where my traffic
goes than the service provider does. I suspect the intent was focused on
IPv4 prefix, but it says address range rather than prefix so how should
that be interpreted?

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?

3.1.5
   The current
   multihoming solution is quite straightforward to deploy and maintain.

Absolute BS. If it were simple there would be many more people that
understood it, and the salary range of the routing geeks would be much
lower.

  A new IPv6 multihoming proposal MUST NOT be substantially more
   complex to deploy and operate than current IPv4 multihoming
   practices.

I think everyone would agree with this.

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.

   New transport-layer sessions MUST be able to be created following a
   re-homing event.

This can't be assured if there are filters in the path that only allowed
the original address range through. Does this requirement mandate that
addresses don't change on the host, or is something else like NAT
expected?

   Transport-layer sessions include those involving transport-layer
   protocols such as TCP, UDP and SCTP over IP.  Applications which
   communicate over raw IP and other network-layer protocols MAY also
   enjoy re-homing transparency.

This appears to be mandating mobile-IP since that is the only way to do
this today if the site prefix changes.

3.2.1
   A new IPv6 multihoming architecture MUST scale to accommodate orders
   of magnitude more multi-homed sites without imposing unreasonable
   requirements on the routing system.

What is unreasonable? Is it unreasonable that we don't do garbage
collection on IPv4 allocations because it is too hard to renumber? Is it
unreasonable that we don't allocate for expected growth today, but
historically allocated well beyond what might ever be necessary? Clearly
there is some middle ground between those which would help the problem
today, but this vague comment gives no guidance on what a IPv6 approach
should do. In draft-hain-ipv6-pi-addr-use-01.txt I suggest that 4
prefixes per AS is a managable number which captures ~80% of the
existing ASs, but I am open on the actual number. If we are setting
requirements here, this is one item that should be specified if nothing
more than an upper bound.

3.2.3
   If the solution requires changes to the host stack, these changes
   MUST be either minor, or in the form of logically separate functions
   added to existing functions.

Is it considered minor that a host implementation has the brain-dead bug
of only allowing 001 for global prefixes?

3.2.4
   The solution MAY involve interaction between a site's hosts and its
   routing system; such an interaction MUST be simple, scaleable and
   securable.

As they say, pick any 2 because you can't afford all 3. A better choice
of wording might be: an interaction must address the issues of
simplicity, scalability, and security.

3.2.5
   It MUST be posssible for staff responsible for the operation of a
   site to monitor and configure the site's multihoming system.

Even if they can't configure their external routing today? I assume you
mean it should be no more complex to manage and monitor their
multihoming solution than any existing external routing.

Tony

---

From: Randy Bush <[email-masked]>
Date: Mon, 17 Dec 2001 12:27:09 -0800

> with a global multihoming routing architecture.

this presumes that the architecture does not impose or negotiate outbound
policy at the border between a site and the more global network, and i don't
smell that this wg has made that decision yet.

and, in order for the site to make outbound decisions, the site or its
components which make such decisions need the routing information on which
to base such decisions, even using christian's ping as a routing protocol.

randy

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 17 Dec 2001 12:42:23 -0800

> smell that this wg has made that decision yet.
If the group wants to invent policy negotiation protocols, they will be
explicitly breaking the requirement in 3.1.5 to make sure the solution
is no more complex than today. Even if the protocol were simple, the ops
staff would not be up to the task of interpreting the dynamic results.

> to base such decisions, even using christian's ping as a
Using the example I sent before; SiteB has a policy based on cost that
if the interface to ISPd is up, default all outbound traffic there. What
routing information does SiteB need beyond the first hop?

Tony

---

From: Randy Bush <[email-masked]>
Date: Mon, 17 Dec 2001 12:54:14 -0800

>> policy at the border between a site and the more global network, and i
>> don't smell that this wg has made that decision yet.
> is no more complex than today.

i guess you have not been tracking drafts in the idr wg

>> components which make such decisions need the routing information on
>> which to base such decisions, even using christian's ping as a routing
>> protocol.
> if the interface to ISPd is up, default all outbound traffic there. 

for a non-trivial but useful set of folk, ISPd may not be able to take
traffic to all destinations.  there are significant sites which peer with a
few folk and buy transit from others.  sometimes they both peer and transit
another network, with separate contracts and maybe separate connections.

randy

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 17 Dec 2001 13:03:24 -0800

> i guess you have not been tracking drafts in the idr wg
There are only so many hours in a day.

> another network, with separate contracts and maybe separate
I was not trying to imply that more complex interconnects are out of
scope, but that the requirements of the words in the current draft can't
be met by the simple case when a site simply defaults to one provider
when the connection is up. Either the wording needs to be softened to
SHOULD, or the default case should be explicitly addressed.

Tony

---

From: Randy Bush <[email-masked]>
Date: Mon, 17 Dec 2001 13:11:42 -0800

> There are only so many hours in a day.

new stuff where filtering policy can be pushed, not that i like it

> SHOULD, or the default case should be explicitly addressed.

i thought the base case was load balanced, or at least load distributed

randy