Site Multihoming in IPv6 (multi6)

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)

headers

Dave Wilson | 26 Jun 01:13

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/

headers

Brian E Carpenter | 26 Jun 14:06

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)