Re: draft-ietf-multi6-multihoming-requirements-03

[smd@ab.use.net (Sean Doran)]

Brian Carpenter writes:

| In fact you made me think of one possible unexpected consequence. If we allow
| diffserv code points to influence multihoming policy, it would be possible for
| someone who thought they were setting QOS policy to accidentally influence
| multihoming policy. That's not a very welcome side effect, but it may be 
| inevitable.

How should this be reflected within the multi6 reqs document (if at all)?

Should one do anything about the doors separating IPv6-global-unicast-format
from extensions of various flavours, including encoding destination information
in places other than strictly the destination address?

In particular, there is an obvious *MAY* requirement looming in this
discussion, and I'm glad it originated with someone other than me. -:)

	Sean.

P.S.: in whose opinion is it unwelcome?  isn't this is a shade of grey?
      consider:

                source
                  |
		  .
		  .
		  |
                upstream
                /     \
       transit-l       transit-r
                \     /
                 dest.

"dest." would like to have inbound traffic through upstream choose
between transit-l and transit-r based on the DSCP rather than on
strictly the destination address.   is this something evil that MUST
not be allowed, something gross that SHOULD NOT be done in practise,
or something the parties themselves should negotiate on their own?
what if transit-l is low-bandwidth/low-delay and transit-r is
high-bandwidth/high-delay?   "dest." might be a national research 
network with a number of universities connected, each with people
wanting to receive all sorts of traffic from elsewhere in the
Internet, some of it bulk transfer (post-napster?) and some of it
delay-sensitive (sshing back home from an IETF meeting?).

the argument in the past has been that since there is no dynamic
routing protocol currently supporting upstream's left-or-right
decision in the event of failure along either path towards dest,
this would best be addressed (ahem), if at all, in someplace like IDR,
or perhaps wherever one puts interdomain MPLS routing support.

on the other hand, in the earlier days of the PRDB, one could also
have observed the evolution of systems to allow the selection of
exit ENSSes towards a particular destination and conclude that they
could easily have wound up supporting exactly this sort of thing.
indeed, some old people around here recall *several* ad hoc methods
of supporting *exactly* this kind of multihoming in the distant past.

i'm sure our requirements draft editor is open to suggestions for new text,
if anyone cares to make one.