Site Multihoming in IPv6 (multi6)

Iljitsch van Beijnum | 1 Jul 20:04

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

On Mon, 1 Jul 2002, Joe Abley wrote:

> >> 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.

> Does anybody have any other proposed changes to this document, or should
> I roll a -04 with that change only, ready for wg last call?

There seems to be a discrepancy between the requirements listed in the
draft and the fact that everyone assumes there won't be a solution that
can meet all of them. I'm afraid this opens up the possibility of problems
down the road when people can easily dismiss otherwise promising
multihoming solutions by pointing out it doesn't meet one or more
requirements.

Some text indicating which requirements are absolutely essential and which
are also important, but can be dropped if there aren't any multihoming
solutions that satisfy them would be good, I think.

On the other hand: I certainly don't want to slow down the whole process.

Iljitsch van Beijnum

Joe Abley | 1 Jul 20:05

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


On Monday, July 1, 2002, at 02:04 , Iljitsch van Beijnum wrote:

> Some text indicating which requirements are absolutely essential and 
> which
> are also important, but can be dropped if there aren't any multihoming
> solutions that satisfy them would be good, I think.

Do you have such text to incorporate?

> On the other hand: I certainly don't want to slow down the whole 
> process.

Joe

Iljitsch van Beijnum | 1 Jul 23:40

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

On Mon, 1 Jul 2002, Joe Abley wrote:

> > Some text indicating which requirements are absolutely essential and
> > which
> > are also important, but can be dropped if there aren't any multihoming
> > solutions that satisfy them would be good, I think.

> Do you have such text to incorporate?

3.1 Capabilities of IPv4 Multihoming

   The following capabilities of current IPv4 multihoming practices MUST
   be supported by an IPv6 multihoming architecture.  IPv4 multihoming
   is discussed in more detail in [1].

Would be replaced by:

3.1 Capabilities of IPv4 Multihoming

   The following capabilities of current IPv4 multihoming practices MUST
   be supported by an IPv6 multihoming architecture to a similar level as
   current IPv4 multihoming does. None of them is optional, but they can
   be omitted or only partially supported if an architecture supporting
   the capability to at least current IPv4 levels is unfeasible or
   doesn't meet the additional requirements listed in section 3.2.

   IPv4 multihoming is discussed in more detail in [1].

Then there is:

(Continue reading)

Brian E Carpenter | 2 Jul 10:31

Picon

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

Iljitsch van Beijnum wrote:
> 
> On Mon, 1 Jul 2002, Joe Abley wrote:
> 
> > > Some text indicating which requirements are absolutely essential and
> > > which
> > > are also important, but can be dropped if there aren't any multihoming
> > > solutions that satisfy them would be good, I think.
> 
> > Do you have such text to incorporate?
> 
> 3.1 Capabilities of IPv4 Multihoming
> 
>    The following capabilities of current IPv4 multihoming practices MUST
>    be supported by an IPv6 multihoming architecture.  IPv4 multihoming
>    is discussed in more detail in [1].
> 
> Would be replaced by:
> 
> 3.1 Capabilities of IPv4 Multihoming
> 
>    The following capabilities of current IPv4 multihoming practices MUST
>    be supported by an IPv6 multihoming architecture to a similar level as
>    current IPv4 multihoming does. None of them is optional, but they can
>    be omitted or only partially supported if an architecture supporting
>    the capability to at least current IPv4 levels is unfeasible or
>    doesn't meet the additional requirements listed in section 3.2.
> 
>    IPv4 multihoming is discussed in more detail in [1].

(Continue reading)

Iljitsch van Beijnum | 2 Jul 15:18

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

On Tue, 2 Jul 2002, Brian E Carpenter wrote:

> I wonder why we are using MUST (upper case) terminology in any case.

Don't ask me, I think there are too many caps in the world anyway.

> Also "None of them is optional,
> but they can be omitted..." makes my head hurt.

It was the best I could come up with. It's your turn now.  

> Why not just change the
> language in the whole document to must/should (lower case)?

I'm all for that. But that doesn't mean the sentence above can be omitted.

> > I don't think this is the intention, but it _can_ be read as if IPv4
> > multihoming has the capability to direct traffic for certain applications
> > over one link and traffic for other applications over another link. Since
> > this is certainly not the case, at least the example should go, possibly
> > the whole thing. (Does it require anything useful anyway?)

