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

From: [email-masked] (Sean Doran)
Date: Wed, 26 Jun 2002 13:33:35 +0000 (GMT)

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Jun 2002 18:19:20 +0200

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

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 26 Jun 2002 12:29:45 -0700

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: [email-masked] [mailto:[email-masked]]On
> Behalf Of Brian E Carpenter
> Sent: Wednesday, June 26, 2002 9:19 AM
> To: Sean Doran
> Cc: [email-masked]
> Subject: Re: draft-ietf-multi6-multihoming-requirements-03
>
>

---

From: Joe Abley <[email-masked]>
Date: Wed, 26 Jun 2002 16:00:02 -0400

> more sense than worrying about IETF process in a mechanism requirements

I have made that change in my working copy.

Joe

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 27 Jun 2002 00:08:09 +0200 (CEST)

On Wed, 26 Jun 2002, Sean Doran wrote:

I don't think this will be much of a problem in practice. If traffic
reaching the "multihomer/load balancer" doesn't have a code point yet, the
multihomer will have to set in order to achieve load balancing. For
instance, if there is an OC3 low delay circuit and an OC12 high delay
circuit, it may set the a code point that has the effect the OC3 circuit
is selected for 20% of all packets, and another code point that has the
effect the OC12 circuit is selected for the remaining 80% of all packets.

If a packet already has a diffserv code point asking for a certain phb,
the multihomer can do two things:

1. grant the request and forward and leave the code point alone (or
   translate it into another to achieve the desired effect)
2. refuse the request and overwrite the code point

Always doing 1 frustrates load balancing, and always doing 2 frustrates
the application. Some adaptability is needed here.

For instance, if 10% of the traffic asks for a "low delay" service, the
multihomer/load balancer will simply select the OC3 code point for 11% of
the remaining traffic, so 20% of the traffic (10% by request, 10% randomly
selected to balance the load) goes over the OC3 and the rest over the OC12
circuit.

And what happens when the OC3 line goes down? Simple: the device that
previously forwarded packets over either the OC3 or OC12 circuit should be
smart enough to not forward data over a broken circuit, so now all traffic
flows over the OC12 circuit, disregarding the traffic classification
efforts of both the source and the multihoming/load balancing device.

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

Is there anything to be required?

I earn part of my living by telling people how to multihome. They are
willing to part with a decent sum of money for this advice. The same isn't
true for differentiated services: end users don't care. So I don't think
diffserv problems should be show stopper for multihoming. And anything
that isn't a show stopper shouldn't be in a requirements document. (Sure,
we can make it a "nice to have" document...)

> in places other than strictly the destination address?

Do we really want NAT in v6?

>                  dest.

Isn't this a bit oversimplified? This assumes there is a single place
where all decisions can be taken. If this is true, then we haven't
achieved full multihoming (there is still a single point of failure.) In
reality, things will look more like:

       Source
       /    \
      A      B
     / \    / \
    C   D--E   F
     \ /    \ /
      G      H
       \    /
     Destination

Since selecting the link over AS H to the destination rather than the link
over AS G means (potentially) influencing the routing decisions made in A,
B, and E (and of course the source), this goes directly against the
current distance path routing and hop-by-hop forwarding paradigms.
However, IDPR should be able to handle this quite nicely.

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 26 Jun 2002 17:27:56 -0700

Iljitsch van Beijnum wrote:
>  ...

And perpetuating the idea that Dest has any influence on routing beyond
G & H where it is paying for service, amounts to a fraud on the scale of
the current accounting scandals. If Src prefers A who in turn chooses to
prefer C, there is nothing Dest can do to change that. Any requirement
that states one AS MUST be able to affect the policy of another AS will
simply be ignored, if not by the implementations, certainly by the
target AS where the policy is attempting to be overridden.

> However, IDPR should be able to handle this quite nicely.

To be seen.

---

From: Tim Chown <[email-masked]>
Date: Thu, 27 Jun 2002 11:41:55 +0100 (BST)

> effect the OC12 circuit is selected for the remaining 80% of all packets.

I assume from this discussion that there is little hope that schemes
such as Scavenger (less than best effort) will become widely used outside
of the academic research networks?  Such schemes have the attraction that
there is no deployment effort required per se except that DSCP values
should be passed unaltered if the intervening network does not utilise
the DSCP (which is not uncommon where currently the academic backbone
networks are not congested, but the MANs and edges are).  I see no reason
why IPv6 and LBE couldn't be used together, but an IPv6 multihoming model
based on DSCPs would break this.  What's the current stance on global
significance of DSCP values (in this instance, Scavenger uses DSCP 8, a
value adopted by US and European research networks).
 
Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Jun 2002 13:49:37 +0200

Tim Chown wrote:
...
> What's the current stance on global

Exactly what it's always been. They are locally mappable in every domain.
This isn't going to change, but it doesn't prevent a RECOMMENDED value if
the scavenger PHB or one of its relatives gets standardised.

There's nothing special about the scavenger PHB in this respect. The same
issue of mapping at domain boundaries arises for any DSCP. Let's not
have that particular flamefest here. The diffserv-interest list is the
place for that.

   brian