headers
Internet-Drafts | 12 Jun 13:14
Picon
Favicon

I-D ACTION:draft-ietf-multi6-multihoming-requirements-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Site Multihoming in IPv6 Working Group of the IETF.

	Title		: Requirements for IPv6 Site- Multihoming Architectures
	Author(s)	: B. Black, V. Gill, J. Abley
	Filename	: draft-ietf-multi6-multihoming-requirements-03.txt
	Pages		: 12
	Date		: 11-Jun-02
	
Site-multihoming, i.e.  connecting to more than one IP service
provider, is an essential component of service for many sites which
are part of the Internet.  Existing IPv4 site-multihoming practices,
described in a companion draft [1], provides a set of capabilities
that must be accommodated by the adopted site-multihoming
architecture in IPv6, and a set of limitations that must be overcome,
relating in particular to scalability.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming-requirements-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-multi6-multihoming-requirements-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sean Doran | 20 Jun 23:53

draft-ietf-multi6-multihoming-requirements-03


Hi -

   Joe has done some updates to the draft, and has been met with
silence from the WG.

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

   Failing that, please feel free to make meta-comments on whether
we should start the last call process and move the document along.

   (Remember this is a gating issue, as this document will be used
within the working group when evaluating proposed multihoming solutions,
so this draft is important, and deserving of a few minutes of reading
and commenting time).

	Sean.
Permalink | Reply | 8 comments |
headers
Iljitsch van Beijnum | 21 Jun 01:52
Favicon

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

On Thu, 20 Jun 2002, Sean Doran wrote:

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

Since you ask... The requirements all seem very reasonable to me. (Many
pretty much go without saying.) I only have two problems:

- multihoming gets blamed for the global routing table bloat, while
  the number of active routes vs the number of active ASNs clearly shows
  this is only a small factor at this time

- what happens when there is no multihoming solution that meets all
  requirements? We then forego multihoming in IPv6, or ...? There is only
  a perfunctory division of the listed requirements into the classes "must
  be supported" and "additional requirements"

>    Failing that, please feel free to make meta-comments on whether
> we should start the last call process and move the document along.

Maybe we should have a look at the "goals and milestones" section of the
charter for guidance.

Iljitsch van Beijnum
Permalink | Reply | 1 comment |
headers
Masataka Ohta | 21 Jun 02:03
Picon

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

Sean;

>    Joe has done some updates to the draft, and has been met with
> silence from the WG.
> 
>    Would anyone like to comment on draft-ietf-multi6-multihoming-requirements-03?

I agree with Brian;

	My opinion: ship it. We need to get done with requirements so that
	we can proceed to look at solutions. Twiddling the requirements to
	achieve universal consensus isn't productive.

>    (Remember this is a gating issue, as this document will be used
> within the working group when evaluating proposed multihoming solutions,
> so this draft is important, and deserving of a few minutes of reading
> and commenting time).

However, the result based not on the universal consensus should not
be used to evaluate proposals.

IMHO, in other words, attempts to ship requirement drafts was not
productive.

Simply listing up all the requirements, some of which contradicts
each other, could have been a better approach, as the result
contains contradicting ones, anyway.

						Masataka Ohta
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian E Carpenter | 21 Jun 15:04
Picon
Favicon

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

Iljitsch van Beijnum wrote:
...
> - what happens when there is no multihoming solution that meets all
>   requirements? We then forego multihoming in IPv6, or ...? There is only
>   a perfunctory division of the listed requirements into the classes "must
>   be supported" and "additional requirements"

I'd certainly expect that there is no perfect solution. The requirements are
just a checklist for evaluating solutions. That's why I said "ship it". Get it
out as Informational so that we can move on.

   Brian
Permalink | Reply | 0 comments |
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 | 4 comments |
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 | 0 comments |
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 | 2 comments |
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 | 1 comment |
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 | 0 comments |

Gmane