Re: requirements draft comments.

[Joe Abley <jabley@nlri.org>]

On Tue, Dec 11, 2001 at 04:57:59PM -0500, Bill Sommerfeld wrote:
> 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?

"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".

> "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..

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.

> 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?

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.

> 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?

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


Joe