[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