> Yes. Today this sort of policy is generally implemented by fiddling with
> DNS entries and addresses. Maybe we can do better for IPv6 if we think about
> it.  The example is a valid *requirement* but it should be cited
> in the IPv6 context.

I am currently multihomed in IPv6 (you have to practive what you preach)
by having two tunnels, each with address space associated with them. I am
only allowed to send out packets with source addresses A over tunnel A,

(Continue reading)

Joe Abley | 2 Jul 05:27

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


On Monday, July 1, 2002, at 05:40 , Iljitsch van Beijnum wrote:

> Then there is:
>
> 3.1.4 Policy
>
>    A customer may choose to multihome for a variety of policy reasons
>    beyond technical scope (e.g.  cost, acceptable use conditions, etc.)
>    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
>    site-multihoming for external policy reasons.
>
> I don't think this is the intention, but it _can_ be read as if IPv4
> multihoming has the capability to direct traffic for certain 
> applications
> over one link and traffic for other applications over another link. 
> Since
> this is certainly not the case, at least the example should go, possibly
> the whole thing. (Does it require anything useful anyway?)

The example I have used for this before concerns people who operate 
networks in places where satellite communications are substantially 
cheaper than terrestrial communications (this is most of the planet, by 
area).

It is common practice to number news, mail, and HTTP proxy servers 
(tuned for retrieval of objects over satellite-like latencies) within 
subnets which can be advertised such that inbound traffic from the rest

(Continue reading)

Iljitsch van Beijnum | 2 Jul 15:08

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

On Mon, 1 Jul 2002, Joe Abley wrote:

> The example I have used for this before concerns people who operate
> networks in places where satellite communications are substantially
> cheaper than terrestrial communications (this is most of the planet, by
> area).

> It is common practice to number news, mail, and HTTP proxy servers
> (tuned for retrieval of objects over satellite-like latencies) within
> subnets which can be advertised such that inbound traffic from the rest
> of the world arrives on those servers via a satellite link, whereas all
> other traffic (including traffic directly aimed at subscriber addresses)
> arrives via terrestrial fibre.

Ok, nothing wrong with that. But BGP doesn't provide any functionality to
really help with this. Since it can be done now without help from BGP,
there is no reason an IPv6 solution should specifically cater to this
need. Just not getting in the way of more specific routes or policy
routing should be enough.

> I think the basic requirement should stay. I am not married to the words
> currently in 3.1.4, however, so if you have better ones I'd be glad to
> hear them.

"Existing IPv4 multihoming practices can coexist with policy-based routing
and forwarding mechanisms. An IPv6 multihoming architecture should
retain this capability."

Joe Abley | 2 Jul 17:27

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

On Tuesday, July 2, 2002, at 09:08 , Iljitsch van Beijnum wrote:

> On Mon, 1 Jul 2002, Joe Abley wrote:
>
>> It is common practice to number news, mail, and HTTP proxy servers
>> (tuned for retrieval of objects over satellite-like latencies) within
>> subnets which can be advertised such that inbound traffic from the rest
>> of the world arrives on those servers via a satellite link, whereas all
>> other traffic (including traffic directly aimed at subscriber 
>> addresses)
>> arrives via terrestrial fibre.
>
> Ok, nothing wrong with that. But BGP doesn't provide any functionality 
> to
> really help with this.

Well, BGP plus CIDR abuse does. If I operate 203.97.0.0/17, and I obtain 
transit from two providers as vaguely described, I can hang all my 
satellite-tolerant gear in (say) 203.97.2.0/24 and advertise just 
203.97.2.0/24 over the satellite circuit. The fact that I am able to 
advertise covered routes to make things work is central to the way that 
multi-homing is made to work with v4, and is one example of things we 
are trying to provide core-safe alternatives for in v6.

>  Since it can be done now without help from BGP,
> there is no reason an IPv6 solution should specifically cater to this
> need. Just not getting in the way of more specific routes or policy
> routing should be enough.

(Continue reading)

Iljitsch van Beijnum | 3 Jul 00:22

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

On Tue, 2 Jul 2002, Joe Abley wrote:

> > Ok, nothing wrong with that. But BGP doesn't provide any functionality
> > to really help with this.

> Well, BGP plus CIDR abuse does. If I operate 203.97.0.0/17, and I obtain
> transit from two providers as vaguely described, I can hang all my
> satellite-tolerant gear in (say) 203.97.2.0/24 and advertise just
> 203.97.2.0/24 over the satellite circuit.

