[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