Subject: Re: Requirement document last call (let's focus!)

From: Eliot Lear <[email-masked]>
Date: Thu, 03 Jan 2002 11:45:55 -0800

At 09:01 AM 1/3/2002 -0800, Christian Huitema wrote:
>Do you agree that this is a fair summary of the discussion on the 
>requirements draft? I yes, we should maybe have a short editing pass, and 
>then proceed towards publication of the requirements and rechartering of 
>this group.

As I previously wrote:

Section 3.1.3 Performance:

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

Why are we adding the caveat of the last sentence?  Manual anything is bad.

In section 3.2.1:

Section 3.2.5 also sounds either redundant or unworkable.  If what you mean 
is that you must be able to retrieve routing information from a router, 
then fine.  If what you mean is that administrators should be able to 
remotely manage and monitor end systems for purposes of multihoming, that's 
a whole other kettle of fish.

Section 4  Security Considerations

This seems overly broad.  I think what you mean is the following:

    It MUST be theoretically possible to deploy a multihomed site that
    is no less secure than a single-homed site.

Anytime a routing protocol is involved there are bound to be more sensitive 
points of attack (like DDOS, for instance).  Just like anything else, 
multihoming can be done poorly.

Eliot

---

From: Vijay Gill <[email-masked]>
Date: Thu, 3 Jan 2002 14:59:00 -0500

> Why are we adding the caveat of the last sentence?  Manual anything is bad.

Unfortunately, while we may like to say manual anything is bad, there
always will be circumstances where some tweaking will have to be done.
There are just no getting around that fact.

>     is no less secure than a single-homed site.

I'm fine with this.

/vijay

---

From: Eliot Lear <[email-masked]>
Date: Thu, 03 Jan 2002 12:44:09 -0800

>There are just no getting around that fact.

In today's world, if both sides announce an aggregation and not a specific 
route for E, this will happen.  But if the problem is congestion, that is 
solved with more bandwidth and or less customers (i.e., letting the market 
decide).  Why does this need to be written into a requirements document?

Or maybe I misunderstand the point you are making.  What are you thinking 
of that needs to be manual?  Is it the coordinated injection of a specific 
during congestion?

Eliot

---

From: Vijay Gill <[email-masked]>
Date: Thu, 3 Jan 2002 17:00:39 -0500

> decide).  Why does this need to be written into a requirements document?

This doesn't need to be in a requirements document, but the option for
E to manually decide what links to dump traffic over should not be
precluded. There are many games being played in networks that I'm
operating right now that rely on some of these sort of tricks.

> of that needs to be manual?  Is it the coordinated injection of a specific

See above. I hope I'm not misunderstanding something here.

/vijay