And you must also make sure the servers you communicate with are routed
over the satellite link. If you don't, you'll have to use policy routing.

> The fact that I am able to
> advertise covered routes to make things work is central to the way that
> multi-homing is made to work with v4, and is one example of things we
> are trying to provide core-safe alternatives for in v6.

Basically you are using two different address ranges here, one multihomed
and one single homed. (The fact that they overlap in this particular
instance is not important.) This is such a basic capability that I can't
even imagine a multihoming solution that conflicts with it.

> >  Since it can be done now without help from BGP,
> > there is no reason an IPv6 solution should specifically cater to this
> > need. Just not getting in the way of more specific routes or policy
> > routing should be enough.

> It seems feasible to me that there will be solutions to the requirement
> as currently stated on the draft that do not need to rely on policy

(Continue reading)

Joe Abley | 3 Jul 03:31

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

On Wed, Jul 03, 2002 at 12:22:29AM +0200, Iljitsch van Beijnum wrote:
> On Tue, 2 Jul 2002, Joe Abley wrote:
> 
> > > "Existing IPv4 multihoming practices can coexist with policy-based
> > > routing
> > > and forwarding mechanisms. An IPv6 multihoming architecture should
> > > retain this capability."
> 
> > As I said, I think that presupposes a solution.
> 
> I didn't have one in mind when I wrote it.

I was talking about the solution which involves "policy-based
routing and forwarding mechanisms". Seems to me that the requirement
in the document right now could be met without using those.

For example, suppose the pure aggregation/no hole-punching addressing
and route advertisement scheme is strictly adhered to, and the effect
of multi-homing is to number each interface with an address from each
transit provider. Further suppose that the TCP endpoint address
selection algorithm can be influenced by some hierarchical policy
signalling mechanism. In that case, inbound traffic towards a TCP
endpoint could be moved between transit providers without resorting
to CIDR abuse.

I'm not saying that such a scheme would feature in a multihoming
architecture v6, or that it is not without other substantial problems,
but it does sound to me like a solution to the specific requirement
in question which does not rely on advertising covering supernets
(or other disparate routes) to different transit providers in order

(Continue reading)

Iljitsch van Beijnum | 3 Jul 13:49

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

On Tue, 2 Jul 2002, Joe Abley wrote:

> > > As I said, I think that presupposes a solution.

> > I didn't have one in mind when I wrote it.

> I was talking about the solution which involves "policy-based
> routing and forwarding mechanisms". Seems to me that the requirement
> in the document right now could be met without using those.

Ah, I see. I was thinking about:

1. Both ends have the special applications use different addresses that
   are routed over just one connection (probably better to use PA space
   for this rather than a more specific in BGP)

2. Policy routing based on application characteristics such as IP address
   or protocol/port number

3. Diffserv code point that has the effect a specific connection is
   selected

Are there additional ways to accomplish this?

> For example, suppose the pure aggregation/no hole-punching addressing
> and route advertisement scheme is strictly adhered to, and the effect
> of multi-homing is to number each interface with an address from each
> transit provider. Further suppose that the TCP endpoint address
> selection algorithm can be influenced by some hierarchical policy
> signalling mechanism. In that case, inbound traffic towards a TCP

(Continue reading)

Joe Abley | 3 Jul 17:02

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


On Wednesday, July 3, 2002, at 07:49 , Iljitsch van Beijnum wrote:

>> For example, suppose the pure aggregation/no hole-punching addressing
>> and route advertisement scheme is strictly adhered to, and the effect
>> of multi-homing is to number each interface with an address from each
>> transit provider. Further suppose that the TCP endpoint address
>> selection algorithm can be influenced by some hierarchical policy
>> signalling mechanism. In that case, inbound traffic towards a TCP
>> endpoint could be moved between transit providers without resorting
>> to CIDR abuse.
>
> You still need either:
>
> - BOTH ends to have their IP address for this application in a separate
>   range, or

This happens by virtue of the fact that each transit provider delegates 
a block of space to the multi-homed site. If the site is single-homed, 
it only has one transit provider, and hence only one IP address. The 
fictional address selection criteria might apply to both ends of the 
session. Yes, there are big holes in this approach :)

> - use policy routing based on address or protocol/port to select the 
> right
>   exit connection
>
> The former is workable for things like NNTP, where the traffic flow is
> easily predicted and some optimization in IP addressing is well worth 
> it.

(Continue reading)

Return

Return to gmane.ietf.multi6.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane