From owner-multi6@ops.ietf.org Mon Jul 2 10:36:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26862 for ; Mon, 2 Jul 2001 10:36:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15H4mH-0000BY-00 for multi6-data@psg.com; Mon, 02 Jul 2001 07:34:17 -0700 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.30 #1) id 15H4mE-0000Aq-00 for multi6@ops.ietf.org; Mon, 02 Jul 2001 07:34:15 -0700 Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA28660; Mon, 2 Jul 2001 15:33:41 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA26894; Mon, 2 Jul 2001 15:33:39 +0100 Message-ID: <3B40863F.8B671AC9@hursley.ibm.com> Date: Mon, 02 Jul 2001 09:33:35 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Joe Abley CC: multi6@ops.ietf.org Subject: Re: [jabley@automagic.org: unscientific multi-homing survey: results] References: <20010629181041.I26708@buddha.home.automagic.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Joe Abley wrote: > > I sent some questions about multi-homing to the nanog list earlier > this week, and a few people replied. This is a summary. > > This is extremely non-rigorous, but might give a tiny bit of > insight into something, maybe. ... > > + what is *bad* about the way that multi-homing works in IPv4? Interesting that nobody mentioned BGP table bloat, and only a couple mentioned convergence overhead - i.e. individual ISPs are not caused immediate pain by the global damage. Brian From owner-multi6@ops.ietf.org Mon Jul 2 14:59:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22629 for ; Mon, 2 Jul 2001 14:59:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15H8uB-00087N-00 for multi6-data@psg.com; Mon, 02 Jul 2001 11:58:43 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.30 #1) id 15H8u8-00087G-00 for multi6@ops.ietf.org; Mon, 02 Jul 2001 11:58:41 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Mon, 02 Jul 2001 10:29:45 -0700 Received: from eagleswings [192.168.123.14] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 5D254025CA3B4FD6A2EE20E808D1DD1A for plus 4 more; Mon, 02 Jul 2001 10:29:44 -0700 Reply-To: From: "Tony Hain" To: "Tony Li" , "Joe Abley" Cc: "Randy Bush" , "Ben Black" , Subject: RE: requirements draft revision Date: Mon, 2 Jul 2001 10:29:44 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <15166.9307.556182.633818@alpha-tli.procket.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: D85BEC37-47A94487-8C10FD67-D9DD89F2 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony Li wrote: > | On the other hand, if you have a better definition, let's hear it. > > > Randy sent you a fine definition that matches common accepted > usage of the term. Using that would be easier than trying to > get the rest of the industry to change their definition. My concern is that the term was defined and is assumed to be used in the context of a tree structured interconnect environment, rather than the briar patch of today's reality. After spending the last couple of days pounding on rocks in the garden, let me try a couple of slightly modified definitions. Enterprise: defines policy for a uniquely identifiable address prefix, and expresses that policy to N providers. Transit provider: T, to enterprise E accepts and propagates E's policy for the uniquely identified prefix to the parts of the Internet within and extending beyond T. The relationship between T & E may be direct or indirect. Getting back to Joe's example (w/small extension): A --- B --- C --- F | | D E \ / -G- F defines policy for prefix 123.123.123/24; therefore is an enterprise. C defines policy for prefix 123.123/16; therefore is an enterprise. C propagates F's policy to B & E; therefore is a transit provider to F B defines a policy for 222.222.222/24; therefore is an enterprise. C propagates B's policy to E, and D & E propagate it to G; therefore C,D,&E are transit providers to B B accepts policies from C for the aggregate 123.123/16 & the enterprise 123.123.123/24, propagating those to A & D; therefore is a transit provider to C and F. ** alternatively B accepts policies from C for 123.123/16 & 123.123.123/24, but instead of propagating those to A & D, defines a different policy for the aggregate 123/8; therefore is not a transit provider to C or F. I think this fits what Joe has been saying, without implying directionality, or customer relationship. The enterprise is defined in terms of its ability to define policy for a prefix, rather than size, complexity, or number of connections. It also does not require that the enterprise be able to 'ensure' an outcome, but allows expression of policy to any number of providers. It also removes from discussion the entities that are multi-homed but adapt to the current network state rather than express a policy to affect it. Tony From owner-multi6@ops.ietf.org Mon Jul 2 19:06:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28787 for ; Mon, 2 Jul 2001 19:06:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15HCj2-000EkN-00 for multi6-data@psg.com; Mon, 02 Jul 2001 16:03:28 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.30 #1) id 15HCiz-000Ek6-00 for multi6@ops.ietf.org; Mon, 02 Jul 2001 16:03:26 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Mon, 02 Jul 2001 15:15:00 -0700 Received: from eagleswings [192.168.123.14] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id C6F4AE4DD24943898D29A270D68A7147 for plus 5 more; Mon, 02 Jul 2001 15:15:00 -0700 Reply-To: From: "Tony Hain" To: Cc: , , , , Subject: Provider-Independent IPv6 address format & usage drafts Date: Mon, 2 Jul 2001 15:14:59 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: ADA5AF46-2C3341AA-A6D16692-57CC9371 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Here are pointers to the current -00 versions of the Provider-Independent address format and usage drafts I have been working on. http://www.tndh.net/~tony/ietf/draft-hain-ipv6-PI-addr-fmt-00.txt http://www.tndh.net/~tony/ietf/draft-hain-ipv6-PI-addr-use-00.txt I would expect the first to be a document for the IPv6 wg, while the second would be for the Muti6 wg. I do not expect these to be wg documents before any discussion at London, so please list them as draft-hain for now, and we will rename when appropriate. Thanks, Tony From owner-multi6@ops.ietf.org Tue Jul 3 15:43:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17302 for ; Tue, 3 Jul 2001 15:43:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15HW4G-000OVL-00 for multi6-data@psg.com; Tue, 03 Jul 2001 12:42:40 -0700 Received: from arpa.it.uc3m.es ([163.117.139.120]) by psg.com with esmtp (Exim 3.30 #1) id 15HW4E-000OV8-00 for multi6@ops.ietf.org; Tue, 03 Jul 2001 12:42:39 -0700 Received: from avispa (avispa.it.uc3m.es [163.117.139.178]) by arpa.it.uc3m.es (8.9.3/8.9.3) with SMTP id VAA31212; Tue, 3 Jul 2001 21:42:26 +0200 From: "marcelo" To: Cc: , Subject: Policy based ISP selection Date: Tue, 3 Jul 2001 21:42:49 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, We have been working in the following idea to provide ISP selection based on internal policies: Enabling Policy based ISP selection in multi-homed sites through address selection mechanism. The mechanism presented performs ISP selection in multi-homed sites. The selection is based on previously defined policies and it is done on a per application basis. Topology The following configuration is considered: ___________________________________________ | Internet | | hostB | |___________________________________________| | | | | +----+ +----+ |ISPA| |ISPB| |BRA | |BRB | +----+ +----+ | | link1 | | link2 __|____________________________|___ | RA RB | | | | | | ------------------------------- | | | | | hostA | | PrefA:Prefsite:hostA | | PrefB:Prefsite:hostA | | | |___________________________________| In the configuration above, the multi-homed site is connected to the Internet through 2 ISPs (ISPA and ISPB) using link1 and link2 respectively. Link 1 is established between site exit router RA and ISP border router BRA. Similarly, Link 2 is established between site exit router RB and ISP border router BRB. Each of the ISP has delegated an address space to the site: ISPA has delegated PRefA:Prefsite::/nA+n and ISPB has delegated PrefB:Prefsite::/nB+n. Host A belongs to the multi-homed site and it has one interface with the following unicast addresses assigned: two global addresses, one form each ISP, PrefA:Prefsite:hostA and PrefB:Prefsite:hostA, a site-local address and a link-local address. Host B does not belong to the multi-homed site and is has only one global address, hostB. The presented mechanism allows ISP selection for outbound and inbound packets of internally generated communications (i.e. the first packet of the communication is generated by a host that belongs to the site) and for outbound packets of externally initiated communications. Note that ISP selection of inbound packets of externally generated connections is the result of the destination address selection algorithm after evaluation of DNS response. ISP selection tools: It is relevant to note that current ISP based address aggregation imposes that ISP selection for inbound packets of an internally generated communication is determined by the source address of the first packet. Consequently, if no intermediate devices performs any changes in the packets, the source address selection mechanism of the host that initiates the communication is naturally involved in the ISP selection mechanism. In order to provide a coherent path for outbound and inbound packets of the same communication, the source address selection mechanism and outbound packets ISP selection mechanism must work in coordinated manner. Internally initiated communications: Outbound packets: the ISP selection is performed using routing headers that include site exit routers connecting to the selected ISP. Inbound packets: the ISP is selected when selecting the source address of the communication initiator packet. If an address with PrefA::/nA prefix is used, inbound packets will be routed through ISPA. Similarly, if an address with PrefB::/nB prefix is used, inbound packets will be routed through ISPB. Externally initiated communications: Inbound packets: ISP selection is the result of the destination address selection algorithm after evaluation of DNS response at the initiating host. The tool available to the site for ISP selection is appropriate definition of DNS responses. This is out of the scope of the presented mechanism. Outbound packets: the ISP selection is performed using routing headers that include site exit routers connecting to the selected ISP. Source address selection algorithm. The mechanism presented is a modification of the source address selection algorithm presented in draft-ietf-ipng-default-addr-select-04. Basically a modified Policy table is proposed. If the source address selection algorithm or the policy table are not familiar to the reader, a summary of the algorithm is presented. Source Address selection algorithm The source address selection mechanism relies on a set of rules to obtain the most appropriate source address from a destination address and a given policy. The policy table is a longest prefix match table that takes an address (source or destination) as input, and returns two values: a label value and a precedence value. The label value is used to match destination addresses with source addresses. The precedence value is used to select destination address among a set of available destination addresses, and it is not needed for source address selection, so it will not be introduced. The process of source address selection is as follows: Once a packet is to be sent to a destination address, the host routing mechanisms will select the interface used for delivering the packet. After this, source address selection is started. Source address selection algorithm has as inputs a destination address (D) and first two source addresses (SA and SB) from a proposed candidate set (all the possible source addresses of the outgoing interface), and it returns the source address that fits best with the destination address. Successive pair-wise comparisons are performed throughout all candidate set to obtain the best address. The algorithm is implemented as an ordered set of rules; if a rule selects one of the two addresses no further rules are processed. Here we list the proposed rules (Sx refers to any SA and SB) - Rule 1: Prefer same address: If Sx=D then prefer Sx - Rule 2: Prefer appropriate scope: If SB has a larger scope than SA (i.e. SA is a site local address and SB is a global address) and D has a larger scope than SA then prefer SB; Otherwise, prefer SA. - Rule 3: Avoid deprecated addresses. - Rule 4: Prefer home address: This applies to mobile IP environments so it will not be discussed here. - Rule 5: Prefer outgoing interface: If SA is assigned to the interface that will be used to send the packet towards D, and SB is not, then prefer SA. Note that the previous rules can be responsible for selecting addresses that were not assigned to the outgoing interface. - Rule 6: Prefer matching label. Obtain label for SA, SB and D from policy table and compute the following condition: if label(SA)=label(D) and label(SB)<>label(D) then prefer SA. - Rule 7: Prefer public address: if SA is a public address and SB is a temporary address, then prefer SA (public and temporary addresses are discussed elsewhere [14]) - Rule 8: Use longest matched prefix. Proposed mechanism: In order to enable ISP selection through the source address selection mechanism the following changes are introduced: Policy table modifications. Port information must be included in order to be able to make application based source address selection. Besides, another entry is included in order to associate intermediate address needed to ISP selection with source addresses used, with the intention to match exit path with return path. The new policy table will then have the following aspect: Port Prefix Precedence Label Intermediate addr. P1 ::/0 60 100 ::1/128 50 0 ::/0 40 1 2002::/16 30 2 ::/96 20 3 ::ffff:0:0/96 10 4 PrefA:Prefsite::hostA/128 5 100 RA Example of policy table To perform lookup in the table, an address and optionally a port are required as inputs, and the outputs are a label value, a precedence value and optionally an intermediate routing address. The lookup algorithm first searches for matching port, and performs longest prefix match among the prefixes of all the port matching policy table entries. If no matching port is found, longest prefix match is performed with entries that do not have a specified port. Resulting behavior. In the considered multi-homing configuration, suppose that internal policies of the considered site are defined as follows: traffic with destination port P1 to several destination addresses through ISPA, and the rest of the traffic through ISPB. The host A policy table could be configured as follows to accomplish the desired behavior: Applying the defined policy table, when an application needs to communicate with a remote host D at port P1, the policy table will return the following values: For destination address D and port P1, it will return label value equal to 100 because destination and entry ports match. For source address PrefA:Prefsite::hostA, it will return label value equal to 100 and RA as an intermediate address for the routing header. For source address PrefB:Prefste::hostA, it will return label value equal to 1, because longest prefix match is applied. Final label matching leads to a resulting packet with PrefA:Prefsite::hostA as source address; RA as destination address and PA as destination port, and a routing header containing address D. This packet will then exit through ISPA, and response packets will also be routed through ISPA because their destination address will be PrefA:Prefsite::hostA. Note that all the previously described process is carried out only if the first five rules specified in the source address selection algorithm do not apply. We will next justify that rule 6, where the ISP selection mechanism resides, is reached when it is needed. Rule 1: Same address only applies when the target host is the local host, so no ISP selection is needed. Rule 2: assures that ISP selection is aimed only to traffic addressed to destinations outside the site; therefore no ISP selection is performed with site local or link-local connections. Mechanism will only work for global addresses, which is the intended behavior. To avoid being routed through exit routers when systems of the same site use ports that have been included in the policy table, site-local addressing should be deployed. Rule 3: allows the mechanism to be compatible with fault tolerance features provided by multi-homing through the Router Renumbering mechanism. So when there is a failure in an ISP, address deprecation through Router Renumbering and Router Advertising precludes the selection of addresses delegated by crashed ISP, without need to modify existing policy tables on hosts. Rule 4: does not applies, Rule 5: The interface selection in the host routing mechanism for a given destination could force selection in rule 5 if the chosen interface has not been assigned at least one address from all ISPs. Then, if one interface has an address with prefix PrefA, it also must have an address with prefix PrefB to ensure proper functioning. Contact information: marcelo@it.uc3m.es alberto@it.uc3m.es azcorra@it.uc3m.es From owner-multi6@ops.ietf.org Tue Jul 3 16:28:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18767 for ; Tue, 3 Jul 2001 16:28:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15HWmX-0000F2-00 for multi6-data@psg.com; Tue, 03 Jul 2001 13:28:25 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.30 #1) id 15HWmS-0000Ek-00 for multi6@ops.ietf.org; Tue, 03 Jul 2001 13:28:21 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Tue, 03 Jul 2001 13:28:07 -0700 Received: from eagleswings [192.168.123.14] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id C91E9E78C75648F0B54A02ECE462AFEB for plus 3 more; Tue, 03 Jul 2001 13:28:07 -0700 Reply-To: From: "Tony Hain" To: "marcelo" , Cc: , Subject: RE: Policy based ISP selection Date: Tue, 3 Jul 2001 13:28:06 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: 02D306F4-FDC24A08-A074E452-61630384 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit While I would agree there is some value in adding ports to the selection rules table, I don't believe the routing header is necessary. If host A were to send a packet to RB that the site policy wants routed through RA, a redirect will straighten it out. Using redirect would also prevent the case where the proposed policy entry points at a dead router, while the routing system knows of an alternative. Basically there is no reason to add the routing header complexity to achieve the policy goal. -----Original Message----- From: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]On Behalf Of marcelo Sent: Tuesday, July 03, 2001 12:43 PM To: multi6@ops.ietf.org Cc: alberto@it.uc3m.es; azcorra@it.uc3m.es Subject: Policy based ISP selection Hi, We have been working in the following idea to provide ISP selection based on internal policies: Enabling Policy based ISP selection in multi-homed sites through address selection mechanism. The mechanism presented performs ISP selection in multi-homed sites. The selection is based on previously defined policies and it is done on a per application basis. Topology The following configuration is considered: ___________________________________________ | Internet | | hostB | |___________________________________________| | | | | +----+ +----+ |ISPA| |ISPB| |BRA | |BRB | +----+ +----+ | | link1 | | link2 __|____________________________|___ | RA RB | | | | | | ------------------------------- | | | | | hostA | | PrefA:Prefsite:hostA | | PrefB:Prefsite:hostA | | | |___________________________________| In the configuration above, the multi-homed site is connected to the Internet through 2 ISPs (ISPA and ISPB) using link1 and link2 respectively. Link 1 is established between site exit router RA and ISP border router BRA. Similarly, Link 2 is established between site exit router RB and ISP border router BRB. Each of the ISP has delegated an address space to the site: ISPA has delegated PRefA:Prefsite::/nA+n and ISPB has delegated PrefB:Prefsite::/nB+n. Host A belongs to the multi-homed site and it has one interface with the following unicast addresses assigned: two global addresses, one form each ISP, PrefA:Prefsite:hostA and PrefB:Prefsite:hostA, a site-local address and a link-local address. Host B does not belong to the multi-homed site and is has only one global address, hostB. The presented mechanism allows ISP selection for outbound and inbound packets of internally generated communications (i.e. the first packet of the communication is generated by a host that belongs to the site) and for outbound packets of externally initiated communications. Note that ISP selection of inbound packets of externally generated connections is the result of the destination address selection algorithm after evaluation of DNS response. ISP selection tools: It is relevant to note that current ISP based address aggregation imposes that ISP selection for inbound packets of an internally generated communication is determined by the source address of the first packet. Consequently, if no intermediate devices performs any changes in the packets, the source address selection mechanism of the host that initiates the communication is naturally involved in the ISP selection mechanism. In order to provide a coherent path for outbound and inbound packets of the same communication, the source address selection mechanism and outbound packets ISP selection mechanism must work in coordinated manner. Internally initiated communications: Outbound packets: the ISP selection is performed using routing headers that include site exit routers connecting to the selected ISP. Inbound packets: the ISP is selected when selecting the source address of the communication initiator packet. If an address with PrefA::/nA prefix is used, inbound packets will be routed through ISPA. Similarly, if an address with PrefB::/nB prefix is used, inbound packets will be routed through ISPB. Externally initiated communications: Inbound packets: ISP selection is the result of the destination address selection algorithm after evaluation of DNS response at the initiating host. The tool available to the site for ISP selection is appropriate definition of DNS responses. This is out of the scope of the presented mechanism. Outbound packets: the ISP selection is performed using routing headers that include site exit routers connecting to the selected ISP. Source address selection algorithm. The mechanism presented is a modification of the source address selection algorithm presented in draft-ietf-ipng-default-addr-select-04. Basically a modified Policy table is proposed. If the source address selection algorithm or the policy table are not familiar to the reader, a summary of the algorithm is presented. Source Address selection algorithm The source address selection mechanism relies on a set of rules to obtain the most appropriate source address from a destination address and a given policy. The policy table is a longest prefix match table that takes an address (source or destination) as input, and returns two values: a label value and a precedence value. The label value is used to match destination addresses with source addresses. The precedence value is used to select destination address among a set of available destination addresses, and it is not needed for source address selection, so it will not be introduced. The process of source address selection is as follows: Once a packet is to be sent to a destination address, the host routing mechanisms will select the interface used for delivering the packet. After this, source address selection is started. Source address selection algorithm has as inputs a destination address (D) and first two source addresses (SA and SB) from a proposed candidate set (all the possible source addresses of the outgoing interface), and it returns the source address that fits best with the destination address. Successive pair-wise comparisons are performed throughout all candidate set to obtain the best address. The algorithm is implemented as an ordered set of rules; if a rule selects one of the two addresses no further rules are processed. Here we list the proposed rules (Sx refers to any SA and SB) - Rule 1: Prefer same address: If Sx=D then prefer Sx - Rule 2: Prefer appropriate scope: If SB has a larger scope than SA (i.e. SA is a site local address and SB is a global address) and D has a larger scope than SA then prefer SB; Otherwise, prefer SA. - Rule 3: Avoid deprecated addresses. - Rule 4: Prefer home address: This applies to mobile IP environments so it will not be discussed here. - Rule 5: Prefer outgoing interface: If SA is assigned to the interface that will be used to send the packet towards D, and SB is not, then prefer SA. Note that the previous rules can be responsible for selecting addresses that were not assigned to the outgoing interface. - Rule 6: Prefer matching label. Obtain label for SA, SB and D from policy table and compute the following condition: if label(SA)=label(D) and label(SB)<>label(D) then prefer SA. - Rule 7: Prefer public address: if SA is a public address and SB is a temporary address, then prefer SA (public and temporary addresses are discussed elsewhere [14]) - Rule 8: Use longest matched prefix. Proposed mechanism: In order to enable ISP selection through the source address selection mechanism the following changes are introduced: Policy table modifications. Port information must be included in order to be able to make application based source address selection. Besides, another entry is included in order to associate intermediate address needed to ISP selection with source addresses used, with the intention to match exit path with return path. The new policy table will then have the following aspect: Port Prefix Precedence Label Intermediate addr. P1 ::/0 60 100 ::1/128 50 0 ::/0 40 1 2002::/16 30 2 ::/96 20 3 ::ffff:0:0/96 10 4 PrefA:Prefsite::hostA/128 5 100 RA Example of policy table To perform lookup in the table, an address and optionally a port are required as inputs, and the outputs are a label value, a precedence value and optionally an intermediate routing address. The lookup algorithm first searches for matching port, and performs longest prefix match among the prefixes of all the port matching policy table entries. If no matching port is found, longest prefix match is performed with entries that do not have a specified port. Resulting behavior. In the considered multi-homing configuration, suppose that internal policies of the considered site are defined as follows: traffic with destination port P1 to several destination addresses through ISPA, and the rest of the traffic through ISPB. The host A policy table could be configured as follows to accomplish the desired behavior: Applying the defined policy table, when an application needs to communicate with a remote host D at port P1, the policy table will return the following values: For destination address D and port P1, it will return label value equal to 100 because destination and entry ports match. For source address PrefA:Prefsite::hostA, it will return label value equal to 100 and RA as an intermediate address for the routing header. For source address PrefB:Prefste::hostA, it will return label value equal to 1, because longest prefix match is applied. Final label matching leads to a resulting packet with PrefA:Prefsite::hostA as source address; RA as destination address and PA as destination port, and a routing header containing address D. This packet will then exit through ISPA, and response packets will also be routed through ISPA because their destination address will be PrefA:Prefsite::hostA. Note that all the previously described process is carried out only if the first five rules specified in the source address selection algorithm do not apply. We will next justify that rule 6, where the ISP selection mechanism resides, is reached when it is needed. Rule 1: Same address only applies when the target host is the local host, so no ISP selection is needed. Rule 2: assures that ISP selection is aimed only to traffic addressed to destinations outside the site; therefore no ISP selection is performed with site local or link-local connections. Mechanism will only work for global addresses, which is the intended behavior. To avoid being routed through exit routers when systems of the same site use ports that have been included in the policy table, site-local addressing should be deployed. Rule 3: allows the mechanism to be compatible with fault tolerance features provided by multi-homing through the Router Renumbering mechanism. So when there is a failure in an ISP, address deprecation through Router Renumbering and Router Advertising precludes the selection of addresses delegated by crashed ISP, without need to modify existing policy tables on hosts. Rule 4: does not applies, Rule 5: The interface selection in the host routing mechanism for a given destination could force selection in rule 5 if the chosen interface has not been assigned at least one address from all ISPs. Then, if one interface has an address with prefix PrefA, it also must have an address with prefix PrefB to ensure proper functioning. Contact information: marcelo@it.uc3m.es alberto@it.uc3m.es azcorra@it.uc3m.es From owner-multi6@ops.ietf.org Wed Jul 4 17:52:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11916 for ; Wed, 4 Jul 2001 17:52:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15HuYZ-0009Mf-00 for multi6-data@psg.com; Wed, 04 Jul 2001 14:51:35 -0700 Received: from arpa.it.uc3m.es ([163.117.139.120]) by psg.com with esmtp (Exim 3.31 #1) id 15HuYT-0009M4-00 for multi6@ops.ietf.org; Wed, 04 Jul 2001 14:51:30 -0700 Received: from cafe-tops-2.demon.nl (nobody@arpa.it.uc3m.es [163.117.139.120]) by arpa.it.uc3m.es (8.9.3/8.9.3) with SMTP id XAA18896; Wed, 4 Jul 2001 23:37:45 +0200 Message-Id: <200107042137.XAA18896@arpa.it.uc3m.es> To: , marcelo , , , Cc: , From: marcelo@it.uc3m.es Subject: Re: RE: Policy based ISP selection - Redirects Date: Wed, 4 Jul 101 21:38:05 +0000 X-Mailer: Endymion MailMan v2.0 Sender: owner-multi6@ops.ietf.org Precedence: bulk There are some issues when using redirect,i believe. The main problem that I found is that redirects must be with local scope. This implies that the first hop must redirect the packet to the correct ISP. Then , if there are several sub-networks in the site, all the routers must know when to send the redirects. This last statement means that: - All the routers must inspect the port information in all the packets which may arise some performance issues - All the routers and all the hosts must know the policies, which makes management more complex In the case that routing headers are used, only hosts must have policies knowledge Best regards, marcelo > While I would agree there is some value in adding ports to the selection > rules table, I don't believe the routing header is necessary. If host A were > to send a packet to RB that the site policy wants routed through RA, a > redirect will straighten it out. Using redirect would also prevent the case > where the proposed policy entry points at a dead router, while the routing > system knows of an alternative. Basically there is no reason to add the > routing header complexity to achieve the policy goal. > > -----Original Message----- > From: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]On Behalf > Of marcelo > Sent: Tuesday, July 03, 2001 12:43 PM > To: multi6@ops.ietf.org > Cc: alberto@it.uc3m.es; azcorra@it.uc3m.es > Subject: Policy based ISP selection > > Hi, > We have been working in the following idea to provide ISP selection based on > internal policies: > > Enabling Policy based ISP selection in multi-homed sites through address > selection mechanism. > > The mechanism presented performs ISP selection in multi-homed sites. The > selection is based on previously defined policies and it is done on a per > application basis. > > Topology > > The following configuration is considered: > > > ___________________________________________ > | Internet | > | hostB | > |___________________________________________| > | | > | | > +----+ +----+ > |ISPA| |ISPB| > |BRA | |BRB | > +----+ +----+ > | | > link1 | | link2 > __|____________________________|___ > | RA RB | > | | | | > | ------------------------------- | > | | | > | hostA | > | PrefA:Prefsite:hostA | > | PrefB:Prefsite:hostA | > | | > |___________________________________| > > > In the configuration above, the multi-homed site is connected to the > Internet through 2 ISPs (ISPA and ISPB) using link1 and link2 respectively. > Link 1 is established between site exit router RA and ISP border router BRA. > Similarly, Link 2 is established between site exit router RB and ISP border > router BRB. Each of the ISP has delegated an address space to the site: ISPA > has delegated PRefA:Prefsite::/nA+n and ISPB has delegated > PrefB:Prefsite::/nB+n. Host A belongs to the multi-homed site and it has one > interface with the following unicast addresses assigned: two global > addresses, one form each ISP, PrefA:Prefsite:hostA and PrefB:Prefsite:hostA, > a site-local address and a link-local address. Host B does not belong to the > multi-homed site and is has only one global address, hostB. > > > > The presented mechanism allows ISP selection for outbound and inbound > packets of internally generated communications (i.e. the first packet of the > communication is generated by a host that belongs to the site) and for > outbound packets of externally initiated communications. Note that ISP > selection of inbound packets of externally generated connections is the > result of the destination address selection algorithm after evaluation of > DNS response. > > > ISP selection tools: > > It is relevant to note that current ISP based address aggregation imposes > that ISP selection for inbound packets of an internally generated > communication is determined by the source address of the first packet. > Consequently, if no intermediate devices performs any changes in the > packets, the source address selection mechanism of the host that initiates > the communication is naturally involved in the ISP selection mechanism. In > order to provide a coherent path for outbound and inbound packets of the > same communication, the source address selection mechanism and outbound > packets ISP selection mechanism must work in coordinated manner. > > Internally initiated communications: > > Outbound packets: the ISP selection is performed using routing headers that > include site exit routers connecting to the selected ISP. > > Inbound packets: the ISP is selected when selecting the source address of > the communication initiator packet. If an address with PrefA::/nA prefix is > used, inbound packets will be routed through ISPA. Similarly, if an address > with PrefB::/nB prefix is used, inbound packets will be routed through ISPB. > > Externally initiated communications: > > Inbound packets: ISP selection is the result of the destination address > selection algorithm after evaluation of DNS response at the initiating host. > The tool available to the site for ISP selection is appropriate definition > of DNS responses. This is out of the scope of the presented mechanism. > > Outbound packets: the ISP selection is performed using routing headers that > include site exit routers connecting to the selected ISP. > > > > Source address selection algorithm. > > The mechanism presented is a modification of the source address selection > algorithm presented in draft-ietf-ipng-default-addr-select-04. Basically a > modified Policy table is proposed. If the source address selection algorithm > or the policy table are not familiar to the reader, a summary of the > algorithm is presented. > Source Address selection algorithm > The source address selection mechanism relies on a set of rules to obtain > the most appropriate source address from a destination address and a given > policy. > The policy table is a longest prefix match table that takes an address > (source or destination) as input, and returns two values: a label value and > a precedence value. The label value is used to match destination addresses > with source addresses. The precedence value is used to select destination > address among a set of available destination addresses, and it is not needed > for source address selection, so it will not be introduced. > > The process of source address selection is as follows: Once a packet is to > be sent to a destination address, the host routing mechanisms will select > the interface used for delivering the packet. After this, source address > selection is started. Source address selection algorithm has as inputs a > destination address (D) and first two source addresses (SA and SB) from a > proposed candidate set (all the possible source addresses of the outgoing > interface), and it returns the source address that fits best with the > destination address. Successive pair-wise comparisons are performed > throughout all candidate set to obtain the best address. The algorithm is > implemented as an ordered set of rules; if a rule selects one of the two > addresses no further rules are processed. Here we list the proposed rules > (Sx refers to any SA and SB) > - Rule 1: Prefer same address: If Sx=D then prefer Sx > - Rule 2: Prefer appropriate scope: If SB has a larger scope than SA > (i.e. > SA is a site local address and SB is a global address) and D has a larger > scope than SA then prefer SB; Otherwise, prefer SA. > - Rule 3: Avoid deprecated addresses. > - Rule 4: Prefer home address: This applies to mobile IP environments > so it > will not be discussed here. > - Rule 5: Prefer outgoing interface: If SA is assigned to the > interface that > will be used to send the packet towards D, and SB is not, then prefer SA. > Note that the previous rules can be responsible for selecting addresses that > were not assigned to the outgoing interface. > - Rule 6: Prefer matching label. Obtain label for SA, SB and D from > policy > table and compute the following condition: if label(SA)=label(D) and > label(SB)<>label(D) then prefer SA. > - Rule 7: Prefer public address: if SA is a public address and SB is a > temporary address, then prefer SA (public and temporary addresses are > discussed elsewhere [14]) > - Rule 8: Use longest matched prefix. > > Proposed mechanism: > > In order to enable ISP selection through the source address selection > mechanism the following changes are introduced: > > Policy table modifications. Port information must be included in order to be > able to make application based source address selection. Besides, another > entry is included in order to associate intermediate address needed to ISP > selection with source addresses used, with the intention to match exit path > with return path. The new policy table will then have the following aspect: > > Port Prefix Precedence > Label Intermediate addr. > > P1 ::/0 60 > 100 > ::1/128 50 0 > ::/0 40 1 > 2002::/16 30 2 > ::/96 20 3 > ::ffff:0:0/96 10 4 > PrefA:Prefsite::hostA/128 5 100 > RA > > > Example of policy table > > To perform lookup in the table, an address and optionally a port are > required as inputs, and the outputs are a label value, a precedence value > and optionally an intermediate routing address. The lookup algorithm first > searches for matching port, and performs longest prefix match among the > prefixes of all the port matching policy table entries. If no matching port > is found, longest prefix match is performed with entries that do not have a > specified port. > > Resulting behavior. > > In the considered multi-homing configuration, suppose that internal policies > of the considered site are defined as follows: traffic with destination port > P1 to several destination addresses through ISPA, and the rest of the > traffic through ISPB. > The host A policy table could be configured as follows to accomplish the > desired behavior: > > Applying the defined policy table, when an application needs to communicate > with a remote host D at port P1, the policy table will return the following > values: > For destination address D and port P1, it will return label value equal to > 100 because destination and entry ports match. > For source address PrefA:Prefsite::hostA, it will return label value equal > to 100 and RA as an intermediate address for the routing header. > For source address PrefB:Prefste::hostA, it will return label value equal to > 1, because longest prefix match is applied. > > Final label matching leads to a resulting packet with PrefA:Prefsite::hostA > as source address; RA as destination address and PA as destination port, and > a routing header containing address D. This packet will then exit through > ISPA, and response packets will also be routed through ISPA because their > destination address will be PrefA:Prefsite::hostA. > > Note that all the previously described process is carried out only if the > first five rules specified in the source address selection algorithm do not > apply. We will next justify that rule 6, where the ISP selection mechanism > resides, is reached when it is needed. > > Rule 1: Same address only applies when the target host is the local host, > so no ISP selection is needed. > > Rule 2: assures that ISP selection is aimed only to traffic addressed to > destinations outside the site; therefore no ISP selection is performed with > site local or link-local connections. Mechanism will only work for global > addresses, which is the intended behavior. To avoid being routed through > exit routers when systems of the same site use ports that have been included > in the policy table, site-local addressing should be deployed. > > Rule 3: allows the mechanism to be compatible with fault tolerance features > provided by multi-homing through the Router Renumbering mechanism. So when > there is a failure in an ISP, address deprecation through Router Renumbering > and Router Advertising precludes the selection of addresses delegated by > crashed ISP, without need to modify existing policy tables on hosts. > > Rule 4: does not applies, > > Rule 5: The interface selection in the host routing mechanism for a given > destination could force selection in rule 5 if the chosen interface has not > been assigned at least one address from all ISPs. Then, if one interface has > an address with prefix PrefA, it also must have an address with prefix PrefB > to ensure proper functioning. > > > Contact information: > marcelo@it.uc3m.es > alberto@it.uc3m.es > azcorra@it.uc3m.es > From owner-multi6@ops.ietf.org Thu Jul 5 06:53:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06590 for ; Thu, 5 Jul 2001 06:53:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15I6lN-0008td-00 for multi6-data@psg.com; Thu, 05 Jul 2001 03:53:37 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.31 #1) id 15I6lM-0008tX-00 for multi6@ops.ietf.org; Thu, 05 Jul 2001 03:53:36 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06417; Thu, 5 Jul 2001 06:52:50 -0400 (EDT) Message-Id: <200107051052.GAA06417@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-hain-ipv6-pi-addr-use-00.txt Date: Thu, 05 Jul 2001 06:52:50 -0400 Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Application and Use of the IPv6 Provider-Independent Global Unicast Address Format Author(s) : T. Hain Filename : draft-hain-ipv6-pi-addr-use-00.txt Pages : 18 Date : 03-Jul-01 This document discusses the expected use of the address format discussed in the companion document [2] in the Internet. In addition to covering implementations where it adds value in managing the growth of the Internet routing tables, the document will discuss implementations which should be avoided due to the negative impact on the routing tables. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-00.txt 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-hain-ipv6-pi-addr-use-00.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-hain-ipv6-pi-addr-use-00.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: <20010703124541.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hain-ipv6-pi-addr-use-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hain-ipv6-pi-addr-use-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010703124541.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Thu Jul 5 14:30:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22744 for ; Thu, 5 Jul 2001 14:30:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15IDtd-000KLT-00 for multi6-data@psg.com; Thu, 05 Jul 2001 11:30:37 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.31 #1) id 15IDtc-000KLK-00 for multi6@ops.ietf.org; Thu, 05 Jul 2001 11:30:36 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Thu, 05 Jul 2001 11:30:27 -0700 Received: from eagleswings [192.168.123.14] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 5BBCB479BF89479A915BC091CB45C0C7 for plus 5 more; Thu, 05 Jul 2001 11:30:27 -0700 Reply-To: From: "Tony Hain" To: , , , Cc: , Subject: RE: RE: Policy based ISP selection - Redirects Date: Thu, 5 Jul 2001 11:30:27 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200107042137.XAA18896@arpa.it.uc3m.es> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: 9A35DE34-5A8249E1-835A90D7-871F5F6B Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Marcelo wrote: > There are some issues when using redirect,i believe. > The main problem that I found is that redirects must be with > local scope. This implies that the first hop must redirect > the packet to the correct ISP. Yes a redirect must be to another router on the local link. In your drawing this is the case, but it is clear from this note you are looking at a different problem. > Then , if there are several sub-networks in the site, all the > routers must know when to send the redirects. No, all the routers must know the routing policy, but that is their role in life. Also as you note redirects are only applicable on link. > This last statement means that: > - All the routers must inspect the port information in all > the packets which may arise some performance issues > - All the routers and all the hosts must know the policies, > which makes management more complex Routers already need to know routing policy, so it is the desire for some host to have a different policy that adds complexity. > In the case that routing headers are used, only hosts must > have policies knowledge Overriding the routing policy of the underlying infrastructure is the reason the routing header was created. In general the use of a routing header has nothing to do with address selection rules. Even if you tried to tie them, there is nothing preventing policy at host B to override that by using a routing header to cause all of its packets to be sent through ISP-B. Tony From owner-multi6@ops.ietf.org Mon Jul 9 14:18:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24619 for ; Mon, 9 Jul 2001 14:18:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15JfXL-000EXe-00 for multi6-data@psg.com; Mon, 09 Jul 2001 11:13:35 -0700 Received: from arpa.it.uc3m.es ([163.117.139.120]) by psg.com with esmtp (Exim 3.31 #1) id 15JfXJ-000EXY-00 for multi6@ops.ietf.org; Mon, 09 Jul 2001 11:13:33 -0700 Received: from avispa (avispa.it.uc3m.es [163.117.139.178]) by arpa.it.uc3m.es (8.9.3/8.9.3) with SMTP id UAA31759 for ; Mon, 9 Jul 2001 20:13:29 +0200 From: "marcelo" To: Subject: RE: RE: Policy based ISP selection - Redirects Date: Mon, 9 Jul 2001 20:13:44 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit I agree with you in both issues, we must keep in mind that routing policies are routers concern and that routing headers spirit is to override existing policies. However, current ISP based address aggregation implies that hosts mechanisms such as source address selection play a relevant role in route selection. (Letīs consider solutions for this case, where ISP based address aggregation is used) In order to provide a coherent path, the outbound path must be selected accordingly to the selected source address. Available options are : Routing based on source address, so that routers take routing decisions based on destination address and source address. We really like this option but it would be quite complex to adopt. Routing based on traffic class field: For example, we assign a traffic class code for each available ISP and then host can choose which one to use marking the packet. Routing based on flow label. I didnīt explore very much yet. Routing based on ports: this implies that routers consider transport layer information which I think should be avoided. Besides, this solution needs changes in actual routing mechanisms. Routing based in routing headers. I really donīt find this solution very attractive but it is the only one which can be implemented easily, only some modifications in the source address selection mechanism are needed. Actually, the solution that I find more interesting is to use the traffic class field. This allows that both the applications and the host routing mechanism select the ISP. Besides routers can re-mark performing policing. The main problem, as I have already mentioned is that more modifications are needed. So, perhaps an initial solution could be to use routing headers and then introduce the traffic class usage. Best regards, marcelo -----Mensaje original----- De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En nombre de Tony Hain Enviado el: jueves, 05 de julio de 2001 20:30 Para: marcelo@it.uc3m.es; multi6@ops.ietf.org; alberto@it.uc3m.es; azcorra@it.uc3m.es CC: alberto@it.uc3m.es; azcorra@it.uc3m.es Asunto: RE: RE: Policy based ISP selection - Redirects Marcelo wrote: > There are some issues when using redirect,i believe. > The main problem that I found is that redirects must be with > local scope. This implies that the first hop must redirect > the packet to the correct ISP. Yes a redirect must be to another router on the local link. In your drawing this is the case, but it is clear from this note you are looking at a different problem. > Then , if there are several sub-networks in the site, all the > routers must know when to send the redirects. No, all the routers must know the routing policy, but that is their role in life. Also as you note redirects are only applicable on link. > This last statement means that: > - All the routers must inspect the port information in all > the packets which may arise some performance issues > - All the routers and all the hosts must know the policies, > which makes management more complex Routers already need to know routing policy, so it is the desire for some host to have a different policy that adds complexity. > In the case that routing headers are used, only hosts must > have policies knowledge Overriding the routing policy of the underlying infrastructure is the reason the routing header was created. In general the use of a routing header has nothing to do with address selection rules. Even if you tried to tie them, there is nothing preventing policy at host B to override that by using a routing header to cause all of its packets to be sent through ISP-B. Tony From owner-multi6@ops.ietf.org Tue Jul 10 15:26:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16474 for ; Tue, 10 Jul 2001 15:26:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15K37Q-00077e-00 for multi6-data@psg.com; Tue, 10 Jul 2001 12:24:24 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.31 #1) id 15K37P-00077W-00 for multi6@ops.ietf.org; Tue, 10 Jul 2001 12:24:23 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f6AJOLw16895 for ; Tue, 10 Jul 2001 22:24:21 +0300 Date: Tue, 10 Jul 2001 22:24:21 +0300 (EEST) From: Pekka Savola To: Subject: Provider Independent addressing usage Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, I just read the recent PI addressing usage I-D. Based on the quotes at the end of the I-D, it would appear that at least some of my concerns are shared by others, but nonetheless, let's hope this brings up something new. Problems with the PI approach: 1) people don't seem to want too specific routes in the DFZ. With current policies, I'd estimate 100-200 routes is the maximum. (though the technical constraints are a couple of orders of magnitude larger). Specifying these with prefix length may give the wrong impression, as the space would be rather densely populated (minus the oceans, sahara etc.) 2) because of non-specific advertisements, operators would be forced to carry a lot of traffic not their own, or throw it out. Neither is acceptable, economically or from user's point-of-view. 3) the only ones that could really gain from advertisements are regional/area/etc. IX's that have a very high level of regional ISP penetration; e.g. if address belongs to the region, it'd be reachable through the members of an IX with over 99.9% probability. 4) ISP's operating at the IX would have to advertise, among themselves, full /48 routes. In some regions, where there are dozens of millions of Internet users, this is probably not an acceptable solution either. So the problem goes back to 2), but in smaller scale where there are often _no_ IX's to exchange the traffic. ==> So, it's often the case, e.g. in Europe, that a country has about one IX. The PI solution would work if the prefix(es) of the region belonging to that country were advertised to by that IX, and _everyone's_ (in that country) /48 PI prefix be advertised within that IX (whether it's directly associated, or a smaller client ISP of the peering bigger ISP). Additionally there would have to be some peering with neighbouring IX's, so the locations near the borders of a country could be sent to the right country. If this was not done, some regional ISP's would have to capture and carry some traffic they have no idea if they can deliver or dumped. Or, the traffic could be sent to some smaller-than-regional IX's which by definition didn't exist. Take the netcraft web server count by domain for example [http://www.netcraft.com/Survey/Reports/0106/bydomain/]; I think it's fair to assume that each /48 site would have at least one if not more web servers. United Kingdom appears to have about 2.8 million, so say 3 million /48's. Even if there were 10 IX's in the UK (distributed nicely by geographical areas, no less), this would still be a whole lot of specific /48 routes between participating ISP's. These appear to be rather unscalable restrictions. ==> So some portions of this resemble the optimal 6to4 relay router finding issue (using anycast, for example); only, this is a about 2^28 times bigger problem.... -- 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 Jul 10 19:33:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29719 for ; Tue, 10 Jul 2001 19:33:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15K6zg-000FJI-00 for multi6-data@psg.com; Tue, 10 Jul 2001 16:32:40 -0700 Received: from coconut.itojun.org ([210.160.95.97]) by psg.com with esmtp (Exim 3.31 #1) id 15K6zf-000FJ7-00 for multi6@ops.ietf.org; Tue, 10 Jul 2001 16:32:39 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 3C2DF4B20 for ; Wed, 11 Jul 2001 08:32:32 +0900 (JST) To: multi6@ops.ietf.org Subject: draft-ietf-ipngwg-ipv6-2260-02.txt X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: itojun@iijlab.net Date: Wed, 11 Jul 2001 08:32:32 +0900 Message-ID: <5328.994807952@itojun.org> Sender: owner-multi6@ops.ietf.org Precedence: bulk just in case you did not see this one (since its name is still under "ipngwg"). itojun ------- Forwarded Message Return-Path: ietf-123-owner@loki.ietf.org Delivery-Date: Wed Jul 11 00:14:59 2001 Return-Path: Delivered-To: itojun@itojun.org Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by coconut.itojun.org (Postfix) with ESMTP id 400D24B20 for ; Wed, 11 Jul 2001 00:14:57 +0900 (JST) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id LAA07278 for ietf-123-outbound.10@ietf.org; Tue, 10 Jul 2001 11:05:02 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id KAA06782 for ; Tue, 10 Jul 2001 10:24:52 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00260; Tue, 10 Jul 2001 10:24:37 -0400 (EDT) Message-Id: <200107101424.KAA00260@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-ipv6-2260-02.txt Date: Tue, 10 Jul 2001 10:24:37 -0400 Sender: nsyracus@cnri.reston.va.us X-Filter: mailagent [version 3.0 PL73] for itojun@itojun.org - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IPv6 multihoming support at site exit routers Author(s) : J. Hagino, H. Snyder Filename : draft-ietf-ipngwg-ipv6-2260-02.txt Pages : 11 Date : 09-Jul-01 The document describes a mechanism for basic IPv6 multihoming support, and its operational requirements. Unlike currently-practiced IPv4 multihoming, the technique does not impact the worldwide routing table size, nor IGP routing table size in upstream ISPs. The mechanism can be combined with more sophisticated (or complex) multihoming support mechanisms, and can be used as a foundation for other mechanisms. The document is largely based on RFC2260 [Bates, 1998] by Tony Bates. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-ipv6-2260-02.txt 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-ipngwg-ipv6-2260-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-ipngwg-ipv6-2260-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: <20010709103427.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-2260-02.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-2260-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010709103427.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message From owner-multi6@ops.ietf.org Fri Jul 13 13:16:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09213 for ; Fri, 13 Jul 2001 13:16:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15L696-000IKa-00 for multi6-data@psg.com; Fri, 13 Jul 2001 09:50:28 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.31 #1) id 15L692-000IKN-00 for multi6@ops.ietf.org; Fri, 13 Jul 2001 09:50:24 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Fri, 13 Jul 2001 09:50:13 -0700 Received: from eagleswings [4.60.71.107] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 11F239CD7A33484E9948EF3D6D37E291 for plus 1 more; Fri, 13 Jul 2001 09:50:13 -0700 Reply-To: From: "Tony Hain" To: "Pekka Savola" , Subject: RE: Provider Independent addressing usage Date: Fri, 13 Jul 2001 09:50:07 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-reply-to: Importance: Normal X-SLUIDL: CA2C8BB6-66B3482E-A7B4C79E-AE104700 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > Based on the quotes at the end of the I-D, it would appear that > at least some of my concerns are shared by others, but > nonetheless, let's hope this brings up something new. Good, the reason I sent it out was to generate additional comments so the document can cover as many concerns as possible. > Problems with the PI approach: > > 1) people don't seem to want too specific routes in the DFZ. > With current policies, I'd estimate 100-200 routes is the > maximum. (though the technical constraints are a couple of > orders of magnitude larger). Specifying these with prefix length > may give the wrong impression, as the space would be rather > densely populated (minus the oceans, sahara etc.) I agree that removing specifics from the DFZ is the goal, but punching holes in provider aggregates is the current reality and that mechanism is directly contrary to the goal. I don't understand your point about prefix length. What I was trying to say in the draft was that each of the regions outside of the current scope would be represented by single prefix. The population density of these remote regions has no impact on routing in the local region. > 2) because of non-specific advertisements, operators would be > forced to carry a lot of traffic not their own, or throw it > out. Neither is acceptable, economically or from user's > point-of-view. Simply FUD. There may not be a customer relationship between an intermediate operator and the destination, but the traffic was originated via a customer relationship with the source, and there is some operator with a relationship to the destination. Inter-provider agreements are what they are, and they have little relationship to end customers. When a site is connected to multiple operators each of them become identifiable entities to the intermediate operator, so there is a potential for customer relationships between providers. If end-sites are directly connecting to exchanges, the exchange becomes the logical customer of the intermediate operators and passes through the costs to the connecting customer. > 3) the only ones that could really gain from advertisements > are regional/area/etc. IX's that have a very high level of > regional ISP penetration; e.g. if address belongs to the > region, it'd be reachable through the members of an IX with > over 99.9% probability. The PI addresses that actually have an attached site will always be reachable through some set of the ISP's in the region. It appears that you are concerned that some of the ISP's in the region are not participants in an exchange. This is not required as long as one of the providers that are participating is willing to tie it all together. The only mechanism to enforce this is for the inter-region providers to refuse more specifics, or charge exorbitant fees. > 4) ISP's operating at the IX would have to advertise, among > themselves, full /48 routes. In some regions, where there > are dozens of millions of Internet users, this is probably > not an acceptable solution either. So the problem goes back > to 2), but in smaller scale where there are often _no_ IX's > to exchange the traffic. Lack of an exchange in the current topology is not relevant to what might be necessary to scale millions of multi-homed sites in a specific scope. Look back a few years and you would find only a few exchanges globally. Additional exchanges were built as the engineering trade-offs showed value in establishing an exchange at a particular place. The design of this PI mechanism allows exchanges to be created at the scopes that make sense for local engineering reasons, without impact about on any other scopes. > ==> > > So, it's often the case, e.g. in Europe, that a country has > about one IX. The PI solution would work if the prefix(es) > of the region belonging to that country were advertised to > by that IX, and _everyone's_ (in that country) /48 PI prefix > be advertised within that IX (whether it's directly associated, > or a smaller client ISP of the peering bigger ISP). Forget country boundaries, and see the previous note about when and where exchanges get built. Certainly the scopes relevant to an existing IX should have their prefixes exchanged by the participants in the IX, or a route server at the IX coordinated the actual prefix/provider relationships. > Additionally there would have to be some peering with > neighbouring IX's, so the locations near the borders of a > country could be sent to the right country. Depending on the provider/scope/IX relationships there may need to be some fine-tuning of scope sizes exchanged at specific IX's. As noted in the document anytime there are overlapping scopes, some coordination is required, but that does not necessarily mean peering. > If this was not done, some regional ISP's would have to capture > and carry some traffic they have no idea if they can deliver or > dumped. Or, the traffic could be sent to some smaller-than- > regional IX's which by definition didn't exist. I don't understand. If there is a site at the defined prefix there will be an explicit entry known to the providers for that scope. If there is no site there may be connection attempts, but that is no different from unassigned provider-based prefix addresses. > Take the netcraft web server count by domain for example > [http://www.netcraft.com/Survey/Reports/0106/bydomain/]; > I think it's fair to assume that each /48 site would have at > least one if not more web servers. United Kingdom appears to > have about 2.8 million, so say 3 million /48's. Even if there > were 10 IX's in the UK (distributed nicely by geographical > areas, no less), this would still be a whole lot of specific > /48 routes between participating ISP's. Yes; if all sites were multi-homed and the providers chose to implement it that way. When they become concerned about scale, history shows they will implement more IX's to break up the space. > These appear to be rather unscalable restrictions. They will appear to be unscalable if one insists on maintaining current interconnect topology while at the same time watching the edge topology move to massive multi-homing. I will not claim that the PI mechanism is necessarily the best choice, but it is much better at global scaling than punching holes in provider aggregates. > ==> > > So some portions of this resemble the optimal 6to4 relay router > finding issue (using anycast, for example); only, this is a > about 2^28 times bigger problem.... The real problem is that the definition of 'optimal' depends on perspective. The ISP perspective will be very different from the end customer perspective. The goal of PI is to balance those perspectives with a slight weighting toward the end customer site. Tony From owner-multi6@ops.ietf.org Sat Jul 14 03:02:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05885 for ; Sat, 14 Jul 2001 03:02:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15LJ7y-000Ask-00 for multi6-data@psg.com; Fri, 13 Jul 2001 23:42:10 -0700 Received: from fozzie.eye-net.com.au ([203.41.228.19]) by psg.com with esmtp (Exim 3.31 #1) id 15LJ7w-000Ase-00 for multi6@ops.ietf.org; Fri, 13 Jul 2001 23:42:09 -0700 Received: by fozzie.eye-net.com.au (Postfix, from userid 1000) id C413CD62A2; Sat, 14 Jul 2001 16:42:03 +1000 (EST) Date: Sat, 14 Jul 2001 16:42:03 +1000 To: Brian E Carpenter Cc: Joe Abley , multi6@ops.ietf.org Subject: Re: [jabley@automagic.org: unscientific multi-homing survey: results] Message-ID: <20010714164203.A17067@eye-net.com.au> References: <20010629181041.I26708@buddha.home.automagic.org> <3B40863F.8B671AC9@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B40863F.8B671AC9@hursley.ibm.com> User-Agent: Mutt/1.3.18i From: csmall@eye-net.com.au (Craig Small) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, Jul 02, 2001 at 09:33:35AM -0500, Brian E Carpenter wrote: > Interesting that nobody mentioned BGP table bloat, and only > a couple mentioned convergence overhead - i.e. individual ISPs are > not caused immediate pain by the global damage. My guess is because when most people think of multi-homing, they think of a leaf node that has two connections. A large provider with multiple connections probably doesn't call itself multi-homed but rather uses that term for some of its customers. Having worked for both sorts of places, sure technically it is the same, but people just must put an additional meaning to the term "multi-homed". I thought this WG was for the first set of people, the bigger guys can do the usual BGP tricks to get around problems. Having a workplace that is about to multihome (IPv4 though) and could be considered a "leaf" means I can see why people do multihome and what problems it causes. - Craig -- Craig Small VK2XLZ GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.eye-net.com.au/ MIEEE Debian developer From owner-multi6@ops.ietf.org Sun Jul 15 22:53:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA09311 for ; Sun, 15 Jul 2001 22:53:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15LyR8-0009oZ-00 for multi6-data@psg.com; Sun, 15 Jul 2001 19:48:42 -0700 Received: from lox.sandelman.ottawa.on.ca ([209.151.24.2] ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15LyR7-0009oS-00 for multi6@ops.ietf.org; Sun, 15 Jul 2001 19:48:41 -0700 Received: from nox.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [209.151.24.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id WAA21790 for ; Sun, 15 Jul 2001 22:48:40 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca ([2002:d197:274::20]) by nox.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f6G2tAw06955 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Sun, 15 Jul 2001 22:55:15 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f6G2hom18255 for ; Sun, 15 Jul 2001 22:43:51 -0400 (EDT) Message-Id: <200107160243.f6G2hom18255@marajade.sandelman.ottawa.on.ca> From: mcrietf@sandelman.ottawa.on.ca To: multi6@ops.ietf.org Subject: Re: An idea: GxSE In-reply-to: Your message of "Mon, 25 Jun 2001 17:01:55 +0200." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sun, 15 Jul 2001 22:43:50 -0400 Sender: owner-multi6@ops.ietf.org Precedence: bulk >>>>> "Iljitsch" == Iljitsch van Beijnum writes: Iljitsch> The only systems that are hard to renumber are those that Iljitsch> others frequently connect to. Since you wouldn't want your web Iljitsch> server to magically get a new IP address and become unreachable Iljitsch> when it gets a new MAC address or someone else uses the same Iljitsch> MAC address these are configured manually. But how many web Iljitsch> servers do most organizations run? Every single Linux and Windows 2000 box that I've installed lately has had a web server installed by default. They are used for system maintenance and all sorts of other things. Please do not let yourself get trapped into client/server world. This is peer to peer world. Deployment of VoIP will make that much more clear. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-multi6@ops.ietf.org Mon Jul 16 00:24:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA24763 for ; Mon, 16 Jul 2001 00:24:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15LzWS-000CyM-00 for multi6-data@psg.com; Sun, 15 Jul 2001 20:58:16 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15LzWS-000CyG-00 for multi6@ops.ietf.org; Sun, 15 Jul 2001 20:58:16 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id UAA27121 for ; Sun, 15 Jul 2001 20:58:15 -0700 (PDT) Date: Sun, 15 Jul 2001 20:58:15 -0700 (PDT) From: Ramakrishna Gummadi To: Subject: A tunneling proposal Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi all, I have been thinking about the following approach that might be useful towards solving the multihoming problem. It does not require changes to end hosts, and can be used together with provider independent addressing. The basic idea is to have a mechanism that can dynamically create stateless tunnels within the transit providers of a multihomed enterprise to route around failures so that existing connections can fail over to the new paths. For example, in the figure below, suppose host B uses hostA's address drawn from ISPB's address space for a connection. Now, if there is a connectivity problem from ISPB to the site, router RA can initiate a tunnel between ISPB and ISPA so that packets from hostB (or any other host trying to reach the multihomed site) are IP-IP encapsulated and forwarded to RA. Traffic exiting the site that uses the failed address can likewise be internally routed to RA, from which point RA injects the packets into ISPB's network using the tunnel. hostB | ______________________|____________________ | | | Internet | |___________________________________________| | | | | +----+ +----+ |ISPA| tunnel |ISPB| | |----------------------- | | +----+---------------------- +----+ | | link1 | | link2 __|___________________________ |___ | RA RB | | | | | | ------------------------------- | | | | | hostA | | PrefA:Prefsite:hostA | | PrefB:Prefsite:hostA | | | |___________________________________| This scheme works with existing protocols like TCP and UDP that can only use one address per connection. The only failure made that this can not tolerate is when an outage occurs between hostB's service provider and ISPB, but that does not affect the site's ability to talk to the rest of the world using ISPB. I think this problem is more of hostB's than the site's, both because this problem is localized, exists in the current Internet, and can be made to go away with protocols like SCTP. I also think that this architecture more or less meets the requirements desribed in the multi6 requirements draft. I am sure proposals like this have been floated around in other contexts, but have no references to make any comparisons. The tunnel creation should be done carefully, but I think it can be managed securely because it is always initiated by one of the site's routers, and the operation is restricted to the site's providers. Thus, any trust can be statically established and maintained. Also, the tunnel is only created upon a failure, and is scalable because there is no per-flow state required. Any comments are welcome. thanks, ramki ------- end of forwarded message ------- From owner-multi6@ops.ietf.org Mon Jul 16 00:29:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA25884 for ; Mon, 16 Jul 2001 00:29:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15LzZY-000D7Q-00 for multi6-data@psg.com; Sun, 15 Jul 2001 21:01:28 -0700 Received: from coconut.itojun.org ([210.160.95.97]) by psg.com with esmtp (Exim 3.31 #1) id 15LzZY-000D7J-00 for multi6@ops.ietf.org; Sun, 15 Jul 2001 21:01:28 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id D92BB4B20; Mon, 16 Jul 2001 13:01:22 +0900 (JST) To: Ramakrishna Gummadi Cc: multi6@ops.ietf.org In-reply-to: ramki's message of Sun, 15 Jul 2001 20:58:15 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: A tunneling proposal From: itojun@iijlab.net Date: Mon, 16 Jul 2001 13:01:22 +0900 Message-ID: <6784.995256082@itojun.org> Sender: owner-multi6@ops.ietf.org Precedence: bulk >Hi all, >I have been thinking about the following approach that might be useful >towards solving the multihoming problem. It does not require changes >to end hosts, and can be used together with provider independent >addressing. I guess your idea is very similar to RFC2260 as well as draft-ietf-ipngwg-ipv6-2260-02.txt. these RFC/draft do not have any "dynamic" tunnel establishment, but the end goal is very similar. itojun From owner-multi6@ops.ietf.org Mon Jul 16 01:02:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02657 for ; Mon, 16 Jul 2001 01:02:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15M0JU-000FLv-00 for multi6-data@psg.com; Sun, 15 Jul 2001 21:48:56 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15M0JU-000FLo-00 for multi6@ops.ietf.org; Sun, 15 Jul 2001 21:48:56 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id VAA27330; Sun, 15 Jul 2001 21:48:52 -0700 (PDT) Date: Sun, 15 Jul 2001 21:48:51 -0700 (PDT) From: Ramakrishna Gummadi To: cc: Subject: Re: A tunneling proposal In-Reply-To: <6784.995256082@itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Thanks, Itojun. I think the difference between the proposals described in these rfc/drafts and my outline is that the tunnel is created (statically or dynamically) directly between the ISPs, without requiring multiple physical links from each of the site's border routers to each of the ISPs. That is, upon receiving a request from the site's border router peering with ISPA, ISPA sets up a traffic tunnel from itself to ISPB for carrying ISPB's traffic at an appropriate peering point. Apart from saving on the extra physical links, this can potentially provide more robustness because one can overcome more failure modes: for example, what happens when the (single, say) ISPB's border router peering with each of the site's border routers (albeit across multiple physical links) goes down? In my outline, because ISPA and ISPB potentially peer at multiple points, these kind of failures can be tolerated. Also, there is a possibility of performance optimization for ISPA (after all, he is carrying extra traffic) because ISPA can choose the optimal exit point (from its perspective) into ISPB. This may complicate things, but I guess there is a possibility that the benefits may well make the complexity worthwhile. thanks, ramki On Mon, 16 Jul 2001 itojun@iijlab.net wrote: > > >Hi all, > >I have been thinking about the following approach that might be useful > >towards solving the multihoming problem. It does not require changes > >to end hosts, and can be used together with provider independent > >addressing. > > I guess your idea is very similar to RFC2260 as well as > draft-ietf-ipngwg-ipv6-2260-02.txt. these RFC/draft do not have > any "dynamic" tunnel establishment, but the end goal is very similar. > > itojun > > From owner-multi6@ops.ietf.org Mon Jul 16 04:25:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA23238 for ; Mon, 16 Jul 2001 04:25:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15M3Rq-000NOK-00 for multi6-data@psg.com; Mon, 16 Jul 2001 01:09:46 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.31 #1) id 15M3Rp-000NOE-00 for multi6@ops.ietf.org; Mon, 16 Jul 2001 01:09:45 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f6G8B4O13196; Mon, 16 Jul 2001 10:11:04 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 16 Jul 2001 10:09:56 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: mcrietf@sandelman.ottawa.on.ca cc: multi6@ops.ietf.org Subject: Re: An idea: GxSE In-Reply-To: <200107160243.f6G2hom18255@marajade.sandelman.ottawa.on.ca> Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 15 Jul 2001 mcrietf@sandelman.ottawa.on.ca wrote: > >>>>> "Iljitsch" == Iljitsch van Beijnum writes: > Iljitsch> The only systems that are hard to renumber are those that > Iljitsch> others frequently connect to. Since you wouldn't want your web > Iljitsch> server to magically get a new IP address and become unreachable > Iljitsch> when it gets a new MAC address or someone else uses the same > Iljitsch> MAC address these are configured manually. But how many web > Iljitsch> servers do most organizations run? > Every single Linux and Windows 2000 box that I've installed lately has > had a web server installed by default. They are used for system > maintenance and all sorts of other things. > Please do not let yourself get trapped into client/server world. This > is peer to peer world. But does this invalidate my point? I don't see boxes that provide actual services use autoconfiguration. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Mon Jul 16 04:26:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA23335 for ; Mon, 16 Jul 2001 04:26:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15M3VR-000NbX-00 for multi6-data@psg.com; Mon, 16 Jul 2001 01:13:29 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.31 #1) id 15M3VQ-000NbQ-00 for multi6@ops.ietf.org; Mon, 16 Jul 2001 01:13:28 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f6G8EqO13201; Mon, 16 Jul 2001 10:14:52 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 16 Jul 2001 10:13:45 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: Ramakrishna Gummadi cc: multi6@ops.ietf.org Subject: Re: A tunneling proposal In-Reply-To: Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 15 Jul 2001, Ramakrishna Gummadi wrote: > The basic idea is to have a mechanism that can dynamically create > stateless tunnels within the transit providers of a multihomed enterprise > to route around failures so that existing connections can fail over > to the new paths. Why would you need to do this? If you can send tunneled packets to the destination network, I can see no reason you can't send un-tunneled packets too. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Mon Jul 16 04:42:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25038 for ; Mon, 16 Jul 2001 04:42:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15M3b0-000NoM-00 for multi6-data@psg.com; Mon, 16 Jul 2001 01:19:14 -0700 Received: from flowpoint.procket.com ([209.140.237.1] helo=alpha-tli.procket.com) by psg.com with esmtp (Exim 3.31 #1) id 15M3az-000Nmd-00 for multi6@ops.ietf.org; Mon, 16 Jul 2001 01:19:13 -0700 Received: (from tli@localhost) by alpha-tli.procket.com (8.9.3/8.9.3) id BAA08440; Mon, 16 Jul 2001 01:18:29 -0700 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: alpha-tli.procket.com: tli set sender to tli@alpha-tli.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15186.41813.520641.729170@alpha-tli.procket.com> Date: Mon, 16 Jul 2001 01:18:29 -0700 To: Iljitsch van Beijnum Cc: Ramakrishna Gummadi , multi6@ops.ietf.org Subject: Re: A tunneling proposal In-Reply-To: References: X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit | > The basic idea is to have a mechanism that can dynamically create | > stateless tunnels within the transit providers of a multihomed enterprise | > to route around failures so that existing connections can fail over | > to the new paths. | | Why would you need to do this? If you can send tunneled packets to the | destination network, I can see no reason you can't send un-tunneled packets | too. Routing. Tony From owner-multi6@ops.ietf.org Mon Jul 16 04:44:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25322 for ; Mon, 16 Jul 2001 04:44:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15M3oy-000OPo-00 for multi6-data@psg.com; Mon, 16 Jul 2001 01:33:40 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.31 #1) id 15M3ox-000OPi-00 for multi6@ops.ietf.org; Mon, 16 Jul 2001 01:33:39 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f6G8YwO13239; Mon, 16 Jul 2001 10:34:58 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 16 Jul 2001 10:33:50 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: Tony Li cc: Ramakrishna Gummadi , multi6@ops.ietf.org Subject: Re: A tunneling proposal In-Reply-To: <15186.41813.520641.729170@alpha-tli.procket.com> Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 16 Jul 2001, Tony Li wrote: > | > The basic idea is to have a mechanism that can dynamically create > | > stateless tunnels within the transit providers of a multihomed enterprise > | > to route around failures so that existing connections can fail over > | > to the new paths. > | Why would you need to do this? If you can send tunneled packets to the > | destination network, I can see no reason you can't send un-tunneled packets > | too. > Routing. I didn't read the original message carefully enough, my apologies. I took "around the failures" to mean from one point within an ISP to another point with the same/a different ISP. Tunnels can fix some types of failures, but they can't fix every type of failure, like routing problems that affect the entire ISP. This kind of multihoming is clearly inferior to the regular IPv4 way. From owner-multi6@ops.ietf.org Mon Jul 16 13:47:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03334 for ; Mon, 16 Jul 2001 13:47:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MCFZ-000PhB-00 for multi6-data@psg.com; Mon, 16 Jul 2001 10:33:41 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.31 #1) id 15MCFY-000Ph4-00 for multi6@ops.ietf.org; Mon, 16 Jul 2001 10:33:40 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Mon, 16 Jul 2001 10:33:04 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id C8859B367305409B8B3DA3D125AB7A13 for plus 2 more; Mon, 16 Jul 2001 10:33:04 -0700 Reply-To: From: "Tony Hain" To: "Iljitsch van Beijnum" , Cc: Subject: RE: An idea: GxSE Date: Mon, 16 Jul 2001 10:32:55 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-reply-to: Importance: Normal X-SLUIDL: 2909B7B0-AE5840C1-99BDAE99-81FAD817 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA03334 Iljitsch van Beijnum wrote: > I don't see boxes that provide actual services > use autoconfiguration. Isn't this simply an artifact of the lack of secure DDNS? There are environments where sufficient trust exists for a 'service' node to autoconfigure itself and register that with DNS. The fact you don't see them says more about your local network / trust environment than it does about technical possibilities. Tony From owner-multi6@ops.ietf.org Mon Jul 16 14:31:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12650 for ; Mon, 16 Jul 2001 14:31:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MCnv-0001cl-00 for multi6-data@psg.com; Mon, 16 Jul 2001 11:09:11 -0700 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.31 #1) id 15MCnu-0001c1-00 for multi6@ops.ietf.org; Mon, 16 Jul 2001 11:09:10 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 9D2B28266E; Mon, 16 Jul 2001 14:08:28 -0400 (EDT) Message-Id: <5.1.0.14.2.20010716140200.00a11970@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 16 Jul 2001 14:04:02 -0400 To: From: RJ Atkinson Subject: RE: An idea: GxSE Cc: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 13:32 16/07/01, Tony Hain wrote: >Isn't this simply an artifact of the lack of secure DDNS? No. Even ignoring security, which I don't advise, DDNS requires more gorp (protocols, network transactions, services, etc.) than just running with a static network configuration. Folks running high-availability {networking, computing} services generally try hard to make their configurations very simple, because simple generally works best and most reliably. Ran From owner-multi6@ops.ietf.org Mon Jul 16 15:23:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22139 for ; Mon, 16 Jul 2001 15:23:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MDWL-0003am-00 for multi6-data@psg.com; Mon, 16 Jul 2001 11:55:05 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.31 #1) id 15MDWK-0003ag-00 for multi6@ops.ietf.org; Mon, 16 Jul 2001 11:55:05 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Mon, 16 Jul 2001 11:54:56 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 8EC1BDBEF20041A9A92CC5A30EBC9F47 for plus 1 more; Mon, 16 Jul 2001 11:54:55 -0700 Reply-To: From: "Tony Hain" To: "RJ Atkinson" Cc: Subject: RE: An idea: GxSE Date: Mon, 16 Jul 2001 11:54:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-reply-to: <5.1.0.14.2.20010716140200.00a11970@10.30.15.2> Importance: Normal X-SLUIDL: 401F0FCE-93C14D4A-B3669855-C17D951A Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA22139 RJ Atkinson wrote: > Even ignoring security, which I don't advise, DDNS > requires more gorp (protocols, network transactions, > services, etc.) than just running with a static network > configuration. This is a trade-off between the automation getting confused, or the operator misconfiguring it. I will agree that the current state of automation in products will lose this contest to a skilled operator, but I will also argue that in the end automation will always beat out the cheap low-skill operator. > Folks running high-availability {networking, computing} > services generally try hard to make their configurations > very simple, because simple generally works best and most > reliably. I agree completely that simplicity is crucial, but there is a crossover between which is simpler based on the skill level of the operator. Generally the lower the skill level, the more automation is required to keep it simple. Tony From owner-multi6@ops.ietf.org Mon Jul 16 17:55:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18721 for ; Mon, 16 Jul 2001 17:55:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MG6l-000BpR-00 for multi6-data@psg.com; Mon, 16 Jul 2001 14:40:51 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15MG6k-000BpL-00 for multi6@ops.ietf.org; Mon, 16 Jul 2001 14:40:50 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id OAA09487 for ; Mon, 16 Jul 2001 14:40:49 -0700 (PDT) Date: Mon, 16 Jul 2001 14:40:48 -0700 (PDT) From: Ramakrishna Gummadi To: Subject: Re: A tunneling proposal Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > Tunnels can fix some types of failures, but they can't fix every type of > failure, like routing problems that affect the entire ISP. This kind of > multihoming is clearly inferior to the regular IPv4 way. > One of the primary goals of tunneling, I think, is to make *existing* connections that use transports such as UDP and TCP survive a partial outage within the ISP. I hypothesize that the only scenario where tunneling for TCP and UDP fails is when the entire ISP is affected in a major way. If one uses SCTP, or some other transport with ability to support multiple addresses per connection, one can deal with this problem completely. True, regular IPv4 multihoming can provide this facility only because end-hosts use a single non-aggregatable address that is announced in the DFZ. If hosts were to use multiple addresses, regular IPv4 multihoming can not provide connection survivability for TCP and UDP even in the face of a partial outage. It all depends on what the first priority is---if it is scalability, then, I think, to make TCP/UDP survive all failures, one needs an approach like GxSE, which affects the IP layer. If you are willing to be less than perfect, and don't want to change the host stacks, tunnels may be a good choice, especially when applications can use SCTP to get the required reliability. -ramki From owner-multi6@ops.ietf.org Mon Jul 16 18:01:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19840 for ; Mon, 16 Jul 2001 18:01:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MGQS-000Cw5-00 for multi6-data@psg.com; Mon, 16 Jul 2001 15:01:12 -0700 Received: from garlic.amaranth.net ([216.235.243.195]) by psg.com with esmtp (Exim 3.31 #1) id 15MGQR-000Cvv-00 for multi6@ops.ietf.org; Mon, 16 Jul 2001 15:01:11 -0700 Received: from yarrow.senie.com (h0040100ebb17.ne.mediaone.net [24.218.3.56]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.3/8.11.3) with ESMTP id f6GM11F15386 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Mon, 16 Jul 2001 18:01:01 -0400 Message-Id: <5.1.0.14.2.20010716175738.03cdc530@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 16 Jul 2001 18:01:01 -0400 To: From: Daniel Senie Subject: Re: A tunneling proposal In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk At 05:40 PM 7/16/01, Ramakrishna Gummadi wrote: >I hypothesize that the only scenario where tunneling for TCP >and UDP fails is when the entire ISP is affected in a major way. Given economic conditions and the relative health or lack thereof of some providers, this alone is a significant concern. If a network is powered down by their bankers, customers who were multihomed via tunneling would be out of luck. This isn't the type of redundancy that is going to make people sleep well at night. People want to multihome so that any outage, from a local loop to a backbone carrier can occur without obliterating their connectivity. I think it important to keep that in mind. Tunneling is quite useful for fixing temporary problems, but I'm not convinced it's a worthwhile solution to the multihoming problem. ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-multi6@ops.ietf.org Mon Jul 16 18:18:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22088 for ; Mon, 16 Jul 2001 18:18:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MGge-000Dnu-00 for multi6-data@psg.com; Mon, 16 Jul 2001 15:17:56 -0700 Received: from mighty.grot.org ([216.15.97.5]) by psg.com with esmtp (Exim 3.31 #1) id 15MGgd-000Dno-00 for multi6@ops.ietf.org; Mon, 16 Jul 2001 15:17:55 -0700 Received: by mighty.grot.org (Postfix, from userid 515) id E8F085DA8; Mon, 16 Jul 2001 15:17:54 -0700 (PDT) Date: Mon, 16 Jul 2001 15:17:54 -0700 From: "R.P. Aditya" To: Ramakrishna Gummadi Cc: multi6@ops.ietf.org Subject: Re: A tunneling proposal Message-ID: <20010716151754.A9145@mighty.grot.org> Reply-To: "R.P. Aditya" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from ramki@cs.berkeley.edu on Mon, Jul 16, 2001 at 02:40:48PM -0700 X-PGP-Key: http://www.grot.org/pubkey.asc X-PGP-Key-ID: 0x6405D8D5 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, Jul 16, 2001 at 02:40:48PM -0700, Ramakrishna Gummadi wrote: > It all depends on what the first priority is---if it is scalability, then, > I think, to make TCP/UDP survive all failures, one needs an approach like > GxSE, which affects the IP layer. If you are willing to be less than > perfect, and don't want to change the host stacks, tunnels may be a good > choice, especially when applications can use SCTP to get the > required reliability. one of the main problems with the tunnel approach (and I'm not saying there is indeed a currently practical or better way) is that it requires a degree of cooperation between ISP-A and ISP-B, which also means that the "decision" is made independently of the end-network. It moves the redundancy from a "local" solution up the AS hierarchy, which is what the *LA design was about. One of the desireable features of current IPv4 multihoming is the ability to solve for "local" connectivity loss (local-loop/router failure) via "local" redundancy. Unfortunately, apart from GxSE or some other "overlay" address scheme that embeds "real-world" (read geographical) information, you can't fully compensate for the loss of routing state information that a path-aggregated DFZ presents and expect to preserve the desireable IPv4 multihoming characteristics (cf. jabley's survey). Adi From owner-multi6@ops.ietf.org Mon Jul 16 18:45:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25405 for ; Mon, 16 Jul 2001 18:45:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MGxg-000EhA-00 for multi6-data@psg.com; Mon, 16 Jul 2001 15:35:32 -0700 Received: from garlic.amaranth.net ([216.235.243.195]) by psg.com with esmtp (Exim 3.31 #1) id 15MGxf-000Egy-00 for multi6@ops.ietf.org; Mon, 16 Jul 2001 15:35:31 -0700 Received: from yarrow.senie.com (h0040100ebb17.ne.mediaone.net [24.218.3.56]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.3/8.11.3) with ESMTP id f6GMZOF16996 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Mon, 16 Jul 2001 18:35:24 -0400 Message-Id: <5.1.0.14.2.20010716182916.03d0de20@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 16 Jul 2001 18:35:24 -0400 To: Ramakrishna Gummadi From: Daniel Senie Subject: Re: A tunneling proposal Cc: In-Reply-To: References: <5.1.0.14.2.20010716175738.03cdc530@mail.amaranth.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk At 06:20 PM 7/16/01, Ramakrishna Gummadi wrote: >One can think of a simple extension to tunneling under such ISP-wide >outages---if tunnel creation fails, the second ISP initiates >non-aggregatable route announcements for the prefixes from the address >space of the first ISP who has become unreachable. This two step approach >may prove effective for fixing both small-scale temporary and large-scale >persistent problems. This could work, provided the alternate upstream ISPs are willing, and other networks are willing to take the announcements. The concern is that RADB and similar are used by providers to restrict where announcements will come from. Keep in mind also that what we're talking about here is human intervention in the case of an outage. The question to be answered by prospective users of such a multhoming solution is how many hours of outage can be tolerated? I suspect it unlikely that automated tunnel creation and announcement setup would be well received by those running backbones, so there's likely to be a human element at play. >It may be a good idea to examine a breakdown of the kind of failures >experiences within an ISP, because this will help judge the effectiveness >of the tunneling approach. But the primary motivation in tunneling is not >to introduce unnecessray routes into the DFZ if there is an alternative. >For example, I know that, in the context of server farms, about 20% of >outages and errors are because of local power failures, but this may not >hold in the ISP case. Does anyone have any info about the main problems >and their frequencies? Where's that 20% figure come from? With all the backups the colo vendor salesfolk talk about, that's a surprising figure. While I understand the desire to find ways to avoid introducing routes into the DFZ, I firmly believe any solution should provide an automated resilience in the face of outages. I'm not yet convinced there's a good way to do this with tunnels. >On Mon, 16 Jul 2001, Daniel Senie wrote: > > > At 05:40 PM 7/16/01, Ramakrishna Gummadi wrote: > > >I hypothesize that the only scenario where tunneling for TCP > > >and UDP fails is when the entire ISP is affected in a major way. > > > > Given economic conditions and the relative health or lack thereof of some > > providers, this alone is a significant concern. If a network is powered > > down by their bankers, customers who were multihomed via tunneling would be > > out of luck. This isn't the type of redundancy that is going to make people > > sleep well at night. > > > > People want to multihome so that any outage, from a local loop to a > > backbone carrier can occur without obliterating their connectivity. I think > > it important to keep that in mind. > > > > Tunneling is quite useful for fixing temporary problems, but I'm not > > convinced it's a worthwhile solution to the multihoming problem. > > > > ----------------------------------------------------------------- > > Daniel Senie dts@senie.com > > Amaranth Networks Inc. http://www.amaranth.com > > > > > > ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-multi6@ops.ietf.org Mon Jul 16 18:45:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25416 for ; Mon, 16 Jul 2001 18:45:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MGnp-000E9z-00 for multi6-data@psg.com; Mon, 16 Jul 2001 15:25:21 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15MGno-000E9n-00 for multi6@ops.ietf.org; Mon, 16 Jul 2001 15:25:20 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id PAA10805; Mon, 16 Jul 2001 15:25:14 -0700 (PDT) Date: Mon, 16 Jul 2001 15:25:14 -0700 (PDT) From: Ramakrishna Gummadi To: "R.P. Aditya" cc: Subject: Re: A tunneling proposal In-Reply-To: <20010716151754.A9145@mighty.grot.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > one of the main problems with the tunnel approach (and I'm not saying there is > indeed a currently practical or better way) is that it requires a degree of > cooperation between ISP-A and ISP-B, which also means that the "decision" is > made independently of the end-network. It moves the redundancy from a "local" > solution up the AS hierarchy, which is what the *LA design was about. One of > the desireable features of current IPv4 multihoming is the ability to solve > for "local" connectivity loss (local-loop/router failure) via "local" > redundancy. I am not certain this is the case. The tunnel will be initiated only at the request of the multihomed site that detects problems with the other ISP, say ISPB. In any case, remember that one end of the tunnel has to be terminated at the site's border router. The other end should be terminated within ISPB, but where exactly this is done can be made a performance-optimizing criterion from the perspective of ISPA who has to carry the tunneled traffic. In any case, since it involves only the site's ISPs, I think this setting up a tunnel may indeed by feasibly, although it may not be optimal in every scenario. -ramki From owner-multi6@ops.ietf.org Mon Jul 16 18:50:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26173 for ; Mon, 16 Jul 2001 18:50:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MGio-000DtA-00 for multi6-data@psg.com; Mon, 16 Jul 2001 15:20:10 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15MGio-000Dt3-00 for multi6@ops.ietf.org; Mon, 16 Jul 2001 15:20:10 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id PAA10644; Mon, 16 Jul 2001 15:20:07 -0700 (PDT) Date: Mon, 16 Jul 2001 15:20:07 -0700 (PDT) From: Ramakrishna Gummadi To: Daniel Senie cc: Subject: Re: A tunneling proposal In-Reply-To: <5.1.0.14.2.20010716175738.03cdc530@mail.amaranth.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk One can think of a simple extension to tunneling under such ISP-wide outages---if tunnel creation fails, the second ISP initiates non-aggregatable route announcements for the prefixes from the address space of the first ISP who has become unreachable. This two step approach may prove effective for fixing both small-scale temporary and large-scale persistent problems. It may be a good idea to examine a breakdown of the kind of failures experiences within an ISP, because this will help judge the effectiveness of the tunneling approach. But the primary motivation in tunneling is not to introduce unnecessray routes into the DFZ if there is an alternative. For example, I know that, in the context of server farms, about 20% of outages and errors are because of local power failures, but this may not hold in the ISP case. Does anyone have any info about the main problems and their frequencies? thanks, ramki On Mon, 16 Jul 2001, Daniel Senie wrote: > At 05:40 PM 7/16/01, Ramakrishna Gummadi wrote: > >I hypothesize that the only scenario where tunneling for TCP > >and UDP fails is when the entire ISP is affected in a major way. > > Given economic conditions and the relative health or lack thereof of some > providers, this alone is a significant concern. If a network is powered > down by their bankers, customers who were multihomed via tunneling would be > out of luck. This isn't the type of redundancy that is going to make people > sleep well at night. > > People want to multihome so that any outage, from a local loop to a > backbone carrier can occur without obliterating their connectivity. I think > it important to keep that in mind. > > Tunneling is quite useful for fixing temporary problems, but I'm not > convinced it's a worthwhile solution to the multihoming problem. > > ----------------------------------------------------------------- > Daniel Senie dts@senie.com > Amaranth Networks Inc. http://www.amaranth.com > > > From owner-multi6@ops.ietf.org Mon Jul 16 18:53:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26723 for ; Mon, 16 Jul 2001 18:53:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MH5c-000FCT-00 for multi6-data@psg.com; Mon, 16 Jul 2001 15:43:44 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15MH5b-000FCM-00 for multi6@ops.ietf.org; Mon, 16 Jul 2001 15:43:43 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id PAA11339; Mon, 16 Jul 2001 15:43:42 -0700 (PDT) Date: Mon, 16 Jul 2001 15:43:41 -0700 (PDT) From: Ramakrishna Gummadi To: Daniel Senie cc: Subject: Re: A tunneling proposal In-Reply-To: <5.1.0.14.2.20010716182916.03d0de20@mail.amaranth.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > At 06:20 PM 7/16/01, Ramakrishna Gummadi wrote: > >One can think of a simple extension to tunneling under such ISP-wide > >outages---if tunnel creation fails, the second ISP initiates > >non-aggregatable route announcements for the prefixes from the address > >space of the first ISP who has become unreachable. This two step approach > >may prove effective for fixing both small-scale temporary and large-scale > >persistent problems. > > This could work, provided the alternate upstream ISPs are willing, and > other networks are willing to take the announcements. The concern is that > RADB and similar are used by providers to restrict where announcements will > come from. Keep in mind also that what we're talking about here is human > intervention in the case of an outage. The question to be answered by > prospective users of such a multhoming solution is how many hours of outage > can be tolerated? I suspect it unlikely that automated tunnel creation and > announcement setup would be well received by those running backbones, so > there's likely to be a human element at play. Is it not possible to create a *static* entry in the RADB or other policy database permitting each of a site's ISPs to advertise the site's prefixes drawn from other the address space of other ISPs? I understand it is not straightforward, but because it is static, perhaps it can be automated... > >It may be a good idea to examine a breakdown of the kind of failures > >experiences within an ISP, because this will help judge the effectiveness > >of the tunneling approach. But the primary motivation in tunneling is not > >to introduce unnecessray routes into the DFZ if there is an alternative. > >For example, I know that, in the context of server farms, about 20% of > >outages and errors are because of local power failures, but this may not > >hold in the ISP case. Does anyone have any info about the main problems > >and their frequencies? > > Where's that 20% figure come from? With all the backups the colo vendor > salesfolk talk about, that's a surprising figure. I heard this number from Jim Gray's seminar talk at UC Berkeley when he was analyzing systems (databases, in particular) failures. But this was from a couple of years ago.... From owner-multi6@ops.ietf.org Mon Jul 16 19:35:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05285 for ; Mon, 16 Jul 2001 19:35:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MHYX-000GnG-00 for multi6-data@psg.com; Mon, 16 Jul 2001 16:13:37 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.31 #1) id 15MHYW-000GnA-00 for multi6@ops.ietf.org; Mon, 16 Jul 2001 16:13:36 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f6GNFCO14164; Tue, 17 Jul 2001 01:15:12 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 17 Jul 2001 01:13:57 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: Ramakrishna Gummadi cc: multi6@ops.ietf.org Subject: Re: A tunneling proposal In-Reply-To: Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 16 Jul 2001, Ramakrishna Gummadi wrote: > > Tunnels can fix some types of failures, but they can't fix every type of > > failure, like routing problems that affect the entire ISP. This kind of > > multihoming is clearly inferior to the regular IPv4 way. > One of the primary goals of tunneling, I think, is to make *existing* > connections that use transports such as UDP and TCP survive a partial > outage within the ISP. Yes, tunnels can be useful for this. > True, regular IPv4 multihoming can provide this facility only because > end-hosts use a > single non-aggregatable address that is announced in the DFZ. Well, maybe this is just the way things will have to be. Is there a known limit to the number of routes in the global routing table? I know bad things started to happen at about 4000 and 10000, but obviously those problems have been solved. Routers run just fine with 100,000 routes at present, and unless I'm mistaken, the most common types of router have CPUs and memory that are well below what most of us have in our desk top PCs. On top of that, each route takes a LOT of memory: 240 bytes for the routing table and for each peer route in the BGP table in a Cisco. If we can both increase memory and decrease the route/BGP table entry size by an order of magnitude, we should be able to run with a global routing table of 10,000,000 routes. That's about the entire IPv4 space as individual /24's. Link speeds are high enough, and if route lookups are implemented as variations of binary search they are of an order log(n) so going from 10e5 to 10e7 should be just a 40% slowdown. The only thing that might be a problem is processing so many routes when BGP sessions come up. I think it's worth it to look at this, because with CIDR it is pretty much impossible to efficiently route traffic: many locations are hidden behind aggregates. Someone in Chicago has to choose between routing traffic for the aggregate to the west coast or the east coast, and in either case some traffic will have gone in the wrong direction. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Mon Jul 16 19:46:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07543 for ; Mon, 16 Jul 2001 19:46:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MHt6-000Hzb-00 for multi6-data@psg.com; Mon, 16 Jul 2001 16:34:52 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.31 #1) id 15MHt5-000HzV-00 for multi6@ops.ietf.org; Mon, 16 Jul 2001 16:34:51 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f6GNaPO14193; Tue, 17 Jul 2001 01:36:25 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 17 Jul 2001 01:35:10 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: Daniel Senie cc: multi6@ops.ietf.org Subject: Re: A tunneling proposal In-Reply-To: <5.1.0.14.2.20010716182916.03d0de20@mail.amaranth.net> Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 16 Jul 2001, Daniel Senie wrote: > >One can think of a simple extension to tunneling under such ISP-wide > >outages---if tunnel creation fails, the second ISP initiates > >non-aggregatable route announcements for the prefixes from the address > >space of the first ISP who has become unreachable. Speaking from operational experience: this is not going to work. As a multihomed site, I have to regularly check if I can still reach the entire internet when one line goes down, because it wouldn't be the first time someone placed the wrong filters at the wrong place. If you don't test something like this, it's not going to work when you need it. Also, when huge amounts of more specific prefixes appear, this could be just the kind of thing to drive a lot of routers over the edge, especially when we're getting close to a common limit, such as 128 MB in Cisco routers. And when you can announce more specifics some of the time, why not make "some" "a lot" or even "all"? And then people will start to filter and we're back to square one. > >For example, I know that, in the context of server farms, about 20% of > >outages and errors are because of local power failures, but this may not > >hold in the ISP case. Does anyone have any info about the main problems > >and their frequencies? > Where's that 20% figure come from? With all the backups the colo vendor > salesfolk talk about, that's a surprising figure. Power is getting less and less stable these days. Those anti-globalisation people do have a point, you know. I got this from http://www.apcc.com/power/problems.cfm "Power problems are the largest cause of data loss" Power Failure/Surge: 45.3% Storm Damage: 9.4% Fire or Explosion: 8.2% Hardware/Software Error: 8.2% Flood & Water Damage: 6.7% Earthquake: 5.5% Network Outage: 4.5% Human Error/Sabotage: 3.2% HVAC Failure: 2.3% Other 6.7% Source: Contingency Planning So power problems are about 8 times as common as earthquakes. That's not so bad. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Mon Jul 16 19:51:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08633 for ; Mon, 16 Jul 2001 19:51:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MHmp-000HbB-00 for multi6-data@psg.com; Mon, 16 Jul 2001 16:28:23 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15MHmo-000Hau-00 for multi6@ops.ietf.org; Mon, 16 Jul 2001 16:28:22 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id QAA12409; Mon, 16 Jul 2001 16:28:21 -0700 (PDT) Date: Mon, 16 Jul 2001 16:28:20 -0700 (PDT) From: Ramakrishna Gummadi To: , Subject: Re: A tunneling proposal Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > One of > the desireable features of current IPv4 multihoming is the ability to solve > for "local" connectivity loss (local-loop/router failure) via "local" > redundancy. To elaborate a little more, I think tunnels can be used to survive "not-so-local" failures in the ISP (such as exchange point resets, as mentioned in the requirements draft). The amount of co-operation required can be a function of the performance requirements (in terms of tunneled traffic carried), as well as how many possible alternate paths should be explored---for example, a naive yet simple way to set up a tunnel between the site and ISPB without requiring any co-operation from ISPA is for the site's border router to try a pre-determined list of exit points within ISPB. thanks, ramki From owner-multi6@ops.ietf.org Mon Jul 16 20:19:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14723 for ; Mon, 16 Jul 2001 20:19:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MIbL-000KhS-00 for multi6-data@psg.com; Mon, 16 Jul 2001 17:20:35 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15MIbK-000KhL-00 for multi6@ops.ietf.org; Mon, 16 Jul 2001 17:20:34 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id RAA13686; Mon, 16 Jul 2001 17:20:32 -0700 (PDT) Date: Mon, 16 Jul 2001 17:20:32 -0700 (PDT) From: Ramakrishna Gummadi To: Iljitsch van Beijnum cc: Subject: Re: A tunneling proposal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > > > >For example, I know that, in the context of server farms, about 20% of > > >outages and errors are because of local power failures, but this may not > > >hold in the ISP case. Does anyone have any info about the main problems > > >and their frequencies? > > > Where's that 20% figure come from? With all the backups the colo vendor > > salesfolk talk about, that's a surprising figure. > > Power is getting less and less stable these days. Those anti-globalisation > people do have a point, you know. > > I got this from http://www.apcc.com/power/problems.cfm > > "Power problems are the largest cause of data loss" > > Power Failure/Surge: 45.3% > Storm Damage: 9.4% > Fire or Explosion: 8.2% > Hardware/Software Error: 8.2% > Flood & Water Damage: 6.7% > Earthquake: 5.5% > Network Outage: 4.5% > Human Error/Sabotage: 3.2% > HVAC Failure: 2.3% > Other 6.7% > > Source: Contingency Planning > > So power problems are about 8 times as common as earthquakes. That's not so > bad. > > Iljitsch van Beijnum > > The following excerpt is from the results of the web-polygraph cache benchmarking bake-off: (http://www.measurement-factory.com/results/public/cacheoff/N03/report.by-alph.html) ---------------------- The IBM-230 entry was unable to complete the downtime test. The system requires manual intervention to boot up. IBM informed us that the product is designed to never lose power. It has triple-redundant power supplies. ---------------- It costs $25,000, BTW. I wonder why they did not anticipate that someone can pull a plug by mistake... -ramki From owner-multi6@ops.ietf.org Mon Jul 16 20:26:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16066 for ; Mon, 16 Jul 2001 20:26:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MIVZ-000KIs-00 for multi6-data@psg.com; Mon, 16 Jul 2001 17:14:37 -0700 Received: from box.mfnx.net ([64.124.216.37]) by psg.com with esmtp (Exim 3.31 #1) id 15MIVY-000KIm-00 for multi6@ops.ietf.org; Mon, 16 Jul 2001 17:14:36 -0700 Received: from ug.mfnx.net (ug.mfnx.net [64.124.216.38]) by box.mfnx.net (8.9.3/8.9.1) via ESMTP id RAA23502; Mon, 16 Jul 2001 17:14:36 -0700 (PDT) env-from (xxvaf@mfnx.net) Received: (from xxvaf@localhost) by ug.mfnx.net (8.9.3/8.9.1) id RAA52201; Mon, 16 Jul 2001 17:14:36 -0700 (PDT) env-from (xxvaf@mfnx.net) Date: Mon, 16 Jul 2001 17:14:35 PDT From: xxvaf To: Iljitsch van Beijnum Cc: Ramakrishna Gummadi , multi6@ops.ietf.org Subject: Re: A tunneling proposal In-Reply-To: Your message of Tue, 17 Jul 2001 01:13:57 +0200 (West-Europa (zomertijd)) Message-ID: Sender: owner-multi6@ops.ietf.org Precedence: bulk > Is there a known limit to the number of routes in the global routing > table? I know bad things started to happen at about 4000 and 10000, but > obviously those problems have been solved. Routers run just fine with 100,000 > routes at present, and unless I'm mistaken, the most common types of router > have CPUs and memory that are well below what most of us have in our desk top > PCs. The veracity of "Routers run just fine with 100,000 routes..." depends on how you define "fine". Modern routers don't fall over with 100,000 routes in them. But initial table load and BGP convergence times when paths change are both a lot longer than many would like. > On top of that, each route takes a LOT of memory: 240 bytes for the routing > table and for each peer route in the BGP table in a Cisco. > > If we can both increase memory and decrease the route/BGP table entry size by > an order of magnitude, we should be able to run with a global routing table > of 10,000,000 routes. That's about the entire IPv4 space as individual /24's. The size of individual routing state entries in modern routers has been the subject of a great deal of optimization over the years. Don't expect to see it improved by an order of magnitude or even by a factor of two. Memory size is not the principal issue; memory speed and routing table update bandwidth are. > I think it's worth it to look at this, because with CIDR it is pretty much > impossible to efficiently route traffic: many locations are hidden behind > aggregates. Someone in Chicago has to choose between routing traffic for the > aggregate to the west coast or the east coast, and in either case some > traffic will have gone in the wrong direction. If global routing state size resumes a hyper-exponential growth pattern that exceeds Moore's law, the problem will get worse faster than CPUs increase in speed. Eliminating CIDR will guarentee hyper-exponential growth - for all the talk about how CIDR has "failed" in that growth is continuing, the growth rate would be far, far worse without it - aggregation has successfully "hidden" at least an order of magnitude of growth. CIDR-style aggregation is the only technology that has been shown to contain routing state growth to a manageable level. Look back at old archives of the IETF and other lists to read some of Noel Chiappa's and others' writings on the mathematics of network topology and addressing. If the "addresses" used by routing don't follow the underlying network topology, excessive state is introduced. For multihoming to really work, it needs to use topologically-significant addressing. That suggests that the "multi" in "multihoming" also implies multiple addresses, with something like SCTP to handle them intelligently. --Vince From owner-multi6@ops.ietf.org Mon Jul 16 20:26:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16097 for ; Mon, 16 Jul 2001 20:26:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MIOm-000Jt9-00 for multi6-data@psg.com; Mon, 16 Jul 2001 17:07:36 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15MIOl-000Jt2-00 for multi6@ops.ietf.org; Mon, 16 Jul 2001 17:07:35 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id RAA13448; Mon, 16 Jul 2001 17:07:33 -0700 (PDT) Date: Mon, 16 Jul 2001 17:07:32 -0700 (PDT) From: Ramakrishna Gummadi To: Iljitsch van Beijnum cc: Subject: Re: A tunneling proposal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 17 Jul 2001, Iljitsch van Beijnum wrote: > On Mon, 16 Jul 2001, Daniel Senie wrote: > > > >One can think of a simple extension to tunneling under such ISP-wide > > >outages---if tunnel creation fails, the second ISP initiates > > >non-aggregatable route announcements for the prefixes from the address > > >space of the first ISP who has become unreachable. > > Speaking from operational experience: this is not going to work. As a > multihomed site, I have to regularly check if I can still reach the entire > internet when one line goes down, because it wouldn't be the first time > someone placed the wrong filters at the wrong place. If you don't test > something like this, it's not going to work when you need it. In this case, at least, I don't see a big scalability problem as long as everyone tests randomly, and the routers forward using longest prefix match. > > Also, when huge amounts of more specific prefixes appear, this could be just > the kind of thing to drive a lot of routers over the edge, especially when > we're getting close to a common limit, such as 128 MB in Cisco routers. It may be useful to know what % of current router memory each ISP currently uses, and how many networks he aggregates. That should give a back-of-the-envolope figure about how much a single ISP can overload a network. While, clearly, this figure will be much better than what is today (assuming every multihomed site today is advertising non-aggregatable routes into the DFZ, and there is no one major ISP serving all multihomed sites), it may give a better idea of the rough number of possible excess routes that can appear due to a single ISP breakdown. > > And when you can announce more specifics some of the time, why not make > "some" "a lot" or even "all"? And then people will start to filter and we're > back to square one. I think we can safely assume that the probability of the event of an entire ISP going down is randomly distributed across time, which means that even if one ISP goes down completely, the overload will be less than that in the case where every ISP advertises non-aggregatable routes (as is the current case today). thanks, ramki From owner-multi6@ops.ietf.org Tue Jul 17 03:44:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA17504 for ; Tue, 17 Jul 2001 03:44:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MPHo-0007fe-00 for multi6-data@psg.com; Tue, 17 Jul 2001 00:28:52 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.31 #1) id 15MPHn-0007fP-00 for multi6@ops.ietf.org; Tue, 17 Jul 2001 00:28:51 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f6H7SkP25584; Tue, 17 Jul 2001 10:28:47 +0300 Date: Tue, 17 Jul 2001 10:28:46 +0300 (EEST) From: Pekka Savola To: Tony Hain cc: Subject: RE: Provider Independent addressing usage In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 13 Jul 2001, Tony Hain wrote: > > Problems with the PI approach: > > > > 1) people don't seem to want too specific routes in the DFZ. > > With current policies, I'd estimate 100-200 routes is the > > maximum. (though the technical constraints are a couple of > > orders of magnitude larger). Specifying these with prefix length > > may give the wrong impression, as the space would be rather > > densely populated (minus the oceans, sahara etc.) > > I agree that removing specifics from the DFZ is the goal, but punching holes > in provider aggregates is the current reality and that mechanism is directly > contrary to the goal. I don't understand your point about prefix length. > What I was trying to say in the draft was that each of the regions outside > of the current scope would be represented by single prefix. The population > density of these remote regions has no impact on routing in the local > region. Punching holes is the current reality with _IPv4_. In IPv6 world (at least 6bone), too specific routes are filtered by almost everybody; so this would not work. > > 2) because of non-specific advertisements, operators would be > > forced to carry a lot of traffic not their own, or throw it > > out. Neither is acceptable, economically or from user's > > point-of-view. > > Simply FUD. There may not be a customer relationship between an intermediate > operator and the destination, but the traffic was originated via a customer > relationship with the source, and there is some operator with a relationship > to the destination. Inter-provider agreements are what they are, and they > have little relationship to end customers. When a site is connected to > multiple operators each of them become identifiable entities to the > intermediate operator, so there is a potential for customer relationships > between providers. If end-sites are directly connecting to exchanges, the > exchange becomes the logical customer of the intermediate operators and > passes through the costs to the connecting customer. FUD how? I don't see flaw in my point _if_ there are no significant exchanges in the regions in question. If there are a lot of exchanges, ie. "neutral ground", this is not a problem. Consider: Assume source is in e.g. Europe and the destination in someone from a different provider in a backwater city in the U.S. Assume there is no regional exchange close by. There are a few issues here: 1) which out-of-the-country provider is selected 2) which intercontinental carrier is selected 3) where the intercontinental carrier drops the traffic 4) where someone else picks it up 1) no problem and no matter; the customer has default routes and direct relation with his ISP's. 2) all EU-US carriers probably want to advertise reachability to all US destinations, I'd suspect. So, one of these is picked. 3) The carrier does not know what to actually do about the packet yet, but let's assume it just pushes it toward a PoP nearest to the region. If there is no IX in the region, the carrier can either dump the packet (if it doesn't know a more specific route), or throw it at some operator operating in the region. 4) Some operator operating in the region _might_ get a packet, but it can't know yet whether the destination in the area is reachable or not. So it could take the packet, muck around with it, perhaps route it closer to the destination (geographically) and "throw the hot potato to the next guy". As said, these problems are "fixed" by: 1) lots and lots of IX's (up to the level where having full /48's is acceptable), or 2) full /48 routes in all ISP's, carriers etc. which makes the entire routing table size consideration moot > > 3) the only ones that could really gain from advertisements > > are regional/area/etc. IX's that have a very high level of > > regional ISP penetration; e.g. if address belongs to the > > region, it'd be reachable through the members of an IX with > > over 99.9% probability. > > The PI addresses that actually have an attached site will always be > reachable through some set of the ISP's in the region. It appears that you > are concerned that some of the ISP's in the region are not participants in > an exchange. This is not required as long as one of the providers that are > participating is willing to tie it all together. The only mechanism to > enforce this is for the inter-region providers to refuse more specifics, or > charge exorbitant fees. What I'm worried about is situation where SiteA is customer of ISPA, and ISPA does not participate in exchange in SiteA's region, but does participate in some other exchanges. Assume SiteB is in the same region as SiteA, using ISPB which does participate in the regional exchange. Now the exchange advertises the reachability of regional prefix, but SiteA will not be reachable. ISPB and ISPA might not be willing to "tie it together" if there is no customer relationship between them (ie, not ISP - Carrier). I think one of the goals is that inter-region providers, or "upper layers" in general, don't have to know all the specific routes. > > 4) ISP's operating at the IX would have to advertise, among > > themselves, full /48 routes. In some regions, where there > > are dozens of millions of Internet users, this is probably > > not an acceptable solution either. So the problem goes back > > to 2), but in smaller scale where there are often _no_ IX's > > to exchange the traffic. > > Lack of an exchange in the current topology is not relevant to what might be > necessary to scale millions of multi-homed sites in a specific scope. Look > back a few years and you would find only a few exchanges globally. > Additional exchanges were built as the engineering trade-offs showed value > in establishing an exchange at a particular place. The design of this PI > mechanism allows exchanges to be created at the scopes that make sense for > local engineering reasons, without impact about on any other scopes. Perhaps the practical requirement for IX's should be noted more clearly in the draft. > > So, it's often the case, e.g. in Europe, that a country has > > about one IX. The PI solution would work if the prefix(es) > > of the region belonging to that country were advertised to > > by that IX, and _everyone's_ (in that country) /48 PI prefix > > be advertised within that IX (whether it's directly associated, > > or a smaller client ISP of the peering bigger ISP). > > Forget country boundaries, and see the previous note about when and where > exchanges get built. Certainly the scopes relevant to an existing IX should > have their prefixes exchanged by the participants in the IX, or a route > server at the IX coordinated the actual prefix/provider relationships. Countries often have an IX, and as international connections often require paying for carrier service or getting possibly rather expensive connections, it's often that regional boundaries are actually de-facto country boundaries. Bigger IX's (probably most of the ones we regard as real exchanges now) are most often "international". > > If this was not done, some regional ISP's would have to capture > > and carry some traffic they have no idea if they can deliver or > dumped. > Or, the traffic could be sent to some smaller-than- > > regional IX's which by definition didn't exist. > > I don't understand. If there is a site at the defined prefix there will be > an explicit entry known to the providers for that scope. If there is no site > there may be connection attempts, but that is no different from unassigned > provider-based prefix addresses. See the concern above on ISPA offering service in an area, but not necessarily peering, or participating in an exchange (if one exists) in that particular area (but perhaps knowing ISPB from some other areas). > > Take the netcraft web server count by domain for example > > [http://www.netcraft.com/Survey/Reports/0106/bydomain/]; > > I think it's fair to assume that each /48 site would have at > > least one if not more web servers. United Kingdom appears to > > have about 2.8 million, so say 3 million /48's. Even if there > > were 10 IX's in the UK (distributed nicely by geographical > > areas, no less), this would still be a whole lot of specific > > /48 routes between participating ISP's. > > Yes; if all sites were multi-homed and the providers chose to implement it > that way. When they become concerned about scale, history shows they will > implement more IX's to break up the space. If PI addressing were to be adopted at large, there would have to be more IX's. Someone has to administer, and pay for them. This might become an important point to consider. -- 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 Jul 17 05:32:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA00649 for ; Tue, 17 Jul 2001 05:32:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MR2u-000ALq-00 for multi6-data@psg.com; Tue, 17 Jul 2001 02:21:36 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.31 #1) id 15MR2t-000ALj-00 for multi6@ops.ietf.org; Tue, 17 Jul 2001 02:21:35 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f6H9NGO14883; Tue, 17 Jul 2001 11:23:16 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 17 Jul 2001 11:21:55 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: xxvaf cc: multi6@ops.ietf.org Subject: Re: A tunneling proposal In-Reply-To: Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 16 Jul 2001, xxvaf wrote: > > Is there a known limit to the number of routes in the global routing > > table? I know bad things started to happen at about 4000 and 10000, but > > obviously those problems have been solved. Routers run just fine with 100,000 > > routes at present, and unless I'm mistaken, the most common types of router > > have CPUs and memory that are well below what most of us have in our desk top > > PCs. > The veracity of "Routers run just fine with 100,000 routes..." depends on > how you define "fine". A few weeks ago, someone posted a survey on the list. Nobody answered "we can't handle the huge number or routers" on it. > Modern routers don't fall over with 100,000 routes in them. But initial table > load and BGP convergence times when paths change are both a lot longer than > many would like. Ok, but is that enough reason to throw out the current way of multihoming? > > On top of that, each route takes a LOT of memory: 240 bytes for the routing > > table and for each peer route in the BGP table in a Cisco. > The size of individual routing state entries in modern routers has been the > subject of a great deal of optimization over the years. Don't expect to see > it improved by an order of magnitude or even by a factor of two. Really? It seems to me that this has not changed since I first started running BGP in 1995. Optimizations have been done under the current CIDR-paradigm, where every route is unique and carries a lot of additional information (such as communities) with it. If we optimize for very many nearly identical routes the results could be very different. > Memory size is not the principal issue; memory speed and routing table update > bandwidth are. You have a point on the table updates. A solution for that could be to only allow information about routes going down to be immediately forwarded, since this is presumably an operation that can be optimized not to be very expensive. New route announcements could be slowed down. I don't believe memory speed is a reason to keep the routing table at its current size: doing a binary search on 10,000,000 rather than 100,000 items only takes 24 steps rather than 17. If this is a problem for 10,000,000 routes, 100,000 routes is too much as well. > > I think it's worth it to look at this, because with CIDR it is pretty much > > impossible to efficiently route traffic: many locations are hidden behind > > aggregates. > If global routing state size resumes a hyper-exponential growth pattern that > exceeds Moore's law, the problem will get worse faster than CPUs increase > in speed. Do we have any inidication that the global routing table is growing faster than the Moore's Law rate? > Eliminating CIDR will guarentee hyper-exponential growth - for all > the talk about how CIDR has "failed" in that growth is continuing, the growth > rate would be far, far worse without it - aggregation has successfully > "hidden" at least an order of magnitude of growth. I'm not saying "CIDR is dead, everybody stop aggregating". But CIDR has reached the limits of its capabilities. Just look at the routing table vs the number of AS numbers: for every assigned ASN there are five routes. This has very little to do with the evil multihomers, since they have little reason to announce more than a single route. > Look back at old archives of the IETF and other lists to read some of Noel > Chiappa's and others' writings on the mathematics of network topology and > addressing. If the "addresses" used by routing don't follow the underlying > network topology, excessive state is introduced. For multihoming to really > work, it needs to use topologically-significant addressing. That suggests > that the "multi" in "multihoming" also implies multiple addresses, with > something like SCTP to handle them intelligently. 1. Forget SCTP: if we want this, we should build it into TCP and not change transport layers to a protocol that has just one desirable feature and forget 20 years of experience with the most successful protocol in history. 2. The current way of multihoming works much better for the multihomed network, what is their incentive to go with multiple addresses? Iljitsch van Beijnum From owner-multi6@ops.ietf.org Tue Jul 17 09:24:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03613 for ; Tue, 17 Jul 2001 09:24:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MUca-000GWT-00 for multi6-data@psg.com; Tue, 17 Jul 2001 06:10:40 -0700 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.31 #1) id 15MUcZ-000GUn-00 for multi6@ops.ietf.org; Tue, 17 Jul 2001 06:10:39 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 86E488266F; Tue, 17 Jul 2001 09:10:00 -0400 (EDT) Message-Id: <5.1.0.14.2.20010717085359.01d93aa0@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 17 Jul 2001 09:05:34 -0400 To: Iljitsch van Beijnum From: RJ Atkinson Subject: Re: A tunneling proposal Cc: multi6@ops.ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 05:21 17/07/01, Iljitsch van Beijnum wrote: >> The veracity of "Routers run just fine with 100,000 routes..." >> depends on how you define "fine". > >A few weeks ago, someone posted a survey on the list. Nobody answered "we >can't handle the huge number or routers" on it. NOTE: Probability of a given person answering a survey on the NANOG list is inversely proportional to the probability that the person works for a major IP carrier and has at least one clue about routing. >> Modern routers don't fall over with 100,000 routes in them. >> But initial table load and BGP convergence times when paths change >> are both a lot longer than many would like. > >Ok, but is that enough reason to throw out the current way of multihoming? Yes. >>> On top of that, each route takes a LOT of memory: 240 bytes >>> for the routing table and for each peer route in the BGP table >>> in a Cisco. > >> The size of individual routing state entries in modern routers >> has been the subject of a great deal of optimization over the years. >> Don't expect to see it improved by an order of magnitude or even >> by a factor of two. > >Really? Yes. >> Memory size is not the principal issue; memory speed and >> routing table update bandwidth are. > >You have a point on the table updates. A solution for that could be to only >allow information about routes going down to be immediately forwarded, since >this is presumably an operation that can be optimized not to be very >expensive. New route announcements could be slowed down. Immediately forwarding information about routes going down increases the load on the overall routing system due to route flaps. Dealing with this system loading issue caused by route flaps is precisely why BGP has dampening. >I don't believe memory speed is a reason to keep the routing table at its >current size: doing a binary search on 10,000,000 rather than 100,000 items >only takes 24 steps rather than 17. If this is a problem for 10,000,000 >routes, 100,000 routes is too much as well. Some think that 100K prefixes is already uncomfortably large for the algorithms currently being used. Others think that that the critical point is more nearly 200K prefixes. Folks mileage varies somewhat on where the critical point lies with the current algorithms. Note my phrasing. I talk about "algorithms" rather than "implementations" quite deliberately. >Do we have any inidication that the global routing table is >growing faster than the Moore's Law rate? As I recall, tli has made precisely this claim in the past. I'm strongly inclined to just take tli's word on such a point. >> Eliminating CIDR will guarentee hyper-exponential growth - for all >> the talk about how CIDR has "failed" in that growth is continuing, >> the growth rate would be far, far worse without it - aggregation >> has successfully "hidden" at least an order of magnitude of growth. > >I'm not saying "CIDR is dead, everybody stop aggregating". But CIDR has >reached the limits of its capabilities. Just look at the routing table >vs the number of AS numbers: for every assigned ASN there are five routes. However, a typical AS is not originating 5 routes. One needs to be fairly careful in playing with statistics in this space. >> Look back at old archives of the IETF and other lists to read some of Noel >> Chiappa's and others' writings on the mathematics of network topology and >> addressing. If the "addresses" used by routing don't follow the underlying >> network topology, excessive state is introduced. For multihoming to really >> work, it needs to use topologically-significant addressing. That suggests >> that the "multi" in "multihoming" also implies multiple addresses, with >> something like SCTP to handle them intelligently. > >1. Forget SCTP: if we want this, we should build it into TCP and not change > transport layers to a protocol that has just one desirable feature and > forget 20 years of experience with the most successful protocol in > history. In the past, this sort of change to TCP was precisely forbidden procedurally. I agree the community should seriously examine ways in which the clues from SCTP multihoming might be injected into the UDP and TCP protocols. I don't understand if examining such changes would be within scope for this WG or would belong elsewhere. >2. The current way of multihoming works much better for the multihomed > network, what is their incentive to go with multiple addresses? Economics is a major constraint on the potential solution space. Ran rja@inet.org From owner-multi6@ops.ietf.org Tue Jul 17 11:28:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29946 for ; Tue, 17 Jul 2001 11:28:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MWaO-000KwT-00 for multi6-data@psg.com; Tue, 17 Jul 2001 08:16:32 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.31 #1) id 15MWaN-000Kvl-00 for multi6@ops.ietf.org; Tue, 17 Jul 2001 08:16:31 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f6HFIAO15263; Tue, 17 Jul 2001 17:18:10 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 17 Jul 2001 17:16:47 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: RJ Atkinson cc: multi6@ops.ietf.org Subject: Re: A tunneling proposal In-Reply-To: <5.1.0.14.2.20010717085359.01d93aa0@10.30.15.2> Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 17 Jul 2001, RJ Atkinson wrote: > >A few weeks ago, someone posted a survey on the list. Nobody answered "we > >can't handle the huge number or routers" on it. > NOTE: > Probability of a given person answering a survey on the NANOG list > is inversely proportional to the probability that the person works > for a major IP carrier and has at least one clue about routing. I don't know about the carrier size, but from what I saw these people seemed to have some clue at least. > >> Modern routers don't fall over with 100,000 routes in them. > >> But initial table load and BGP convergence times when paths change > >> are both a lot longer than many would like. > >Ok, but is that enough reason to throw out the current way of multihoming? > Yes. Well, I disagree. Slow initial sync and convergence times are bad, but outlawing current multihoming is very bad as well. And I'm certaintly not convinced this is well-optimized. Not much is. > >> The size of individual routing state entries in modern routers > >> has been the subject of a great deal of optimization over the years. > >> Don't expect to see it improved by an order of magnitude or even > >> by a factor of two. > >Really? > Yes. So how does this relate to my experience that the amount of memory used by BGP table entries is the same as six years ago? > >You have a point on the table updates. A solution for that could be to only > >allow information about routes going down to be immediately forwarded, since > >this is presumably an operation that can be optimized not to be very > >expensive. New route announcements could be slowed down. > Immediately forwarding information about routes going down > increases the load on the overall routing system due to route flaps. Going down just once isn't really flapping. Flapping is when routes keep coming up and going down. Going down shouldn't have to be an expensive operation if you leave the information in place but just mark it as "invalid". Coming up means inserting information, which is a more expensive operation. If we slow this down, the routes can't go back down again. When going down means staying down for a while, people will start to pay more attention to unnecessary flapping. > Dealing with this system loading issue caused by route flaps > is precisely why BGP has dampening. Unfortunately, a major source of flapping seems to be unaddressed: when an AS has a route coming in from a lot of different directions, a lot of iBGP updates will start flying around when this route disappears. I wouldn't be surprised if each of those iBGP state changes also caused an eBGP flap. > >I don't believe memory speed is a reason to keep the routing table at its > >current size: doing a binary search on 10,000,000 rather than 100,000 items > >only takes 24 steps rather than 17. If this is a problem for 10,000,000 > >routes, 100,000 routes is too much as well. > Some think that 100K prefixes is already uncomfortably large > for the algorithms currently being used. Which algorithms? Forwarding or route processing? > Others think that > that the critical point is more nearly 200K prefixes. Folks > mileage varies somewhat on where the critical point lies > with the current algorithms. Note my phrasing. I talk about > "algorithms" rather than "implementations" quite deliberately. I've read about tests with 2 million routes on some boxes. Note that CIDR causes route lookup algorithms to be less efficient: in stead of just finding a single match, the algorithm has to eveluate all possible prefix lengths. Unless there is some brilliant algorithm for this I'm unaware of, this makes the lookup about 1.5 - 2 times as expensive. > >Do we have any inidication that the global routing table is > >growing faster than the Moore's Law rate? > As I recall, tli has made precisely this claim in the past. > I'm strongly inclined to just take tli's word on such a point. Well, have a look at http://www.cisco.com/warp/public/759/ipj_4-1/ipj_4-1_bgp.html It seems the growth between the beginning of 1999 and the beginning of 2001 was a little less than a factor two, so we're a little below Moore, but not a lot. (But enough to reach 1 billion routes in 2027 rather than 2021.) It would be interesting to know how much of this growth is from multihoming. Since the absolute number of routes grows much faster than the absolute number of ASNs, most of the growth has to be from poor aggregation, probably due to the address conservation efforts of the regional registries. > >2. The current way of multihoming works much better for the multihomed > > network, what is their incentive to go with multiple addresses? > Economics is a major constraint on the potential solution space. I'm not even talking about economics, but just basic functionality and human nature: how are you going to convince someone stop doing something that works for them to help some greater good, that doesn't show obvious signs of needing help? "Global warming? Let me turn up the airco..." If there really is a limit above which global routing breaks down, we should implement some policies to prevent the number of routes from reaching this limit. This means forcing existing ASes to aggregate, and limiting the growth in the number of ASes. That way, SCTP-like solutions become more attractive. But I think we can: 1. optimize protocols 2. optimize implementations 3. look for alternative ways to aggregate, for instance on geography Iljitsch van Beijnum From owner-multi6@ops.ietf.org Tue Jul 17 12:01:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08374 for ; Tue, 17 Jul 2001 12:01:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MWpF-000LZd-00 for multi6-data@psg.com; Tue, 17 Jul 2001 08:31:53 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.31 #1) id 15MWpD-000LZV-00 for multi6@ops.ietf.org; Tue, 17 Jul 2001 08:31:51 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f6HFVab27957; Tue, 17 Jul 2001 18:31:36 +0300 Date: Tue, 17 Jul 2001 18:31:35 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: Subject: Re: A tunneling proposal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 17 Jul 2001, Iljitsch van Beijnum wrote: > I'm not even talking about economics, but just basic functionality and human > nature: how are you going to convince someone stop doing something that works > for them to help some greater good, that doesn't show obvious signs of > needing help? "Global warming? Let me turn up the airco..." > > If there really is a limit above which global routing breaks down, we should > implement some policies to prevent the number of routes from reaching this > limit. This means forcing existing ASes to aggregate, and limiting the growth > in the number of ASes. That way, SCTP-like solutions become more attractive. How about "all the specifics you'd want to annouce are being filtered by other parties in the Internet so your multihoming only works for 1% of Internet users" ? Could be rather effective if people stick to these prefix length filters... -- 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 Jul 17 12:01:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08386 for ; Tue, 17 Jul 2001 12:01:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MWya-000LyE-00 for multi6-data@psg.com; Tue, 17 Jul 2001 08:41:32 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15MWyZ-000Ly2-00 for multi6@ops.ietf.org; Tue, 17 Jul 2001 08:41:31 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id IAA19059; Tue, 17 Jul 2001 08:41:21 -0700 (PDT) Date: Tue, 17 Jul 2001 08:41:20 -0700 (PDT) From: Ramakrishna Gummadi To: Iljitsch van Beijnum cc: RJ Atkinson , Subject: Re: A tunneling proposal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > > Economics is a major constraint on the potential solution space. > > I'm not even talking about economics, but just basic functionality and human > nature: how are you going to convince someone stop doing something that works > for them to help some greater good, that doesn't show obvious signs of > needing help? "Global warming? Let me turn up the airco..." > > If there really is a limit above which global routing breaks down, we should > implement some policies to prevent the number of routes from reaching this > limit. This means forcing existing ASes to aggregate, and limiting the growth > in the number of ASes. That way, SCTP-like solutions become more attractive. > Currently, multihomers pay each their ISPs extra to carry non-aggregatable routes. This means if the ISPs encounter problems with the additional routes, they are directly going to charge the sites more. This way, one can impose artificial constraints on how many sites multihome, but this is exactly what we are trying to avoid. As for backpatcing TCP to work with multihoming, this would not work with the current apps, and socket API if done the SCTP way---SCTP requires the apps to *explicitly* give a list of addresses to use on a connection. To backpatch TCP to do the same would mean requiring the TCP layer itself to figure out what additional addresses it can use *without* the app knowledge. This means that the protocol stack can get it wrong if there is address translation going on for getting provider independence, etc... Ultimately, it will basically look like GxSE... -ramki From owner-multi6@ops.ietf.org Tue Jul 17 13:48:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01632 for ; Tue, 17 Jul 2001 13:48:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MYbi-000PV7-00 for multi6-data@psg.com; Tue, 17 Jul 2001 10:26:02 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MYbh-000PV0-00 for multi6@ops.ietf.org; Tue, 17 Jul 2001 10:26:01 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MYbc-0000LO-00 for multi6@ops.ietf.org; Tue, 17 Jul 2001 13:25:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group cc: iesg@ietf.org Subject: Note Well Sender: owner-multi6@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 10:26:02 -0700 Content-Transfer-Encoding: 7bit Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. From owner-multi6@ops.ietf.org Tue Jul 17 14:17:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08669 for ; Tue, 17 Jul 2001 14:17:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MZ8a-0000iw-00 for multi6-data@psg.com; Tue, 17 Jul 2001 11:00:00 -0700 Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15MZ8Z-0000iq-00 for multi6@ops.ietf.org; Tue, 17 Jul 2001 10:59:59 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MZ8Y-0000Mx-00 for multi6@ops.ietf.org; Tue, 17 Jul 2001 13:59:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group cc: iesg@ietf.org Subject: Note Well Sender: owner-multi6@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 17 Jul 2001 11:00:00 -0700 Content-Transfer-Encoding: 7bit Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. From owner-multi6@ops.ietf.org Tue Jul 17 16:47:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09898 for ; Tue, 17 Jul 2001 16:47:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MbUW-0005Sh-00 for multi6-data@psg.com; Tue, 17 Jul 2001 13:30:48 -0700 Received: from flowpoint.procket.com ([209.140.237.1] helo=alpha-tli.procket.com) by psg.com with esmtp (Exim 3.31 #1) id 15MbUV-0005Qa-00 for multi6@ops.ietf.org; Tue, 17 Jul 2001 13:30:47 -0700 Received: (from tli@localhost) by alpha-tli.procket.com (8.9.3/8.9.3) id NAA20366; Tue, 17 Jul 2001 13:30:03 -0700 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: alpha-tli.procket.com: tli set sender to tli@alpha-tli.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15188.41035.202910.657065@alpha-tli.procket.com> Date: Tue, 17 Jul 2001 13:30:03 -0700 To: Iljitsch van Beijnum Cc: RJ Atkinson , multi6@ops.ietf.org Subject: Re: A tunneling proposal In-Reply-To: References: <5.1.0.14.2.20010717085359.01d93aa0@10.30.15.2> X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit | > >> Modern routers don't fall over with 100,000 routes in them. But | > >> initial table load and BGP convergence times when paths change are | > >> both a lot longer than many would like. | | > >Ok, but is that enough reason to throw out the current way of | > >multihoming? | | > Yes. | | Well, I disagree. Slow initial sync and convergence times are bad, but | outlawing current multihoming is very bad as well. And I'm certaintly | not convinced this is well-optimized. Not much is. You are welcome to disagree. However, the facts of the matter are very clear. If the Internet is to grow, it will continue to add 'sites' to it, almost indefinitely. Some percentage of those sites will want to multihome. Under the current multihoming architecture, those sites will appear in the DFZ routing table. If the growth rate of those sites exceeds Moore's law, then it will be become exceedingly expensive to support the routing subsystem. It is vital to the life of the net that the routing subsystem continue to scale well. The price of this scalability is the discipline to adhere to a scalable architecture. Are you willing to pay that price? | > >> The size of individual routing state entries in modern routers has | > >> been the subject of a great deal of optimization over the years. | > >> Don't expect to see it improved by an order of magnitude or even by | > >> a factor of two. | | > >Really? | | > Yes. | | So how does this relate to my experience that the amount of memory used | by BGP table entries is the same as six years ago? Your experience does not match mine. | > >Do we have any inidication that the global routing table is growing | > >faster than the Moore's Law rate? | | > As I recall, tli has made precisely this claim in the past. I'm | > strongly inclined to just take tli's word on such a point. To be 100% accurate: I made the point that the rate of growth is increasing and that if left unchecked, this implies that the growth will someday exceed Moore's law. | I'm not even talking about economics, but just basic functionality and | human nature: how are you going to convince someone stop doing something | that works for them to help some greater good, that doesn't show obvious | signs of needing help? "Global warming? Let me turn up the airco..." We're well aware that we have a tragedy of the commons scenario. The first step has to be to convince you that the IPv6 routing architecture needs to be something scalable. | If there really is a limit above which global routing breaks down, we | should implement some policies to prevent the number of routes from | reaching this limit. This means forcing existing ASes to aggregate, and | limiting the growth in the number of ASes. That way, SCTP-like solutions | become more attractive. | | But I think we can: | | 1. optimize protocols This has been in progress for 8 years. | 2. optimize implementations This has also been in progress for 8 years. | 3. look for alternative ways to aggregate, for instance on geography Local geographic aggregation (i.e. metro aggregation) has issues about forced connectivity that we are not able to regulate. Global geographic aggregation (i.e., at the continental scale) has been struck down as a bad idea. If you ignore history, you're doomed to repeat it. Just like this conversation. Tony From owner-multi6@ops.ietf.org Tue Jul 17 17:16:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16239 for ; Tue, 17 Jul 2001 17:16:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Mc4N-0006ij-00 for multi6-data@psg.com; Tue, 17 Jul 2001 14:07:51 -0700 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.31 #1) id 15Mc4M-0006ic-00 for multi6@ops.ietf.org; Tue, 17 Jul 2001 14:07:50 -0700 Subject: Re: A tunneling proposal Date: Tue, 17 Jul 2001 14:07:48 -0700 Message-ID: <2B81403386729140A3A899A8B39B046403AC80@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message Thread-Topic: A tunneling proposal Thread-Index: AcEPANTgWOs4rc1BSJ64ed+kxUgOdQAAq3Za From: "Michel Py" To: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id RAA16239 My opinion it that it all comes to this: If we thought that multihoming the way it is currently done was good, this working group "multi6" would not exist to begin with. I think the purpose of this workgroup is not to reproduce the existing situation but rather fix it. My $0.02 Michel. -----Original Message----- From: Tony Li Sent: Tue 7/17/2001 1:30 PM To: Iljitsch van Beijnum Cc: RJ Atkinson; multi6@ops.ietf.org Subject: Re: A tunneling proposal | > >> Modern routers don't fall over with 100,000 routes in them. But | > >> initial table load and BGP convergence times when paths change are | > >> both a lot longer than many would like. | | > >Ok, but is that enough reason to throw out the current way of | > >multihoming? | | > Yes. | | Well, I disagree. Slow initial sync and convergence times are bad, but | outlawing current multihoming is very bad as well. And I'm certaintly | not convinced this is well-optimized. Not much is. You are welcome to disagree. However, the facts of the matter are very clear. If the Internet is to grow, it will continue to add 'sites' to it, almost indefinitely. Some percentage of those sites will want to multihome. Under the current multihoming architecture, those sites will appear in the DFZ routing table. If the growth rate of those sites exceeds Moore's law, then it will be become exceedingly expensive to support the routing subsystem. It is vital to the life of the net that the routing subsystem continue to scale well. The price of this scalability is the discipline to adhere to a scalable architecture. Are you willing to pay that price? | > >> The size of individual routing state entries in modern routers has | > >> been the subject of a great deal of optimization over the years. | > >> Don't expect to see it improved by an order of magnitude or even by | > >> a factor of two. | | > >Really? | | > Yes. | | So how does this relate to my experience that the amount of memory used | by BGP table entries is the same as six years ago? Your experience does not match mine. | > >Do we have any inidication that the global routing table is growing | > >faster than the Moore's Law rate? | | > As I recall, tli has made precisely this claim in the past. I'm | > strongly inclined to just take tli's word on such a point. To be 100% accurate: I made the point that the rate of growth is increasing and that if left unchecked, this implies that the growth will someday exceed Moore's law. | I'm not even talking about economics, but just basic functionality and | human nature: how are you going to convince someone stop doing something | that works for them to help some greater good, that doesn't show obvious | signs of needing help? "Global warming? Let me turn up the airco..." We're well aware that we have a tragedy of the commons scenario. The first step has to be to convince you that the IPv6 routing architecture needs to be something scalable. | If there really is a limit above which global routing breaks down, we | should implement some policies to prevent the number of routes from | reaching this limit. This means forcing existing ASes to aggregate, and | limiting the growth in the number of ASes. That way, SCTP-like solutions | become more attractive. | | But I think we can: | | 1. optimize protocols This has been in progress for 8 years. | 2. optimize implementations This has also been in progress for 8 years. | 3. look for alternative ways to aggregate, for instance on geography Local geographic aggregation (i.e. metro aggregation) has issues about forced connectivity that we are not able to regulate. Global geographic aggregation (i.e., at the continental scale) has been struck down as a bad idea. If you ignore history, you're doomed to repeat it. Just like this conversation. Tony From owner-multi6@ops.ietf.org Tue Jul 17 17:20:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16861 for ; Tue, 17 Jul 2001 17:20:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15McH6-00078d-00 for multi6-data@psg.com; Tue, 17 Jul 2001 14:21:00 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15McH5-00078X-00 for multi6@ops.ietf.org; Tue, 17 Jul 2001 14:20:59 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id OAA26835 for ; Tue, 17 Jul 2001 14:20:58 -0700 (PDT) Date: Tue, 17 Jul 2001 14:20:58 -0700 (PDT) From: Ramakrishna Gummadi To: Subject: Re: A tunneling proposal In-Reply-To: <2B81403386729140A3A899A8B39B046403AC80@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 Multi6 chairs, I know that the official IETF deadline for submitting internet drafts has passed, but I was wondering if the wg is going to still consider internet drafts if submitted by the end of this week... thanks, ramki From owner-multi6@ops.ietf.org Tue Jul 17 21:21:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA04367 for ; Tue, 17 Jul 2001 21:21:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Mfv8-000Fa0-00 for multi6-data@psg.com; Tue, 17 Jul 2001 18:14:34 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Mfv7-000FZb-00 for multi6@ops.ietf.org; Tue, 17 Jul 2001 18:14:33 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id UAA59666; Tue, 17 Jul 2001 20:14:31 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Tue, 17 Jul 2001 20:14:31 -0500 (CDT) From: "Jon (Taz) Mischo" To: Daniel Senie cc: Ramakrishna Gummadi , multi6@ops.ietf.org Subject: Re: A tunneling proposal In-Reply-To: <5.1.0.14.2.20010716182916.03d0de20@mail.amaranth.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Forgive me...I'm running behind...see notes below. On Mon, 16 Jul 2001, Daniel Senie wrote: > This could work, provided the alternate upstream ISPs are willing, and > other networks are willing to take the announcements. The concern is that > RADB and similar are used by providers to restrict where announcements will > come from. Keep in mind also that what we're talking about here is human > intervention in the case of an outage. The question to be answered by > prospective users of such a multhoming solution is how many hours of outage > can be tolerated? I suspect it unlikely that automated tunnel creation and > announcement setup would be well received by those running backbones, so > there's likely to be a human element at play. I'm sorry, but you're incorrect here. Multihoming is meant to be "automatic," no intervention required. You're talking about manually rerouting traffic, not multihoming. What's the point of this if you have to do it manually? > While I understand the desire to find ways to avoid introducing routes into > the DFZ, I firmly believe any solution should provide an automated > resilience in the face of outages. I'm not yet convinced there's a good way > to do this with tunnels. -Taz > >On Mon, 16 Jul 2001, Daniel Senie wrote: > > > > > At 05:40 PM 7/16/01, Ramakrishna Gummadi wrote: > > > >I hypothesize that the only scenario where tunneling for TCP > > > >and UDP fails is when the entire ISP is affected in a major way. > > > > > > Given economic conditions and the relative health or lack thereof of some > > > providers, this alone is a significant concern. If a network is powered > > > down by their bankers, customers who were multihomed via tunneling would be > > > out of luck. This isn't the type of redundancy that is going to make people > > > sleep well at night. > > > > > > People want to multihome so that any outage, from a local loop to a > > > backbone carrier can occur without obliterating their connectivity. I think > > > it important to keep that in mind. > > > > > > Tunneling is quite useful for fixing temporary problems, but I'm not > > > convinced it's a worthwhile solution to the multihoming problem. > > > > > > ----------------------------------------------------------------- > > > Daniel Senie dts@senie.com > > > Amaranth Networks Inc. http://www.amaranth.com > > > > > > > > > > > ----------------------------------------------------------------- > Daniel Senie dts@senie.com > Amaranth Networks Inc. http://www.amaranth.com > > -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Tue Jul 17 21:22:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA04502 for ; Tue, 17 Jul 2001 21:22:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Mg1F-000Fon-00 for multi6-data@psg.com; Tue, 17 Jul 2001 18:20:53 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Mg1E-000Foh-00 for multi6@ops.ietf.org; Tue, 17 Jul 2001 18:20:52 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id UAA59689; Tue, 17 Jul 2001 20:20:50 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Tue, 17 Jul 2001 20:20:50 -0500 (CDT) From: "Jon (Taz) Mischo" To: Iljitsch van Beijnum cc: Ramakrishna Gummadi , multi6@ops.ietf.org Subject: Re: A tunneling proposal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 17 Jul 2001, Iljitsch van Beijnum wrote: > Is there a known limit to the number of routes in the global routing > table? I know bad things started to happen at about 4000 and 10000, but > obviously those problems have been solved. Routers run just fine with 100,000 > routes at present, and unless I'm mistaken, the most common types of router > have CPUs and memory that are well below what most of us have in our desk top > PCs. My PC has 768M of RAM, which is unusual. Most have 256M or less, and I wouldn't want multiple full BGP feeds on a router with under 256M. > On top of that, each route takes a LOT of memory: 240 bytes for the routing > table and for each peer route in the BGP table in a Cisco. > > If we can both increase memory and decrease the route/BGP table entry size by > an order of magnitude, we should be able to run with a global routing table > of 10,000,000 routes. That's about the entire IPv4 space as individual /24's. > > Link speeds are high enough, and if route lookups are implemented as > variations of binary search they are of an order log(n) so going from 10e5 to > 10e7 should be just a 40% slowdown. The only thing that might be a problem is > processing so many routes when BGP sessions come up. Wow...you sure are optimistic. > I think it's worth it to look at this, because with CIDR it is pretty much > impossible to efficiently route traffic: many locations are hidden behind > aggregates. Someone in Chicago has to choose between routing traffic for the > aggregate to the west coast or the east coast, and in either case some > traffic will have gone in the wrong direction. > > Iljitsch van Beijnum > > -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Tue Jul 17 21:24:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA04874 for ; Tue, 17 Jul 2001 21:24:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Mfqi-000FNs-00 for multi6-data@psg.com; Tue, 17 Jul 2001 18:10:00 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.31 #1) id 15Mfqg-000FNi-00 for multi6@ops.ietf.org; Tue, 17 Jul 2001 18:09:58 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Tue, 17 Jul 2001 18:09:52 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 49DDEBB151BB4E4F9405F9D87D9D0DBD for plus 1 more; Tue, 17 Jul 2001 18:09:52 -0700 Reply-To: From: "Tony Hain" To: "Pekka Savola" Cc: Subject: RE: Provider Independent addressing usage Date: Tue, 17 Jul 2001 18:09:39 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-reply-to: Importance: Normal X-SLUIDL: 25AB1FFA-FDF64F67-90FA7479-71C32180 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA04874 Pekka Savola wrote: > Punching holes is the current reality with _IPv4_. In IPv6 world > (at least 6bone), too specific routes are filtered by almost > everybody; so this would not work. Filtering more-specifics was an IPv4 activity 5 years ago, but the reality of providing the service the end customer is paying for trumps the 'network-centric' viewpoint every time. If a site uses provider-based addresses and expects those to be routable through another provider then the upstream table of those two providers has to accept the explicit entry. No amount of wishing will make that untrue. > FUD how? I don't see flaw in my point _if_ there are no > Significant exchanges in the regions in question. If there are > a lot of exchanges, ie. "neutral ground", this is not a problem. > > Consider: > > Assume source is in e.g. Europe and the destination in someone > from a different provider in a backwater city in the U.S. > Assume there is no regional exchange close by. > > There are a few issues here: > 1) which out-of-the-country provider is selected > 2) which intercontinental carrier is selected > 3) where the intercontinental carrier drops the traffic > 4) where someone else picks it up > > 1) no problem and no matter; the customer has default routes > and direct relation with his ISP's. > > 2) all EU-US carriers probably want to advertise reachability > to all US destinations, I'd suspect. So, one of these is > picked. > > 3) The carrier does not know what to actually do about the > packet yet, but let's assume it just pushes it toward a PoP > nearest to the region. > > If there is no IX in the region, the carrier can either dump > the packet (if it doesn't know a more specific route), or throw > it at some operator operating in the region. > > 4) Some operator operating in the region _might_ get a packet, > but it can't know yet whether the destination in the area is > reachable or not. > So it could take the packet, muck around with it, perhaps route > it closer to the destination (geographically) and "throw the hot > potato to the next guy". > > As said, these problems are "fixed" by: > 1) lots and lots of IX's (up to the level where having full > /48's is acceptable), or > 2) full /48 routes in all ISP's, carriers etc. which makes > the entire routing table size consideration moot The reason I say FUD is the argument appears to be ignoring the origin of the routing entry. If an operator is forwarding a packet toward a pop in the destination region, it had to get that route from somewhere. The only way your scenario works is if the operator is not providing service in the destination region and decided to make up a route to that prefix for internal use. If a provider does this, yes the traffic will die, but this is no different than making up any other prefix. The only way a provider would know which provider to hand a packet off to is not a hot-potato guess, but hearing a routing advertisement. If the origin provider hands off the packet based on the longest-match prefix for the destination, the expectation is that the packet will get delivered. If there are providers not participating in the exchange covering that region, the provider holding the packet would need to know the specifics from them. This is no different from provider-based prefixes; there is no magic. There may be additional exchanges built, but this will be a clear engineering driven decision based on the number of multi-homed sites and the acceptable size of the local routing table. This is in contrast to the current set of exchanges that were built for purely political reasons, or simply avoiding the politically motivated international tariffs. Yes this mechanism will shift the balance back from private peering toward exchange-based peering, but is that a bad thing? It certainly opens up the local service area in a way that locking sites to a provider-based address will never do. The cost of connecting to multiple exchanges will act as a natural counter balance to prevent an absurd number of them from being created. > What I'm worried about is situation where SiteA is customer > of ISPA, and ISPA does not participate in exchange in SiteA's > region, but does participate in some other exchanges. Assume > SiteB is in the same region as SiteA, using ISPB which does > participate in the regional exchange. Now the exchange > advertises the reachability of regional prefix, but SiteA > will not be reachable. ISPB and ISPA might not be willing > to "tie it together" if there is no customer relationship > between them (ie, not ISP - Carrier). We are talking about multi-homed sites, right? So I assume you mean SiteA is a customer of ISPA & ISPC, while SiteB is a customer of ISPB & ISPD. If ISPA or ISPC neither one participate in the regional exchange, and their upstream filters the specific for SiteA (as it should), SiteA has a reason to switch to ISPB or ISPD. Since the addresses are not derived from ISPA or ISPC, there is no deterrent causing SiteA to stick with its current lame providers. SiteA is paying for a service; insulation from problems any individual provider may have; and in this scenario ISPA & ISPC both have a problem that SiteA wants to avoid. > I think one of the goals is that inter-region providers, or > "upper layers" in general, don't have to know all the specific > routes. I agree completely, but they can't push back and refuse to know specifics unless they have a replacement mechanism that gets the bits delivered to the paying customer. Provider-based specifics are all we have currently defined, and they are demonstrably broken for this purpose. > Perhaps the practical requirement for IX's should be noted > more clearly in the draft. Please send text. > Countries often have an IX, and as international connections > often require paying for carrier service or getting possibly > rather expensive connections, it's often that regional > boundaries are actually de-facto country boundaries. > > Bigger IX's (probably most of the ones we regard as real > exchanges now) are most often "international". I will give you the point that costs change as national boundaries are crossed, but the size and location of an exchange have no mandatory relationship to the prefix lengths exchanged there. For example, assume there is a massive exchange in London with 100's of providers participating covering all of the UK, and nearby another exchange, say Moscow, where there may only be 5 providers, but they cover all of Russia. The fact that one has more participants, or covers a region approximately 10 degrees square, while the other covers a region 20 x 150 degrees has nothing to do with the number of multi-homed sites supported. They may both be inadequate, or may both be overkill for the required service. The requirement is that all participants agree on the set of prefixes to be exchanged, and that set will almost assuredly contain multiple lengths to avoid overlapping with a neighboring exchange. > If PI addressing were to be adopted at large, there would have > to be more IX's. Someone has to administer, and pay for them. > This might become an important point to consider. And the multi-homed sites, which created the need, would be the logical place to look for the money. Currently there is no way to associate the site that creates the problem with where the pain is felt; but something like this where the providers could point at a specific local cost to support the site's goal, and the site could in turn see explicit value for the additional cost, might help that problem. Tony From owner-multi6@ops.ietf.org Tue Jul 17 21:40:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09288 for ; Tue, 17 Jul 2001 21:40:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MgA9-000G2b-00 for multi6-data@psg.com; Tue, 17 Jul 2001 18:30:05 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15MgA8-000G2V-00 for multi6@ops.ietf.org; Tue, 17 Jul 2001 18:30:04 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id UAA59708; Tue, 17 Jul 2001 20:30:00 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Tue, 17 Jul 2001 20:30:00 -0500 (CDT) From: "Jon (Taz) Mischo" To: Pekka Savola cc: Tony Hain , multi6@ops.ietf.org Subject: RE: Provider Independent addressing usage In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 17 Jul 2001, Pekka Savola wrote: > I think one of the goals is that inter-region providers, or "upper layers" > in general, don't have to know all the specific routes. This is exactly what the NA PSTN had to move away from. Next thing you know, your DSL router or cable modem or POTS modem is going to have a coinbox attached to it. -Taz -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Tue Jul 17 21:51:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11728 for ; Tue, 17 Jul 2001 21:51:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MgCQ-000GDH-00 for multi6-data@psg.com; Tue, 17 Jul 2001 18:32:26 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15MgCP-000GDA-00 for multi6@ops.ietf.org; Tue, 17 Jul 2001 18:32:25 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id UAA59716; Tue, 17 Jul 2001 20:32:24 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Tue, 17 Jul 2001 20:32:24 -0500 (CDT) From: "Jon (Taz) Mischo" To: Iljitsch van Beijnum cc: xxvaf , multi6@ops.ietf.org Subject: Re: A tunneling proposal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 17 Jul 2001, Iljitsch van Beijnum wrote: > > Look back at old archives of the IETF and other lists to read some of Noel > > Chiappa's and others' writings on the mathematics of network topology and > > addressing. If the "addresses" used by routing don't follow the underlying > > network topology, excessive state is introduced. For multihoming to really > > work, it needs to use topologically-significant addressing. That suggests > > that the "multi" in "multihoming" also implies multiple addresses, with > > something like SCTP to handle them intelligently. > > 1. Forget SCTP: if we want this, we should build it into TCP and not change > transport layers to a protocol that has just one desirable feature and > forget 20 years of experience with the most successful protocol in > history. Wow...let's not use something based on 20 years of experience that already exists, let's re-invent the wheel instead. > 2. The current way of multihoming works much better for the multihomed > network, what is their incentive to go with multiple addresses? The current way? The incentive is seamless failover. -Taz -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Tue Jul 17 22:27:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16878 for ; Tue, 17 Jul 2001 22:27:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MgxX-000ICB-00 for multi6-data@psg.com; Tue, 17 Jul 2001 19:21:07 -0700 Received: from mako1.telstra.net ([203.50.0.28]) by psg.com with esmtp (Exim 3.31 #1) id 15MgxW-000IBW-00 for multi6@ops.ietf.org; Tue, 17 Jul 2001 19:21:06 -0700 Received: from tecra.telstra.net (gorp.telstra.net [203.50.0.66]) by mako1.telstra.net (8.11.3/8.11.1) with ESMTP id f6I2KQM90823; Wed, 18 Jul 2001 12:20:26 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <4.3.2.7.2.20010718103927.00ba7380@kahuna.telstra.net> X-Sender: gih@kahuna.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 18 Jul 2001 10:48:07 +1000 To: Ramakrishna Gummadi From: Geoff Huston Subject: Re: A tunneling proposal Cc: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk At 7/18/01 01:41 AM, Ramakrishna Gummadi wrote: > > > Economics is a major constraint on the potential solution space. > > > > I'm not even talking about economics, but just basic functionality and > human > > nature: how are you going to convince someone stop doing something that > works > > for them to help some greater good, that doesn't show obvious signs of > > needing help? "Global warming? Let me turn up the airco..." > > > > If there really is a limit above which global routing breaks down, we > should > > implement some policies to prevent the number of routes from reaching this > > limit. This means forcing existing ASes to aggregate, and limiting the > growth > > in the number of ASes. That way, SCTP-like solutions become more > attractive. It would be good if we could say "this is the number of routes in the global table which will cause the integrity of the global routing system to collapse". Unfortunately we know of no such hard limit. We suspect that somewhere between where we are (a little over 100,000) and 4 billion route entries (every /32 address fragment is announced globally) there is such a limit. Our concern is that we will not know what such a threshold is until a number of As's cross it. >Currently, multihomers pay each their ISPs extra to carry non-aggregatable >routes. This means if the ISPs encounter problems with the >additional routes, they are directly going to charge the sites >more. This way, one can impose artificial constraints on how >many sites multihome, but this is exactly what we are trying to avoid. Do you have some evidence of such an arrangement? While I've heard of such charging for routing entry schemes in the past I've yet to see it become commercially viable in a heavily contested IP transit market. Your comment suggests that such a scheme has become commercially viable in some IP transit markets, and it wouldbe interesting to learn more about such a development. >As for backpatcing TCP to work with multihoming, this would >not work with the current apps, and socket API if done the SCTP >way---SCTP requires the apps to *explicitly* give a list of addresses >to use on a connection. To backpatch TCP to do the same would mean >requiring the TCP layer itself to figure out what additional addresses >it can use *without* the app knowledge. This means that the protocol >stack can get it wrong if there is address translation going on >for getting provider independence, etc... >Ultimately, it will basically look like GxSE... The problem is that multi-homing may be a number of AS's away. i.e. the local AS may single-home to an upstream AS which in turn may multi-home to a number of AS's via peering connections, multiple upstreams, etc. How then does the local TCP session understand the situation if the upstream AS is doing multi-homing via dynamic translation of the routing goop part of the end point's address? regards, Geoff From owner-multi6@ops.ietf.org Wed Jul 18 00:48:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA08345 for ; Wed, 18 Jul 2001 00:48:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MjGO-000O1r-00 for multi6-data@psg.com; Tue, 17 Jul 2001 21:48:44 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15MjGN-000O1k-00 for multi6@ops.ietf.org; Tue, 17 Jul 2001 21:48:43 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id VAA03281; Tue, 17 Jul 2001 21:47:25 -0700 (PDT) Date: Tue, 17 Jul 2001 21:47:25 -0700 (PDT) From: Ramakrishna Gummadi To: , Geoff Huston cc: Subject: Re: A tunneling proposal In-Reply-To: <4.3.2.7.2.20010718103927.00ba7380@kahuna.telstra.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > >As for backpatcing TCP to work with multihoming, this would > >not work with the current apps, and socket API if done the SCTP > >way---SCTP requires the apps to *explicitly* give a list of addresses > >to use on a connection. To backpatch TCP to do the same would mean > >requiring the TCP layer itself to figure out what additional addresses > >it can use *without* the app knowledge. This means that the protocol > >stack can get it wrong if there is address translation going on > >for getting provider independence, etc... > >Ultimately, it will basically look like GxSE... > > > The problem is that multi-homing may be a number of AS's away. i.e. the > local AS may single-home to an upstream AS which in turn may multi-home to > a number of AS's via peering connections, multiple upstreams, etc. How then > does the local TCP session understand the situation if the upstream AS is > doing multi-homing via dynamic translation of the routing goop part of the > end point's address? > In SCTP, it is the job of the app to be feed the transport with a list of correct globally routable destination addresses, and be prepared to receive error notifications after an address fails. This is different than the GxSE's behavior of making the destination advertise the addresses where it can be reached. As for GxSE's behavior in the multi-level multihoming scenario, I think Paul is probably the best person to answer this, as I am not certain how the site border router knows to signal the upstream provider's router to attach the address-list extension header. As far as tunneling is concerned, although not strictly related to multihoming per se, one can use address translation (or goop rewriting) to get provider independence. In this multi-level multihomed case, this translation would work as follows. Consider the following concrete scenario, to ease explaining things a bit: D | +-----+-----+ | Internet | +---+----+--+ | | | || | | //-+\\ L5 //--+-\\ | ISP ******* ISP2 | | 1 | * --+-// \\-+/| ** | | **L2 | L3 L4 | ** /++ +--+---* | \ | R2|+-----+R1 |<--Multihomed Enterprise E |ISP3 | \-+/ +------+ L1 | S Assume that E multihomes via ISP3 and ISP2, whule ISP3 itself multihomes via ISP1 and ISP2. Further, assume that both ISP3 and E use PI addresses, and border exit routers R2 and R1 respectively rewrite the source addresses on outgoing packets, and destination addresses on incoming packets. Destination D will correctly see a globally routable address for source S even after the packet uses R1-L1-R2-L4-ISP1-(Internet)-D, while reverse packets correctly reach S with the PI address set by E. Thus, S does not need to know a globally routable address as part of the ISP3 prefix space (it may still have a globally routable address from ISP2 prefix space to use for traffic via S-L3-ISP2-(Internet)). If ISP2 has problems, and links L3 become unusable, R1 tries to setup a tunnel to ISP2 using a globally routable address in ISP2 via ISP3 so that existing connections can survive. Note that ISP3 does not have to setup a tunnel himself---when R1 requests a tunnel setup, since L2 is assumed to have become useless, he has no other way than use L4-ISP1-ISP2 as the path on which to forward the tunnel setup request as well as further tunnel traffic. ISP2 knows the globally routable address of R1 because ISP3 would have translated it to become a globally routable one, and now ISP2 would use L5-ISP1-L4-L1 as the tunnel path for traffic that was previously using D-Internet-ISP2-L3-E-S. Thus, nothing short of a complete outage within ISP2 should hamper traffic flow. The sticky question seems to be whether it is acceptable for R1 to request ISP3 to trigger a global BGP announcement for the site's address prefix drawn from ISP2 so that traffic can be forwarded via (Internet)-ISP1-L4-ISP3-L1 directly instead of a tunnel. I don't know what bad things happen in this case. Of course, the unworked out part in the above is how R1 knows a valid address in ISP2 that can be used as the other tunnel endpoint. thanks, ramki From owner-multi6@ops.ietf.org Wed Jul 18 00:55:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA09691 for ; Wed, 18 Jul 2001 00:55:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MjNR-000OPV-00 for multi6-data@psg.com; Tue, 17 Jul 2001 21:56:01 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15MjNR-000OPP-00 for multi6@ops.ietf.org; Tue, 17 Jul 2001 21:56:01 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id VAA03318; Tue, 17 Jul 2001 21:55:57 -0700 (PDT) Date: Tue, 17 Jul 2001 21:55:57 -0700 (PDT) From: Ramakrishna Gummadi To: , Geoff Huston cc: Subject: A minor correction In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Sorry for this, but the following line: > If ISP2 has problems, and links L3 become unusable, R1 tries to setup a in my previous mail should read: If ISP2 has problems, and links *L2 and* L3 become unusable, R1 tries to setup a (etc.) -ramki From owner-multi6@ops.ietf.org Wed Jul 18 01:25:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17736 for ; Wed, 18 Jul 2001 01:25:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Mjb5-000Osc-00 for multi6-data@psg.com; Tue, 17 Jul 2001 22:10:07 -0700 Received: from mighty.grot.org ([216.15.97.5]) by psg.com with esmtp (Exim 3.31 #1) id 15Mjb4-000OsU-00 for multi6@ops.ietf.org; Tue, 17 Jul 2001 22:10:06 -0700 Received: by mighty.grot.org (Postfix, from userid 515) id 8A4825DA8; Tue, 17 Jul 2001 22:10:05 -0700 (PDT) Date: Tue, 17 Jul 2001 22:10:05 -0700 From: "R.P. Aditya" To: Ramakrishna Gummadi Cc: paul@francis.com, Geoff Huston , multi6@ops.ietf.org Subject: Re: A minor correction Message-ID: <20010717221005.C60329@mighty.grot.org> Reply-To: "R.P. Aditya" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from ramki@cs.berkeley.edu on Tue, Jul 17, 2001 at 09:55:57PM -0700 X-PGP-Key: http://www.grot.org/pubkey.asc X-PGP-Key-ID: 0x6405D8D5 Sender: owner-multi6@ops.ietf.org Precedence: bulk The crux of the problem with the tunnel approach, and/or the conditional announcement approach is not technical, it is that it requires a level of inter-provider cooperation that experience has shown is not likely to exist. Requiring it will likely engender yet more resistance to migrating to v6. Furthermore, it is more complex for the customer and providers. I can easily envision scenarios where one provider will refuse to create a tunnel to certain other providers based on politics or even internal lack of capacity. Customers will be forced to multihome only with providers who have agreed to work together; providers will have to trust customers to send them automatic messages to make what amount to TE decisions within their network. Just getting providers to accept well-known communities (saying nothing of getting them to tell you) is painful now. Adi On Tue, Jul 17, 2001 at 09:55:57PM -0700, Ramakrishna Gummadi wrote: > Sorry for this, but the following line: > > > If ISP2 has problems, and links L3 become unusable, R1 tries to setup a > > in my previous mail should read: > > If ISP2 has problems, and links *L2 and* L3 become unusable, R1 tries to > setup a (etc.) > > -ramki > > From owner-multi6@ops.ietf.org Wed Jul 18 01:38:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21420 for ; Wed, 18 Jul 2001 01:38:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Mk2i-00005r-00 for multi6-data@psg.com; Tue, 17 Jul 2001 22:38:40 -0700 Received: from flowpoint.procket.com ([209.140.237.1] helo=alpha-tli.procket.com) by psg.com with esmtp (Exim 3.31 #1) id 15Mk2h-00004d-00 for multi6@ops.ietf.org; Tue, 17 Jul 2001 22:38:39 -0700 Received: (from tli@localhost) by alpha-tli.procket.com (8.9.3/8.9.3) id WAA21075; Tue, 17 Jul 2001 22:37:38 -0700 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: alpha-tli.procket.com: tli set sender to tli@alpha-tli.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15189.8354.161806.817441@alpha-tli.procket.com> Date: Tue, 17 Jul 2001 22:37:38 -0700 To: Ramakrishna Gummadi Cc: , Geoff Huston , Subject: Re: A tunneling proposal In-Reply-To: References: <4.3.2.7.2.20010718103927.00ba7380@kahuna.telstra.net> X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit | In SCTP, it is the job of the app to be feed the transport with a list of | correct globally routable destination addresses, and be prepared to | receive error notifications after an address fails. I don't mean to be a pedantic layerist, but it seems to me that the network and transport layers probably should keep the multihoming problems out of the hands of the applications. Tony From owner-multi6@ops.ietf.org Wed Jul 18 01:47:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA25005 for ; Wed, 18 Jul 2001 01:47:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MkCD-0000Wg-00 for multi6-data@psg.com; Tue, 17 Jul 2001 22:48:29 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15MkCC-0000WZ-00 for multi6@ops.ietf.org; Tue, 17 Jul 2001 22:48:28 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id WAA03567; Tue, 17 Jul 2001 22:48:27 -0700 (PDT) Date: Tue, 17 Jul 2001 22:48:26 -0700 (PDT) From: Ramakrishna Gummadi To: cc: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > Furthermore, it is more complex for the customer and providers. I can easily > envision scenarios where one provider will refuse to create a tunnel to > certain other providers based on politics or even internal lack of capacity. Internal lack of capacity seems a valid technical reason; this should be addressed in the SLA between the provider and the subscriber. Note, however, that we are not asking one provider to carry traffic, tunneled or otherwise, that *exceeds* the subscriber connectivity bandwidth. The amount of traffic would in no (significant) way be altered if the multihomed subscriber became singlehomed, and received/sent all the traffic along the original line. > Customers will be forced to multihome only with providers who have agreed to > work together; This is a difficult question for me to answer. But what kinds of arrangements are drawn up for carrying multicast traffic, where these kinds of political problems are potentially more severe? Also, I am not sure if this wg should outlaw any proposals based on political reasons alone...If so, we probably should have the rough guidelines rewritten down in the requirements document. thanks, ramki From owner-multi6@ops.ietf.org Wed Jul 18 02:01:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA01621 for ; Wed, 18 Jul 2001 02:01:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MkJF-0000sH-00 for multi6-data@psg.com; Tue, 17 Jul 2001 22:55:45 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15MkJF-0000sB-00 for multi6@ops.ietf.org; Tue, 17 Jul 2001 22:55:45 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id WAA03610; Tue, 17 Jul 2001 22:55:43 -0700 (PDT) Date: Tue, 17 Jul 2001 22:55:43 -0700 (PDT) From: Ramakrishna Gummadi To: Tony Li cc: Subject: Re: A tunneling proposal In-Reply-To: <15189.8354.161806.817441@alpha-tli.procket.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk For most applications, what you say is true. But given that SCTP was first devised for SS7 signaling where operator alerts, log generation, etc. may be required, I can sympathize with this design... -ramki On Tue, 17 Jul 2001, Tony Li wrote: > > | In SCTP, it is the job of the app to be feed the transport with a list of > | correct globally routable destination addresses, and be prepared to > | receive error notifications after an address fails. > > > I don't mean to be a pedantic layerist, but it seems to me that the network > and transport layers probably should keep the multihoming problems out of > the hands of the applications. > > Tony > From owner-multi6@ops.ietf.org Wed Jul 18 02:45:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA16949 for ; Wed, 18 Jul 2001 02:45:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MkPi-00017S-00 for multi6-data@psg.com; Tue, 17 Jul 2001 23:02:26 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15MkPi-00017M-00 for multi6@ops.ietf.org; Tue, 17 Jul 2001 23:02:26 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id XAA03660; Tue, 17 Jul 2001 23:02:24 -0700 (PDT) Date: Tue, 17 Jul 2001 23:02:24 -0700 (PDT) From: Ramakrishna Gummadi To: "R.P. Aditya" cc: Subject: Re: A minor correction In-Reply-To: <20010717221005.C60329@mighty.grot.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Also, I do know that, currently, large server farms have about 11 connections to the Internet that run at roughly 90% of the capacity, so that they can gracefully tolerate a link failure. Whether these 11 links feed into just one or many ISPs is something that I am not very certain. regards, ramki On Tue, 17 Jul 2001, R.P. Aditya wrote: > The crux of the problem with the tunnel approach, and/or the conditional > announcement approach is not technical, it is that it requires a level of > inter-provider cooperation that experience has shown is not likely to exist. > Requiring it will likely engender yet more resistance to migrating to v6. > > Furthermore, it is more complex for the customer and providers. I can easily > envision scenarios where one provider will refuse to create a tunnel to > certain other providers based on politics or even internal lack of capacity. > > Customers will be forced to multihome only with providers who have agreed to > work together; providers will have to trust customers to send them automatic > messages to make what amount to TE decisions within their network. Just > getting providers to accept well-known communities (saying nothing of getting > them to tell you) is painful now. > > Adi > > On Tue, Jul 17, 2001 at 09:55:57PM -0700, Ramakrishna Gummadi wrote: > > Sorry for this, but the following line: > > > > > If ISP2 has problems, and links L3 become unusable, R1 tries to setup a > > > > in my previous mail should read: > > > > If ISP2 has problems, and links *L2 and* L3 become unusable, R1 tries to > > setup a (etc.) > > > > -ramki > > > > > > From owner-multi6@ops.ietf.org Wed Jul 18 07:05:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28382 for ; Wed, 18 Jul 2001 07:05:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MomW-000DAI-00 for multi6-data@psg.com; Wed, 18 Jul 2001 03:42:16 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.31 #1) id 15MomV-000DAC-00 for multi6@ops.ietf.org; Wed, 18 Jul 2001 03:42:15 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f6IAg8p20711; Wed, 18 Jul 2001 13:42:08 +0300 Date: Wed, 18 Jul 2001 13:42:08 +0300 (EEST) From: Pekka Savola To: Tony Hain cc: Subject: RE: Provider Independent addressing usage In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 17 Jul 2001, Tony Hain wrote: > Filtering more-specifics was an IPv4 activity 5 years ago, but the > reality of providing the service the end customer is paying for trumps > the 'network-centric' viewpoint every time. If a site uses > provider-based addresses and expects those to be routable through > another provider then the upstream table of those two providers has to > accept the explicit entry. No amount of wishing will make that untrue. That's not enough; every client's ISP in DFZ also has to accept the explicit entry, at least in the case that: 1) you want to protect from failure of your original PB ISP, or 2) your PB ISP will not co-operate with secondary ISP, and give your traffic to them when needed your PB-ISP link is dead. Further, this protects against link loss toward PB-ISP, but not against bigger failures _unless_ every router in DFZ has the explicit entry (so return packets don't get blackholed, or sent to PB-ISP not Secondary-ISP). When this level (really, at least 95%!) of filter-free 'ness is required, multihomers might not see breaking the aggregates as a _working_ solution. I don't know how IPv4 filtering was done 5 years ago, but currently I believe many organizations in DFZ filter e.g. from /25 to up; I see this as equivalent to filtering /48 in IPv6 world. > The reason I say FUD is the argument appears to be ignoring the origin > of the routing entry. If an operator is forwarding a packet toward a pop > in the destination region, it had to get that route from somewhere. The > only way your scenario works is if the operator is not providing service > in the destination region and decided to make up a route to that prefix > for internal use. If a provider does this, yes the traffic will die, but > this is no different than making up any other prefix. The problem here is, that unless the carrier or big ISP makes up a route (e.g. based on assumption it has a PoP with a few customers in the area, but no exchange nearby), e.g. with adding a static Null0 route and redistributing that into BGP, and only uses specifics, it has to exchange specifics with other carriers or huge ISP's and the number of these might not be small. But anyway.. this is perhaps kinda theoretical discussion as I doubt that many sites would jump to use PI immediately, and the problem would be rather unlikely to "explode" that soon. > > Perhaps the practical requirement for IX's should be noted > > more clearly in the draft. > > Please send text. Perhaps, something like, to be included in General Considerations: It is believed that the amount of overly-specific route advertisements can be minimized using exchange-based aggregation in different scopes. This way there would be no need for non-aggregated advertisements in the networks interconnecting different scopes. However, setting up exchanges is not always technically, economically or otherwise feasible; it is a balance between the amount of full /48 prefixes ISP's operating in the scope are willing to accept, and between forming an exchange, or some other "neutral ground", and using provider independent aggregates. It is believed that when the list of overly-specific route advertisements grows too long, some sort of traffic exchanging will be established between the vast majority of ISP's operating in that scope. -- 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 Wed Jul 18 08:42:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14024 for ; Wed, 18 Jul 2001 08:42:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MqX8-000I9z-00 for multi6-data@psg.com; Wed, 18 Jul 2001 05:34:30 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.31 #1) id 15MqX6-000I9s-00 for multi6@ops.ietf.org; Wed, 18 Jul 2001 05:34:29 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f6ICXpI21340; Wed, 18 Jul 2001 15:33:51 +0300 Date: Wed, 18 Jul 2001 15:33:51 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter cc: "Jon (Taz) Mischo" , Tony Hain , Subject: Re: Provider Independent addressing usage In-Reply-To: <3B557DB8.1FBE5FAF@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 18 Jul 2001, Brian E Carpenter wrote: > > On Tue, 17 Jul 2001, Pekka Savola wrote: > > > > > I think one of the goals is that inter-region providers, or "upper layers" > > > in general, don't have to know all the specific routes. > > Er, that is the goal of all route aggregation techniques and is the thing that > multihoming makes very hard. It's the governing clause for every single > thing that multi6 discusses. PI is one of the oldest ideas around to satisfy this > goal and the question is still the same as always: is the deployment of all the > necessary IX's a realistic expectation? No; it's unrealistic to believe people start forming IX's just to appease one multihoming solution.. > I think you'll find this goes back at least to a draft by Bill Simpson about 5 > years ago, and I still haven't seen a convincing argument why all those IX's will > spring into existence. .. But luckily all the IX's aren't required. As long as operators in a region are satisfied with carrying full /48 routes to every site in each region, there are not that many problems. When you get to the 10,000th PI site in a region, I'm sure more exchanging will be considered if it hasn't been by then.. -- 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 Wed Jul 18 08:44:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14217 for ; Wed, 18 Jul 2001 08:44:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MqKJ-000Hcw-00 for multi6-data@psg.com; Wed, 18 Jul 2001 05:21:15 -0700 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.31 #1) id 15MqKI-000Hao-00 for multi6@ops.ietf.org; Wed, 18 Jul 2001 05:21:14 -0700 Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id NAA32232; Wed, 18 Jul 2001 13:20:09 +0100 Received: from hursley.ibm.com ([9.242.148.96]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id NAA72078; Wed, 18 Jul 2001 13:20:04 +0100 Message-ID: <3B557DB8.1FBE5FAF@hursley.ibm.com> Date: Wed, 18 Jul 2001 07:14:48 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Jon (Taz) Mischo" CC: Pekka Savola , Tony Hain , multi6@ops.ietf.org Subject: Re: Provider Independent addressing usage References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > On Tue, 17 Jul 2001, Pekka Savola wrote: > > > I think one of the goals is that inter-region providers, or "upper layers" > > in general, don't have to know all the specific routes. Er, that is the goal of all route aggregation techniques and is the thing that multihoming makes very hard. It's the governing clause for every single thing that multi6 discusses. PI is one of the oldest ideas around to satisfy this goal and the question is still the same as always: is the deployment of all the necessary IX's a realistic expectation? I think you'll find this goes back at least to a draft by Bill Simpson about 5 years ago, and I still haven't seen a convincing argument why all those IX's will spring into existence. Brian From owner-multi6@ops.ietf.org Wed Jul 18 12:35:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07598 for ; Wed, 18 Jul 2001 12:35:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MthK-0002Pf-00 for multi6-data@psg.com; Wed, 18 Jul 2001 08:57:14 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15MthJ-0002PX-00 for multi6@ops.ietf.org; Wed, 18 Jul 2001 08:57:13 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id KAA60841; Wed, 18 Jul 2001 10:57:06 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Wed, 18 Jul 2001 10:57:06 -0500 (CDT) From: "Jon (Taz) Mischo" To: Ramakrishna Gummadi cc: aditya@grot.org, multi6@ops.ietf.org Subject: Re: your mail In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 17 Jul 2001, Ramakrishna Gummadi wrote: > > Furthermore, it is more complex for the customer and providers. I can > easily > > envision scenarios where one provider will refuse to create a tunnel to > > certain other providers based on politics or even internal lack of > capacity. > > Internal lack of capacity seems a valid technical reason; this should be > addressed in the SLA between the provider and the subscriber. Note, > however, that we > are not asking one provider to carry traffic, tunneled or otherwise, that > *exceeds* the subscriber connectivity bandwidth. The amount of traffic > would in no (significant) way be altered if the multihomed subscriber > became singlehomed, and received/sent all the traffic along the original > line. Yes you are. You are asking a provider to take all traffic destined for a specific egress point and re-route it through their network to a peering point. You are *DOUBLING* the traffic they are carrying for that subscriber. > > Customers will be forced to multihome only with providers who have > agreed to > > work together; > > This is a difficult question for me to answer. But what kinds of > arrangements are drawn up for carrying multicast traffic, where these > kinds of political problems are potentially more severe? Multicast traffic is a whole other ball of wax. > Also, I am not sure if this wg should outlaw any proposals based on > political reasons alone...If so, we probably should have the rough > guidelines rewritten down in the requirements document. This isn't based on political reasons, but feasibility reasons, and we don't outlaw, we just decide what we predict will be best. -Taz -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Wed Jul 18 12:36:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07811 for ; Wed, 18 Jul 2001 12:36:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MtiC-0002Tc-00 for multi6-data@psg.com; Wed, 18 Jul 2001 08:58:08 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15MtiB-0002TV-00 for multi6@ops.ietf.org; Wed, 18 Jul 2001 08:58:08 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id KAA60848; Wed, 18 Jul 2001 10:58:05 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Wed, 18 Jul 2001 10:58:05 -0500 (CDT) From: "Jon (Taz) Mischo" To: Ramakrishna Gummadi cc: Tony Li , multi6@ops.ietf.org Subject: Re: A tunneling proposal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 17 Jul 2001, Ramakrishna Gummadi wrote: > For most applications, what you say is true. But given that SCTP was first > devised for SS7 signaling where operator alerts, log generation, etc. may > be required, I can sympathize with this design... Also, it doesn't HAVE to be that way. You *CAN* bind to all the addresses the machine has. -Taz > -ramki > > On Tue, 17 Jul 2001, Tony Li wrote: > > > > > | In SCTP, it is the job of the app to be feed the transport with a list of > > | correct globally routable destination addresses, and be prepared to > > | receive error notifications after an address fails. > > > > > > I don't mean to be a pedantic layerist, but it seems to me that the network > > and transport layers probably should keep the multihoming problems out of > > the hands of the applications. > > > > Tony > > > > -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Wed Jul 18 12:38:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08361 for ; Wed, 18 Jul 2001 12:38:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MttJ-00035B-00 for multi6-data@psg.com; Wed, 18 Jul 2001 09:09:37 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15MttI-000354-00 for multi6@ops.ietf.org; Wed, 18 Jul 2001 09:09:36 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id LAA60885; Wed, 18 Jul 2001 11:09:30 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Wed, 18 Jul 2001 11:09:30 -0500 (CDT) From: "Jon (Taz) Mischo" To: Paul Francis cc: Ramakrishna Gummadi , Geoff Huston , multi6@ops.ietf.org Subject: Re: A tunneling proposal In-Reply-To: <002b01c10f9e$f5f1d2c0$87030a0a@tahoenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 18 Jul 2001, Paul Francis wrote: > > As for GxSE's behavior in the multi-level multihoming scenario, > > I think Paul is probably the best person to > > answer this, as I am not certain how the site border router knows to > > signal the upstream provider's router to attach the address-list extension > > header. > > > > The signalling is done by the end host...the end host attaches an extension > that is basically a placeholder for the prefix-list that the site border > router fills in. > I hadn't considered the multi-level case. My first thought is that the site > border router should be configured to know of the multiple upstream > prefixes, although this does open up the problem of having to reconfigure > all of the site border routers when the mom&pop ISP decides to > change/add/delete its upstream ISP... This is required anyway, so it's not a big deal. Besides, as I said before, if you propagate some of this information into routing, such changes can be less painful. -Taz -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Wed Jul 18 12:43:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09675 for ; Wed, 18 Jul 2001 12:43:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MtK9-00012q-00 for multi6-data@psg.com; Wed, 18 Jul 2001 08:33:17 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.31 #1) id 15MtK8-00012k-00 for multi6@ops.ietf.org; Wed, 18 Jul 2001 08:33:16 -0700 Received: from tnpfrancis ([10.10.3.135]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 18 Jul 2001 08:33:15 -0700 Message-ID: <002b01c10f9e$f5f1d2c0$87030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: "Ramakrishna Gummadi" , "Geoff Huston" Cc: References: Subject: Re: A tunneling proposal Date: Wed, 18 Jul 2001 08:33:14 -0700 Organization: TAHOE Networks 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 18 Jul 2001 15:33:15.0891 (UTC) FILETIME=[F68F2430:01C10F9E] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > As for GxSE's behavior in the multi-level multihoming scenario, > I think Paul is probably the best person to > answer this, as I am not certain how the site border router knows to > signal the upstream provider's router to attach the address-list extension > header. > The signalling is done by the end host...the end host attaches an extension that is basically a placeholder for the prefix-list that the site border router fills in. I hadn't considered the multi-level case. My first thought is that the site border router should be configured to know of the multiple upstream prefixes, although this does open up the problem of having to reconfigure all of the site border routers when the mom&pop ISP decides to change/add/delete its upstream ISP... PF From owner-multi6@ops.ietf.org Wed Jul 18 12:46:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10141 for ; Wed, 18 Jul 2001 12:46:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Mu7Q-0003os-00 for multi6-data@psg.com; Wed, 18 Jul 2001 09:24:12 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15Mu7P-0003om-00 for multi6@ops.ietf.org; Wed, 18 Jul 2001 09:24:11 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id JAA07391; Wed, 18 Jul 2001 09:24:01 -0700 (PDT) Date: Wed, 18 Jul 2001 09:24:00 -0700 (PDT) From: Ramakrishna Gummadi To: "Jon (Taz) Mischo" cc: Geoff Huston , Subject: Re: A tunneling proposal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 18 Jul 2001, Jon (Taz) Mischo wrote: > On Tue, 17 Jul 2001, Ramakrishna Gummadi wrote: > > > > Furthermore, it is more complex for the customer and providers. I can > > easily > > > envision scenarios where one provider will refuse to create a tunnel to > > > certain other providers based on politics or even internal lack of > > capacity. > > > > Internal lack of capacity seems a valid technical reason; this should be > > addressed in the SLA between the provider and the subscriber. Note, > > however, that we > > are not asking one provider to carry traffic, tunneled or otherwise, that > > *exceeds* the subscriber connectivity bandwidth. The amount of traffic > > would in no (significant) way be altered if the multihomed subscriber > > became singlehomed, and received/sent all the traffic along the original > > line. > > Yes you are. You are asking a provider to take all traffic destined for a > specific egress point and re-route it through their network to a peering > point. You are *DOUBLING* the traffic they are carrying for that > subscriber. I am sorry, but I may be missing something here---true, the traffic is doubled, but how to deal with the doubled traffic should be a decision between the provider and the subscriber according to the SLA. Increased load could cause higher packet loss, greater latency, etc. Indeed, if the provider were using fair queuing, this would what happen, without affecting any other customers of the provider. Like I said before, how is this case different than the one where the subscriber cancels the service from the other provider, due to which the load on the first provider would be increased anyway? Remember that we are not even requiring the first provider to participate in the tunnel setup... > > > Customers will be forced to multihome only with providers who have > > agreed to > > > work together; > > > > This is a difficult question for me to answer. But what kinds of > > arrangements are drawn up for carrying multicast traffic, where these > > kinds of political problems are potentially more severe? > > Multicast traffic is a whole other ball of wax. > > > Also, I am not sure if this wg should outlaw any proposals based on > > political reasons alone...If so, we probably should have the rough > > guidelines rewritten down in the requirements document. > > This isn't based on political reasons, but feasibility reasons, and we > don't outlaw, we just decide what we predict will be best. Well, there is an easy, although socially questionable, answer to that---use IPSec on the tunnel so that the provider can not find out anything about the payload... Once again, I don't see how doing this, while suboptimal and probably unfair, is going to violate the contract between the provider and the subscriber. All the provider would see is a surge in the traffic for the subscriber, and he will probably use the usual tools (fair queuing, increased latency and drop rate, etc. ) to deal with them... thanks, ramki From owner-multi6@ops.ietf.org Wed Jul 18 12:46:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10236 for ; Wed, 18 Jul 2001 12:46:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MuHN-0004HF-00 for multi6-data@psg.com; Wed, 18 Jul 2001 09:34:29 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15MuHM-0004H8-00 for multi6@ops.ietf.org; Wed, 18 Jul 2001 09:34:29 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id LAA60958; Wed, 18 Jul 2001 11:34:21 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Wed, 18 Jul 2001 11:34:21 -0500 (CDT) From: "Jon (Taz) Mischo" To: Ramakrishna Gummadi cc: aditya@grot.org, multi6@ops.ietf.org Subject: Re: your mail In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 18 Jul 2001, Ramakrishna Gummadi wrote: > On Wed, 18 Jul 2001, Jon (Taz) Mischo wrote: > > > Yes you are. You are asking a provider to take all traffic destined for a > > specific egress point and re-route it through their network to a peering > > point. You are *DOUBLING* the traffic they are carrying for that > > subscriber. > > I am sorry, but I may be missing something here---true, the traffic is > doubled, but how to deal with the doubled traffic should be a decision > between the provider and the subscriber according to the SLA. Increased > load could cause higher packet loss, greater latency, etc. Indeed, if the > provider were using fair queuing, this would what happen, without > affecting any other customers of the provider. The last sentence is what's wrong. A single router does not a backbone make. You seem to forget that a tunnel is not a wormhole. Packets don't enter a tunnel in one router and magically appear at the other end. The still traverse the network, following a different path than the one they would normally, messing up a LOT. > Like I said before, how is this case different than the one where the > subscriber cancels the service from the other provider, due to which the > load on the first provider would be increased anyway? Remember that we > are not even requiring the first provider to participate in the tunnel > setup... Because you're completely munging up the ultilization. There are suddenly many megabits of traffic where there was none before. I'd say that's pretty different. > > This isn't based on political reasons, but feasibility reasons, and we > > don't outlaw, we just decide what we predict will be best. > > Well, there is an easy, although socially questionable, answer to > that---use IPSec on the tunnel so that the provider can not find out > anything about the payload... I fail to see how IPsec is going to get you around the problem. The problem isn't, "Oh, I see that's tunnelled data, I'll drop it!" It is, "I see that packet is coming from someone I don't peer with. I'll drop it." The main problem here is that some providers won't peer with others. I can guarantee that those same two providers won't configure their routers to automatically build tunnels to each other. > Once again, I don't see how doing this, while suboptimal and probably > unfair, is going to violate the contract between the provider and the > subscriber. All the provider would see is a surge in the traffic for the > subscriber, and he will probably use the usual tools (fair queuing, > increased latency and drop rate, etc. ) to deal with them... Hello! The provider will see a surge along his entire network! This isn't the magic schoolbus full of 0 length packets. It's someone's OC-3 at full capacity being re-routed through other peoples' networks. There's a LOT more impact than you think. -Taz -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Wed Jul 18 13:18:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15842 for ; Wed, 18 Jul 2001 13:18:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MuiR-0005UH-00 for multi6-data@psg.com; Wed, 18 Jul 2001 10:02:27 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15MuiQ-0005UB-00 for multi6@ops.ietf.org; Wed, 18 Jul 2001 10:02:26 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id KAA08283; Wed, 18 Jul 2001 10:02:24 -0700 (PDT) Date: Wed, 18 Jul 2001 10:02:24 -0700 (PDT) From: Ramakrishna Gummadi To: "Jon (Taz) Mischo" cc: , Subject: Re: your mail In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > > doubled, but how to deal with the doubled traffic should be a decision > > between the provider and the subscriber according to the SLA. Increased > > load could cause higher packet loss, greater latency, etc. Indeed, if the > > provider were using fair queuing, this would what happen, without > > affecting any other customers of the provider. > > The last sentence is what's wrong. A single router does not a backbone > make. You seem to forget that a tunnel is not a wormhole. But that is the beauty of fair-queuing and variants---the single router implementing FQ can perform virtual admission control, guaranteeing that no more than the specified percentage of traffic from a subscriber can be injected into the network. Also, it only needs to be implmented in the border routers. thanks, ramki From owner-multi6@ops.ietf.org Wed Jul 18 13:18:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15857 for ; Wed, 18 Jul 2001 13:18:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MuY3-0004z0-00 for multi6-data@psg.com; Wed, 18 Jul 2001 09:51:43 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15MuY2-0004yZ-00 for multi6@ops.ietf.org; Wed, 18 Jul 2001 09:51:42 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id JAA08091; Wed, 18 Jul 2001 09:51:39 -0700 (PDT) Date: Wed, 18 Jul 2001 09:51:39 -0700 (PDT) From: Ramakrishna Gummadi To: "Jon (Taz) Mischo" cc: Ramakrishna Gummadi , , Subject: Re: your mail In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 18 Jul 2001, Jon (Taz) Mischo wrote: > On Wed, 18 Jul 2001, Ramakrishna Gummadi wrote: > > > On Wed, 18 Jul 2001, Jon (Taz) Mischo wrote: > > > > > Yes you are. You are asking a provider to take all traffic destined for a > > > specific egress point and re-route it through their network to a peering > > > point. You are *DOUBLING* the traffic they are carrying for that > > > subscriber. > > > > I am sorry, but I may be missing something here---true, the traffic is > > doubled, but how to deal with the doubled traffic should be a decision > > between the provider and the subscriber according to the SLA. Increased > > load could cause higher packet loss, greater latency, etc. Indeed, if the > > provider were using fair queuing, this would what happen, without > > affecting any other customers of the provider. > > The last sentence is what's wrong. A single router does not a backbone > make. You seem to forget that a tunnel is not a wormhole. Packets don't > enter a tunnel in one router and magically appear at the other end. The > still traverse the network, following a different path than the one they > would normally, messing up a LOT. Which is why tools such as fair queuing and fair dropping exist--they give you the perfect isolation and bandwidth management guarantees. And I think they are present on most cisco's already on most high speed interfaces.. > > that---use IPSec on the tunnel so that the provider can not find out > > anything about the payload... > > I fail to see how IPsec is going to get you around the problem. The > problem isn't, "Oh, I see that's tunnelled data, I'll drop it!" It is, "I > see that packet is coming from someone I don't peer with. I'll drop it." > > The main problem here is that some providers won't peer with others. I > can guarantee that those same two providers won't configure their routers > to automatically build tunnels to each other. We are not requiring anybody to accept traffic from those they don't peer with or have subscriber-provider relationships (and we don't require any extra physical links): D served by ISP2 and ISP3 that don't peer: Scenario A: (normal operation): S-ISP1-Internet-ISP2-D. Scenario B: (failure-mode operation): S-ISP1-Internet-ISP2-Internet-ISP3-D. How is B different than A, and how does ISP3 know the tunneled traffic originated in ISP2 (without looking at the internals of the packet, which can be forbidden by IPSec anyway)? If ISP2 and ISP3 cooperatate, the system as a whole can achieve a more optimal operation point than if they don't. In both cases, however, it continues to work. As an aside, should not one be first concerned that the Internet expects end-to-end congestion control out of hosts who can directly collapse an ISP if they are greedy? Because people got concerned about such problems, they invented fair queuing, etc., that allow the ISP full control over how to fairly manage traffic. These tools can be used in this scenario as well, if required. Finally, I don't see how any other multihoming scenario (end-to-end solutions included) that has to provide failure protection can behave significantly better---after all, the goal is to redistribute the load onto working links, with a possible degradation in performance. thanks, ramki From owner-multi6@ops.ietf.org Wed Jul 18 13:31:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18029 for ; Wed, 18 Jul 2001 13:31:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Mut1-0005yT-00 for multi6-data@psg.com; Wed, 18 Jul 2001 10:13:23 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Mut0-0005yN-00 for multi6@ops.ietf.org; Wed, 18 Jul 2001 10:13:22 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id MAA61061; Wed, 18 Jul 2001 12:13:19 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Wed, 18 Jul 2001 12:13:19 -0500 (CDT) From: "Jon (Taz) Mischo" To: Ramakrishna Gummadi cc: Ramakrishna Gummadi , aditya@grot.org, multi6@ops.ietf.org Subject: Re: your mail In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 18 Jul 2001, Ramakrishna Gummadi wrote: > Which is why tools such as fair queuing and fair dropping exist--they give > you the perfect isolation and bandwidth management guarantees. And I think > they are present on most cisco's already on most high speed interfaces.. I'm sorry, but as a customer, I wouldn't want my traffic dropped because someone else's OC-3 went down. > We are not requiring anybody to accept traffic from those they don't peer > with or have subscriber-provider relationships (and we don't require any > extra physical links): Yes, you ARE. For it to work right, that's EXACTLY what you have to require. > D served by ISP2 and ISP3 that don't peer: > > Scenario A: (normal operation): > S-ISP1-Internet-ISP2-D. > > Scenario B: (failure-mode operation): > S-ISP1-Internet-ISP2-Internet-ISP3-D. ISP2 and 3 would HAVE to peer to do this. I'm sorry, but as a provider I wouldn't want just anybody to be capable of building a tunnel. Any potential tunnels of this sort I'd want to be pre-configured so there couldn't be abuse. But who's to say it still won't be abused anyway? What if ISP2 brings up the tunnel because of a low bandwidth situation? As ISP3, I didn't sign up for that. > How is B different than A, and how does ISP3 know the tunneled traffic > originated in ISP2 (without looking at the internals of the packet, which > can be forbidden by IPSec anyway)? You're missing the point. ISP3 can see the tunnel originated at ISP2. The tunnel would be from ISP2's router to ISP3's router. Hard to miss. And if I don't trust ISP2 as ISP3, I'm sure as hell not going to let them create a pipe and pour packets into my network. > If ISP2 and ISP3 cooperatate, the system as a whole can achieve a more > optimal operation point than if they don't. In both cases, however, it > continues to work. Again, they have to be peers or have a mutual trust relationship. We're right back to square one. This can't work unless they cooperate. > As an aside, should not one be first concerned that the Internet expects > end-to-end congestion control out of hosts who can directly collapse an > ISP if they are greedy? Because people got concerned about such problems, > they invented fair queuing, etc., that allow the ISP full control over how > to fairly manage traffic. These tools can be used in this scenario as > well, if required. Again, NO. If you can't afford the bandwidth to do this, don't do it, cause as a customer, I won't tolerate high packet loss. Why bother at that point? > Finally, I don't see how any other multihoming scenario (end-to-end > solutions included) that has to > provide failure protection can behave significantly better---after all, > the goal is to redistribute the load onto working links, with a possible > degradation in performance. Lots of scenarios can behave FAR better than this. You're not looking at the big picture here. You're assuming someone's T1 fails over. Most people with T1's aren't going to be buying this these days. -Taz -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Wed Jul 18 13:34:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18422 for ; Wed, 18 Jul 2001 13:34:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Muuo-00064A-00 for multi6-data@psg.com; Wed, 18 Jul 2001 10:15:14 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Muun-000644-00 for multi6@ops.ietf.org; Wed, 18 Jul 2001 10:15:13 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id MAA61076; Wed, 18 Jul 2001 12:15:12 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Wed, 18 Jul 2001 12:15:12 -0500 (CDT) From: "Jon (Taz) Mischo" To: Ramakrishna Gummadi cc: aditya@grot.org, multi6@ops.ietf.org Subject: Re: your mail In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 18 Jul 2001, Ramakrishna Gummadi wrote: > But that is the beauty of fair-queuing and variants---the single router > implementing FQ can perform virtual admission control, guaranteeing that > no more than the specified percentage of traffic from a subscriber can be > injected into the network. Also, it only needs to be implmented in the > border routers. Think about what you just said. Why the hell would I pay someone to redirect a percentage of my packets? That's not multihoming, that's ridiculous. -Taz -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Wed Jul 18 13:51:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21787 for ; Wed, 18 Jul 2001 13:51:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MvIK-0007BS-00 for multi6-data@psg.com; Wed, 18 Jul 2001 10:39:32 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15MvIJ-0007BM-00 for multi6@ops.ietf.org; Wed, 18 Jul 2001 10:39:31 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id KAA09304; Wed, 18 Jul 2001 10:39:29 -0700 (PDT) Date: Wed, 18 Jul 2001 10:39:28 -0700 (PDT) From: Ramakrishna Gummadi To: "Jon (Taz) Mischo" cc: , Subject: Re: your mail In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk > On Wed, 18 Jul 2001, Ramakrishna Gummadi wrote: > > > Which is why tools such as fair queuing and fair dropping exist--they give > > you the perfect isolation and bandwidth management guarantees. And I think > > they are present on most cisco's already on most high speed interfaces.. > > I'm sorry, but as a customer, I wouldn't want my traffic dropped because > someone else's OC-3 went down. Fair queuing says: If there are n customers, there is a scheduling algorithm that guarantees that each of these customer's traffic has a fair share of the link bandwidht. This means, an ISP can choose to set the weights for its n customers such that: a) each customer can inject no more than 1/n of the traffic into the outgoing link, no matter how much they try to pump via their respective access links, and b) the packet losses and delays suffered due to an increased load on one customer are restricted to that customer *alone*, and are *completely* invisible to the other customers---the other customers' traffic does not experience *any* increased delay or packet loss. Think of it FQ's role as being similar to a virtual memory manager in an Operating system. The customers would correspond to processes, and the memory manager guarantees that no process can affect any other processes in terms of access to memory pages, crashing via sigment faulting, etc... > > We are not requiring anybody to accept traffic from those they don't peer > > with or have subscriber-provider relationships (and we don't require any > > extra physical links): > > Yes, you ARE. For it to work right, that's EXACTLY what you have to > require. > > > D served by ISP2 and ISP3 that don't peer: > > > > Scenario A: (normal operation): > > S-ISP1-Internet-ISP2-D. > > > > Scenario B: (failure-mode operation): > > S-ISP1-Internet-ISP2-Internet-ISP3-D. > > ISP2 and 3 would HAVE to peer to do this. I'm sorry, but as a provider I > wouldn't want just anybody to be capable of building a tunnel. Any > potential tunnels of this sort I'd want to be pre-configured so there > couldn't be abuse. But who's to say it still won't be abused > anyway? What if ISP2 brings up the tunnel because of a low bandwidth > situation? As ISP3, I didn't sign up for that. I don't think ISP2 and ISP3 have to *directly* peer---it is enough for each to be reachable from the other. The ISPs could be regional providers with no direct peering, while their parents can peer at some internation point, for example. > > > How is B different than A, and how does ISP3 know the tunneled traffic > > originated in ISP2 (without looking at the internals of the packet, which > > can be forbidden by IPSec anyway)? > > You're missing the point. ISP3 can see the tunnel originated at > ISP2. The tunnel would be from ISP2's router to ISP3's router. Hard to > miss. And if I don't trust ISP2 as ISP3, I'm sure as hell not going to > let them create a pipe and pour packets into my network. > > > If ISP2 and ISP3 cooperatate, the system as a whole can achieve a more > > optimal operation point than if they don't. In both cases, however, it > > continues to work. Agreed, I made a mistake---ISP3 can figure out that the traffic originated in ISP2's network. But, then again, in the context of fair queuing above, I don't see why it is illegal for ISP2 to originate traffic for the site's border router (in fact, some of the traffic may have been originating from ISP2's customers). > Again, they have to be peers or have a mutual trust relationship. We're > right back to square one. This can't work unless they cooperate. One end of the tunnel terminates at the site's border router, the other end at one of ISP2's routers. ISP3 can choose not to participate in the tunnel creation, and can enforce bandwidth restrictions using FQ on this traffic as well. > > > As an aside, should not one be first concerned that the Internet expects > > end-to-end congestion control out of hosts who can directly collapse an > > ISP if they are greedy? Because people got concerned about such problems, > > they invented fair queuing, etc., that allow the ISP full control over how > > to fairly manage traffic. These tools can be used in this scenario as > > well, if required. > > Again, NO. If you can't afford the bandwidth to do this, don't do it, > cause as a customer, I won't tolerate high packet loss. Why bother at > that point? If one of a site's two links breakdown, I don't see how the site can not expect to see performance degradation at all. Of course, we require, and enforce, that no other site's are affected by this degradation using FQ. Finally, there is no need for the tunnels to be dynamically configured, although that facility will allow them to possibly withstand additional failures. Also, the tunnel is between ISP2 and the site, and does not need to have anything to do with ISP3 at all. thanks, ramki From owner-multi6@ops.ietf.org Wed Jul 18 13:53:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22212 for ; Wed, 18 Jul 2001 13:53:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MvLH-0007Li-00 for multi6-data@psg.com; Wed, 18 Jul 2001 10:42:35 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.31 #1) id 15MvLG-0007Lc-00 for multi6@ops.ietf.org; Wed, 18 Jul 2001 10:42:34 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 18 Jul 2001 10:42:16 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 86F6139D6C9047608CF543F3857199B9 for plus 3 more; Wed, 18 Jul 2001 10:42:16 -0700 Reply-To: From: "Tony Hain" To: "Brian E Carpenter" , "Jon \(Taz\) Mischo" Cc: "Pekka Savola" , Subject: RE: Provider Independent addressing usage Date: Wed, 18 Jul 2001 10:42:05 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-reply-to: <3B557DB8.1FBE5FAF@hursley.ibm.com> Importance: Normal X-SLUIDL: F8AD1E38-B3814110-8BB89891-DE7B9B12 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA22212 Brian E Carpenter wrote: > I think you'll find this goes back at least to a draft by Bill > Simpson about 5 years ago, and I still haven't seen a convincing > argument why all those IX's will spring into existence. I never claimed it was novel. :) I think the difference between now and then is that at that time the discussion centered around having to make a hard choice between PI or provider-aggregates. The insurmountable problem was that exchanges had to come into existence immediately, or PI would sink the routing system. I believe that we are at a point were the host and routing implementations can realistically support both approaches simultaneously, and there are enough existing exchanges to bootstrap the process. Taking all of the multi-homed site problems out of PA space will allow meeting the IPv6 routing goal of reducing the table by 10x or more, as long as we can agree on a scaleable PI approach for those problems. It would be nice if someone with access to current topology and routing information would provide feedback about the real impact of each proposal from the perspective of each continent. I still contend from a theoretical perspective that if you write-off NA/Europe as hopelessly intertwined for the moment, my approach reduces the tables in the other 75% of the world to a handful of entries. I also believe that over time with a scaleable PI mechanism, even the NA/Europe problem will be cut in half. Tony From owner-multi6@ops.ietf.org Wed Jul 18 14:35:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00559 for ; Wed, 18 Jul 2001 14:35:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MwA7-0009iC-00 for multi6-data@psg.com; Wed, 18 Jul 2001 11:35:07 -0700 Received: from dsl081-150-057.chi1.dsl.speakeasy.net ([64.81.150.57] helo=marduk.tazlore.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15MwA7-0009i6-00 for multi6@ops.ietf.org; Wed, 18 Jul 2001 11:35:07 -0700 Received: from localhost (taz@localhost.tazlore.com [127.0.0.1]) by marduk.tazlore.com (8.9.3/8.9.3) with ESMTP id NAA61241; Wed, 18 Jul 2001 13:35:05 -0500 (CDT) (envelope-from taz@tazlore.com) Date: Wed, 18 Jul 2001 13:35:04 -0500 (CDT) From: "Jon (Taz) Mischo" To: Ramakrishna Gummadi cc: aditya@grot.org, multi6@ops.ietf.org Subject: Re: your mail In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 18 Jul 2001, Ramakrishna Gummadi wrote: > Fair queuing says: If there are n customers, there is a scheduling > algorithm that guarantees that each of these customer's traffic has a fair > share of the link bandwidht. This means, an ISP can choose to set the > weights for its n customers such that: > a) each customer can inject no more than > 1/n of the traffic into the outgoing link, no matter how much they try > to pump via their respective access links, and > b) the packet losses and delays suffered due to an increased load > on one customer are restricted to that customer *alone*, and are > *completely* invisible to the other customers---the other customers' > traffic does not experience *any* increased delay or packet loss. I know how fair queueing works. What I'm saying is that if I'm multihoming via tunnels like this, fair queuing is not what I'm paying for...I'm paying for QoS beyond that. Besides, FQ does NOT come into play here. If the router where the access link was is where you're tunneling from, you may or may not be subject to fair queuing, just as your link was. However, through the rest of the network, fair queuing does not come into play, as it would really mess things up. Or, if it does, you're still changing the characteristics of the network traffic. The point here is traffic patterns. You're arguing when I'm trying to make it clear that you're missing the point. > I don't think ISP2 and ISP3 have to *directly* peer---it is enough for > each to be reachable from the other. The ISPs could be regional providers > with no direct peering, while their parents can peer at some internation > point, for example. I can tell you this: if ISP2 and ISP3 aren't directly peered, they're going to be paying for someone else's traffic. So you're saying that to multihome like this, if ISP2 and ISP3 aren't peers, the customer is going to have to pay for 4 links instead of 2, because those two ISPs are going to be buying extra transit to carry this. You're not winning this argument. > Agreed, I made a mistake---ISP3 can figure out that the traffic originated > in ISP2's network. But, then again, in the context of fair queuing above, > I don't see why it is illegal for ISP2 to originate traffic for the site's > border router (in fact, some of the traffic may have been originating from > ISP2's customers). Ummm...I'm sorry, but do you have operational engineering experience? I don't know a whole lot of people who do that would feel comfortable with someone else causing a change in their provisioning and routing, even if it was temporary, especially if they didn't trust those people. I just can't see it happening. > > Again, they have to be peers or have a mutual trust relationship. We're > > right back to square one. This can't work unless they cooperate. > > One end of the tunnel terminates at the site's border router, the other > end at one of ISP2's routers. ISP3 can choose not to participate in the > tunnel creation, and can enforce bandwidth restrictions using FQ on this > traffic as well. In this case, though, you're still doing bad things. See, now you're saying that the tunnel can cause legitimate packets for that ingress point to be dropped. Furthermore, you've just taken control of any of that from the router the tunnel is terminating on, and moved it upstream. Do you see what I'm getting at? Now you're dropping the packets in the tunnel AND the legitimate packets bound for that ingress point that DON'T have problems. You're making this assumption that everyone has dormant circuits laying around with no traffic on them. This is NOT the case. > > Again, NO. If you can't afford the bandwidth to do this, don't do it, > > cause as a customer, I won't tolerate high packet loss. Why bother at > > that point? > > If one of a site's two links breakdown, I don't see how the site can > not expect to see performance degradation at all. Of course, we > require, and enforce, that no other site's are affected by this > degradation using FQ. Finally, there is no need for the tunnels to be Ummmm...why are you so obsessed with fair queuing? It is not God, I assure you. It won't be upset if you see that it has flaws. If you multihome a site properly and smartly, and have adequate bandwidth, you don't have to take any significant performance hit. However, if you do it this way, you're breaking provisioning for everyone, cost everyone a lot of money, and making it more and more unattractive. When I first read this I liked the idea...you've made me see how ugly this idea is, though. > dynamically configured, although that facility will allow them to > possibly withstand additional failures. Also, the tunnel is between > ISP2 and the site, and does not need to have anything to do with ISP3 > at all. Read my comments above. I don't think you understand the issues involved in doing this. You're looking at certain pieces of the puzzle, but not the big picture. There has GOT to be a better way. -Taz -- "Be liberal in what you accept, and conservative in what you send." --Jon Postel (1943-1998) RFC 1122, October 1989 From owner-multi6@ops.ietf.org Wed Jul 18 14:50:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03680 for ; Wed, 18 Jul 2001 14:50:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Mw4B-0009Sc-00 for multi6-data@psg.com; Wed, 18 Jul 2001 11:28:59 -0700 Received: from www.bit-net.com ([208.146.132.4] helo=mail.users.bit-net.com) by psg.com with smtp (Exim 3.31 #1) id 15Mw4A-0009SV-00 for multi6@ops.ietf.org; Wed, 18 Jul 2001 11:28:58 -0700 Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA10354; Wed, 18 Jul 2001 14:28:47 -0400 Date: Wed, 18 Jul 2001 14:28:47 -0400 (EDT) From: Jim Bound To: Tony Hain Cc: Brian E Carpenter , "Jon (Taz) Mischo" , Pekka Savola , multi6@ops.ietf.org Subject: RE: Provider Independent addressing usage In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id OAA03680 The IXs are in process now first in Europe and now in Asia. Do not view this as U.S. focus that is just one part of the Internet. /jim On Wed, 18 Jul 2001, Tony Hain wrote: > Brian E Carpenter wrote: > > > I think you'll find this goes back at least to a draft by Bill > > Simpson about 5 years ago, and I still haven't seen a convincing > > argument why all those IX's will spring into existence. > > I never claimed it was novel. :) I think the difference between now and then is that at that time the discussion centered around having to make a hard choice between PI or provider-aggregates. The insurmountable problem was that exchanges had to come into existence immediately, or PI would sink the routing system. I believe that we are at a point were the host and routing implementations can realistically support both approaches simultaneously, and there are enough existing exchanges to bootstrap the process. Taking all of the multi-homed site problems out of PA space will allow meeting the IPv6 routing goal of reducing the table by 10x or more, as long as we can agree on a scaleable PI approach for those problems. It would be nice if someone with access to current topology and routing information would provide feedback about the real impact of each proposal from the perspective of each continent. I still contend from a theoretical perspective that if you write-off NA/Europe as hopelessly intertwined for the moment, my approach reduces the tables in the other 75% of the world to a handful of entries. I also believe that over time with a scaleable PI mechanism, even the NA/Europe problem will be cut in half. > > Tony > > > > From owner-multi6@ops.ietf.org Wed Jul 18 16:03:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20741 for ; Wed, 18 Jul 2001 16:03:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MxNK-000DKM-00 for multi6-data@psg.com; Wed, 18 Jul 2001 12:52:50 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15MxNJ-000DK6-00 for multi6@ops.ietf.org; Wed, 18 Jul 2001 12:52:49 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id MAA12710; Wed, 18 Jul 2001 12:52:46 -0700 (PDT) Date: Wed, 18 Jul 2001 12:52:46 -0700 (PDT) From: Ramakrishna Gummadi To: "Jon (Taz) Mischo" cc: , Subject: Re: your mail In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, > > I know how fair queueing works. What I'm saying is that if I'm > multihoming via tunnels like this, fair queuing is not what I'm paying > for...I'm paying for QoS beyond that. First of all, the site uses normal links if there are no problems. It only switches to tunnels when there is are failures. I don't think it is fair to say we are "multihoming via tunnels" in all contexts. I may be missing something, but, as far as I know, FQ can provide the strongest possible QoS guarantees as far as flow isolation, bandwidth allocation, delay, and loss are concerned. It is not widely deployed so far because of implementation complexities (lots of approximations exist), and is currently being deployed at least in the sprint backbone. I am interested in knowing what additional QoS you have on your mind. > Besides, FQ does NOT come into play > here. If the router where the access link was is where you're tunneling > from, you may or may not be subject to fair queuing, just as your link > was. However, through the rest of the network, fair queuing does not come > into play, as it would really mess things up. Or, if it does, you're > still changing the characteristics of the network traffic. If an ISP guards its exits/entrances, it does not have to worry about whether it changes the internal traffic patterns because FQ guarantees it does not. > The point here is traffic patterns. You're arguing when I'm trying to > make it clear that you're missing the point. > > > I don't think ISP2 and ISP3 have to *directly* peer---it is enough for > > each to be reachable from the other. The ISPs could be regional providers > > with no direct peering, while their parents can peer at some internation > > point, for example. > > I can tell you this: if ISP2 and ISP3 aren't directly peered, they're > going to be paying for someone else's traffic. So you're saying that to > multihome like this, if ISP2 and ISP3 aren't peers, the customer is going > to have to pay for 4 links instead of 2, because those two ISPs are going > to be buying extra transit to carry this. You're not winning this > argument. Let us pick the following concrete example, count the extra packets, and figure out who is paying the extra cost for whose failures: D | | /--+---\ // \\ | Internet | \\ / L7 / \------/ \ L6 // \\ / \ // \ +--/---+ L1 +--\---+ | ISP4+--------------+ ISP3 | | | | | +--+---+ +--+---+ | | L2 | | L3 | | | +---+--+ +--+---+ | ISP2| | ISP1 | | | | | +---/--+ +------*\ // \\ // L4 \\ // L5 \\ // +--\*--+ | | | Site | +---+--+ | | S Suppose the multihomed site gets connectivity from regional ISPs, ISP1 and ISP2 who do not trust and peer with each other, while their parents, ISP4 and ISP3, peer using link L1. The site has a host S that is talking to a destination D on the Internet using the path: D-(Internet)-L6-ISP3-L3-ISP2-L5-S. Suppose there is a major problem within ISP2, and link L5 goes down. However, assume ISP2 is still partially functional, so assume L3 continues to work. Packets would now follow the route: D-(Internet)-L6-ISP3-L3-ISP2-L3-ISP3-L1-ISP4-L2-ISP1-L4-S. The number of extra packets introduced on the inter-provider links is 4 (L3, L1, L2, L4). However, consider the perspective of ISP1 and ISP4. Theoretically, the destination D could have used the path through them (and this would be true in any end-to-end failover rerouting scheme as well), meaning the flow of packets would be: D-(Internet)-L7-ISP4-L2-ISP1-L4-S. This means that ISP1 and ISP4 are *not* taking any additional load in the first case versus the second case---they are not resposible for the problem, and they don't pay *any* extra price in terms of extra packets than they would otherwise have had to. The extra penalty is paid by ISP2 and ISP3, but because it is fault of ISP2, it should be willing to bear this cost both for itself and its transit provider. The multihomed site does not have to pay any penalty because it is not its problem. If ISP3 had a problem, on the other hand, it alone would have had to pay the extra bandwidth price, and would not burden ISP2 and the site. We should not consider sending packets via L1-ISP4-L2-ISP1 a burden because ISP3 is, by definition, allowed to send packets via L1 to ISP4. It would be great if you can use this scenario to make your objections. > Ummm...I'm sorry, but do you have operational engineering experience? I > don't know a whole lot of people who do that would feel comfortable with > someone else causing a change in their provisioning and routing, even if > it was temporary, especially if they didn't trust those people. I just > can't see it happening. I don't have operational experience, but I still think this is not a case of changing provisioning as the same could have happened in a non-failure mode scenario where the site simply stopped using one link and diverted the entire traffic over the other link. And, I definitely don't see this requiring any routing changes. I am interested in seeing what other peoples' reactions are to this. > Ummmm...why are you so obsessed with fair queuing? It is not God, I > assure you. It won't be upset if you see that it has flaws. If you > multihome a site properly and smartly, and have adequate bandwidth, you > don't have to take any significant performance hit. However, if you do it > this way, you're breaking provisioning for everyone, cost everyone a lot > of money, and making it more and more unattractive. I am just highlighting a technique that can be used to provide worst-case guarantees. I think it is useful in general because it is theoretically sound, backbone carriers (like Sprint) are beginning to deploy it in their networks, and router implementations are appearing for highspeed interfaces (an OC-48 channel can be split up fairly between n customers, for example). It helps in strictly enforcing SLAs. thanks, ramki From owner-multi6@ops.ietf.org Wed Jul 18 16:34:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27367 for ; Wed, 18 Jul 2001 16:34:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MxpC-000EU4-00 for multi6-data@psg.com; Wed, 18 Jul 2001 13:21:38 -0700 Received: from garlic.amaranth.net ([216.235.243.195]) by psg.com with esmtp (Exim 3.31 #1) id 15MxpB-000ETy-00 for multi6@ops.ietf.org; Wed, 18 Jul 2001 13:21:37 -0700 Received: from yarrow.senie.com (h0040100ebb17.ne.mediaone.net [24.218.3.56]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.3/8.11.3) with ESMTP id f6IKLZ021758 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Wed, 18 Jul 2001 16:21:36 -0400 Message-Id: <5.1.0.14.2.20010718161707.00a90150@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 18 Jul 2001 16:21:36 -0400 To: multi6@ops.ietf.org From: Daniel Senie Subject: Re: your mail In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk At 03:52 PM 7/18/01, Ramakrishna Gummadi wrote: >Hi, > > > > > I know how fair queueing works. What I'm saying is that if I'm > > multihoming via tunnels like this, fair queuing is not what I'm paying > > for...I'm paying for QoS beyond that. > >First of all, the site uses normal links if there are no problems. It only >switches to tunnels when there is are failures. I don't think it is fair >to say we are "multihoming via tunnels" in all contexts. So let's make sure everyone is clear on this point. You're saying the only reason to multi-home is for failover purposes. As long as the "primary" link is up, the "secondary" interface (which is used solely to carry tunneled traffic in the event of an outage with the primary) is never used. Sites multi-home for reasons other than line outage recovery, but you don't take those into account. It is common for sites to select a second upstream provider for multihoming based on a business need for reliable communications to a specific destination (business partner, for example). I'm not convinced a multi-homing solution based solely on the notion of disaster recovery is sufficient. ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-multi6@ops.ietf.org Wed Jul 18 17:15:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04303 for ; Wed, 18 Jul 2001 17:15:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MyRB-000GAM-00 for multi6-data@psg.com; Wed, 18 Jul 2001 14:00:53 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.31 #1) id 15MyRA-000GAB-00 for multi6@ops.ietf.org; Wed, 18 Jul 2001 14:00:53 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f6IL2qO17142; Wed, 18 Jul 2001 23:02:52 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 18 Jul 2001 23:01:16 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: Daniel Senie cc: multi6@ops.ietf.org Subject: Re: your mail In-Reply-To: <5.1.0.14.2.20010718161707.00a90150@mail.amaranth.net> Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 18 Jul 2001, Daniel Senie wrote: > Sites multi-home for reasons other than line outage recovery, but you don't > take those into account. It is common for sites to select a second upstream > provider for multihoming based on a business need for reliable > communications to a specific destination (business partner, for example). > I'm not convinced a multi-homing solution based solely on the notion of > disaster recovery is sufficient. Here in The Netherlands many fairly small ISPs only have one transit connection, but they connect to the Amsterdam Internet Exchange because that way they save a bundle on transit costs. The "real" multihomed networks I've worked with multihome for disaster recovery reasons, but since multihoming is expensive, they also want to balance traffic over both connections. Just an idea I just thought of: a large transit network could have a backup-network that announces the same routes as the primary network and uses tunnels to send traffic over the second ISP of multihomed networks. Under normal circumstances the primary network collects all incoming traffic (better routes) and the backup network does nothing. When the primary network goes down, other ISPs send the traffic to the backup network and the backup network tunnels it to the customers. As long as the primary and backup networks don't suffer from (much) shared fate, this could be a very resilient solution with no routing impact. As long as we're talking about tunnels: we should fix the path MTU discovery problems they expose. Iljitsch From owner-multi6@ops.ietf.org Wed Jul 18 17:17:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04513 for ; Wed, 18 Jul 2001 17:17:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15MyN3-000FvO-00 for multi6-data@psg.com; Wed, 18 Jul 2001 13:56:37 -0700 Received: from relay.eecs.berkeley.edu ([169.229.34.228]) by psg.com with esmtp (Exim 3.31 #1) id 15MyN2-000FvI-00 for multi6@ops.ietf.org; Wed, 18 Jul 2001 13:56:36 -0700 Received: from moses.CS.Berkeley.EDU (moses.CS.Berkeley.EDU [128.32.46.218]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id NAA14253; Wed, 18 Jul 2001 13:56:34 -0700 (PDT) Date: Wed, 18 Jul 2001 13:56:33 -0700 (PDT) From: Ramakrishna Gummadi To: Daniel Senie cc: Subject: Re: your mail In-Reply-To: <5.1.0.14.2.20010718161707.00a90150@mail.amaranth.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 18 Jul 2001, Daniel Senie wrote: > At 03:52 PM 7/18/01, Ramakrishna Gummadi wrote: > >Hi, > > > > > > > > I know how fair queueing works. What I'm saying is that if I'm > > > multihoming via tunnels like this, fair queuing is not what I'm paying > > > for...I'm paying for QoS beyond that. > > > >First of all, the site uses normal links if there are no problems. It only > >switches to tunnels when there is are failures. I don't think it is fair > >to say we are "multihoming via tunnels" in all contexts. > > So let's make sure everyone is clear on this point. You're saying the only > reason to multi-home is for failover purposes. As long as the "primary" > link is up, the "secondary" interface (which is used solely to carry > tunneled traffic in the event of an outage with the primary) is never used. No, all I am saying is a normal working link can carry tunneled traffic in the face of an outage in addition to the normal traffic; thus, if a site has 11 links (possibly to 11 different providers) that each operate under 90% utilization in normal conditions, when a provider or link goes down, the remaining 10 links carry both the spillover (9% each) and the normal traffic, so that they now operate at near-full (99%) utilization. thanks, ramki From owner-multi6@ops.ietf.org Wed Jul 18 18:09:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17615 for ; Wed, 18 Jul 2001 18:09:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Mz6M-000IDO-00 for multi6-data@psg.com; Wed, 18 Jul 2001 14:43:26 -0700 Received: from flowpoint.procket.com ([209.140.237.1] helo=alpha-tli.procket.com) by psg.com with esmtp (Exim 3.31 #1) id 15Mz6L-000ID6-00 for multi6@ops.ietf.org; Wed, 18 Jul 2001 14:43:25 -0700 Received: (from tli@localhost) by alpha-tli.procket.com (8.9.3/8.9.3) id OAA22423; Wed, 18 Jul 2001 14:42:43 -0700 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: alpha-tli.procket.com: tli set sender to tli@alpha-tli.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15190.723.696133.77848@alpha-tli.procket.com> Date: Wed, 18 Jul 2001 14:42:43 -0700 To: Tony Hain Cc: Brian E Carpenter , "Jon (Taz) Mischo" , Pekka Savola , multi6@ops.ietf.org Subject: RE: Provider Independent addressing usage In-Reply-To: References: X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit | The IXs are in process now first in Europe and now in Asia. Do not view | this as U.S. focus that is just one part of the Internet. | | > The insurmountable problem was that exchanges had to come into | > existence immediately, or PI would sink the routing system. I think a very important question is about whether or not exchanges are part of the natural economically incented growth of the Internet. What we've seen in the US is that they made some sense for awhile, but that private interconnect is drawing the traffic away. One then has to ask how this architecture will play out given an underlying private interconnect architecture. If one can get better (i.e., more reliable, higher bandwidth) service by being in PA space and relying on that provider's private interconnect, why then would anyone want to be in PI space? For those places where exchanges do not currently exist, it seems unlikely that the creation of a routing architecture would cause those exchanges to come into being. And for those places where exchanges already exist, wouldn't most customer trend away from PI space? The meta point here is that whatever architecture is selected, it needs to operate with the natural economic order. Otherwise carriers and customers will both be incented to circumvent the architecture to optimize their own benefit. Tony From owner-multi6@ops.ietf.org Wed Jul 18 20:52:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19546 for ; Wed, 18 Jul 2001 20:52:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15N1o8-0000ta-00 for multi6-data@psg.com; Wed, 18 Jul 2001 17:36:48 -0700 Received: from evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net ([4.60.68.77] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.31 #1) id 15N1o7-0000t6-00 for multi6@ops.ietf.org; Wed, 18 Jul 2001 17:36:47 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 18 Jul 2001 17:36:23 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id C7CDA3CEF64A47B0B7CD36E197C9537F for plus 4 more; Wed, 18 Jul 2001 17:36:23 -0700 Reply-To: From: "Tony Hain" To: "Tony Li" Cc: "Brian E Carpenter" , "Jon \(Taz\) Mischo" , "Pekka Savola" , Subject: RE: Provider Independent addressing usage Date: Wed, 18 Jul 2001 17:36:11 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-reply-to: <15190.723.696133.77848@alpha-tli.procket.com> Importance: Normal X-SLUIDL: 81B8AF65-C8524A13-B59666AD-AFA5F8A2 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA19546 Tony Li wrote: > I think a very important question is about whether or not > exchanges are part of the natural economically incented > growth of the Internet. What we've seen in the US is that > they made some sense for awhile, but that private interconnect > is drawing the traffic away. One then has to ask how this > architecture will play out given an underlying private > interconnect architecture. Actually what you have seen in the US is the natural tension between captivity and openness play out. With the possible exception of the CIX, the exchanges in the US have always been about lowering interconnect costs to open the playing field to the small operator, and that is economically contrary to the large operators interests. Yes the big players want to lower costs, but their mechanism is to make the little guys become customers and pay for the private interconnects. > If one can get better (i.e., more reliable, higher bandwidth) > service by being in PA space and relying on that provider's > private interconnect, why then would anyone want to be in PI > space? For those places where exchanges do not currently > exist, it seems unlikely that the creation of a routing > architecture would cause those exchanges to come into being. > And for those places where exchanges already exist, wouldn't > most customer trend away from PI space? If one trusted that single provider to be reliable and fast, they should in fact be in PA space. The counter question is; why would one want any association with a provider's address space when that trust does not exist? Customers are trending away from the traditional defined PI space in IPv4 simply because it is hard to get. At the same time the routing table growth shows they are in fact trending toward PI as an architecture, by requiring the PA space to be hacked up. A routing architecture by itself will not cause exchanges to be built. What will cause them to be built is a demonstrable business model that shows it is cheaper to go that route than to fight with the instability of the current bloat. Something I sent in a related private thread: The only way I see anything new being deployed is for someone to sit down with real data and show a sustainable business model that actually lowers overall costs. That exercise in itself is substantial enough that nobody will take it on unless there is general consensus that there is sufficient potential in the approach, and that its scope is bounded and understood. The reason I have been persisting on this is that I think we can bound this approach, and it is simple to understand and deploy. I am explicitly trading off efficiency in the address consumption for simplicity in the derivation and routing, as well as trading off maximal routing efficiency for end-to-end system level efficiency. > The meta point here is that whatever architecture is selected, > it needs to operate with the natural economic order. Otherwise > carriers and customers will both be incented to circumvent the > architecture to optimize their own benefit. Since those perspectives on 'optimal benefit' are in direct conflict, circumvention will happen in any case. The real question is can we define an architecture that limits the need to circumvent it to accomplish each party's goals? Or when it is circumvented, contain the damage. Tony From owner-multi6@ops.ietf.org Fri Jul 20 10:43:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23096 for ; Fri, 20 Jul 2001 10:43:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NbAp-0009eV-00 for multi6-data@psg.com; Fri, 20 Jul 2001 07:22:35 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.31 #1) id 15NbAo-0009eM-00 for multi6@ops.ietf.org; Fri, 20 Jul 2001 07:22:34 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f6KEOnF20010 for ; Fri, 20 Jul 2001 16:24:55 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 20 Jul 2001 16:22:54 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: multi6@ops.ietf.org Subject: ETCP Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk It seems there is an implementation of a multiple-addresses-per-host capable TCP: http://www.chem.ucla.edu/~beichuan/etcp/ From owner-multi6@ops.ietf.org Fri Jul 20 11:05:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28713 for ; Fri, 20 Jul 2001 11:05:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Nbg0-000AZq-00 for multi6-data@psg.com; Fri, 20 Jul 2001 07:54:48 -0700 Received: from server.pasta.cs.uit.no ([129.242.16.119] helo=dillema.net) by psg.com with esmtp (Exim 3.31 #1) id 15Nbfz-000AZj-00 for multi6@ops.ietf.org; Fri, 20 Jul 2001 07:54:47 -0700 Received: (from dillema@localhost) by dillema.net (8.11.4/8.11.3) id f6KEeLX03016 for multi6@ops.ietf.org; Fri, 20 Jul 2001 16:40:22 +0200 (CEST) Date: Fri, 20 Jul 2001 16:40:21 +0200 From: Feico Dillema To: multi6@ops.ietf.org Subject: Re: ETCP Message-ID: <20010720164021.C690@pasta.cs.uit.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from iljitsch@muada.com on Fri, Jul 20, 2001 at 04:22:54PM +0200 X-Operating-System: NetBSD drifter.dillema.net 1.5W NetBSD 1.5W (DRIFTER) X-URL: http://www.dillema.net/ Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, Jul 20, 2001 at 04:22:54PM +0200, Iljitsch van Beijnum wrote: > It seems there is an implementation of a multiple-addresses-per-host capable > TCP: > > http://www.chem.ucla.edu/~beichuan/etcp/ One of our students implemented a similar thing for his Master's thesis last year: http://www.vermicelli.pasta.cs.uit.no/ipv6/students/troels/index.html Feico. From owner-multi6@ops.ietf.org Fri Jul 20 11:05:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28782 for ; Fri, 20 Jul 2001 11:05:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NbaK-000ANX-00 for multi6-data@psg.com; Fri, 20 Jul 2001 07:48:56 -0700 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.31 #1) id 15NbaJ-000ANE-00 for multi6@ops.ietf.org; Fri, 20 Jul 2001 07:48:55 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id E74128266F; Fri, 20 Jul 2001 10:48:14 -0400 (EDT) Message-Id: <5.1.0.14.2.20010720104308.00ac02d0@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 20 Jul 2001 10:43:36 -0400 To: Iljitsch van Beijnum From: RJ Atkinson Subject: Re: ETCP Cc: multi6@ops.ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 10:22 20/07/01, Iljitsch van Beijnum wrote: >It seems there is an implementation of a multiple-addresses-per-host capable >TCP: > >http://www.chem.ucla.edu/~beichuan/etcp/ Interesting. IMHO, the specification for this and also any experimental/operational experience with this would make very good and useful Experimental RFCs. Ran From owner-multi6@ops.ietf.org Fri Jul 20 11:48:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09166 for ; Fri, 20 Jul 2001 11:48:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NcHU-000Bkd-00 for multi6-data@psg.com; Fri, 20 Jul 2001 08:33:32 -0700 Received: from arpa.it.uc3m.es ([163.117.139.120]) by psg.com with esmtp (Exim 3.31 #1) id 15NcHR-000BkJ-00 for multi6@ops.ietf.org; Fri, 20 Jul 2001 08:33:29 -0700 Received: from avispa (avispa.it.uc3m.es [163.117.139.178]) by arpa.it.uc3m.es (8.9.3/8.9.3) with SMTP id RAA26097; Fri, 20 Jul 2001 17:32:36 +0200 From: "marcelo" To: "Iljitsch van Beijnum" , Subject: RE: ETCP Date: Fri, 20 Jul 2001 17:32:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Does anybody know why this is implemented as a TCP option an not as an IPv6 option? The IPv6 option usage was suggested in IPng Tokio meeting and it was letf as an open issue for further discussion. marcelo -----Mensaje original----- De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En nombre de Iljitsch van Beijnum Enviado el: viernes, 20 de julio de 2001 16:23 Para: multi6@ops.ietf.org Asunto: ETCP It seems there is an implementation of a multiple-addresses-per-host capable TCP: http://www.chem.ucla.edu/~beichuan/etcp/ From owner-multi6@ops.ietf.org Fri Jul 20 12:02:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13352 for ; Fri, 20 Jul 2001 12:02:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NcZz-000CLl-00 for multi6-data@psg.com; Fri, 20 Jul 2001 08:52:39 -0700 Received: from server.pasta.cs.uit.no ([129.242.16.119] helo=dillema.net) by psg.com with esmtp (Exim 3.31 #1) id 15NcZy-000CLR-00 for multi6@ops.ietf.org; Fri, 20 Jul 2001 08:52:38 -0700 Received: (from dillema@localhost) by dillema.net (8.11.4/8.11.3) id f6KFbjM03170; Fri, 20 Jul 2001 17:37:45 +0200 (CEST) Date: Fri, 20 Jul 2001 17:37:45 +0200 From: Feico Dillema To: marcelo Cc: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: RE: ETCP Message-ID: <20010720173745.E690@pasta.cs.uit.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from marcelo@it.uc3m.es on Fri, Jul 20, 2001 at 05:32:16PM +0200 X-Operating-System: NetBSD drifter.dillema.net 1.5W NetBSD 1.5W (DRIFTER) X-URL: http://www.dillema.net/ Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, Jul 20, 2001 at 05:32:16PM +0200, marcelo wrote: > Does anybody know why this is implemented as a TCP option an not as an IPv6 > option? > The IPv6 option usage was suggested in IPng Tokio meeting and it was letf as > an open issue for further discussion. Not an answer to your question, but this was the approach taken by our student, see: http://www.vermicelli.pasta.cs.uit.no/ipv6/students/troels/html/thesis/node27.html Feico. From owner-multi6@ops.ietf.org Fri Jul 20 12:03:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13740 for ; Fri, 20 Jul 2001 12:03:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NccE-000CPW-00 for multi6-data@psg.com; Fri, 20 Jul 2001 08:54:58 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.31 #1) id 15NccD-000CPQ-00 for multi6@ops.ietf.org; Fri, 20 Jul 2001 08:54:57 -0700 Received: from wt.muada.com (wt [213.156.3.172]) by sequoia.muada.com (8.11.0/8.9.3) with ESMTP id f6KFvIF20131; Fri, 20 Jul 2001 17:57:18 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 20 Jul 2001 17:55:21 +0200 (West-Europa (zomertijd)) From: Iljitsch van Beijnum To: marcelo cc: multi6@ops.ietf.org Subject: RE: ETCP In-Reply-To: Message-ID: X-X-Sender: iljitsch@mail.muada.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 20 Jul 2001, marcelo wrote: > Does anybody know why this is implemented as a TCP option an not as an IPv6 > option? > The IPv6 option usage was suggested in IPng Tokio meeting and it was letf as > an open issue for further discussion. Maybe the last line at the bottom of the page will clarify this: Last Modified: December 7, 1997 Iljitsch From owner-multi6@ops.ietf.org Sat Jul 21 14:31:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13154 for ; Sat, 21 Jul 2001 14:31:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15O1Wo-000Jn0-00 for multi6-data@psg.com; Sat, 21 Jul 2001 11:31:02 -0700 Received: from ren-6.cais.net ([205.252.14.81]) by psg.com with esmtp (Exim 3.31 #1) id 15O1Wm-000Jmu-00 for multi6@ops.ietf.org; Sat, 21 Jul 2001 11:31:00 -0700 Received: from [63.216.127.100] (63-216-127-100.sdsl.cais.net [63.216.127.100]) by ren-6.cais.net (8.11.1/8.11.1) with ESMTP id f6LIUwj13622 for ; Sat, 21 Jul 2001 14:30:58 -0400 (EDT) Mime-Version: 1.0 X-Sender: hcb@pop3.clark.net Message-Id: Date: Sat, 21 Jul 2001 14:30:50 -0400 To: multi6@ops.ietf.org From: "Howard C. Berkowitz" Subject: Complementary work? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-multi6@ops.ietf.org Precedence: bulk We submitted, just before the deadline, an update of the expired I-D below. It appears to complement the work being done in the MULTI6 WG, in that it deals with a higher level of abstraction about multihoming than at the routing level alone. While it was presented to IDR some time ago, the consensus was that it had useful content but, since it did not deal with protocol development, was outside their scope. Variants of the document have been presented at NANOG, and are also in my book, _WAN Survival Guide_ from Wiley. What would be the group's feeling about taking it on as a working document, with the routing multihoming document being at a more technology specific level, possibly with some of the routing-specific detail moving to the IPv4 and IPv6 drafts? This is meant as a friendly amendment only! Howard Berkowitz Nortel ---------- Network Working Group H. Berkowitz Internet-Draft D. Krioukov July 2001 Nortel Networks draft-berkowitz-multirqmt-02.txt (if possible, change to draft-berkowitz-multireq-02.txt) To Be Multihomed: Requirements & Definitions Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract As organizations find their Internet connectivity increasingly critical to their mission, they seek ways of making that connectivity more robust. The term ''multi-homing'' often is used to describe means of fault-tolerant connection. Unfortunately, this term covers a variety of mechanisms, including naming/directory services, routing, and physical connectivity. The "home" may be identified by a DNS name, an IP address, or an IP address and transport-layer port identifier. Any of these identifiers may be translated in the path between source and destination. This memorandum presents a systematic way to define the requirement for resilience, and a taxonomy for describing mechanisms to achieve it. Its intended audience is primarily people concerned with planning and performing multihoming deployments, rather than protocol developers. It examines both requirements and applications, with the emphasis on the former. As organizations find their Internet connectivity increasingly critical to their mission, they seek ways of making that connectivity more robust. The term ''multi-homing'' often is used to describe means of fault-tolerant connection. Unfortunately, this term covers a variety of mechanisms, including naming/directory services, routing, and physical connectivity. The "home" may be identified by a DNS name, an IP address, or an IP address and transport-layer port identifier. Any of these identifiers may be translated in the path between source and destination. This memorandum presents a systematic way to define the requirement for resilience, and a taxonomy for describing mechanisms to achieve it. Its intended audience is primarily people concerned with planning and performing multihoming deployments, rather than protocol developers. It examines both requirements and applications, with the emphasis on the former. 1. Introduction As the Internet becomes more ubiquitous, more and more enterprises connect to it. Some of those enterprises, such as Web software vendors, have no effective business if their connectivity fails. Other enterprises do not have mission-critical Internet applications, but become so dependent on routine email, news, web, and similar access that a loss of connectivity becomes a crisis. As this Internet dependence becomes more critical, prudent management suggests there be no single point of failure that can break all Internet connectivity. The term "multihoming" has come into vogue to describe various means of enterprise-to-service provider connectivity that avoid a single point of failure. Multihoming also can describe connectivity between Internet Service Providers and "upstream" Network Service Providers. Several terms have become overloaded to the point of confusion, including multihoming, virtual private networks, and load balancing. This document attempts to bring some order to the definition of multihoming. It partially overlaps definitions of virtual private networks [Ferguson & Huston]. If we take the word "multihoming" in the broadest context, it implies there are multiple ways to reach a "home" destination. Another way to look at this is that the Internet, in the broadest sense, consists of a set of layered virtualizations: time division multiplexing on top of media, data link multiplexing on top of multiplexed channels, routes and label switched paths on top of data link virtual circuits, transport sessions on top of routes, etc. See Chapter 5 of [Berkowitz 2000]. This "home" may be identified by a name, an IP address, or a combination of IP address and TCP/UDP port. In this document, TCP/UDP ports will be referred to as TU ports. There are other motivations for complex connectivity from enterprises to the Internet. Mergers and acquisitions, where the joined enterprises each had their own Internet access, often mean complex connectivity, at least for a transition period. Consolidation of separate divisional networks also creates this situation. A frequent case arises when a large enterprise decides that Internet access should be available corporate-wide, but their research labs have had Internet access for years -- and it works, as opposed to the new corporate connection that at best is untried. Many discussions of multihoming focus on the details of implementation, using such techniques as the Border Gateway Protocol (BGP) [RFC number of the Applicability Statement], multiple DNS entries for a server, etc. This document suggests that it is wise to look systematically at the requirements before selecting a means of resilient connectivity. One implementation technique is not appropriate for all requirements. There are special issues in implementing solutions in the general Internet, because poor implementations can jeopardize the proper function of global routing or DNS. An incorrect BGP route advertisement injected into the global routing system is a problem whether it originates in an ISP or in an enterprise. 2. Requirements In this document, the words that are used to define the significance of each particular requirement are capitalized. These words are: * "MUST" This word, or the words "REQUIRED" and "SHALL" mean that the item is an absolute requirement of the specification. * "SHOULD" This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. * "MAY" This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item. An implementation is not compliant if it fails to satisfy one or more of the MUST requirements for the protocols it implements. An implementation that satisfies all the MUST and all the SHOULD requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST requirements but not all the SHOULD requirements for its protocols is said to be "conditionally compliant". 3. Goals Requirements tend to be driven by one or more of several major goals for server availability and performance. Availability goals are realized with resiliency mechanisms, to avoid user-perceived failures from single failures in servers, routing systems, or media. Performance goals are realized by mechanisms that distribute the workload among multiple machines such that the load is distributed in a useful manner. Like multi-homing, the terms load-balancing and load-sharing have many definitions. In defining requirements, the servers themselves may either share or balance the load, there may be load-sharing or load-balancing routing paths to them, or the routed traffic may be carried over load-shared or load-balanced media. 3.1 Analyzing Application Requirements Several questions need to be answered in the process of refining goals: -- the administrative model and administrative awareness of endpoints -- availability requirements -- the security model -- addressing requirements -- scope of multihoming 3.1.1 Administrative Model A key question is: are endpoints predefined in the multihoming process, or will either the client or server end be arbitrary? The servers of interest may be inside the enterprise, or outside it. If they are outside, their names or addresses may or may not be preconfigured into multihoming mechanisms. In this document, intranet clients and servers are inside the enterprise and intendedprimarily for enterprise use. The existence of both can be preconfigured. Intranet clients have access only to machines on the intranet. Multinet clients servers are inside the enterprise, but there is pre- authorized access by known external partners. Internet servers are operated by the enterprise but intended to be accessible to the general Internet. Internet clients have general Internet access that may be mediated by a firewall. The client administrator will know the prior identity of clients, but not of servers. The server administrator will know the prior identity of servers, but not of clients. 3.1.2 Availability Requirements There are major implications between defining a requirement for high availability of initial access, and making the connection stay up once access has been achieved. The latter tends to require transport layer awareness. In the terminology of RFC1775, "To be 'on' the Internet," servers described here have "full" or a subset of "client" access. Client servers may not directly respond to specific IP packet from an arbitrary host, but a system such as a firewall MUST respond for them unless a security policy precludes that. Some valid security policies, for example, suppress the response of ICMP Destination Administratively Prohibited responses, because that would reveal there is an information resource being protected. RFC1775 defines full access as " a permanent (full-time) Internet attachment running TCP/IP, primarily appropriate for allowing the Internet community to access application servers, operated by Internet service providers. Machines with Full access are directly visible to others attached to the Internet, such as through the Internet Protocol's ICMP Echo (ping) facility. The core of the Internet comprises those machines with Full access." This definition is extended here to allow full firewalls or screening routers always to be present. If a proxy or address translation service exists between the real machine and the Internet, if this service is available on a full-time basis, and consistently responds to requests sent to a DNS name of the server, it is considered to be full-time. In this discussion, we generalize the definition beyond machines primarily appropriate for the Internet community as a whole, to include in-house and authorized partner machines that use the Internet for connectivity. Both the cases described in 4.2.3 and 4.2.4 have been termed "Virtual Private Networks." 3.1.3 Security Model Security requirements can include various cryptographic schemes, as well as mechanisms to hinder denial of service attacks. The requirements analyst must determine whether cryptography is needed, and, if so, whether cryptographic trust must be between end hosts or between end hosts and a trusted gateway. Such gateways can be routers or multiported application servers. 3.1.4. Addressing Refinements and Issues It is arguable that addressing used to support multihoming is a routing deployment issue, beyond the scope of this document. Rationales for including it here is that addressing MAY affect application behavior. There also may be administrative requirements for addressing, such as a service provider that contracts to run a multinet may require addresses to be registered, possibly from the provider's address space. If the enterprise runs applications that embed network layer addresses in higher-level data fields, solutions that employ address translation, at the packet or virtual connection level, MAY NOT work. Use of such applications inherently is a requirement for the eventual multihoming solution. Consideration also needs to be given to application caches in addition to those of DNS. Firewall proxy servers are a good example where multiple addresses associated with a given destination may not be supported. Network Address Translation (NAT) is a widespread technique undergoing significant enhancement in the NAT Working Group. The traditional approached either did a one-to-one translation from inside to outside address, or a many-to-one mapping from a large number of addresses on one side to a much smaller number of addresses (with a larger number of TCP/UDP ports). The traditional approaches, in practice, include: RFC1918 internal, static network address translation (NAT) to outside The outside space may be an extranet partner's private or registered address space, or may be registered space allocated to an ISP. RFC1918 internal, dynamic port address translation (PAT) to outside The outside space may be an extranet partner's private or registered address space, or may be registered space allocated to an ISP. -- Registered internal, Provider Assigned (PA) -- Registered internal, Provider Independent (PI) More powerful translation technologies such as Load-Sharing NAT [RFC2391] or Address Layer Gateways (ALG) [RFC2663] may be needed. 3.1.5 Scope of multihoming Multihoming may be defined between an end host and a router or application gateway, on an end-to-end basis possibly involving virtual servers, among routers, or among elements in a transmission system. Different multihoming scopes may support the same application requirement. 3.2. Application Goals These goals need to be agreed to by the people or organization responsible for the applications. Not to reach fairly formal agreement here can lead to problems of inappropriate expectations. At the application layer, there will be expectations of connectivity. Not all applications will operate through classical NAT devices. Application designers should proceed on two fronts: following NAT-friendly application design principles [Senie 1999a] and being aware of potential application protocol interactions with NAT technologies [Holdredge 1999a]. The term "service level agreement" often refers to expectations of performance, such as throughput or response time. Ideas here extend the performance-based model to include availability. 3.2.1 Specific network application availability The first goal involves well-defined applications that run on a specific set of servers visible to the Internet at large. This will be termed "endpoint multihoming", emphasizing the need for resilience of connectivity to well-defined endpoints. Solutions here involve DNS mechanisms as well as route injection techniques. There are both availability and performance goals here. Availability goals arise when there are multiple routing paths that can reach the server, protecting it from single routing failures. Other availability goals involve replicated servers, so that the client will reach a server regardless of single server failures. Replicated servers can be either placed in the same location or distributed geographically. Performance goals include balancing client requests over multiple servers, so that one or more servers do not become overloaded and provide poor service. Requests can be distributed among servers in a round-robin fashion, or more sophisticated distribution mechanisms can be employed. Such mechanisms can consider actual real-time workload on the server or other devices involved, proximity between the client and the server, known server capacity, etc. From an application standpoint, this is either a many-to-one topology, many clients to one server, or a many-to-many topology when multiple servers are involved. It can be worthwhile to consider a many-to-few case, when the few are multiple instances of a server function, which may appear as a single server to the general Internet. The idea of many-to-few topology allows for a local optimization of inter-server communications, without affecting the global many-to-one model. Addresses on interfaces that connect to the general Internet need to be unique in the global Internet routing system, although they may be translated, at the network address or port level, from public to internal space. However, in route injection techniques, virtual addresses corresponding to the same geographically distributed application may be the same in different locations. 3.2.1.1 Content Delivery Networks (CDNs) CDNs can be considered as a special case of the application availability scenario. The emphasis here is on dealing with the client-server proximity and/or on delivering of specialized content and network-based applications to (the predefined set of) clients in the best possible way. CDNs can be though of as a next generation hosting solutions. In the usual hosting scenario, Content/Collocation Service Provider limits itself to the Internet Data Center (IDC) operations. In the CDN model, the service provider distributes copies of content to remote replicas (caches) located as close to the client edge as possible. The fundamental reasons for doing so are: - improved end user experience (even speed-of-light delays become comparable with the maximum delays required by some applications and, hence, service provider's SLAs; as a result, the physical proximity of the content to the client becomes crucial); - improved network bandwidth utilization; - decreased load on the origin server(s). The value of a CDN is defined by its reach and scale. The way to increase the reach and scale of CDNs is CDN peering, [Day]. In the CDN peering model, separate CDNs can peer (exchange content as well as content routing, proximity and accounting information) in a way similar to traditional ISP peering. Success of CDN peering standard effort may lead to appearance of a content-and-proximity-aware global network overlaid with the current Internet infrastructure. 3.2.2 General Internet connectivity from the enterprise The second is high availability of general Internet connectivity for arbitrary enterprise users to the outside. This will be called "internetwork multihoming". Solutions here tend to involve routing mechanisms. This can be viewed as a few-to-many application topology. Addresses on interfaces that connect to the general Internet need to be unique in the global Internet routing system, although they may be translated, at the network address or port level, from internal private address to public space. 3.2.3 Use of Internet services to interconnect "intranet" enterprise campuses The third involves the growing number of situations where Internet services are used to interconnect parts of an enterprise. This is "intranetwork multihoming". This will usually involve dedicated or virtual circuits, or some sort of tunneling mechanisms. This case may be termed a "virtual private network." The "multihoming" aspect of this case is associated with high availability to the connectivity network that underlies the tunneling system. In this case, addresses only need to be unique within the enterprise. 3.2.4 Use of Internet services to connect to "multinet" partners A fourth category involves use of the Internet to connect with strategic partners. True, this does deal with endpoints, but the emphasis is different than the first case. In the first case, the emphasis is on connectivity from arbitrary points outside the enterprise to points within it. This second case deals with pairs of well-known endpoints. These endpoints may be linked with dedicated or virtual circuits defined at the physical or data link layer. Tunneling or other virtual private networks may be relevant here as well. There will be coordination issues that do not exist for the third case, where all resources are under common control. Addresses need to be unique in the different enterprises, but do not need to be unique in the global Internet. 4. Planning and Budgeting In each of these scenarios, organization managers need to assign some economic cost to outages. Typically, there will be an incident cost and an incremental cost based on the length or scope of the connectivity loss. Ideally, this cost is then weighted by the probability of outage. A weighted exposure cost results when the outage cost is multiplied by the probability of the outage. Resiliency measures modify the probability, but increase the cost of operation. Operational costs obviously include the costs of redundant mechanisms (i.e., the addititional multihomed paths), but also the incremental costs of personnel to administer the more complex mechanisms -- their training and salaries. 5. Issues 5.1 Performance and Robustness Goals of some forms of "multi-homing" conflict with goals of improving local performance. For example, DNS queries normally are cached in DNS servers, and in the requesting host. From the performance standpoint, this is a perfectly reasonable thing to do, reducing the need to send out queries. From the multihoming standpoint, it is far less desirable, as application-level multihoming may be based on rapid changes of the DNS master files. The binding of a given IP address to a DNS name can change rapidly. On the other hand, goals of some other forms of "multi-homing" just revolve around the improved performance (while higher robustness is delivered "automatically"). The CDN approach is a good example. 5.2 Service Level Agreements Enterprise networks, especially mainframe-based, are accustomed to building and enforcing service level agreements for application performance. A key to being able to do this is total control of the end-to-end communications path. In the current Internet, the enterprise(s) at one or both ends control their local environments, and have contractual control over connections to their direct service providers. If service level control is a requirement, and both ends of the path are not under control (i.e., cases 1 and 2), the general Internet cannot now provide service level guarantees. The need for control should be reexamined, and, if it still exists, the underlying structure will need to be dedicated resources at the network layer or below. A network service provider may be able to engineer this so that some facilities are shared to reduce cost, but the sharing is planned and controlled. 5.3 Symmetry One of the reasons service level agreements are not enforceable in the general Internet is the reality that global routing cannot be guaranteed to be symmetrical. Symmetrical routing assumes the path to a destination is simply reversed to return a response from that destination. Both legs of a symmetrical path are assumed to have the same performance characteristics. Global Internet routing is not necessarily optimized for best end-to-end routing, but for efficient handling in the Autonomous Systems along the path. Many service providers use "closest exit" routing, where they will go to the closest exit point from their perspective to get to the next hop AS. The return path, however, is not necessarily of a mirror image of the path from the original source to the destination. Closest exit routing is, in fact, a "feature" rather than a "bug" in some multihoming schemes [Peterson] [Friedman]. Especially when the enterprise network has multiple points of attachment to the Internet, either to a single ISP AS or to multiple ISPs, it becomes likely that the response to a given packet will not come back at the same entry point in which it left the enterprise. This is probably not avoidable, and troubleshooting procedures and traffic engineering have to consider this characteristic of multi-exit routing. 5.4 Security ISPs may be reluctant to let user routing advertisements or DNS zone information flow directly into their routing or naming systems. Users should understand that BGP is not intended to be a plug-and-play mechanism; manual configuration often is considered an important part of maintaining integrity. Supplemental mechanisms may be used for additional control, such as registering policies in a registry [RPS, RA documents] or egress/ingress filtering [Ferguson draft] Challenges may arise when client security mechanisms interact with fault tolerance mechanisms associated with servers. For example, if a server address changes to that of a backup server, a stateful packet screening firewall might not accept a valid return. Similarly, unless servers back one another up in a full mirroring mode, if one end of a TCP-based application connection fails, the user will need to reconnect. As long as another server is ready to accept that connection, there may not be major user impact, and the goal of high availability is realized. High availability and user transparent high availability are not synonymous. 5.5 Load Balancing vs. Load Sharing These terms are often interchanged, but they really mean different things. Load balancing is deterministic, and at a finer level of control than load sharing, which is statistical. Load balancing is generally not something that can be realized in general Internet routing, other than in special and local cases between adjacent AS. A degree of load sharing is achievable in routing, but it may introduce significant resource demands and operational complexity. Historically, load balancing was thought of as a true equal split of traffic over a set of transmission pipes. More modern concepts of controlled load balancing use much more intelligent algorithms. In the server load balancing (SLB) context, for example, the balancing is done by a SLB algorithm. For local server load balancing (i.e., in a LAN-connected cluster of servers), deployed algorithms include round robin, least real server sessions, least server response time, least real server load, etc. Global load balancing among multiple clusters becomes even more complex. The key point to understand is that load balancing is a result of some dynamic algorithm, while load sharing is a result of some static configurations. 5.6 Application Compatibility Some deployment mechanisms involve network address, or network address and TCP/UDP port, translation (NAT and NAPT). If the application protocols embed IP addresses in their protocol fields, NAT or NAPT may cause protocol failures. Translation mechanisms for such cases may require knowledge of the application protocol, as typified by application proxies in firewalls, or in application gateways with multiple interfaces. 6. Multihoming Deployment Technologies A basic way to tell which technology(ies) is applicable is to ask oneself whether the functional requirement is defined in terms of multihoming to specific hosts, or to specific networks. A given multihoming implementation may draw on several of these technologies, such as DNS name-level redirection based in part on routing metrics. 6.1 Application/Name Based Technologies in this category may involve referring a client request to different instances of the endpoint represented by a single name. Another aspect of application/name multihoming may work at the level of IP addressing, but specifically is constrained to endpoint (i.e., server) activities that redirect the client request to a different endpoint. Application-level firewall proxy services can provide this functionality, although their application protocol modification emphasizes security while a multihoming application service emphasizes availability and quality of service. 6.2 Transport Based Transport based technologies are based on maintaining tunnels through an underlying network or transmission system. The tunnels may be true end to end, connecting a client host with a server host, or may interconnect between proxy servers or other gateways. 6.3 Network Based Network based approaches to multihoming are router-based. They involve having alternate next-hops, or complete routes, to alternate destinations. 6.4 Data Link Based Data link layer methods may involve coordinated use of multiple physical paths, as in multilink PPP or X.25. If the underlying WAN service has a virtual circuit mechanism, as in frame relay or ATM, the service provider may have multihomed paths provided as part of the service. Such functions blur between data link and physical layers. Other data link methods may manipulate MAC addresses to provide virtual server functions. 6.5 Physically-based Physical multihoming strategies can use diverse media, often of different types such as a wire backed up with a wireless data link. They also involve transmission media which have internal redundancy, such as SONET. 7. Application/Name Multihoming While many people look at the multihoming problem as one of routing, the goal is often multihoming to endpoints. Finding an endpoint usually begins in DNS. Once an endpoint address is found, some application protocols, notably HTTP and FTP, may redirect the request to a different endpoint. The basic idea here is that arbitrary clients will first request access to a resource by its DNS name, and certain DNS servers will resolve the same name to different addresses based on conditions of which DNS is aware, or using some statistical load-distribution mechanism. There are some general DNS issues here. DNS was not really designed to do this. A key issue is that of DNS caching. Caching and frequent changes in name resolution are opposite goals. Traditional DNS schemes emphasize performance over resiliency. 7.1 DNS Caching DNS standards do provide the capability for short cache lifetimes, which in principle support name based multihoming. "The meaning of the TTL field is a time limit on how long an RR can be kept in a cache. This limit does not apply to authoritative data in zones; it is also timed out, but by the refreshing policies for the zone. The TTL is assigned by the administrator for the zone where the data originates. While short TTLs can be used to minimize caching, and a zero TTL prohibits caching, the realities of Internet performance suggest that these times should be on the order of days for the typical host. If a change can be anticipated, the TTL can be reduced prior to the change to minimize inconsistency during the change, and then increased back to its former value following the change. [RFC1034] Several real-world factors limit the utility of simply shortening the cache time. Widely used BIND, the most widely used DNS implementation, does not accept cache lifetimes less than 5 minutes, while the older versions of BIND just ignore responses with TTL 0. Dynamic DNS may be a long-term solution here. In the short term, setting very short TTL values may be help in some cases, but is not likely to help below a granularity of 5 minutes. Remember that the name normally is resolved when an application session first is established (that is, the application must be restarted for updated DNS mapping to take effect), and the decisions are made over a longer time base than per-packet routing decisions. 7.2 DNS Multiple Hosts and Round Robin Response The DNS protocol allows it to return multiple host addresses in response to a single query. At the first level of DNS-based multihoming, this can provide additional reliability. A DNS server knows three IP addresses for the server function identified by server.example.com, 10.0.1.1, 10.0.2.1, and 10.0.3.1. A simple response to a query for server.example.com returns all three addresses. Assume the response provides server addresses in the order 10.0.1.1, 10.0.2.1, and 10.0.3.1. Whether this will provide multihoming now depends on the DNS client. Not all host client implementations will, if the first address returned (i.e., 10.0.1.1) does not respond, try the additional addresses. In this example, 10.0.2.1 might be operating perfectly. A variant suggested by Kent England on the NANOG mailing list is to have the addresses returned in the DNS response come from the CIDR blocks of different ISPs that provide connectivity to the server function. This approach combines aspects of name and network multihoming. Again, this will work when intelligent clients try every IP address returned until a server responds. Not all clients are intelligent. 7.3 Intelligent DNS Responses This is usually a part of Global Server Load Balancing (GSLB) functionality of specialized devices (load balancers) from various vendors. In this case, information about availability of and load on servers is collected and proximity to the client DNS server is measured by the load balancer. Given this information, the load balancer can make more intelligent (than in the round robin case) decision replying to the DNS request. 7.4 Cache Servers and Application Multihoming Caching is actively used in Content Delivery Networks (CDNs). Clusters of caching devices are installed in a set of "strategic" locations, closer to the client edge. Availability, load and proximity information is exchanged between these clusters and IDCs, where the original servers are located. In case of a cluster failure, the next closest to a given client cluster or IDC serves this client. 8. Transport Multihoming Transport layer functions are conceptually end-to-end. There are two broad classes of transport multihoming function, those maintained by the endpoints and those that involve intermediate translation devices. 8.1 End-to-end Tunnel Maintenance Basic point-to-point tunneling mechanisms include GRE, PPTP and L2TP and IPIP. DVMRP is a special case. Choices here will depend in part on the security policy and the administrative model by which multihoming is provided. GRE, for example, does not itself provide encryption, while PPTP and L2TP do. "The differences between PPTP and L2TP are more of where one wishes the PPP session to terminate, and one of control. It really depends on who you are, and where you are, in the scheme of the control process. If your desire is to control where the PPP session terminates (as an ISP might wish to control), then L2TP might be the right approach. On the other hand, however, if you are a subscriber, and you wish to control where the PPP session terminates (to, say, a PPTP server somewhere across the cloud), then PPTP might be the right approach -- and it would be transparent to the service provider). It really depends on what problem one is trying to solve, and if you are in the business of trying to create "services." [Ferguson-1998-2] 8.2 Load Sharing NAT (LSNAT) Various proxy and address translation mechanisms can play a role in multihoming. They can be divided into several levels of topological constraints: -- all servers are collocated in a single address domain "behind" the translator -- servers are in different parts of a single address domain. These parts are connected by tunnels. -- the servers are at arbitrary network addresses, but the translator knows how to reach them. Application-aware proxies can have even more knowledge of application load. A variant of NAT, called load sharing NAT (LS-NAT), offers a load sharing mechanism at the transport/network level rather than the DNS level [Srishuresh]. When considering LSNAT-style load sharing, remember that it emphasizes providing a pool of servers capable of servicing requests. In its "local" form, it does not easily provide mechanisms for increasing reliability by mapping the user request to geographically distributed servers. More advanced variants can combine with DNS- and routing-aware mechanisms to increase reliability as well as performance. The LSNAT function is visible globally as a server address. It is actually a virtual server. When a client request arrives at the LSNAT, the LSNAT translates the destination address, transparently to the client, and passes it to a server in the LSNAT's server pool. LSNATs, in their basic form, do have topological restriction. It has been suggested that all request/response traffic in a single session must go from the real client, to one specific LSNAT, to the server. It is conceivable that multiple routers could be used, but they would need to be tightly synchronized. LSNAT builds on NAPT, but adds intelligence to the port mapping function. Also, general NAPT is oriented toward outgoing requests from the stub domain to the outside, while LSNAT emphasizes incoming requests to a virtual server address. As currently conceived, LSNATs operate at the TCP/UDP transport level, so they could not easily change server hosts during a session. There are potential workarounds to this, including using a multicast address as the server pool destination, with coordination between the servers as to which actually answers the request. For highly fault-tolerant applications, more than one server conceivably could answer the NAT request, and the LSNAT decide which to pass to the client. Typically, if servers are identical, it would be the first response received by the server pool side of the LSNAT. This general topology restriction suggests LSNAT functionality belongs on a single NAT-capable border router, with the server pool inside the stub domain. A LSNAT violates the Internet end-to-end model in the same way that basic NAT does. There is no requirement that the addressing in the stub domain be private, only that all access to the servers go through the NAT. In basic LSNAT, an arbitrary external client attempts to establish a session with what it believes to be a server. In reality, it is attempting to establish a session with the virtual server address of the "outside" interface of the LSNAT. The LSNAT, based on internal criteria, redirects the external request to a specific internal server in a server pool. Unique connections are established from the LSNAT to the pool server for each request, translating addresses and ports as needed. 8.2.1 Source LS-NAT Adding source address translation removes many topological limitations between the real servers and the LS-NAT router. In a LS-NAT router, inbound sessions identified by the tuple ; Sun, 22 Jul 2001 18:11:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15OR6I-000Hc7-00 for multi6-data@psg.com; Sun, 22 Jul 2001 14:49:22 -0700 Received: from lox.sandelman.ottawa.on.ca ([209.151.24.2] ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15OR6G-000Hbz-00 for multi6@ops.ietf.org; Sun, 22 Jul 2001 14:49:21 -0700 Received: from nox.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [209.151.24.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id RAA05363; Sun, 22 Jul 2001 17:49:06 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [209.151.24.20]) by nox.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f6MLuFw15375 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Sun, 22 Jul 2001 17:56:16 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f6MLfQH03191; Sun, 22 Jul 2001 17:41:26 -0400 (EDT) Message-Id: <200107222141.f6MLfQH03191@marajade.sandelman.ottawa.on.ca> From: mcrietf@sandelman.ottawa.on.ca To: Tony Li cc: multi6@ops.ietf.org Subject: Re: Provider Independent addressing usage In-reply-to: Your message of "Wed, 18 Jul 2001 14:42:43 PDT." <15190.723.696133.77848@alpha-tli.procket.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sun, 22 Jul 2001 17:41:25 -0400 Sender: owner-multi6@ops.ietf.org Precedence: bulk >>>>> "Tony" == Tony Li writes: Tony> I think a very important question is about whether or not exchanges are Tony> part of the natural economically incented growth of the Internet. What Tony> we've seen in the US is that they made some sense for awhile, but that Tony> private interconnect is drawing the traffic away. One then has to Is this because the exchanges are unprofitable, they fail to scale, or is it due to concentration of ownership? It seems that exchanges are of greater benefit when there are many ISPs, while bilateral agreements are easier when there are fewer players. Tony> The meta point here is that whatever architecture is selected, it needs to Tony> operate with the natural economic order. Otherwise carriers and customers I'm not sure the the US marketplace is a very good example of "national economic order" due to legacy of monopoly telco. At this point, we get into politics. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-multi6@ops.ietf.org Sun Jul 22 18:16:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12014 for ; Sun, 22 Jul 2001 18:16:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15ORXU-000I16-00 for multi6-data@psg.com; Sun, 22 Jul 2001 15:17:28 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15ORXT-000I10-00 for multi6@ops.ietf.org; Sun, 22 Jul 2001 15:17:27 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15ORXQ-000HN3-00; Sun, 22 Jul 2001 15:17:24 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: mcrietf@sandelman.ottawa.on.ca Cc: Tony Li , multi6@ops.ietf.org Subject: Re: Provider Independent addressing usage References: <15190.723.696133.77848@alpha-tli.procket.com> <200107222141.f6MLfQH03191@marajade.sandelman.ottawa.on.ca> Message-Id: Date: Sun, 22 Jul 2001 15:17:24 -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> I think a very important question is about whether or not exchanges are >> part of the natural economically incented growth of the Internet. What >> we've seen in the US is that they made some sense for awhile, but that >> private interconnect is drawing the traffic away. One then has to > Is this because the exchanges are unprofitable, they fail to scale, or is > it due to concentration of ownership? the exchanges are still there, the number of isps meeting at them has not (yet?) declined significantly. the *traffic* *proportion* has declined, likely because the cost for providers to use private interconnect has fallen with the price of circuits, and private interconnects are more easily managed. i guess this might be your "fail to scale" point. > It seems that exchanges are of greater benefit when there are many ISPs, > while bilateral agreements are easier when there are fewer players. uh, bi-lats are what are used at the public exchanges. no one went for mlpas. >> The meta point here is that whatever architecture is selected, it needs >> to operate with the natural economic order. Otherwise carriers and >> customers > I'm not sure the the US marketplace is a very good example of "national > economic order" due to legacy of monopoly telco. then please remind us what country does not have the history (or present) of monopoly telco? this leaves us without lessons to follow, not a good space. randy From owner-multi6@ops.ietf.org Mon Jul 23 15:06:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16590 for ; Mon, 23 Jul 2001 15:06:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15OjMw-000CoC-00 for multi6-data@psg.com; Mon, 23 Jul 2001 10:19:46 -0700 Received: from lox.sandelman.ottawa.on.ca ([209.151.24.2] ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15OjMv-000Cnt-00 for multi6@ops.ietf.org; Mon, 23 Jul 2001 10:19:45 -0700 Received: from nox.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [209.151.24.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id NAA15465 for ; Mon, 23 Jul 2001 13:19:01 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [209.151.24.20]) by nox.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f6NHQFw16512 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Mon, 23 Jul 2001 13:26:16 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f6NHBJh09288 for ; Mon, 23 Jul 2001 13:11:19 -0400 (EDT) Message-Id: <200107231711.f6NHBJh09288@marajade.sandelman.ottawa.on.ca> To: multi6@ops.ietf.org From: mcrietf@sandelman.ottawa.on.ca (Michael Richardson) Subject: Re: Provider Independent addressing usage In-reply-to: Your message of "Mon, 23 Jul 2001 08:50:26 PDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 23 Jul 2001 13:11:18 -0400 Sender: owner-multi6@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Randy" == Randy Bush writes: >> So there is no "natural economic order" to learn from, is my point. Randy> i wish all my competitors were similarly hamstrung by having to start from Randy> a tabula rasa every morning. If the market has been distorted, then the market has been distorted. It means that we can not claim that our technical discussion will be immune to political concerns. It might be, in a theoretically "natural" market that there is a business case for IXs, but that given where we are now, there is no reason for them, and little likelyhood that their need will return. I genuinely hope that this isn't the case! My impression of the discussion is: if we assume IXs will grow in number, then multihoming becomes easier/cheaper. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface iQCVAwUBO1xatIqHRg3pndX9AQF7JgP/QRySx27SX6a9elMASUdSvGlrOG3N3AVG oi5VQ4jSMDN2OknlfEb9yY6mIXRJPwRdLGD0k/3CTeWdO27bKe3OkVXK8OYjWaCN gtcFU0TwnIwopjFSS5armE6R2obGPWP3FoNRSn1FgAgOzSy87Q+ox789SS08RBi9 RvcN6PP4784= =EagA -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Jul 23 15:10:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16788 for ; Mon, 23 Jul 2001 15:10:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Ohyh-000Awp-00 for multi6-data@psg.com; Mon, 23 Jul 2001 08:50:39 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Ohyh-000Awj-00 for multi6@ops.ietf.org; Mon, 23 Jul 2001 08:50:39 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15OhyU-000F5r-00; Mon, 23 Jul 2001 08:50:26 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: mcrietf@sandelman.ottawa.on.ca (Michael Richardson) Cc: multi6@ops.ietf.org Subject: Re: Provider Independent addressing usage References: <200107231521.f6NFLVB05623@marajade.sandelman.ottawa.on.ca> Message-Id: Date: Mon, 23 Jul 2001 08:50:26 -0700 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > If two ISPs, who happen to have equipement located at an exchange decided > to pull a x-over cable between their two boxes, is this a public or > private circuit? it is generally considered to be private peering. > So there is no "natural economic order" to learn from, is my point. i wish all my competitors were similarly hamstrung by having to start from a tabula rasa every morning. randy From owner-multi6@ops.ietf.org Mon Jul 23 15:40:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18726 for ; Mon, 23 Jul 2001 15:40:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15OheG-000ARZ-00 for multi6-data@psg.com; Mon, 23 Jul 2001 08:29:32 -0700 Received: from lox.sandelman.ottawa.on.ca ([209.151.24.2] ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15OheF-000ARI-00 for multi6@ops.ietf.org; Mon, 23 Jul 2001 08:29:31 -0700 Received: from nox.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [209.151.24.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id LAA14175 for ; Mon, 23 Jul 2001 11:29:17 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [209.151.24.20]) by nox.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f6NFaRw16418 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Mon, 23 Jul 2001 11:36:32 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f6NFLVB05623 for ; Mon, 23 Jul 2001 11:21:32 -0400 (EDT) Message-Id: <200107231521.f6NFLVB05623@marajade.sandelman.ottawa.on.ca> To: multi6@ops.ietf.org From: mcrietf@sandelman.ottawa.on.ca (Michael Richardson) Subject: Re: Provider Independent addressing usage In-reply-to: Your message of "Sun, 22 Jul 2001 15:17:24 PDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 23 Jul 2001 11:21:30 -0400 Sender: owner-multi6@ops.ietf.org Precedence: bulk >>>>> "Randy" == Randy Bush writes: mcr> It seems that exchanges are of greater benefit when there are many ISPs, mcr> while bilateral agreements are easier when there are fewer players. Randy> uh, bi-lats are what are used at the public exchanges. no one went for Randy> mlpas. I realize that. I meant that the private circuits take actual work to arrange vs using the exchange. If two ISPs, who happen to have equipement located at an exchange decided to pull a x-over cable between their two boxes, is this a public or private circuit? >>> The meta point here is that whatever architecture is selected, it needs >>> to operate with the natural economic order. Otherwise carriers and >>> customers mcr> I'm not sure the the US marketplace is a very good example of "national (my typo should be "natural") mcr> economic order" due to legacy of monopoly telco. Randy> then please remind us what country does not have the history (or present) Randy> of monopoly telco? this leaves us without lessons to follow, not a good Practically none. So there is no "natural economic order" to learn from, is my point. This may be a situation where we will have to write a document aimed at the regulators before we can properly solve a technical problem. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-multi6@ops.ietf.org Mon Jul 23 18:42:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28708 for ; Mon, 23 Jul 2001 18:42:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Oo2h-000LTm-00 for multi6-data@psg.com; Mon, 23 Jul 2001 15:19:11 -0700 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.31 #1) id 15Oo2g-000LTL-00 for multi6@ops.ietf.org; Mon, 23 Jul 2001 15:19:10 -0700 Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA35794; Mon, 23 Jul 2001 23:18:36 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA80264; Mon, 23 Jul 2001 23:18:35 +0100 Message-ID: <3B5CA242.2B46A1C8@hursley.ibm.com> Date: Mon, 23 Jul 2001 17:16:34 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Michael Richardson CC: multi6@ops.ietf.org Subject: Re: Provider Independent addressing usage References: <200107231711.f6NHBJh09288@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Michael Richardson wrote: ... > My impression of the discussion is: if we assume IXs will grow in number, > then multihoming becomes easier/cheaper. And we therefore need to find a technical solution that funnels the ISPs in this direction, i.e. makes it in their selfish self-interest to connect via IXes. I've been waiting for that since March 1995 at least (that is the date on draft-simpson-exchanges-00.txt, and no, I don't have soft copy or a URL). Brian From owner-multi6@ops.ietf.org Tue Jul 24 13:28:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04293 for ; Tue, 24 Jul 2001 13:28:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15P5iS-0005ut-00 for multi6-data@psg.com; Tue, 24 Jul 2001 10:11:28 -0700 Received: from nat2.tahoenetworks.com ([63.99.114.2] helo=mail.tahoenetworks.com) by psg.com with esmtp (Exim 3.31 #1) id 15P5iS-0005um-00 for multi6@ops.ietf.org; Tue, 24 Jul 2001 10:11:28 -0700 Received: from tnpfrancis ([10.10.3.135]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 24 Jul 2001 10:11:27 -0700 Message-ID: <00c401c11463$aa833d50$87030a0a@tahoenetworks.com> Reply-To: "Paul Francis" From: "Paul Francis" To: References: <200107231711.f6NHBJh09288@marajade.sandelman.ottawa.on.ca> <3B5CA242.2B46A1C8@hursley.ibm.com> Subject: GxSE bar bof? Date: Tue, 24 Jul 2001 10:11:23 -0700 Organization: TAHOE Networks 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 24 Jul 2001 17:11:27.0334 (UTC) FILETIME=[AC9C8060:01C11463] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I've been pecking at an internet draft for GxSE, but I'm not sure I'll be done with it before London. What I can do, though, is put together some slides with the basic mechanism and use that to lead a *small* bar bof if there is interest. The goal of the BOF would be to flesh out the design a bit, figure out the pros and cons, and decide if it is something worth pursuing. Any interest? PF From owner-multi6@ops.ietf.org Tue Jul 24 18:40:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29047 for ; Tue, 24 Jul 2001 18:40:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15PAc3-000FoS-00 for multi6-data@psg.com; Tue, 24 Jul 2001 15:25:11 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15PAc2-000Fnq-00 for multi6@ops.ietf.org; Tue, 24 Jul 2001 15:25:11 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15PAbz-0002Ok-00 for multi6@ops.ietf.org; Tue, 24 Jul 2001 15:25:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Toomas Soome To: Todd Whipple cc: , , <6bone@ISI.EDU>, , , , , , Subject: Re: News server In-Reply-To: <5.1.0.14.2.20010724093711.02cf04a0@postoff1.zama.net> Sender: owner-multi6@ops.ietf.org Precedence: bulk Message-Id: Date: Tue, 24 Jul 2001 15:25:11 -0700 Content-Transfer-Encoding: 7bit unfortunately: [196] root@madli:root/kadri> traceroute news.zamanetworks.com traceroute: Warning: Multiple interfaces found; using 3ffe:200:25:500:a00:20ff:fe83:b3ae @ hme0:2 traceroute to news.zamanetworks.com (2001:2d0:2:1::3007), 30 hops max, 60 byte packets 1 kadri.ut.ee (3ffe:200:25:500:a00:20ff:fec4:93e3) 1.057 ms 0.630 ms 0.445 ms 2 ut-gw-v6.ut.ee (3ffe:200:25:f000::c128:167f) 1.599 ms 1.418 ms 1.091 ms 3 ut-cisco.ut.ee (3ffe:200:25:0:2d0:97ff:fe91:a001) 1.547 ms 2.310 ms 2.549 ms 4 2001:6c0:1fff:ffd0::4 19.557 ms 22.475 ms 22.048 ms 5 spacenet-if.6r1.doc.london.ip6.pipex.net (3ffe:1100:0:c11::1) 175.020 ms 120.682 ms * 6 * * * 7 * * * 8 * * * 9 *^C On Tue, 24 Jul 2001, Todd Whipple wrote: > Zama Networks is pleased to announced our IPv6 news group service. The > news server is open only over IPv6. To read news, point your IPv6 capable > news client to news.zamanetworks.com. The server currently has the big > eight group hierarchies except for alt.* > > Currrently, Netscape 6 and TIN 1.5.8 are IPv6 capable news clients. > > Enjoy. > toomas -- Old musicians never die, they just decompose. From owner-multi6@ops.ietf.org Fri Jul 27 09:19:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15984 for ; Fri, 27 Jul 2001 09:19:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Q7WG-000MvA-00 for multi6-data@psg.com; Fri, 27 Jul 2001 06:19:08 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.31 #1) id 15Q7WF-000Mv4-00 for multi6@ops.ietf.org; Fri, 27 Jul 2001 06:19:07 -0700 From: Masataka Ohta Message-Id: <200107271304.WAA24621@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id WAA24621; Fri, 27 Jul 2001 22:04:03 +0900 Subject: revised draft To: multi6@ops.ietf.org Date: Fri, 27 Jul 2001 22:04:03 +0859 () X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-multi6@ops.ietf.org Precedence: bulk draft-ohta-e2e-multihoming-02.txt The Architecture of End to End Multihoming is now available as an ID (without any non-editorial change from the previous one). Masataka Ohta From owner-multi6@ops.ietf.org Fri Jul 27 11:44:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28938 for ; Fri, 27 Jul 2001 11:44:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Q9n9-0005kY-00 for multi6-data@psg.com; Fri, 27 Jul 2001 08:44:43 -0700 Received: from ren-4.cais.net ([205.252.14.79]) by psg.com with esmtp (Exim 3.31 #1) id 15Q9n8-0005kS-00 for multi6@ops.ietf.org; Fri, 27 Jul 2001 08:44:42 -0700 Received: from [63.216.127.100] (63-216-127-100.sdsl.cais.net [63.216.127.100]) by ren-4.cais.net (8.11.1/8.11.1) with ESMTP id f6RFhFa36207; Fri, 27 Jul 2001 11:43:15 -0400 (EDT) Mime-Version: 1.0 X-Sender: hcb@pop3.clark.net Message-Id: In-Reply-To: <200107271304.WAA24621@necom830.hpcl.titech.ac.jp> References: <200107271304.WAA24621@necom830.hpcl.titech.ac.jp> Date: Fri, 27 Jul 2001 11:41:39 -0400 To: multi6@ops.ietf.org From: "Howard C. Berkowitz" Subject: Agenda item Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-multi6@ops.ietf.org Precedence: bulk Never knowing when email becomes a black hole, again I'd like to mention http://www.ietf.org/draft-berkowitz-multireq-02.txt is on the server, and request agenda time in London to discuss it as a potential work item, essentially as a framework/definition document to complement specific multihoming technology documents Howard Berkowitz Nortel From owner-multi6@ops.ietf.org Fri Jul 27 18:09:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08708 for ; Fri, 27 Jul 2001 18:09:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15QEfB-000MuK-00 for multi6-data@psg.com; Fri, 27 Jul 2001 13:56:49 -0700 Received: from fwns1d.raleigh.ibm.com ([204.146.167.235] helo=fwns1.raleigh.ibm.com) by psg.com with esmtp (Exim 3.31 #1) id 15QEfA-000Mtw-00 for multi6@ops.ietf.org; Fri, 27 Jul 2001 13:56:48 -0700 Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA07900; Fri, 27 Jul 2001 16:56:16 -0400 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA27672; Fri, 27 Jul 2001 16:56:05 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id QAA01999; Fri, 27 Jul 2001 16:55:19 -0400 Message-Id: <200107272055.QAA01999@rotala.raleigh.ibm.com> To: multi6@ops.ietf.org cc: Sean Doran Subject: Pseudo "last call" for draft-ietf-ipngwg-ipv6-2260-02.txt Date: Fri, 27 Jul 2001 16:55:19 -0400 From: Thomas Narten Sender: owner-multi6@ops.ietf.org Precedence: bulk The document "IPv6 multihoming support at site exit routers" came out of the IPng WG, which has requested that it be published as an informational RFC. Given that the subject of the draft overlaps with the main focus of this group, we'd be interested in getting WG feedback on the contents of the document. Namely: - is the document reasonable to publish as an informational RFC as is, or are some specific changes appropriate? - How feasible do the techniques described in the document appear to be from the perspective of an operator? - What are the main (if any) limitations to using the described techniques from an operational perspective? Are these limitations, if any, adequately described in the document? Explicit feedback (including "looks fine to me") from all those who read it would be helpful. Sean & Thomas Multi6 WG Chairs From owner-multi6@ops.ietf.org Fri Jul 27 18:09:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08721 for ; Fri, 27 Jul 2001 18:09:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15QEST-000MD9-00 for multi6-data@psg.com; Fri, 27 Jul 2001 13:43:41 -0700 Received: from fwns2d.raleigh.ibm.com ([204.146.167.236] helo=fwns2.raleigh.ibm.com) by psg.com with esmtp (Exim 3.31 #1) id 15QESS-000MCv-00 for multi6@ops.ietf.org; Fri, 27 Jul 2001 13:43:40 -0700 Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA14786; Fri, 27 Jul 2001 16:37:39 -0400 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA28608; Fri, 27 Jul 2001 16:43:07 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id QAA01929; Fri, 27 Jul 2001 16:42:22 -0400 Message-Id: <200107272042.QAA01929@rotala.raleigh.ibm.com> To: multi6@ops.ietf.org cc: Sean Doran Subject: WG Docs & Call for Agenda Items Date: Fri, 27 Jul 2001 16:42:21 -0400 From: Thomas Narten Sender: owner-multi6@ops.ietf.org Precedence: bulk Multi6 has been assigned a 1-hour slot in London, tentatively scheduled for the first Tuesday afternoon slot. If you wish to have some agenda time, please let Sean and I know. We have two WG documents that will likely see some discussion: draft-ietf-multi6-multihoming-requirements-01.txt draft-ietf-multi6-v4-multihoming-00.txt There has been quite a lot of discussion on the requirements document, I'll leave it to the authors to summarize the next steps/open issues. The second document has seen only a bit of discussion. Does that mean everyone thinks its already fine and dandy? Either way, I'm sure the authors would welcome additional feedback. Thomas (as multi6 co-chair) From owner-multi6@ops.ietf.org Sun Jul 29 01:53:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14304 for ; Sun, 29 Jul 2001 01:52:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15QGJQ-00031t-00 for multi6-data@psg.com; Fri, 27 Jul 2001 15:42:28 -0700 Received: from lint.cisco.com ([171.68.224.209]) by psg.com with esmtp (Exim 3.31 #1) id 15QGJP-0002yp-00 for multi6@ops.ietf.org; Fri, 27 Jul 2001 15:42:28 -0700 Received: from cisco.com (dhcp-2sjc13-85-76.cisco.com [171.70.85.76]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA03096; Fri, 27 Jul 2001 15:41:56 -0700 (PDT) Message-ID: <3B61EE34.734C5867@cisco.com> Date: Fri, 27 Jul 2001 15:41:56 -0700 From: Eliot Lear Reply-To: lear@cisco.com X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Howard C. Berkowitz" CC: multi6@ops.ietf.org Subject: Re: Agenda item References: <200107271304.WAA24621@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Make that http://www.ietf.org/internet-drafts/draft-berkowitz-multireq-02.txt "Howard C. Berkowitz" wrote: [...] > > is on the server, > > and request agenda time in London to discuss it as a potential work > item, essentially as a framework/definition document to complement > specific multihoming technology documents > > Howard Berkowitz > Nortel -- Eliot Lear lear@cisco.com From owner-multi6@ops.ietf.org Sun Jul 29 10:49:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22580 for ; Sun, 29 Jul 2001 10:49:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Qp8I-000J7M-00 for multi6-data@psg.com; Sun, 29 Jul 2001 04:53:18 -0700 Received: from coconut.itojun.org ([210.160.95.97]) by psg.com with esmtp (Exim 3.31 #1) id 15Qp8I-000J7G-00 for multi6@ops.ietf.org; Sun, 29 Jul 2001 04:53:18 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id A35364B20; Sun, 29 Jul 2001 20:53:14 +0900 (JST) To: Pekka Savola Cc: Thomas Narten , multi6@ops.ietf.org, Sean Doran In-reply-to: pekkas's message of Sun, 29 Jul 2001 14:38:19 +0300. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Pseudo "last call" for draft-ietf-ipngwg-ipv6-2260-02.txt From: itojun@iijlab.net Date: Sun, 29 Jul 2001 20:53:14 +0900 Message-ID: <9418.996407594@itojun.org> Sender: owner-multi6@ops.ietf.org Precedence: bulk >Personally, I find the approach workable in theory but rather awkward in >practise; I don't see one's upstream operator(s) jumping with joy if >they'd have to set up and operate a rather extensive "link backup >service", co-operating with their competitors. In an academic, >no-money-exchanged world this probably works better. actually, you may use it with two POPs of a single ISP too. if they do not aggregate per-POP you can use a single prefix and advertise routes normally. if the upstream ISP aggregates per-POP, you may get two /48 from them and operate these two prefixes (the scenario is closer to two different ISP case). itojun From owner-multi6@ops.ietf.org Sun Jul 29 10:49:21 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22590 for ; Sun, 29 Jul 2001 10:49:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15QouS-000Iiy-00 for multi6-data@psg.com; Sun, 29 Jul 2001 04:39:00 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.31 #1) id 15QouR-000Iir-00 for multi6@ops.ietf.org; Sun, 29 Jul 2001 04:38:59 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f6TBcJd03895; Sun, 29 Jul 2001 14:38:20 +0300 Date: Sun, 29 Jul 2001 14:38:19 +0300 (EEST) From: Pekka Savola To: Thomas Narten cc: , Sean Doran Subject: Re: Pseudo "last call" for draft-ietf-ipngwg-ipv6-2260-02.txt In-Reply-To: <200107272055.QAA01999@rotala.raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 27 Jul 2001, Thomas Narten wrote: > The document "IPv6 multihoming support at site exit routers" > came out of the IPng WG, which > has requested that it be published as an informational RFC. Given that > the subject of the draft overlaps with the main focus of this group, > we'd be interested in getting WG feedback on the contents of the > document. Namely: > > - is the document reasonable to publish as an informational RFC as > is, or are some specific changes appropriate? > > - How feasible do the techniques described in the document appear to > be from the perspective of an operator? > > - What are the main (if any) limitations to using the described > techniques from an operational perspective? Are these limitations, > if any, adequately described in the document? > > Explicit feedback (including "looks fine to me") from all those who > read it would be helpful. Personally, I find the approach workable in theory but rather awkward in practise; I don't see one's upstream operator(s) jumping with joy if they'd have to set up and operate a rather extensive "link backup service", co-operating with their competitors. In an academic, no-money-exchanged world this probably works better. These are in reality rather big operational and management issues, and I believe should be stated more clearly. So, I'm a little sceptic of the wide-spread value of this, but the idea is interesting and worth an informational RFC. I think _explicit_ Goals should be stated more clearly (as non-goals have been); as far as I can see, this method protects against ISP link failure and your edge router failure. "Why should I use this mechanism?" if I may. -- 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 Sun Jul 29 10:49:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22600 for ; Sun, 29 Jul 2001 10:49:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Qoun-000IkN-00 for multi6-data@psg.com; Sun, 29 Jul 2001 04:39:21 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.31 #1) id 15Qoum-000Ija-00 for multi6@ops.ietf.org; Sun, 29 Jul 2001 04:39:20 -0700 From: Masataka Ohta Message-Id: <200107291132.UAA07933@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id UAA07933; Sun, 29 Jul 2001 20:32:40 +0900 Subject: Re: WG Docs & Call for Agenda Items In-Reply-To: <200107272042.QAA01929@rotala.raleigh.ibm.com> from Thomas Narten at "Jul 27, 2001 04:42:21 pm" To: Thomas Narten Date: Sun, 29 Jul 2001 20:32:40 +0859 () CC: multi6@ops.ietf.org, Sean Doran X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-multi6@ops.ietf.org Precedence: bulk Thomas and Sean; > Multi6 has been assigned a 1-hour slot in London, tentatively > scheduled for the first Tuesday afternoon slot. If you wish to have > some agenda time, please let Sean and I know. I wish to have some agenda time for discussions on: draft-ohta-e2e-multihoming-02.txt The Architecture of End to End Multihoming Masataka Ohta From owner-multi6@ops.ietf.org Mon Jul 30 12:22:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03074 for ; Mon, 30 Jul 2001 12:22:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15RFY0-0004jk-00 for multi6-data@psg.com; Mon, 30 Jul 2001 09:05:36 -0700 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by psg.com with esmtp (Exim 3.31 #1) id 15RFXz-0004jL-00 for multi6@ops.ietf.org; Mon, 30 Jul 2001 09:05:36 -0700 Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6UG4f317337; Mon, 30 Jul 2001 09:04:41 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f6UFvYk02257; Mon, 30 Jul 2001 08:57:34 -0700 (PDT) Received: from chuegen-sun.cisco.com (chuegen-sun.cisco.com [171.71.80.88]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id IAA26895; Mon, 30 Jul 2001 08:57:33 -0700 (PDT) Received: from localhost (chuegen@localhost) by chuegen-sun.cisco.com (8.11.0/8.11.0) with ESMTP id f6UFvXp17994; Mon, 30 Jul 2001 08:57:33 -0700 (PDT) X-Authentication-Warning: chuegen-sun.cisco.com: chuegen owned process doing -bs Date: Mon, 30 Jul 2001 08:57:33 -0700 (PDT) From: "Craig A. Huegen" To: Pekka Savola cc: Thomas Narten , , Sean Doran Subject: Re: Pseudo "last call" for draft-ietf-ipngwg-ipv6-2260-02.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 29 Jul 2001, Pekka Savola wrote: > Personally, I find the approach workable in theory but rather awkward in > practise; I don't see one's upstream operator(s) jumping with joy if > they'd have to set up and operate a rather extensive "link backup > service", co-operating with their competitors. In an academic, > no-money-exchanged world this probably works better. From an enterprise end-user point of view, this approach adds more confusion to a solution that already has major concerns. The number 1 concern that we have to deal with in this multihoming scheme is the path selection by the originating TCP stack through its selection of source and destination addresses. The tunnel adds a kludge under the guise of resiliency. It will be hell to troubleshoot in case of a failure of the primary link, and has the potential to introduce a suboptimal path that would be better addressed through utilizing another provider. /cah --- Craig A. Huegen CCIE #2100 C i s c o S y s t e m s Sr Network Architect, GCTS || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Mon Jul 30 13:05:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07094 for ; Mon, 30 Jul 2001 13:05:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15RG1z-0005Q5-00 for multi6-data@psg.com; Mon, 30 Jul 2001 09:36:35 -0700 Received: from evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net ([4.60.69.141] helo=smtp.tndh.net) by psg.com with esmtp (Exim 3.31 #1) id 15RG1y-0005Py-00 for multi6@ops.ietf.org; Mon, 30 Jul 2001 09:36:34 -0700 Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Mon, 30 Jul 2001 09:35:16 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 5DFA09AA4AC94ED5BFFD893459036233 for plus 2 more; Mon, 30 Jul 2001 09:35:15 -0700 Reply-To: From: "Tony Hain" To: "Thomas Narten" , Cc: "Sean Doran" Subject: RE: WG Docs & Call for Agenda Items Date: Mon, 30 Jul 2001 09:35:15 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200107272042.QAA01929@rotala.raleigh.ibm.com> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-SLUIDL: B1955F08-DCE243D3-84A99444-B3F26675 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA07094 I am willing to lead a short discussion on draft-hain-ipv6-pi-addr-00.txt & draft-hain-ipv6-pi-addr-use-00.txt. Tony -----Original Message----- From: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]On Behalf Of Thomas Narten Sent: Friday, July 27, 2001 1:42 PM To: multi6@ops.ietf.org Cc: Sean Doran Subject: WG Docs & Call for Agenda Items Multi6 has been assigned a 1-hour slot in London, tentatively scheduled for the first Tuesday afternoon slot. If you wish to have some agenda time, please let Sean and I know. We have two WG documents that will likely see some discussion: draft-ietf-multi6-multihoming-requirements-01.txt draft-ietf-multi6-v4-multihoming-00.txt There has been quite a lot of discussion on the requirements document, I'll leave it to the authors to summarize the next steps/open issues. The second document has seen only a bit of discussion. Does that mean everyone thinks its already fine and dandy? Either way, I'm sure the authors would welcome additional feedback. Thomas (as multi6 co-chair) From owner-multi6@ops.ietf.org Tue Jul 31 12:12:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23766 for ; Tue, 31 Jul 2001 12:12:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Rc5i-000AMv-00 for multi6-data@psg.com; Tue, 31 Jul 2001 09:09:54 -0700 Received: from fwns2d.raleigh.ibm.com ([204.146.167.236] helo=fwns2.raleigh.ibm.com) by psg.com with esmtp (Exim 3.31 #1) id 15Rc5g-000AME-00 for multi6@ops.ietf.org; Tue, 31 Jul 2001 09:09:53 -0700 Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA28964 for ; Tue, 31 Jul 2001 12:03:37 -0400 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id MAA33426 for ; Tue, 31 Jul 2001 12:09:21 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id MAA11925 for ; Tue, 31 Jul 2001 12:07:45 -0400 Message-Id: <200107311607.MAA11925@rotala.raleigh.ibm.com> To: multi6@ops.ietf.org Subject: Multi6 London Agenda Date: Tue, 31 Jul 2001 12:07:45 -0400 From: Thomas Narten Sender: owner-multi6@ops.ietf.org Precedence: bulk Site Multihoming in IPv6 (multi6) Chair(s): Sean Doran Thomas Narten What: Meeting in London When: Tuesday Afternoon I (1 hour) Location: Palace Suite/Blenheim (tentative) Proposed Agenda Intro (5 min) "Vijay Gill" (15 min) draft-ietf-multi6-multihoming-requirements-01.txt draft-ietf-multi6-v4-multihoming-00.txt "Tony Hain" (15 min) draft-hain-ipv6-pi-addr-00.txt draft-hain-ipv6-pi-addr-use-00.txt. "Howard C. Berkowitz" (15 min) draft-berkowitz-multireq-02.txt Fumio Teraoka (5 min) draft-teraoka-ipng-lin6-01.txt Wrapup (5 min) Thomas From owner-multi6@ops.ietf.org Tue Jul 31 20:39:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA09433 for ; Tue, 31 Jul 2001 20:39:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Rk2v-000Ljw-00 for multi6-data@psg.com; Tue, 31 Jul 2001 17:39:33 -0700 Received: from coconut.itojun.org ([210.160.95.97]) by psg.com with esmtp (Exim 3.31 #1) id 15Rk2u-000Ljm-00 for multi6@ops.ietf.org; Tue, 31 Jul 2001 17:39:32 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 964DF4B20 for ; Wed, 1 Aug 2001 09:39:22 +0900 (JST) X-UIDL: ("^"!e;n!!^8i!!0`<"! Delivered-To: itojun@coconut.itojun.org Received: from starfruit.itojun.org (unknown [3ffe:501:4819:abcd:202:2dff:fe0f:f845]) by coconut.itojun.org (Postfix) with ESMTP id B8DFD4B20 for ; Wed, 1 Aug 2001 09:01:09 +0900 (JST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id F3CBA7BC; Wed, 1 Aug 2001 09:00:28 +0900 (JST) To: Thomas Narten , Sean Doran In-reply-to: agenda's message of Tue, 31 Jul 2001 14:16:26 -0400. <200107311816.OAA05257@ietf.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: 51st IETF - Site Multihoming in IPv6 WG (multi6) From: Jun-ichiro itojun Hagino Date: Wed, 01 Aug 2001 09:00:28 +0900 Message-Id: <20010801000029.F3CBA7BC@starfruit.itojun.org> X-Filter: mailagent [version 3.0 PL73] for itojun@itojun.org Status: RO Sender: owner-multi6@ops.ietf.org Precedence: bulk I have already asked you (like 2 weeks ago) to include the following into the agenda: draft-ietf-ipngwg-ipv6-2260-02.txt please give me 5 minute. itojun >Site Multihoming in IPv6 WG (multi6) >Tuesday, August 07 at 1300-1400 >================================ >AGENDA: > >Intro (5 min) > >"Vijay Gill" (15 min) > draft-ietf-multi6-multihoming-requirements-01.txt > draft-ietf-multi6-v4-multihoming-00.txt > >"Tony Hain" (15 min) > draft-hain-ipv6-pi-addr-00.txt > draft-hain-ipv6-pi-addr-use-00.txt. > >"Howard C. Berkowitz" (15 min) > draft-berkowitz-multireq-02.txt > >Fumio Teraoka (5 min) > draft-teraoka-ipng-lin6-01.txt > >Wrapup (5 min) > > From owner-multi6@ops.ietf.org Tue Jul 31 21:34:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13407 for ; Tue, 31 Jul 2001 21:34:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15RkuY-000MsZ-00 for multi6-data@psg.com; Tue, 31 Jul 2001 18:34:58 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.31 #1) id 15RkuX-000MsO-00 for multi6@ops.ietf.org; Tue, 31 Jul 2001 18:34:57 -0700 From: Masataka Ohta Message-Id: <200108010128.KAA11589@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA11589; Wed, 1 Aug 2001 10:28:35 +0900 Subject: Re: Multi6 London Agenda In-Reply-To: <200107311607.MAA11925@rotala.raleigh.ibm.com> from Thomas Narten at "Jul 31, 2001 12:07:45 pm" To: Thomas Narten Date: Wed, 1 Aug 2001 10:28:34 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-multi6@ops.ietf.org Precedence: bulk Thomas; > Site Multihoming in IPv6 (multi6) > Proposed Agenda Why can't you allocate time for my draft? Masataka Ohta From mohta Sun Jul 29 20:32:39 2001 Subject: Re: WG Docs & Call for Agenda Items In-Reply-To: <200107272042.QAA01929@rotala.raleigh.ibm.com> from Thomas Narten at "Jul 27, 2001 04:42:21 pm" To: Thomas Narten Date: Sun, 29 Jul 2001 20:32:39 +0859 () CC: multi6@ops.ietf.org, Sean Doran X-Mailer: ELM [version 2.4ME+ PL68 (25)] Content-Length: 356 Status: OR Thomas and Sean; > Multi6 has been assigned a 1-hour slot in London, tentatively > scheduled for the first Tuesday afternoon slot. If you wish to have > some agenda time, please let Sean and I know. I wish to have some agenda time for discussions on: draft-ohta-e2e-multihoming-02.txt The Architecture of End to End Multihoming Masataka Ohta