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

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

While I believe this document still assumes too much in terms of
affecting policy outside the domain of direct administrative control, I
have to agree it is time to ship it. There is one comment about the IESG
in 3.2.7 that simply doesn't belong in any I-D, so I wouldn't be
surprised when the IESG asks to have it changed or removed. If the words
'within the IESG' were removed, the sentence would stand and makes much
more sense than worrying about IETF process in a mechanism requirements
doc.

Tony


> -----Original Message-----
> From: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]On
> Behalf Of Brian E Carpenter
> Sent: Wednesday, June 26, 2002 9:19 AM
> To: Sean Doran
> Cc: multi6@ops.ietf.org
> Subject: Re: draft-ietf-multi6-multihoming-requirements-03
>
>
> 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.
>