RE: requirements draft comments.

["Tony Hain" <alh-ietf@tndh.net>]

Bill Sommerfeld wrote:
> This is very strong (lots of MUSTs, and "none") but is also vague --

I agree, the tone is over the top in many places, and very IPv4 centric.
I believe the intent is that the technical approach allow for specific
capabilities, though policy may not. In any case it the full set of
MUSTs are applied to a single site or service provider set, the result
is not operationally viable.

3.1.2
   By multihoming, a site MUST be able to distribute both inbound and
   outbound traffic between multiple transit providers.  This
   requirement is for concurrent use of the multiple transit providers,
   not just the usage of one provider over one interval of time and
   another provider over a different interval.

The outbound case is local policy within the site, and has nothing to do
with a global multihoming routing architecture. For the inbound case, a
site only has as much control as their policy aligns with the remote
site. For example: SiteA and SiteB are each attached to both ISPc and
ISPd. It is SiteA's policy to direct inbound traffic through ISPc, but
it is SiteB's policy to send everything to ISPd, and ISPd's policy to
deliver bits over the direct connection rather than through another ISP.
Since the holder of the traffic wins, there is no way a multihoming
technology can assure that SiteA will achieve the MUST written here.


3.1.3 para 3:
   A multi-homed site MUST be able to distribute inbound traffic from
   particular multiple transit providers according to the particular
   address range within their site which is sourcing or sinking the
   traffic.

As I read that every provider MUST accept my *subnet* ranges into their
routing because I as a customer have more control over where my traffic
goes than the service provider does. I suspect the intent was focused on
IPv4 prefix, but it says address range rather than prefix so how should
that be interpreted?


3.1.4
   A new IPv6 multihoming proposal MUST provide support for
   site-multihoming for external policy reasons.

This is vague. The example is focused on applications that use a well
known port, but the requirement does not say that route policy be based
on ports. Doing so would clearly be broken, and since people do this by
selecting address ranges for those applications today, why is an IPv6
solution expected to be any different?


3.1.5
   The current
   multihoming solution is quite straightforward to deploy and maintain.

Absolute BS. If it were simple there would be many more people that
understood it, and the salary range of the routing geeks would be much
lower.

  A new IPv6 multihoming proposal MUST NOT be substantially more
   complex to deploy and operate than current IPv4 multihoming
   practices.

I think everyone would agree with this.


3.1.6
   Multihoming solutions MUST provide re-homing transparency for
   transport-layer sessions; i.e.  exchange of data between devices on
   the multihomed site and devices elsewhere on the Internet may proceed
   with no greater interruption than that associated with the transient
   packet loss during the re-homing event.

This appears to be requiring provider independence, since that is the
only way to do this today.

   New transport-layer sessions MUST be able to be created following a
   re-homing event.

This can't be assured if there are filters in the path that only allowed
the original address range through. Does this requirement mandate that
addresses don't change on the host, or is something else like NAT
expected?

   Transport-layer sessions include those involving transport-layer
   protocols such as TCP, UDP and SCTP over IP.  Applications which
   communicate over raw IP and other network-layer protocols MAY also
   enjoy re-homing transparency.

This appears to be mandating mobile-IP since that is the only way to do
this today if the site prefix changes.


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.

What is unreasonable? Is it unreasonable that we don't do garbage
collection on IPv4 allocations because it is too hard to renumber? Is it
unreasonable that we don't allocate for expected growth today, but
historically allocated well beyond what might ever be necessary? Clearly
there is some middle ground between those which would help the problem
today, but this vague comment gives no guidance on what a IPv6 approach
should do. In draft-hain-ipv6-pi-addr-use-01.txt I suggest that 4
prefixes per AS is a managable number which captures ~80% of the
existing ASs, but I am open on the actual number. If we are setting
requirements here, this is one item that should be specified if nothing
more than an upper bound.


3.2.3
   If the solution requires changes to the host stack, these changes
   MUST be either minor, or in the form of logically separate functions
   added to existing functions.

Is it considered minor that a host implementation has the brain-dead bug
of only allowing 001 for global prefixes?


3.2.4
   The solution MAY involve interaction between a site's hosts and its
   routing system; such an interaction MUST be simple, scaleable and
   securable.

As they say, pick any 2 because you can't afford all 3. A better choice
of wording might be: an interaction must address the issues of
simplicity, scalability, and security.


3.2.5
   It MUST be posssible for staff responsible for the operation of a
   site to monitor and configure the site's multihoming system.

Even if they can't configure their external routing today? I assume you
mean it should be no more complex to manage and monitor their
multihoming solution than any existing external routing.



Tony