Subject: RE: a response to "A Simple Solution for IPv6 Multihoming"

From: [email-masked]
Date: Fri, 17 Sep 1999 11:16:37 +0100

Steve,

Can I also clarify the purpose of this discussion?
In the light of what Steve clarified do we try to single out a multihoming
technique and abandon all others? I would hope not! Different networks,
customers and ISPs will have different requirements and in general
multihoming is more an administration/net. management issue i.e: we do not
try to develop a new protocol here (not so far anyway...).

I would say that both Jessica's and Itojun/RFC2260 and probably others are
workable solutions with different limitations. As long as we *understand*
what the limitations/advantages are in each case we should be very careful
dismissing configurations and system designs that some might find useful now
or in the future.

I think Peter Tattam's suggestion to summarise the proposals and hopefully
the discussion in the Interim meeting will help us to objectively document
options and allow net.admins and customers to evaluate solution for THEIR!
requirements.

Regards

George

> -----Original Message-----
> From:	Steve Deering [SMTP:[email-masked]]
> Sent:	Friday, September 17, 1999 6:53 AM
> To:	[email-masked]
> Cc:	[email-masked]
> Subject:	Re: a response to "A Simple Solution for IPv6 Multihoming"
> 
> At 2:37 PM +0900 9/17/99, [email-masked] wrote:
> >	I checked  draft-ietf-ngtrans-harden-01.txt and it says like this:
> >
> > >>All pTLAs MUST NOT advertise prefixes longer than a given pTLA
> > >>delegation (currently /24 or /28) to other pTLAs unless special
> peering
> > >>arrangements are implemented. When such special peering aggreements
> are in
> > >>place between any two or more pTLAs, care MUST be taken not to leak
> the more
> > >>specifics to other pTLAs not participating in the peering aggreement.
> pTLAs
> > >>which have such agreements in place MUST NOT advertise other pTLA more
> > >>specifics to downstream pNLAs or leaf sites, as this will break the
> > >>best-path routing decision.
> 
> Yes, that's consistent with what I said.
> 
> Steve
> 
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [email-masked]
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Jessica Yu <[email-masked]>
Date: Mon, 20 Sep 1999 14:37:29 -0400

>try to develop a new protocol here (not so far anyway...).

	I gather that you are saying that there could be more than
	one multhoming solutions.  The selection of such mechanism
	is largely depending on customers' requirements such as,
	the level of desirable redundancy and financial constrains
	(this could vary from customer to customer) and ISPs' own 
	considerations such as managibility, scalability and charging 
	mechanism.  I agree.

	My sense is that the requirements of many multihoming sites would 
	be: a) reasonable redundancy and b) less complexed solution.  
	Since most of such sites do not have in-house expertises to deal 
	with on site complexed configuration and network management and 
	neither can they afford to hire one.  

						--Jessica