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

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

Sean, all good points. I'm not sure I would change the requirements at all,
or that there is anything very evil here; but unexpected side effects
are always worth noting.

   Brian

Sean Doran wrote:
> 
> 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.