Re: comments on requirements draft

[Brian E Carpenter <brian@hursley.ibm.com>]

Steve,

Cherry-picking among your comments:

...
> >3.1.4 Policy
> >
> >   A customer may choose to multihome for a variety of policy reasons
> >   outside technical scope (e.g.  cost, acceptable use conditions, etc.)
>            ^
>            the?
> 
> >   For example, customer C homed to ISP A may wish to shift traffic of a
> >   certain class or application, NNTP, for example, to ISP B as matter
> >   of policy.  A new IPv6 multihoming proposal must provide support for
> >   multihoming for external policy reasons.
> 
> Inbound only?  Outbound only?  Both?  This requirement seems excessive
> to me, e.g., if end systems ESP encrypt their traffic, how can the
> network recognize NNTP traffic?

Joe Abley already responded and I agree with him. Like any traffic classification
policy, this one would have restricted applicability in the case of ESP traffic.
In fact the issues are essentially if not totally identical to those for
diffserv classification. If you can't classify for diffserv reasons, you
can't classify for multi6 reasons either and default policy will apply. There
is nothing special here - multi6 is simply added to the list of modules
that look at policy (i.e. a local config table) as part of their decision
process.

...
> 
> >3.2.2 Impact on Routers
> >
> >   The solution may require changes to IPv6 router implementations, but
> >   these changes must be either minor, or in the form of logically
> >   separate functions added to existing functions.
> 
> This is a surprising requirement -- can you elaborate?  

You work for a router company so you tell us :-)

The intention is to *require* a solution that does not cause router
vendors to need to throw away their IPv6 routing engines and start again.
IMHO such a solution would have no chance of getting implemented
across all routers, and therefore is not something the IETF can endorse.

> Also, the
> nature and degree of acceptable change would presumably depend on
> whether or not the change was required in the data plane (already being
> cast in hardware for IPv6 on some routers) or the control plane
> (still in software), and perhaps also on how many routers would have
> to change, e.g., all routers vs. backbone routers vs. edge routers vs.
> enterprise routers.

Indeed. Of course not all hardware architectures are so rigid that
the data plane is carved in the silicon. 
> 
> >3.2.3 Impact on Hosts
> >
> >   The solution must not destroy IPv6 connectivity for a legacy host
> >   implementing RFC 2373 [5], RFC 2460 [7], RFC 2553 [8] and other basic
> >   IPv6 specifications current in June 2001.  That is to say, if a host
> >   can work in a single-homed site, it must still be able to work in a
> >   multihomed site, even if it cannot benefit from multihoming.
> >
> >   It would be compatible with this requirement for such a host to lose
> >   connectivity if the site's primary ISP connection failed.
> 
> Is the assumption that there's a "primary" ISP always valid?

In the sense of providing backwards compatibility, for pre-multi6
hosts, I think it is (even if it is an arbitrary choice among the
site's ISPs). 

> 
> What about newly-established sessions?

You mean can a pre-multi6 host switch to a backup ISP for new sessions? 
I intended *not* to require that, since that would require today's 
(BGP-expensive) solution still to be in place. Thus in this respect the 
pre-multi6 host gets *worse* service from multi6, and there's the incentive 
to upgrade it.

> 
> >   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.
> 
> This needs more elaboration.

As for routers, the intention is to *not* require stack rewrites, which I can
tell you are very unlikely to happen. Multi6 needs to be an add-on. I don't know 
how to say it more clearly.
...
> >4. Security Considerations
> >
> >   Multihoming no doubt offers some attractive opportunites for denial
> >   of service and spoofing attacks.  Multihomed sites must be protected
> >   against such attacks at least as well as single-homed sites.
> 
> I.e., not at all?

:-)

Well, you write a better security section!

   Brian