[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

comments on the requirements draft



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:

>  A new IPv6 multihoming architecture MUST scale to accommodate orders
>    of magnitude more multi-homed sites without imposing unreasonable
>    requirements on the routing system.

This is redundant.

Sections 3.2.2 and 3.2.3 presume a real installed base.  There is none.

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.

Good luck,

Eliot