Re: comments on requirements draft

[Joe Abley <jabley@nlri.org>]

Hi Steve,

Thanks for your comments! A couple of small comments on a couple of
them to start off with:

On Mon, Aug 06, 2001 at 01:27:59PM -0700, Steve Deering wrote:
> >   An "enterprise" is an entity autonomously operating a network using
> >   TCP/IP and, in particular, determining the addressing plan and
> >   address assignments within that network.  This is the definition of
> >   "enterprise" used in [3].
> 
> I wonder why "TCP/IP" and not just "IP"?  Must an enterprise use TCP?

The origin of this (surprisingly contentious!) paragraph is an idea
that was put forward in response to -00, which was that since
"enterprise" was already defined in an existing document (RFC1918),
it might be nice to re-use the definition.

The definiton as shown is that included in RFC1918, and that is where
the reference to "TCP" comes from.

I agree with the point you are making, particularly as people will be
reading this draft with transport-layer solutions in mind; I just wanted
to explain why "TCP" featured in that paragraph.

> >3.1.3 Performance
> >
> >   By multihoming, an enterprise should be able to protect itself from
> >   performance difficulties between transit providers.
> >
> >   For example, suppose enterprise E obtains transit from transit
> >   providers T1 and T2, and there is long-term congestion between T1 and
> >   T2.  The multihoming architecture should allow E to ensure that in
> >   normal operation none of its traffic is carried over the congested
> >   interconnection T1-T2.
> 
> How is the capability offered in the current multihoming approach,
> given that BGP is not sensitive to congestion, short-term or long-term?

That capability is provided by the fact that T[i] will apply a higher
local preference to the prefixes operated by E that they learn directly
from E, rather than those they learn from T[3-i]. That means in normal
operation, traffic from T[i] destined for E will never be routed
towards T[3-i].

> >   A multi-homed enterprise must also be able to distribute inbound
> >   traffic particular multiple transit providers according to the
>            ^
>            from
> 
> >   particular network within their enterprise which is sourcing or
> >   sinking the traffic.
> 
> How can a network within the enterprise source inbound traffic to that
> enterprise via a particular transit provider?

"network" here refers to a prefix; an enterprise may advertise more
than one prefix to its transit providers. By advertising a particular
prefix in different ways to different transit providers (e.g. path
prepending, setting provider-specific community strings), the enterprise
and change the way in which inbound traffic to that prefix is handled.

We were trying to avoid terms with routing connotations in the reqs
draft, and unfortunately that has introduced some ambiguity. We
certainly need to make sure we define our terms rigourously.

> This Performance section needs more elaboration and clarification.


> >3.1.4 Policy
> >
> >   A customer may choose to multihome for a variety of policy reasons
> >   outside technical scope (e.g.  cost, acceptable use conditions, etc.)
>            ^
>            the?

Mmm. I don't think so -- perhaps s/outside/beyond/ ?

> >   For example, customer C homed to ISP A may wish to shift traffic of a
> >   certain class or application, NNTP, for example, to ISP B as matter
> >   of policy.  A new IPv6 multihoming proposal must provide support for
> >   multihoming for external policy reasons.
> 
> Inbound only?

Sure.

> Outbound only?

Sure.

> Both?

Sure.

> This requirement seems excessive
> to me, e.g., if end systems ESP encrypt their traffic, how can the
> network recognize NNTP traffic?

In current practice, this can be achieved so long as the traffic
shifting is accommodated at the IP layer -- i.e. stick all your news
servers on one subnet, and advertise that subnet in different ways.

This is done in the real world, horrible though it may seem. A common
example is in far-flung networks where under-sea cable is expensive,
rare and low-latency, and satellite circuits are cheaper, more readily
available and high-latency. Shifting non-interactive traffic such
as mail and news onto satellite circuits is good for business. If
we can't accommodate this kind of thing, there are lots of operators
in (apparently) the fastest-growing parts of the network who will not
be very happy.

> >3.2.2 Impact on Routers
> >
> >   The solution may require changes to IPv6 router implementations, but
> >   these changes must be either minor, or in the form of logically
> >   separate functions added to existing functions.
> 
> This is a surprising requirement -- can you elaborate?

That's Brian's paragraph -- perhaps he can comment on it?

> >   The multi-homing solution should allow host or application changes to
> >   enhance session survivability.
> 
> s/to enhance/if that would enhance/

s/if // :)

> >3.2.5 Operations and Management
> >
> >   It must be posssible to monitor and configure the multihoming system.
> 
> Possible for whom?

Possible for the operator of the multi-homed enterprise. I think I'm
not seeing the ambiguity -- who else could that be read as referring
to?

> >4. Security Considerations
> >
> >   Multihoming no doubt offers some attractive opportunites for denial
> >   of service and spoofing attacks.  Multihomed sites must be protected
> >   against such attacks at least as well as single-homed sites.
> 
> I.e., not at all?

I have also been harbouring some doubts about that paragraph. I'm glad
I'm not alone :)


Joe