From owner-multi6@ops.ietf.org Sat Nov 3 22:42:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22717 for ; Sat, 3 Nov 2001 22:42:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 160E4b-000IZl-00 for multi6-data@psg.com; Sat, 03 Nov 2001 19:35:49 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 160E4a-000IZd-00 for multi6@ops.ietf.org; Sat, 03 Nov 2001 19:35:48 -0800 Subject: (multi6) 52nd IETF Date: Sat, 3 Nov 2001 19:35:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046403D423@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Thread-Topic: (multi6) 52nd IETF Thread-Index: AcFk4b66q4AEjhZnT+igKbiPVAIWsw== From: "Michel Py" To: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA22717 How come there is nothing about multi6 in the draft agenda for the 52nd IETF? From owner-multi6@ops.ietf.org Sat Nov 3 23:20:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22888 for ; Sat, 3 Nov 2001 23:20:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 160Ekv-000JCX-00 for multi6-data@psg.com; Sat, 03 Nov 2001 20:19:33 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 160Eku-000JCR-00 for multi6@ops.ietf.org; Sat, 03 Nov 2001 20:19:32 -0800 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 160Ekn-000D3f-00; Sat, 03 Nov 2001 20:19:25 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Michel Py" Cc: Subject: Re: (multi6) 52nd IETF References: <2B81403386729140A3A899A8B39B046403D423@server2000.arneill-py.sacramento.ca.us> Message-Id: Date: Sat, 03 Nov 2001 20:19:25 -0800 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > How come there is nothing about multi6 in the draft agenda for the 52nd > IETF? usually it is because the chairs did not ask to have a slot scheduled. how is the wg doing on milestones? is there for the agenda? randy From owner-multi6@ops.ietf.org Wed Nov 7 16:45:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24367 for ; Wed, 7 Nov 2001 16:45:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 161aRB-000I51-00 for multi6-data@psg.com; Wed, 07 Nov 2001 13:40:45 -0800 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.33 #1) id 161aR9-000I4m-00 for multi6@ops.ietf.org; Wed, 07 Nov 2001 13:40:43 -0800 Received: (qmail 41004 invoked by uid 1000); 7 Nov 2001 21:40:42 -0000 Date: Wed, 7 Nov 2001 16:40:42 -0500 From: Joe Abley To: multi6@ops.ietf.org Subject: requirements and current-practices drafts Message-ID: <20011107164041.B20667@buffoon.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.22.1i Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, Many apologies for the impressive period of dead air on this, but it has not been possible to juggle the non-paid and paid daily grind to the usual degree over the past few months. I have offered to Thomas and Sean to collate feedback since the last draft revisions were issued, and to amend the two drafts with the help of the list to bring them to a state worthy of last call. I have a fair pile of multi6 mail to catch up on, but should be able to post an initial set of proposed revisions to the list this week for discussion. I would like to do this paragraph-by- paragraph so we can keep some momentum going with incremental changes. Again, apologies for the huge delay and consequent gross milestone slippage. Joe From owner-multi6@ops.ietf.org Mon Nov 12 05:11:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24199 for ; Mon, 12 Nov 2001 05:11:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 163E0n-000Nf2-00 for multi6-data@psg.com; Mon, 12 Nov 2001 02:08:17 -0800 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.33 #1) id 163E0m-000New-00 for multi6@ops.ietf.org; Mon, 12 Nov 2001 02:08:16 -0800 Received: (qmail 2825 invoked by uid 1000); 12 Nov 2001 10:08:13 -0000 Date: Mon, 12 Nov 2001 05:08:12 -0500 From: Joe Abley To: multi6@ops.ietf.org Subject: draft-ietf-multi6-multihoming-requirements-02-candidate1 Message-ID: <20011112050812.T20667@buffoon.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.22.1i Sender: owner-multi6@ops.ietf.org Precedence: bulk I have completed a rough set of initial edits to the requirements draft, along the lines discussed here over the last few months. I haven't submitted this to the rfc editor yet, since I expect more changes to come out of discussion on the list this week (and I suspect the rfc editor could do without the additional work right now). If this is bad form, please let me know. The text is here: http://buffoon.automagic.org/dist/draft-ietf-multi6-multihoming-requirements-02-candidate1.txt and is attached below, depaginated with change bars in the left- hand margin indicating changed lines, in case someone finds that useful. The diff was against the -01 draft. The main changes are: 1. The use of "enterprise" was contentious and I think the consensus was it was not the best word. I have subsituted "site", and mentioned the RFC1918 definition of "enterprise" as compatible in the glossary. 2. I have tried to use "site-multihoming" or "multihomed site" to be more explicit about the kind of multihoming we are talking about. 3. Clarification of the definition of "transit provider", since it was evident that this term is understood differently by many different people. I have chosen to clarify the definition I used previously rather than change it. If the definition below is not sufficiently familiar to enough people, an alternative would be welcomed. 4. SHOULD/MUST/etc. Please review. I have almost certainly missed some other modifications that someone was expecting, so if they could be pointed out that would be good. We have a week, I think, to knock this into shape before the submission deadline. Joe Network Working Group B. Black Internet-Draft Layer8 Networks |Expires: May 13, 2002 V. Gill J. Abley | MFN | November 12, 2001 | Requirements for IPv6 Site-Multihoming Architectures | draft-ietf-multi6-multihoming-requirements-02-candidate1 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. | This Internet-Draft will expire on May 13, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract | 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. | This document outlines a set of requirements for a new IPv6 site- | multihoming architecture. 1. Introduction | Current IPv4 site-multihoming practices have been added on to the | CIDR architecture [2], which assumes that routing table entries can | be aggregated based upon a hierarchy of customers and service | providers [1]. However, it appears that this hierarchy is being supplanted by a dense mesh of interconnections [9]. Additionally, there has been an | enormous growth in the number of multihomed sites. For purposes of | redundancy and load-sharing, the multihomed address blocks, which are | almost always a longer prefix than the provider aggregate, are | announced along with the larger, covering aggregate originated by the | provider. This contributes to the rapidly-increasing size of the | global routing table. This explosion places significant stress on | the inter-provider routing system. | Continued growth of both the internet and the practice of site- | multihoming will seriously exacerbate this stress. The site- | multihoming architecture for IPv6 should allow the routing system to | scale more pleasantly. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [4]. | A "site" is an entity autonomously operating a network using IP and, | in particular, determining the addressing plan and routing policy for | that network. This definition is intended to be equivalent to | "enterprise" as defined in [3]. | A "transit provider" operates a site which directly provides | connectivity to the Internet to one or more external sites. The | connectivity provided extends beyond the transit provider's own site. | A transit provider's site is directly connected to the sites for | which it provides transit. | A "multihomed" site is one with more than one transit provider. | "Site-multihoming" is the practice of arranging a site to be multi- | homed. | The term "re-homing" denotes a transition of a site between two | states of connectedness, due to a change in the connectivity between | the site and its transit providers' sites. 3. Multihoming Requirements 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]. 3.1.1 Redundancy | By multihoming, a site MUST be able to insulate itself from certain | failure modes within one or more transit providers, as well as | failures in the network providing interconnection among one or more transit providers. | Infrastructural commonalities below the IP layer may result in | connectivity which is apparently diverse sharing single points of | failure. For example, two separate DS3 circuits ordered from | different suppliers and connecting a site to independent transit | providers may share a single conduit from the street into a building; | in this case backhoe-fade of both circuits may be experienced due to | a single incident in the street. The two circuits are said to "share | fate". | The multihoming architecture MUST accommodate (in the general case, | issues of shared fate notwithstanding) continuity of connectivity | during the following failures: | o Physical failure, such as a fiber cut, or router failure, o Logical link failure, such as a misbehaving router interface, o Routing protocol failure, such as a BGP peer reset, o Transit provider failure, such as a backbone-wide IGP failure, and o Exchange failure, such as a BGP reset on an inter-provider peering. 3.1.2 Load Sharing | By multihoming, a site MUST be able to distribute both inbound and | outbound traffic between multiple transit providers. This | requirement is for concurrent use of the multiple transit providers, | not just the usage of one provider over one interval of time and | another provider over a different interval. |3.1.3 Performance | By multihoming, a site MUST be able to protect itself from | performance difficulties directly between the site's transit | providers. | For example, suppose site E obtains transit from transit providers T1 | and T2, and there is long-term congestion between T1 and T2. The | multihoming architecture MUST allow E to ensure that in normal | operation none of its traffic is carried over the congested | interconnection T1-T2. The process by which this is achieved MAY be | a manual one. | A multi-homed site MUST be able to distribute inbound traffic from | particular multiple transit providers according to the particular | address range within their site which is sourcing or sinking the | traffic. 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. 3.1.5 Simplicity As any proposed multihoming solution must be deployed in real networks with real customers, simplicity is paramount. The current multihoming solution is quite straightforward to deploy and maintain. | A new IPv6 multihoming proposal MUST NOT be substantially more complex to deploy and operate than current IPv4 multihoming practices. 3.1.6 Transport-Layer Survivability | Multihoming solutions MUST provide re-homing transparency for | transport-layer sessions; i.e. exchange of data between devices on | the multihomed site and devices elsewhere on the Internet may proceed | with no greater interruption than that associated with the transient | packet loss during the re-homing event. | New transport-layer sessions MUST be able to be created following a | re-homing event. | Transport-layer sessions include those involving transport-layer | protocols such as TCP, UDP and SCTP over IP. Applications which | communicate over raw IP and other network-layer protocols MAY also | enjoy re-homing transparency. 3.2 Additional Requirements 3.2.1 Scalability Current IPV4 multihoming practices contribute to the significant growth currently observed in the state held in the global inter- provider routing system; this is a concern both because of the hardware requirements it imposes and also because of the impact on the stability of the routing system. This issue is discussed in great detail in [9]. | A new IPv6 multihoming architecture MUST scale to accommodate orders | of magnitude more multi-homed sites without imposing unreasonable | requirements on the routing system. 3.2.2 Impact on Routers | The solution MAY require changes to IPv6 router implementations, but these changes must be either minor, or in the form of logically separate functions added to existing functions. | Such changes MUST NOT prevent normal single-homed operation, and routers implementing these changes must be able to interoperate fully with hosts and routers not implementing them. 3.2.3 Impact on Hosts | The solution MUST NOT destroy IPv6 connectivity for a legacy host implementing RFC 2373 [5], RFC 2460 [7], RFC 2553 [8] and other basic | IPv6 specifications current in November 2001. That is to say, if a | host can work in a single-homed site, it must still be able to work | in a multihomed site, even if it cannot benefit from site- | multihoming. It would be compatible with this requirement for such a host to lose | connectivity if a site lost connectivity to one transit provider, | despite the fact that other transit provider connections were still | operational. If the solution requires changes to the host stack, these changes | MUST be either minor, or in the form of logically separate functions added to existing functions. If the solution requires changes to the socket API and/or the | transport layer, it MUST be possible to retain the original socket API and transport protocols in parallel, even if they cannot benefit from multihoming. | The multi-homing solution MAY allow host or application changes if | that would enhance session survivability. 3.2.4 Interaction between Hosts and the Routing System | The solution MAY involve interaction between a site's hosts and its | routing system; such an interaction MUST be simple, scaleable and securable. 3.2.5 Operations and Management | It MUST be posssible for staff responsible for the operation of a | site to monitor and configure the site's multihoming system. 4. Security Considerations | A multihomed site MUST be no more vulnerable to security breaches | than a non-multihomed site. References [1] Abley, J., Black, B. and V. Gill, "IPv4 Multihoming Motivation, Practices and Limitations (work-in-progress)", I-D draft-ietf- multi6-v4-multihoming-00, June 2001, . [2] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter- Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993. [3] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [5] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [6] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggregatable Global Unicast Address Format", RFC 2374, July 1998. [7] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [8] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 2553, March 1999. [9] Huston, G., "Analyzing the Internet's BGP Routing Table", January 2001. Authors' Addresses Benjamin Black Layer8 Networks EMail: ben@layer8.net Vijay Gill | MFN 8075 Leesburg Pike Suite 300 Vienna, VA 22182 US Phone: +1 410 262 0660 | EMail: vgill@mfn.com Joe Abley | MFN | 10805 Old River Road | Komoka, ON N0L 1R0 Canada | Phone: +1 519 641 3738 | EMail: jabley@mfn.com Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. From owner-multi6@ops.ietf.org Mon Nov 12 09:17:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01172 for ; Mon, 12 Nov 2001 09:17:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 163Hqo-0002r5-00 for multi6-data@psg.com; Mon, 12 Nov 2001 06:14:14 -0800 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.33 #1) id 163Hqn-0002qz-00 for multi6@ops.ietf.org; Mon, 12 Nov 2001 06:14:13 -0800 Received: (qmail 4766 invoked by uid 1000); 12 Nov 2001 14:14:12 -0000 Date: Mon, 12 Nov 2001 09:14:12 -0500 From: Joe Abley To: multi6@ops.ietf.org Subject: site vs enterprise Message-ID: <20011112091412.X20667@buffoon.automagic.org> References: <20011112050812.T20667@buffoon.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011112050812.T20667@buffoon.automagic.org> User-Agent: Mutt/1.3.22.1i Sender: owner-multi6@ops.ietf.org Precedence: bulk [at Thomas' suggestion, I am posting the text of each of the contentious changes I mentioned, for ease of comment] 1. The use of "enterprise" was contentious and I think the consensus was it was not the best word. I have subsituted "site", and mentioned the RFC1918 definition of "enterprise" as compatible in the glossary. > 2. Terminology > > [snip] > > | A "site" is an entity autonomously operating a network using IP and, > | in particular, determining the addressing plan and routing policy for > | that network. This definition is intended to be equivalent to > | "enterprise" as defined in [3]. From owner-multi6@ops.ietf.org Mon Nov 12 09:26:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02012 for ; Mon, 12 Nov 2001 09:26:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 163I17-00039B-00 for multi6-data@psg.com; Mon, 12 Nov 2001 06:24:53 -0800 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.33 #1) id 163I16-000395-00 for multi6@ops.ietf.org; Mon, 12 Nov 2001 06:24:52 -0800 Received: (qmail 4952 invoked by uid 1000); 12 Nov 2001 14:24:51 -0000 Date: Mon, 12 Nov 2001 09:24:50 -0500 From: Joe Abley To: multi6@ops.ietf.org Subject: transit provider definition Message-ID: <20011112092449.Y20667@buffoon.automagic.org> References: <20011112050812.T20667@buffoon.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011112050812.T20667@buffoon.automagic.org> User-Agent: Mutt/1.3.22.1i Sender: owner-multi6@ops.ietf.org Precedence: bulk 3. Clarification of the definition of "transit provider", since it was evident that this term is understood differently by many different people. I have chosen to clarify the definition I used previously rather than change it. If the definition below is not sufficiently familiar to enough people, an alternative would be welcomed. I toyed with the idea of including a diagram here, since it seemed to help before. For example, in the following picture: S0 --- S1 --- S2 --- S3 --- Rest of World | || | `---- S4 =====' | ----- transit circuit | | ===== peering circuit `-------------' S1, S4 are transit providers for S0 S2 is a transit provider of S1 S3 is a transit provider of S2 and S4 I toyed with the idea of using "global transit provider", and introducing the idea that S2 was a transit provider for S4 to S1 and S0 only, whilst S3 was a global transit provider for S4. However, the definition is woolly enough already, and I thought I would avoid any unnecessary confusion by not raising the issue. Comments and suggestions for improvement very welcome. > 2. Terminology > > [snip] > > | A "transit provider" operates a site which directly provides > | connectivity to the Internet to one or more external sites. The > | connectivity provided extends beyond the transit provider's own site. > | A transit provider's site is directly connected to the sites for > | which it provides transit. From owner-multi6@ops.ietf.org Mon Nov 12 09:33:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02508 for ; Mon, 12 Nov 2001 09:33:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 163I7d-0003Jz-00 for multi6-data@psg.com; Mon, 12 Nov 2001 06:31:37 -0800 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.33 #1) id 163I7c-0003Jt-00 for multi6@ops.ietf.org; Mon, 12 Nov 2001 06:31:36 -0800 Received: (qmail 5069 invoked by uid 1000); 12 Nov 2001 14:31:35 -0000 Date: Mon, 12 Nov 2001 09:31:35 -0500 From: Joe Abley To: multi6@ops.ietf.org Subject: additional requirements: capneg and policy discovery Message-ID: <20011112093135.Z20667@buffoon.automagic.org> References: <20011112050812.T20667@buffoon.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011112050812.T20667@buffoon.automagic.org> User-Agent: Mutt/1.3.22.1i Sender: owner-multi6@ops.ietf.org Precedence: bulk I just found some additional requirements in e-mail that I couldn't find in the draft (I may have missed them; I am slightly caffeine- deprived). Here are the first two: On Tue, Jun 26, 2001 at 05:49:41PM -0500, Tony_Hiller wrote: > > - - capabilities negotiation - Multihoming solutions must provide a > means for peers to communicate capabilities to each other, in order > to support new capabilities that may or may not be included in all > implementations. > > - - policy - Multihoming solutions should provide a means for peers > to discover the routing policies applied to their routes by peer networks. From owner-multi6@ops.ietf.org Mon Nov 12 09:34:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02644 for ; Mon, 12 Nov 2001 09:34:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 163I9J-0003Mo-00 for multi6-data@psg.com; Mon, 12 Nov 2001 06:33:21 -0800 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.33 #1) id 163I9I-0003Mi-00 for multi6@ops.ietf.org; Mon, 12 Nov 2001 06:33:20 -0800 Received: (qmail 5087 invoked by uid 1000); 12 Nov 2001 14:33:19 -0000 Date: Mon, 12 Nov 2001 09:33:19 -0500 From: Joe Abley To: multi6@ops.ietf.org Subject: additional requirement: cooperation Message-ID: <20011112093319.A20667@buffoon.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.22.1i Sender: owner-multi6@ops.ietf.org Precedence: bulk A multihoming strategy MAY require cooperation between a site and its transit providers, but MUST NOT require cooperation directly between the transit providers. From owner-multi6@ops.ietf.org Mon Nov 12 11:07:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08825 for ; Mon, 12 Nov 2001 11:07:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 163JaL-0005xi-00 for multi6-data@psg.com; Mon, 12 Nov 2001 08:05:21 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 163JaL-0005xb-00 for multi6@ops.ietf.org; Mon, 12 Nov 2001 08:05:21 -0800 Subject: RE: additional requirement: cooperation Date: Mon, 12 Nov 2001 08:05:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2B81403386729140A3A899A8B39B046403AEFB@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Thread-Topic: additional requirement: cooperation Thread-Index: AcFriQ8PYZgJ5PI2T4m/hluvpcrrpwABnw1g From: "Michel Py" To: "Joe Abley" , Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA08825 I think this one should be changed as follows: "A multihoming strategy MAY require cooperation between a site and its transit providers, but MUST NOT require cooperation directly between the transit providers, EXCEPT when the transit providers are directly connected to one another". "Directly connected" means that the traffic from/to the two concerned transit providers does not have to cross any AS other than one owned by either provider. We don't want to require providers to peer or something with every other provider in the world, but some cooperation with other providers connected directly, which typically means a peering agreement or being in the same NAP is acceptable. In other words, for the same reason some cooperation might be needed between a site and its transit providers, some might also be needed between a transit providers and its neighbors. If unchanged, this sentence is very restrictive and would make impossible multihoming as it is done today (not that I recommend it..) because the necessary BGP peering between transit providers would be considered cooperation. Michel. -----Original Message----- From: Joe Abley [mailto:jabley@nlri.org] Sent: Monday, November 12, 2001 6:33 AM To: multi6@ops.ietf.org Subject: additional requirement: cooperation A multihoming strategy MAY require cooperation between a site and its transit providers, but MUST NOT require cooperation directly between the transit providers. From owner-multi6@ops.ietf.org Mon Nov 12 12:09:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11486 for ; Mon, 12 Nov 2001 12:09:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 163KZf-0007oa-00 for multi6-data@psg.com; Mon, 12 Nov 2001 09:08:43 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 163KZe-0007o7-00 for multi6@ops.ietf.org; Mon, 12 Nov 2001 09:08:42 -0800 Subject: RE: additional requirements: capneg and policy discovery Date: Mon, 12 Nov 2001 09:08:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046403AEFC@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Thread-Topic: additional requirements: capneg and policy discovery Thread-Index: AcFriNOULpco5sMQSnmGCarkbQ+QDAAEUOJA From: "Michel Py" To: "Joe Abley" , Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA11486 > - - capabilities negotiation - Multihoming solutions must provide a > means for peers to communicate capabilities to each other, in order > to support new capabilities that may or may not be included in all > implementations. I think this is putting the car before the horse. Let's say there are multiple multihoming solutions in service. Within each solution, the capability negotiation (or the lack of one) should be left to the choice of that solution. In case more than one solution is available simultaneously, the capabilities negotiation is a good idea because it would eventually allow choosing the "best" one, but requires some understanding of each solution pros and cons, and we are far from that point. I think this could be changed to having a version number within each packet. The behavior when two different versions are present should be defined for each solution, when the next version is available. > - - policy - Multihoming solutions should provide a means for peers > to discover the routing policies applied to their routes by peer networks. I missed the email thread on that one; can we have it again? I am not sure everyone would agree to do that. From owner-multi6@ops.ietf.org Mon Nov 12 12:36:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12457 for ; Mon, 12 Nov 2001 12:36:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 163Kzp-0008YY-00 for multi6-data@psg.com; Mon, 12 Nov 2001 09:35:45 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 163Kzp-0008Y7-00 for multi6@ops.ietf.org; Mon, 12 Nov 2001 09:35:45 -0800 Subject: RE: site vs enterprise Date: Mon, 12 Nov 2001 09:35:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046403D484@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Thread-Topic: site vs enterprise Thread-Index: AcFrh4XkgK2trz3cT8yr/Jfy2aE9oQAGEFwA From: "Michel Py" To: "Joe Abley" , Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA12457 A good move, IMHO, since some multi-homing solutions might be geared towards the "enterprise" and some not. -----Original Message----- From: Joe Abley [mailto:jabley@nlri.org] Sent: Monday, November 12, 2001 6:14 AM To: multi6@ops.ietf.org Subject: site vs enterprise [at Thomas' suggestion, I am posting the text of each of the contentious changes I mentioned, for ease of comment] 1. The use of "enterprise" was contentious and I think the consensus was it was not the best word. I have subsituted "site", and mentioned the RFC1918 definition of "enterprise" as compatible in the glossary. > 2. Terminology > > [snip] > > | A "site" is an entity autonomously operating a network using IP and, > | in particular, determining the addressing plan and routing policy for > | that network. This definition is intended to be equivalent to > | "enterprise" as defined in [3]. From owner-multi6@ops.ietf.org Mon Nov 12 12:54:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13133 for ; Mon, 12 Nov 2001 12:54:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 163LDb-0008wn-00 for multi6-data@psg.com; Mon, 12 Nov 2001 09:49:59 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 163LDa-0008wg-00 for multi6@ops.ietf.org; Mon, 12 Nov 2001 09:49:58 -0800 Subject: RE: additional requirements: policy and policy discovery Date: Mon, 12 Nov 2001 09:49:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046403AEFD@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Thread-Topic: additional requirements: policy and policy discovery Thread-Index: AcFriNOULpco5sMQSnmGCarkbQ+QDAAF4AHA From: "Michel Py" To: "Joe Abley" , Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA13133 > - - policy - Multihoming solutions should provide a means for peers > to discover the routing policies applied to their routes by peer networks. I think this is premature. If the requirements draft is to recommend policy discovery, there should be a companion document describing policy discovery, since it is a completely new topic applied to multihoming. Same idea for 3.1.4 itself, it appears difficult to do more than reserving a field for policy before a "policy discovery and selection" protocol is defined. From owner-multi6@ops.ietf.org Mon Nov 12 12:59:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13309 for ; Mon, 12 Nov 2001 12:59:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 163LMS-0009BX-00 for multi6-data@psg.com; Mon, 12 Nov 2001 09:59:08 -0800 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.33 #1) id 163LMR-0009BR-00 for multi6@ops.ietf.org; Mon, 12 Nov 2001 09:59:08 -0800 Received: (qmail 7633 invoked by uid 1000); 12 Nov 2001 17:59:06 -0000 Date: Mon, 12 Nov 2001 12:59:06 -0500 From: Joe Abley To: Michel Py Cc: multi6@ops.ietf.org Subject: Re: additional requirements: capneg and policy discovery Message-ID: <20011112125905.C20667@buffoon.automagic.org> References: <2B81403386729140A3A899A8B39B046403AEFC@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2B81403386729140A3A899A8B39B046403AEFC@server2000.arneill-py.sacramento.ca.us> User-Agent: Mutt/1.3.22.1i Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, Nov 12, 2001 at 09:08:39AM -0800, Michel Py wrote: > > - - policy - Multihoming solutions should provide a means for peers > > to discover the routing policies applied to their routes by peer > networks. > > I missed the email thread on that one; can we have it again? I am not > sure everyone would agree to do that. It was a private message, which I am copying below, since it contains some elaboration on that point (I should have included it before). ----- Forwarded message from Tony_Hiller ----- Delivered-To: jabley@automagic.org Date: Tue, 26 Jun 2001 17:49:41 -0500 From: Tony_Hiller To: jabley@automagic.org Subject: suggestions for multi6 draft User-Agent: Mutt/1.2.5i Hi jabley, I'd like to make some suggestions for your multihoming draft. They're probably pretty specific, and may be beyond the scope of your doc, but here goes: - - capabilities negotiation - Multihoming solutions must provide a means for peers to communicate capabilities to each other, in order to support new capabilities that may or may not be included in all implementations. - - policy - Multihoming solutions should provide a means for peers to discover the routing policies applied to their routes by peer networks. Uh, I don't like the way that sounds. Suffice it to say, I want some way to tell what filters my peers have in place at any given time. I realize this is asking for denial of service attacks, but it seems that such things could be minimized through proper authentication of peers. There are similiar drafts in idr right now - but I have no idea how close they are to running code. I'm not sure if these are outside your scope, but I'd see both (especially the first) as valuable capabilities. Just my thoughts... hiller ----- End forwarded message ----- From owner-multi6@ops.ietf.org Mon Nov 12 12:59:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13328 for ; Mon, 12 Nov 2001 12:59:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 163LMl-0009CW-00 for multi6-data@psg.com; Mon, 12 Nov 2001 09:59:27 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 163LMk-0009CQ-00 for multi6@ops.ietf.org; Mon, 12 Nov 2001 09:59:26 -0800 Subject: RE: additional requirement: cooperation Date: Mon, 12 Nov 2001 09:59:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046403AEFE@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Thread-Topic: additional requirement: cooperation Thread-Index: AcFriQ8PYZgJ5PI2T4m/hluvpcrrpwAGRsRw From: "Michel Py" To: "Joe Abley" , Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA13328 >> A multihoming strategy MAY require cooperation between a site >> and its transit providers, but MUST NOT require cooperation >> directly between the transit providers. More on this: The term "directly connected" I used before is obviously a poor choice of words, especially for the 6bone. The word "neighbor" is not appropriate either, because it has some strong BGP connotations: an "ebgp-multihop" BGP neighbor could be completely unrelated to one's router. I welcome other phrasing and someone to check my bad English, this is what I coined: "direct neighbor" : As related to two transit providers, direct neighbors are BGP peers that can communicate without crossing any AS that is not owned by either transit provider. The cooperation additional requirement could then be: "A multihoming strategy MAY require cooperation between a site and its transit providers, but MUST NOT require cooperation directly between the transit providers except for direct neighbors". From owner-multi6@ops.ietf.org Mon Nov 12 13:05:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13463 for ; Mon, 12 Nov 2001 13:05:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 163LRl-0009Lu-00 for multi6-data@psg.com; Mon, 12 Nov 2001 10:04:37 -0800 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.33 #1) id 163LRl-0009Ln-00 for multi6@ops.ietf.org; Mon, 12 Nov 2001 10:04:37 -0800 Received: (qmail 7706 invoked by uid 1000); 12 Nov 2001 18:04:36 -0000 Date: Mon, 12 Nov 2001 13:04:36 -0500 From: Joe Abley To: Michel Py Cc: multi6@ops.ietf.org Subject: Re: additional requirement: cooperation Message-ID: <20011112130435.D20667@buffoon.automagic.org> References: <2B81403386729140A3A899A8B39B046403AEFB@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2B81403386729140A3A899A8B39B046403AEFB@server2000.arneill-py.sacramento.ca.us> User-Agent: Mutt/1.3.22.1i Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, Nov 12, 2001 at 08:05:19AM -0800, Michel Py wrote: > I think this one should be changed as follows: > > "A multihoming strategy MAY require cooperation between a site > and its transit providers, but MUST NOT require cooperation > directly between the transit providers, EXCEPT when the transit > providers are directly connected to one another". > > "Directly connected" means that the traffic from/to the two > concerned transit providers does not have to cross any AS other > than one owned by either provider. > > We don't want to require providers to peer or something with > every other provider in the world, but some cooperation with > other providers connected directly, which typically means a > peering agreement or being in the same NAP is acceptable. > > In other words, for the same reason some cooperation might be > needed between a site and its transit providers, some might > also be needed between a transit providers and its neighbors. > > If unchanged, this sentence is very restrictive and would make > impossible multihoming as it is done today (not that I recommend > it..) because the necessary BGP peering between transit providers > would be considered cooperation. I think your modified version is more restrictive than the original. Multihoming today does not require cooperation at all between transit providers in the general case (although it can be necessary to achieve certain goals, e.g. load sharing between providers without PI address space). Having said that, I think your changes are reasonable, although I would substitute "site" for AS, since we have site defined and AS suggests a routing solution. Joe From owner-multi6@ops.ietf.org Mon Nov 12 13:11:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13744 for ; Mon, 12 Nov 2001 13:11:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 163LXD-0009YO-00 for multi6-data@psg.com; Mon, 12 Nov 2001 10:10:15 -0800 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.33 #1) id 163LXC-0009YH-00 for multi6@ops.ietf.org; Mon, 12 Nov 2001 10:10:14 -0800 Received: (qmail 7832 invoked by uid 1000); 12 Nov 2001 18:10:13 -0000 Date: Mon, 12 Nov 2001 13:10:13 -0500 From: Joe Abley To: Michel Py Cc: multi6@ops.ietf.org Subject: Re: additional requirement: cooperation Message-ID: <20011112131013.E20667@buffoon.automagic.org> References: <2B81403386729140A3A899A8B39B046403AEFE@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2B81403386729140A3A899A8B39B046403AEFE@server2000.arneill-py.sacramento.ca.us> User-Agent: Mutt/1.3.22.1i Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, Nov 12, 2001 at 09:59:23AM -0800, Michel Py wrote: > "direct neighbor" : As related to two transit providers, direct > neighbors are BGP peers that can communicate without crossing any AS > that is not owned by either transit provider. How about: Two sites are "direct neighbours" if they are able to exchange traffic betwen their sites directly, without IP datagrams being processed by a router located at some third site. That avoids the routing connotations, but accommodates traffic carried over tunnels (since the encapsulated packets' IP datagrams are unmolested by the routers involved in providing tunnel transport). I can relax my spelling of "neighbour" if necessary :) > The cooperation additional requirement could then be: > > "A multihoming strategy MAY require cooperation between a site > and its transit providers, but MUST NOT require cooperation > directly between the transit providers except for direct neighbors". Joe From owner-multi6@ops.ietf.org Mon Nov 12 13:23:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14102 for ; Mon, 12 Nov 2001 13:23:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 163LiP-0009zu-00 for multi6-data@psg.com; Mon, 12 Nov 2001 10:21:49 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 163LiO-0009zn-00 for multi6@ops.ietf.org; Mon, 12 Nov 2001 10:21:48 -0800 Subject: RE: additional requirement: cooperation Date: Mon, 12 Nov 2001 10:21:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046403AF00@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Thread-Topic: additional requirement: cooperation Thread-Index: AcFrpVln7pFBM0STRkSlnRLwkNT9wwAAB8AQ From: "Michel Py" To: "Joe Abley" Cc: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA14102 >> I think your modified version is more restrictive than the original. >> Multihoming today does not require cooperation at all between >> transit providers in the general case (although it can be >> necessary to achieve certain goals, e.g. load sharing between >> providers without PI address space). The purpose of my posting was that I think the original text has some restrictions in the following sense: A new multihoming solution might require a new protocol, let's call it "xyz". The original text allows "xyz" to be configured between a site and its transit providers, but not between transit providers. If "xyz" needs to flow over the entire Internet, which is a reasonable scenario for global multihoming, "xyz" would likely need to be configured between transit providers. >> How about: >> Two sites are "direct neighbours" if they are able to exchange >> traffic betwen their sites directly, without IP datagrams being >> processed by a router located at some third site. >> That avoids the routing connotations, but accommodates traffic >> carried over tunnels (since the encapsulated packets' IP datagrams >> are unmolested by the routers involved in providing tunnel transport). You might want to be more specific, because it could be argued that IP datagrams crossing routers providing tunnel transport are "unmolested" but are "processed", indeed. Otherwise the sentence is a lot better than mine ;-) > "A multihoming strategy MAY require cooperation between a site > and its transit providers, but MUST NOT require cooperation > directly between the transit providers except for direct neighbors". From owner-multi6@ops.ietf.org Mon Nov 12 13:36:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14580 for ; Mon, 12 Nov 2001 13:36:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 163Lui-000AWA-00 for multi6-data@psg.com; Mon, 12 Nov 2001 10:34:32 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 163Luh-000AW2-00 for multi6@ops.ietf.org; Mon, 12 Nov 2001 10:34:31 -0800 Subject: RE: additional requirement: cooperation Date: Mon, 12 Nov 2001 10:34:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046403AF01@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Thread-Topic: additional requirement: cooperation Thread-Index: AcFrpVln7pFBM0STRkSlnRLwkNT9wwAAj6mQ From: "Michel Py" To: "Joe Abley" Cc: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA14580 These tunnels are annoying in the sense that they could be a loophole if someone wanted to bypass the requirements. What about: Two sites are "direct neighbours" if they are able to exchange ** traffic betwen their sites directly, without IPv6 datagrams being processed by a router located at some third site. > "A multihoming strategy MAY require cooperation between a site > and its transit providers, but MUST NOT require cooperation > directly between the transit providers except for direct neighbors". From owner-multi6@ops.ietf.org Mon Nov 12 13:43:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14782 for ; Mon, 12 Nov 2001 13:43:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 163M2f-000Amg-00 for multi6-data@psg.com; Mon, 12 Nov 2001 10:42:45 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.33 #1) id 163M2d-000AmC-00 for multi6@ops.ietf.org; Mon, 12 Nov 2001 10:42:43 -0800 Received: from x17.ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.11.6/8.11.6) with ESMTP id fACIgeq02858 for ; Mon, 12 Nov 2001 19:42:40 +0100 Received: (from shane@localhost) by x17.ripe.net (8.11.6/8.11.6) id fACIge821683 for multi6@ops.ietf.org; Mon, 12 Nov 2001 19:42:40 +0100 Date: Mon, 12 Nov 2001 19:42:39 +0100 From: Shane Kerr To: multi6@ops.ietf.org Subject: Re: additional requirement: cooperation Message-ID: <20011112194239.A21677@x17.ripe.net> References: <2B81403386729140A3A899A8B39B046403AF01@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2B81403386729140A3A899A8B39B046403AF01@server2000.arneill-py.sacramento.ca.us>; from michel@arneill-py.sacramento.ca.us at 2001-11-12 10:34:25 -0800 Sender: owner-multi6@ops.ietf.org Precedence: bulk On 2001-11-12 10:34:25 -0800, Michel Py wrote: > These tunnels are annoying in the sense that they could be a loophole if > someone wanted to bypass the requirements. > > What about: > > Two sites are "direct neighbours" if they are able to exchange > ** traffic betwen their sites directly, without IPv6 datagrams being > processed by a router located at some third site. > > > "A multihoming strategy MAY require cooperation between a site > > and its transit providers, but MUST NOT require cooperation > > directly between the transit providers except for direct neighbors". How about we leave the "except" off and revisit it if it seems really necessary later on? I worry that any protocol that requires coordination between competitors is doomed to failure. :( -- Shane Carpe Diem From owner-multi6@ops.ietf.org Mon Nov 12 14:05:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15473 for ; Mon, 12 Nov 2001 14:05:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 163MNt-000BRS-00 for multi6-data@psg.com; Mon, 12 Nov 2001 11:04:41 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 163MNs-000BRM-00 for multi6@ops.ietf.org; Mon, 12 Nov 2001 11:04:40 -0800 Subject: RE: additional requirement: cooperation Date: Mon, 12 Nov 2001 11:04:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046403D489@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Thread-Topic: additional requirement: cooperation Thread-Index: AcFrrEN/FEedDc4HRo2xEhsvMWGrPwAADFRw From: "Michel Py" To: "Shane Kerr" , Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA15473 >> How about we leave the "except" off and revisit it if it seems really >> necessary later on? I worry that any protocol that requires >> coordination between competitors is doomed to failure. :( Well, BGP does require some coordination between competitors and it would be foolish to require that an IPv6 solution could do without. The purpose of that "except" is to restrict the amount of cooperation required between competitors to where it is really necessary, which is when these competitors are directly connected to one another. Michel. From owner-multi6@ops.ietf.org Mon Nov 12 14:12:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15662 for ; Mon, 12 Nov 2001 14:12:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 163MTT-000Bey-00 for multi6-data@psg.com; Mon, 12 Nov 2001 11:10:27 -0800 Received: from garlic.amaranth.net ([208.254.46.17]) by psg.com with esmtp (Exim 3.33 #1) id 163MTT-000Bes-00 for multi6@ops.ietf.org; Mon, 12 Nov 2001 11:10:27 -0800 Received: from yarrow.senie.com (amaranth.ne.mediaone.net [24.218.3.14]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.6/8.11.6) with ESMTP id fACJAOu24134 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Mon, 12 Nov 2001 14:10:25 -0500 Message-Id: <5.1.0.14.2.20011112140357.04105050@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 12 Nov 2001 14:10:23 -0500 To: multi6@ops.ietf.org From: Daniel Senie Subject: Re: additional requirement: cooperation In-Reply-To: <20011112194239.A21677@x17.ripe.net> References: <2B81403386729140A3A899A8B39B046403AF01@server2000.arneill-py.sacramento.ca.us> <2B81403386729140A3A899A8B39B046403AF01@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk At 01:42 PM 11/12/01, you wrote: >On 2001-11-12 10:34:25 -0800, Michel Py wrote: > > These tunnels are annoying in the sense that they could be a loophole if > > someone wanted to bypass the requirements. > > > > What about: > > > > Two sites are "direct neighbours" if they are able to exchange > > ** traffic betwen their sites directly, without IPv6 datagrams being > > processed by a router located at some third site. > > > > > "A multihoming strategy MAY require cooperation between a site > > > and its transit providers, but MUST NOT require cooperation > > > directly between the transit providers except for direct neighbors". > >How about we leave the "except" off and revisit it if it seems really >necessary later on? I worry that any protocol that requires >coordination between competitors is doomed to failure. :( I was going to make a similar comment. Further, I will think of Multi6 as a failure if the only solution developed does wind up requiring such cooperation between competitors. Such requirement fails customers' needs in a very important way: failure of one upstream's network should NOT impact the viability of connectivity through other upstreams. While this cooperative approach is used today, it has generated a significant division between the "haves" and the "have nots" separating those who were around early and got portable IP space, and those who came later. It is my belief that such inequity must not occur in the future. Should we ultimately decide there is no other choice than upstream cooperation, then ALL sites which need to multihome MUST be subject to the same rules, and the same pain. ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-multi6@ops.ietf.org Mon Nov 12 15:02:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16749 for ; Mon, 12 Nov 2001 15:02:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 163NDd-000D35-00 for multi6-data@psg.com; Mon, 12 Nov 2001 11:58:09 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 163NDc-000D2y-00 for multi6@ops.ietf.org; Mon, 12 Nov 2001 11:58:08 -0800 Subject: RE: additional requirement: cooperation Date: Mon, 12 Nov 2001 11:58:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046403AF02@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Thread-Topic: additional requirement: cooperation Thread-Index: AcFrsJXsyOV0C8q/THyBzYXG0mjjdAAAXg4w From: "Michel Py" To: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA16749 I will think of Multi6 as a failure if there is no solution developed because the requirements are too specific. Let's stop dreaming and keep in mind that the requirements' goals are to be guidelines to actual solutions, not to wishes. As mentioned in 3.1.5, "the current multihoming solution is quite straightforward to deploy and maintain" which includes the necessary peering and provider cooperation. There would be an inconsistency if the requirements draft was to say that it is too bad to prohibit the use of a similar solution in IPv6. Michel. From owner-multi6@ops.ietf.org Mon Nov 12 20:19:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26198 for ; Mon, 12 Nov 2001 20:19:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 163SCe-000MeW-00 for multi6-data@psg.com; Mon, 12 Nov 2001 17:17:28 -0800 Received: from zeus.anet-chi.com ([207.7.4.6]) by psg.com with esmtp (Exim 3.33 #1) id 163SCd-000MeO-00 for multi6@ops.ietf.org; Mon, 12 Nov 2001 17:17:27 -0800 Received: from pamela (as1b-31.chi.il.dial.anet.com [198.92.157.31]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id TAA03446 for ; Mon, 12 Nov 2001 19:17:34 -0600 (CST) Message-ID: <0b0801c16be2$47b35300$3200a8c0@pamela> From: "Jim Fleming" To: Subject: Fw: Can we assume this it the "official" ICANN and IETF Architecture Picture ? Date: Mon, 12 Nov 2001 19:26:53 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Jim Fleming" To: "Jeroen Massar" ; "'D. J. Bernstein'" ; Cc: ; ; "Brian E Carpenter" ; ; "NCC Discuss list (E-mail)" Sent: Monday, November 12, 2001 7:11 PM Subject: Can we assume this it the "official" ICANN and IETF Architecture Picture ? > Can we assume this it the "official" ICANN and IETF Architecture Picture ? > > ----------------------------------------------------- > From: "Jeroen Massar" > > http://unfix.org/projects/ipv6/IPv6andIPv4.gif > > > > It nicely (at least I hope ;) illustrates: > > - IPv6 to IPv4 traffic using NAT-PT > > - IPv6 in IPv4 to IPv6 traffic using 6to4 and 6in4 > > - IPv4 to IPv6 traffic using winsock5/6tunnel/... > > - native IPv6 well duh ;) > > - native IPv4 duh again... > ----------------------------------------------------- > > > > > > Jim Fleming > http://www.IPv8.info > IPv16....One Better !! > From owner-multi6@ops.ietf.org Mon Nov 19 15:28:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23001 for ; Mon, 19 Nov 2001 15:28:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 165uxX-00003P-00 for multi6-data@psg.com; Mon, 19 Nov 2001 12:24:03 -0800 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.33 #1) id 165uxW-00003J-00 for multi6@ops.ietf.org; Mon, 19 Nov 2001 12:24:02 -0800 Received: (qmail 14808 invoked by uid 1000); 19 Nov 2001 20:23:59 -0000 Date: Mon, 19 Nov 2001 15:23:57 -0500 From: Joe Abley To: multi6@ops.ietf.org Subject: draft-ietf-multi6-multihoming-requirements-02 Message-ID: <20011119152355.O2101@buffoon.automagic.org> References: <20011112050812.T20667@buffoon.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011112050812.T20667@buffoon.automagic.org> User-Agent: Mutt/1.3.22.1i Sender: owner-multi6@ops.ietf.org Precedence: bulk The following is the text of the candidate1 draft with minor revisions relating to the small amount of discussion over the past week. Main changes: + I included the cooperation requirement, since nobody seemed to object to it. I didn't include Michael's proposed changes to that clause, since there seemed to be some (small amount of) dissent about them. Further discussion on that paragraph would be useful, perhaps. + minor change of "internet" to "Internet". Complete draft with change bars, less pagination, follows. If there is no further discussion in the next day or so I'd like to mail it in comfortably before the deadline as -02. Joe Network Working Group B. Black Internet-Draft Layer8 Networks |Expires: May 20, 2002 V. Gill J. Abley MFN | November 19, 2001 Requirements for IPv6 Site-Multihoming Architectures | draft-ietf-multi6-multihoming-requirements-02 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. | This Internet-Draft will expire on May 20, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract 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. This document outlines a set of requirements for a new IPv6 site- multihoming architecture. 1. Introduction Current IPv4 site-multihoming practices have been added on to the CIDR architecture [2], which assumes that routing table entries can be aggregated based upon a hierarchy of customers and service providers [1]. However, it appears that this hierarchy is being supplanted by a dense mesh of interconnections [9]. Additionally, there has been an enormous growth in the number of multihomed sites. For purposes of redundancy and load-sharing, the multihomed address blocks, which are almost always a longer prefix than the provider aggregate, are announced along with the larger, covering aggregate originated by the provider. This contributes to the rapidly-increasing size of the global routing table. This explosion places significant stress on the inter-provider routing system. | Continued growth of both the Internet and the practice of site- multihoming will seriously exacerbate this stress. The site- multihoming architecture for IPv6 should allow the routing system to scale more pleasantly. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [4]. A "site" is an entity autonomously operating a network using IP and, in particular, determining the addressing plan and routing policy for that network. This definition is intended to be equivalent to "enterprise" as defined in [3]. A "transit provider" operates a site which directly provides connectivity to the Internet to one or more external sites. The connectivity provided extends beyond the transit provider's own site. A transit provider's site is directly connected to the sites for which it provides transit. A "multihomed" site is one with more than one transit provider. "Site-multihoming" is the practice of arranging a site to be multi- homed. The term "re-homing" denotes a transition of a site between two states of connectedness, due to a change in the connectivity between the site and its transit providers' sites. 3. Multihoming Requirements 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]. 3.1.1 Redundancy By multihoming, a site MUST be able to insulate itself from certain failure modes within one or more transit providers, as well as failures in the network providing interconnection among one or more transit providers. Infrastructural commonalities below the IP layer may result in connectivity which is apparently diverse sharing single points of failure. For example, two separate DS3 circuits ordered from different suppliers and connecting a site to independent transit providers may share a single conduit from the street into a building; in this case backhoe-fade of both circuits may be experienced due to a single incident in the street. The two circuits are said to "share fate". The multihoming architecture MUST accommodate (in the general case, issues of shared fate notwithstanding) continuity of connectivity during the following failures: o Physical failure, such as a fiber cut, or router failure, o Logical link failure, such as a misbehaving router interface, o Routing protocol failure, such as a BGP peer reset, o Transit provider failure, such as a backbone-wide IGP failure, and o Exchange failure, such as a BGP reset on an inter-provider peering. 3.1.2 Load Sharing By multihoming, a site MUST be able to distribute both inbound and outbound traffic between multiple transit providers. This requirement is for concurrent use of the multiple transit providers, not just the usage of one provider over one interval of time and another provider over a different interval. 3.1.3 Performance By multihoming, a site MUST be able to protect itself from performance difficulties directly between the site's transit providers. For example, suppose site E obtains transit from transit providers T1 and T2, and there is long-term congestion between T1 and T2. The multihoming architecture MUST allow E to ensure that in normal operation none of its traffic is carried over the congested interconnection T1-T2. The process by which this is achieved MAY be a manual one. A multi-homed site MUST be able to distribute inbound traffic from particular multiple transit providers according to the particular address range within their site which is sourcing or sinking the traffic. 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. 3.1.5 Simplicity As any proposed multihoming solution must be deployed in real networks with real customers, simplicity is paramount. The current multihoming solution is quite straightforward to deploy and maintain. A new IPv6 multihoming proposal MUST NOT be substantially more complex to deploy and operate than current IPv4 multihoming practices. 3.1.6 Transport-Layer Survivability Multihoming solutions MUST provide re-homing transparency for transport-layer sessions; i.e. exchange of data between devices on the multihomed site and devices elsewhere on the Internet may proceed with no greater interruption than that associated with the transient packet loss during the re-homing event. New transport-layer sessions MUST be able to be created following a re-homing event. Transport-layer sessions include those involving transport-layer protocols such as TCP, UDP and SCTP over IP. Applications which communicate over raw IP and other network-layer protocols MAY also enjoy re-homing transparency. 3.2 Additional Requirements 3.2.1 Scalability Current IPV4 multihoming practices contribute to the significant growth currently observed in the state held in the global inter- provider routing system; this is a concern both because of the hardware requirements it imposes and also because of the impact on the stability of the routing system. This issue is discussed in great detail in [9]. A new IPv6 multihoming architecture MUST scale to accommodate orders of magnitude more multi-homed sites without imposing unreasonable requirements on the routing system. 3.2.2 Impact on Routers The solution MAY require changes to IPv6 router implementations, but these changes must be either minor, or in the form of logically separate functions added to existing functions. Such changes MUST NOT prevent normal single-homed operation, and routers implementing these changes must be able to interoperate fully with hosts and routers not implementing them. 3.2.3 Impact on Hosts The solution MUST NOT destroy IPv6 connectivity for a legacy host implementing RFC 2373 [5], RFC 2460 [7], RFC 2553 [8] and other basic IPv6 specifications current in November 2001. That is to say, if a host can work in a single-homed site, it must still be able to work in a multihomed site, even if it cannot benefit from site- multihoming. It would be compatible with this requirement for such a host to lose connectivity if a site lost connectivity to one transit provider, despite the fact that other transit provider connections were still operational. If the solution requires changes to the host stack, these changes MUST be either minor, or in the form of logically separate functions added to existing functions. If the solution requires changes to the socket API and/or the transport layer, it MUST be possible to retain the original socket API and transport protocols in parallel, even if they cannot benefit from multihoming. The multi-homing solution MAY allow host or application changes if that would enhance session survivability. 3.2.4 Interaction between Hosts and the Routing System The solution MAY involve interaction between a site's hosts and its routing system; such an interaction MUST be simple, scaleable and securable. 3.2.5 Operations and Management It MUST be posssible for staff responsible for the operation of a site to monitor and configure the site's multihoming system. |3.2.6 Cooperation between Transit Providers | A multihoming strategy MAY require cooperation between a site and its | transit providers, but MUST NOT require cooperation directly between | the transit providers. 4. Security Considerations A multihomed site MUST be no more vulnerable to security breaches than a non-multihomed site. References [1] Abley, J., Black, B. and V. Gill, "IPv4 Multihoming Motivation, Practices and Limitations (work-in-progress)", I-D draft-ietf- multi6-v4-multihoming-00, June 2001, . [2] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter- Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993. [3] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [5] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [6] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggregatable Global Unicast Address Format", RFC 2374, July 1998. [7] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [8] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 2553, March 1999. [9] Huston, G., "Analyzing the Internet's BGP Routing Table", January 2001. Authors' Addresses Benjamin Black Layer8 Networks EMail: ben@layer8.net Vijay Gill MFN 8075 Leesburg Pike Suite 300 Vienna, VA 22182 US Phone: +1 410 262 0660 EMail: vgill@mfn.com Joe Abley MFN 10805 Old River Road Komoka, ON N0L 1R0 Canada Phone: +1 519 641 3738 EMail: jabley@mfn.com Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. From owner-multi6@ops.ietf.org Mon Nov 19 17:34:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00625 for ; Mon, 19 Nov 2001 17:34:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 165wvP-0003RZ-00 for multi6-data@psg.com; Mon, 19 Nov 2001 14:29:59 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 165wvO-0003RN-00 for multi6@ops.ietf.org; Mon, 19 Nov 2001 14:29:58 -0800 Subject: RE: draft-ietf-multi6-multihoming-requirements-02 Date: Mon, 19 Nov 2001 14:29:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046403AF1E@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Thread-Topic: draft-ietf-multi6-multihoming-requirements-02 Thread-Index: AcFxO31GWEBLYJv2QECPIoL8aMi3XgACWi6A From: "Michel Py" To: "Joe Abley" , Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA00625 Joe and multi6 folk, It seems to me there is a circular reference issue here, two requirements mutually incompatible that could lead to the impossibility to provide a proposal that would meet all the requirements. More specifically, I don't see how it would be possible to meet the following requirement: >> 3.1.3 Performance >> A multi-homed site MUST be able to distribute inbound traffic from >> particular multiple transit providers according to the particular >> address range within their site which is sourcing or sinking the >> traffic. Without some form of cooperation (exchange of routes for the IPv4 model) between directly connected transit providers ("direct peers") which is the following. >> |3.2.6 Cooperation between Transit Providers >> | A multihoming strategy MAY require cooperation between a site and its >> | transit providers, but MUST NOT require cooperation directly between >> | the transit providers. In other words, the "performance" requirement, also referred to as "global load sharing" (the capability to receive traffic from other parties by the link closer to them, avoiding NAPs or interconnects) is in IPv4 a function of routing. Regardless of the way it will be done in IPv6, it is highly improbable that it could be achieved without collaboration between direct peers, for the same reason it is highly unlikely improbable without cooperation between a site and its transit providers. As I mentioned before, this is extremely restrictive and would prevent the development of any new network-layer protocol. It could be argued that exchanging routes between directly connected transit providers is a form of cooperation. I think both requirements are good, but that the cooperation between a site and its transit provider must be extended to transit providers that are direct peers as well. I encourage every multi6 folk to comment on this, Michel. -----Original Message----- From: Joe Abley [mailto:jabley@nlri.org] Sent: Monday, November 19, 2001 12:24 PM To: multi6@ops.ietf.org Subject: draft-ietf-multi6-multihoming-requirements-02 The following is the text of the candidate1 draft with minor revisions relating to the small amount of discussion over the past week. Main changes: + I included the cooperation requirement, since nobody seemed to object to it. I didn't include Michael's proposed changes to that clause, since there seemed to be some (small amount of) dissent about them. Further discussion on that paragraph would be useful, perhaps. + minor change of "internet" to "Internet". From owner-multi6@ops.ietf.org Mon Nov 19 21:08:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06606 for ; Mon, 19 Nov 2001 21:08:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 1660KU-0009Ch-00 for multi6-data@psg.com; Mon, 19 Nov 2001 18:08:06 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 1660KT-0009Cb-00 for multi6@ops.ietf.org; Mon, 19 Nov 2001 18:08:06 -0800 Subject: (multi6) draft-ietf-multi6-multihoming-requirements-02 Date: Mon, 19 Nov 2001 18:08:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046403AF1F@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Thread-Topic: (multi6) draft-ietf-multi6-multihoming-requirements-02 Thread-Index: AcFxO31GWEBLYJv2QECPIoL8aMi3XgAKY/lQ From: "Michel Py" To: "Joe Abley" , Cc: "Brian E Carpenter" Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA06606 Joe and multi6 folk, I wonder why you have not included in the draft something about "3.1.4 Policy" to clarify it, such as what quoted below, which everyone seems to agree on. [Brian Carpenter wrote] >> Joe Abley already responded and I agree with him. Like any traffic >> classification policy, this one would have restricted applicability >> in the case of ESP traffic. In fact the issues are essentially if >> not totally identical to those for diffserv classification. If you >> can't classify for diffserv reasons, you can't classify for multi6 >> reasons either and default policy will apply. There is nothing >> special here - multi6 is simply added to the list of modules that >> look at policy (i.e. a local config table) as part of their decision >> process. Michel. From owner-multi6@ops.ietf.org Mon Nov 19 21:08:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06618 for ; Mon, 19 Nov 2001 21:08:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 1660Jl-0009BZ-00 for multi6-data@psg.com; Mon, 19 Nov 2001 18:07:21 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 1660Jk-0009BT-00 for multi6@ops.ietf.org; Mon, 19 Nov 2001 18:07:21 -0800 Subject: (multi6) additional requirement: cooperation Date: Mon, 19 Nov 2001 18:07:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046403AF20@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Thread-Topic: (multi6) additional requirement: cooperation Thread-Index: AcFrr4qei2NwOg1xSOKxhj98apX2ZwFtwF1g From: "Michel Py" To: "Shane Kerr" Cc: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA06618 Multi6 folk, Maybe we need a clearer definition of "cooperation between transit providers", or examples of what is cooperation and what is not. - Is an exchange of routes (bgp peering) cooperation? - Is a statically configured tunnel cooperation? - Is a dynamically configured tunnel (6to4 like) cooperation? - [add your own] My take on it: yes yes no. Everyone's comments welcome! Feel free to comment on my previous posting about the performance requirement possibly being incompatible with the cooperation one. Michel. From owner-multi6@ops.ietf.org Tue Nov 20 02:50:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01597 for ; Tue, 20 Nov 2001 02:50:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 1665cb-000HBx-00 for multi6-data@psg.com; Mon, 19 Nov 2001 23:47:09 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.33 #1) id 1665ca-000HBq-00 for multi6@ops.ietf.org; Mon, 19 Nov 2001 23:47:08 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fAK7ksT32683; Tue, 20 Nov 2001 09:46:54 +0200 Date: Tue, 20 Nov 2001 09:46:54 +0200 (EET) From: Pekka Savola To: Michel Py cc: Shane Kerr , Subject: Re: (multi6) additional requirement: cooperation In-Reply-To: <2B81403386729140A3A899A8B39B046403AF20@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 19 Nov 2001, Michel Py wrote: > Maybe we need a clearer definition of "cooperation between transit > providers", or examples of what is cooperation and what is not. > > - Is an exchange of routes (bgp peering) cooperation? > - Is a statically configured tunnel cooperation? > - Is a dynamically configured tunnel (6to4 like) cooperation? > - [add your own] > > My take on it: yes yes no. Mine: no *), yes, not sure what you mean but probably no. *) it's unrealistic to believe transits don't exchanges routes. Else we'd have to buy transit from every transit operator in the world. To be more specific, co-operation would be having to set up some special exchanging of routes. Ie, IMO co-operation requirement to me seems simple: do the transits have to set up or take into consideration something specific, just for this customer? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-multi6@ops.ietf.org Tue Nov 20 04:56:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03034 for ; Tue, 20 Nov 2001 04:56:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 1667cw-000KQI-00 for multi6-data@psg.com; Tue, 20 Nov 2001 01:55:38 -0800 Received: from miata.procket.com ([209.140.237.2]) by psg.com with esmtp (Exim 3.33 #1) id 1667cv-000KQC-00 for multi6@ops.ietf.org; Tue, 20 Nov 2001 01:55:37 -0800 Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id fAK9t08A012949; Tue, 20 Nov 2001 01:55:00 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id fAK9sxqO018285; Tue, 20 Nov 2001 01:54:59 -0800 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15354.10355.712859.753200@alpha-tli.procket.com> Date: Tue, 20 Nov 2001 01:54:59 -0800 To: Pekka Savola Cc: Michel Py , Shane Kerr , Subject: Re: (multi6) additional requirement: cooperation In-Reply-To: References: <2B81403386729140A3A899A8B39B046403AF20@server2000.arneill-py.sacramento.ca.us> X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit | *) it's unrealistic to believe transits don't exchanges routes. Else we'd | have to buy transit from every transit operator in the world. To be more | specific, co-operation would be having to set up some special exchanging | of routes. I don't think the comments were there to preclude transits from interacting. Instead, the requirement is that we can still make multihoming work even if the multihomed site selects two transit providers who refuse to cooperate with each other. Tony From owner-multi6@ops.ietf.org Tue Nov 20 10:44:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15657 for ; Tue, 20 Nov 2001 10:44:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 166Czd-0002oj-00 for multi6-data@psg.com; Tue, 20 Nov 2001 07:39:25 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 166Czc-0002oc-00 for multi6@ops.ietf.org; Tue, 20 Nov 2001 07:39:24 -0800 Subject: RE: (multi6) additional requirement: cooperation Date: Tue, 20 Nov 2001 07:39:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2B81403386729140A3A899A8B39B046403AF22@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Thread-Topic: (multi6) additional requirement: cooperation Thread-Index: AcFxl6ocmTJD16SSRPWceaAgTgWKegAQK3qw From: "Michel Py" To: "Pekka Savola" , "Joe Abley" Cc: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA15657 Multi6 folk, I like Pekka's way better than my "direct peers", actually. Could we make it: 3.2.6 Cooperation between Transit Providers A multihoming strategy MAY require cooperation between a site and its | transit providers, but MUST NOT require site-specific cooperation directly between the transit providers. -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] *) it's unrealistic to believe transits don't exchanges routes. Agree. From owner-multi6@ops.ietf.org Wed Nov 21 10:25:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19496 for ; Wed, 21 Nov 2001 10:25:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 166ZCP-0001T1-00 for multi6-data@psg.com; Wed, 21 Nov 2001 07:22:05 -0800 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.33 #1) id 166ZCO-0001Sr-00 for multi6@ops.ietf.org; Wed, 21 Nov 2001 07:22:04 -0800 Received: (qmail 37411 invoked by uid 1000); 21 Nov 2001 15:22:02 -0000 Date: Wed, 21 Nov 2001 10:22:02 -0500 From: Joe Abley To: multi6@ops.ietf.org Subject: draft-ietf-multi6-multihoming-requirements-02 submitted Message-ID: <20011121102202.I2101@buffoon.automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.22.1i Sender: owner-multi6@ops.ietf.org Precedence: bulk The draft submitted was the revision I sent to this list a day or three ago. ----- Forwarded message from Internet Draft Submission Manager ----- Delivered-To: jabley-nlri-jabley@nlri.org Date: Wed, 21 Nov 2001 01:07:35 -0500 (EST) To: jabley@nlri.org Subject: Re: draft-ietf-multi6-multihoming-requirements-02.txt In-Reply-To: <20011121010732.Y2101@buffoon.automagic.org> X-URL: http://www.ietf.org/ Subject: Autoreply from Internet Draft Submission Manager From: ietfauto@ietf.org (Internet Draft Submission Manager) Hello, This message is being sent to acknowledge receipt of your submission (or message) to internet-drafts@ietf.org Please note: if you submitted a completely new document (-00), it will NOT be processed or announced. You must resubmit after the Salt Lake City IETF meeting. If you attempt to update an initial document received between November 5-14, it will NOT be processed or announced. You must resubmit after the Salt Lake City IETF meeting. AS you may surmise, this is an extremly busy week. Be advised that it may take a number of days to process and announce your document. Our goal is to process and announce all valid Internet-Draft submissions by December 3, 2001 at the latest. We appreciate your understanding and patience. Internet-Drafts Administrator ----- End forwarded message ----- From owner-multi6@ops.ietf.org Wed Nov 21 19:46:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14878 for ; Wed, 21 Nov 2001 19:46:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 166hw8-0000WF-00 for multi6-data@psg.com; Wed, 21 Nov 2001 16:41:52 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 166hw7-0000W8-00 for multi6@ops.ietf.org; Wed, 21 Nov 2001 16:41:51 -0800 Subject: (multi6) Salt Lake meeting agenda Date: Wed, 21 Nov 2001 16:41:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046403AF26@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Thread-Topic: (multi6) Salt Lake meeting agenda Thread-Index: AcFy7ex3YU0V3WZXTv+XKuqxKCP0EQ== From: "Michel Py" To: , , Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA14878 Multi6 chairs and folks, I would like a small slot during the Salt Lake meeting to discuss issues with draft-multi6-py-mhtp-01.txt (it is in the pipe as an individual submission; in the meantime the text can be found at http://209.233.126.65/draft-multi6-py-mhtp-01.txt). Regards, Michel. TUESDAY, December 11, 2001 1415-1515 Afternoon Sessions II OPS multi6 Site Multihoming in IPv6 WG From owner-multi6@ops.ietf.org Wed Nov 28 06:03:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29573 for ; Wed, 28 Nov 2001 06:03:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 1692SK-000ID7-00 for multi6-data@psg.com; Wed, 28 Nov 2001 03:00:44 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.33 #1) id 1692SJ-000ID0-00 for multi6@ops.ietf.org; Wed, 28 Nov 2001 03:00:43 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29330; Wed, 28 Nov 2001 06:00:35 -0500 (EST) Message-Id: <200111281100.GAA29330@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: multi6@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-multi6-multihoming-requirements-02.txt Date: Wed, 28 Nov 2001 06:00:35 -0500 Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart 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-02.txt Pages : 12 Date : 27-Nov-01 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-02.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-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-multi6-multihoming-requirements-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011127135813.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-multi6-multihoming-requirements-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-multi6-multihoming-requirements-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011127135813.I-D@ietf.org> --OtherAccess-- --NextPart--