headers
Dave Wilson | 24 Jun 23:47
Picon
Favicon

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

>    Would anyone like to comment on draft-ietf-multi6-multihoming-requirements-03?

Question about sections 3.1.2-3.1.4.

During the discussions on global-v6, a scenario came up that caused trouble.

Imagine network A does not (under current RIR rules) qualify for a /35.
Network A has routes to network B via (a) a high speed direct connection,
(b) a high-speed network and (c) an ordinary commodity internet connection.
Network A provides connectivity to a number of sites (< 200) not under its
direct control.

In IPv4, where Network A has an ASN and allocation from a RIR, BGP localprefs
enforce a routing policy which uses the high-speed connects in preference to
the commodity internet.

Does section 3.1.4 require a solution to this scenario? "class of traffic"
might just mean a protocol or could be wider, so I am not sure.

The reason I bring this up is that it is not an unusual configuration for a
national research network. If the answer is "no" then it is not necessarily
a problem with the document :) but if the group [does|does not] plan to
address it, I think it would be useful feedback for the policy groups.

Best regards,
Dave

--

-- 
 dave.wilson <at> heanet.ie  ------- DW238-RIPE ------- GPG key: davew+pgp <at> heanet.ie
 HEAnet Limited, Brooklawn House, Crampton Ave, Ballsbridge, D4 p:353-1-6609040
(Continue reading)

Permalink | Reply |
headers
Brian E Carpenter | 25 Jun 09:57
Picon
Favicon

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

I think "class of traffic" would certainly include diffserv codepoints as well
as (or instead of) protocol numbers. If traffic has been classified by a diffserv
classifier before it hits the multihoming logic, that could imply that the source
and/or destination address helped to determine the diffserv codepoint and hence 
the multihoming policy.

Are you suggesting any change to the text?

   Brian 

Dave Wilson wrote:
> 
> >    Would anyone like to comment on draft-ietf-multi6-multihoming-requirements-03?
> 
> Question about sections 3.1.2-3.1.4.
> 
> During the discussions on global-v6, a scenario came up that caused trouble.
> 
> Imagine network A does not (under current RIR rules) qualify for a /35.
> Network A has routes to network B via (a) a high speed direct connection,
> (b) a high-speed network and (c) an ordinary commodity internet connection.
> Network A provides connectivity to a number of sites (< 200) not under its
> direct control.
> 
> In IPv4, where Network A has an ASN and allocation from a RIR, BGP localprefs
> enforce a routing policy which uses the high-speed connects in preference to
> the commodity internet.
> 
> Does section 3.1.4 require a solution to this scenario? "class of traffic"
> might just mean a protocol or could be wider, so I am not sure.
(Continue reading)

Permalink | Reply |
headers
Dave Wilson | 26 Jun 01:13
Picon
Favicon

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

> I think "class of traffic" would certainly include diffserv codepoints as well
> as (or instead of) protocol numbers. If traffic has been classified by a diffserv
> classifier before it hits the multihoming logic, that could imply that the source
> and/or destination address helped to determine the diffserv codepoint and hence 
> the multihoming policy.

Ok, thanks.

> Are you suggesting any change to the text?

No. Even if the text fails to include the scenario I mentioned, I am not sure
that it would be a problem. However I'd like to make sure that multihoming
expectations in the policy groups match expectations here.

Regards,
Dave

--

-- 
 dave.wilson <at> heanet.ie  ------- DW238-RIPE ------- GPG key: davew+pgp <at> heanet.ie
 HEAnet Limited, Brooklawn House, Crampton Ave, Ballsbridge, D4 p:353-1-6609040
 "A reload a day keeps the TAC away" - Roger Gottsponer RIPE-40 f:353-1-6603666
 HEAnet's National Networking Conference http://www.heanet.ie/conferences/2001/
Permalink | Reply |
headers
Brian E Carpenter | 26 Jun 14:06
Picon
Favicon

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

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.

   Brian

Dave Wilson wrote:
> 
> > I think "class of traffic" would certainly include diffserv codepoints as well
> > as (or instead of) protocol numbers. If traffic has been classified by a diffserv
> > classifier before it hits the multihoming logic, that could imply that the source
> > and/or destination address helped to determine the diffserv codepoint and hence
> > the multihoming policy.
> 
> Ok, thanks.
> 
> > Are you suggesting any change to the text?
> 
> No. Even if the text fails to include the scenario I mentioned, I am not sure
> that it would be a problem. However I'd like to make sure that multihoming
> expectations in the policy groups match expectations here.
> 
> Regards,
> Dave
> 
> --
>  dave.wilson <at> heanet.ie  ------- DW238-RIPE ------- GPG key: davew+pgp <at> heanet.ie
>  HEAnet Limited, Brooklawn House, Crampton Ave, Ballsbridge, D4 p:353-1-6609040
(Continue reading)

Permalink | Reply |
headers
Iljitsch van Beijnum | 25 Jun 09:40
Favicon

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

On Mon, 24 Jun 2002, Dave Wilson wrote:

> Imagine network A does not (under current RIR rules) qualify for a /35.
> Network A has routes to network B via (a) a high speed direct connection,
> (b) a high-speed network and (c) an ordinary commodity internet connection.
> Network A provides connectivity to a number of sites (< 200) not under its
> direct control.

> In IPv4, where Network A has an ASN and allocation from a RIR, BGP localprefs
> enforce a routing policy which uses the high-speed connects in preference to
> the commodity internet.

Only for outgoing traffic. Balancing incoming traffic is much harder,
unless the networks sending the traffic cooperate.

> Does section 3.1.4 require a solution to this scenario? "class of traffic"
> might just mean a protocol or could be wider, so I am not sure.

> The reason I bring this up is that it is not an unusual configuration for a
> national research network. If the answer is "no" then it is not necessarily
> a problem with the document :) but if the group [does|does not] plan to
> address it, I think it would be useful feedback for the policy groups.

A multihoming solution that doesn't provide for a way to make a
higher-bandwidth connection to be more preferred than a lower-bandwidth
connection won't fly, because it doesn't address real-world needs. There
are still many places in the world where bandwidth is expensive enough
wasting a significant amount of it is not an option.

Route selection and load balancing are mainly a problem with solutions
(Continue reading)

Permalink | Reply |

Gmane