[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Requirement document last call (let's focus!)
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