From memsvcs at arin.net Mon Jun 5 11:18:17 2006 From: memsvcs at arin.net (Member Services) Date: Mon, 05 Jun 2006 11:18:17 -0400 Subject: [ppml] Proposed Policy: Recommended v6 aggregation practices - not accepted by AC as formal policy proposal Message-ID: <44844B39.6050800@arin.net> On May 25, 2006, the ARIN Advisory Council (AC) concluded its review of the proposed policy 'Recommended v6 aggregation practices' and did not accept it as a formal policy proposal. "It is the sense of the Advisory Council that while this does not belong in the Number Resource Policy Manual this is a good idea to pursue. As this type of information is not normally developed in the ARIN forum, the members of ARIN should decide whether this should be done by ARIN or should be developed in another forum with encouragement from ARIN." During the initial review period the AC may decide to: 1) Accept the proposal as a formal policy proposal as it is presented, 2) Work with the author to clarify, divide or combine it with another proposal, or 3) Not accept the policy proposal. In the event that the AC decides not to accept the proposed policy, then the author may elect to use the petition process to advance the proposal. For petition details see the section called "Petition Process" in the ARIN Internet Resource Policy Evaluation Process which can be found at: http://www.arin.net/policy/irpep.html The deadline for the author to initiate a petition per the ARIN Internet Resource Policy Evaluation Process is 40 days prior to the meeting; the petition deadline for the ARIN XVIII Public Policy Meeting is September 1, 2006. If the author chooses not to petition or the petition is unsuccessful, then the proposed policy is closed. If a petition is successful, then the proposal will be numbered and posted for discussion and presented at ARIN's Public Policy Meeting. The proposed policy text can be found at: http://lists.arin.net/pipermail/ppml/2006-May/005555.html Regards, Member Services American Registry for Internet Numbers (ARIN) From memsvcs at arin.net Mon Jun 5 11:19:20 2006 From: memsvcs at arin.net (Member Services) Date: Mon, 05 Jun 2006 11:19:20 -0400 Subject: [ppml] Proposed Policy: Requirement for Reasonable Contract Terms - not accepted by AC as formal policy proposal Message-ID: <44844B78.1040602@arin.net> On May 25, 2006, the ARIN Advisory Council (AC) concluded its review of the proposed policy 'Requirement for Reasonable Contract Terms' and did not accept it as a formal policy proposal. "It is the sense of the Advisory Council that this is a matter that can best be addressed by the ARIN Board of Trustees. The AC requests that the ARIN President refer the matter to the ARIN Board of Trustees." During the initial review period the AC may decide to: 1) Accept the proposal as a formal policy proposal as it is presented, 2) Work with the author to clarify, divide or combine it with another proposal, or 3) Not accept the policy proposal. In the event that the AC decides not to accept the proposed policy, then the author may elect to use the petition process to advance the proposal. For petition details see the section called "Petition Process" in the ARIN Internet Resource Policy Evaluation Process which can be found at: http://www.arin.net/policy/irpep.html The deadline for the author to initiate a petition per the ARIN Internet Resource Policy Evaluation Process is 40 days prior to the meeting; the petition deadline for the ARIN XVIII Public Policy Meeting is September 1, 2006. If the author chooses not to petition or the petition is unsuccessful, then the proposed policy is closed. If a petition is successful, then the proposal will be numbered and posted for discussion and presented at ARIN's Public Policy Meeting. The proposed policy text can be found at: http://lists.arin.net/pipermail/ppml/2006-May/005614.html Regards, Member Services American Registry for Internet Numbers (ARIN) From memsvcs at arin.net Mon Jun 5 12:55:34 2006 From: memsvcs at arin.net (Member Services) Date: Mon, 05 Jun 2006 12:55:34 -0400 Subject: [ppml] Policy Implementation Schedule Message-ID: <44846206.8050103@arin.net> On May 9, 2006 the ARIN Board of Trustees adopted several policy proposals. These proposals and their expected implementation dates are listed below. * 2005-1: Provider-independent IPv6 Assignments for End Sites - Not later than Friday, 1 Sep 2006. * 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement - Not later than Friday, 1 Sep 2006. * 2005-9: 4-Byte AS Number - According to the schedule within the policy. As final implementation details are determined exact implementation dates of these policies will be published. Policy proposal texts are available at the Policy Proposal Archive which can be found at: http://www.arin.net/policy/proposal_archive.html Regards, Member Services Department American Registry for Internet Numbers From memsvcs at arin.net Wed Jun 7 10:32:23 2006 From: memsvcs at arin.net (Member Services) Date: Wed, 07 Jun 2006 10:32:23 -0400 Subject: [ppml] LACNIC IX Report Message-ID: <4486E377.1070909@arin.net> Members of the ARIN staff attended the recent LACNIC meeting. We offer you the following brief report of that meeting. Regards, Member Services American Registry for Internet Numbers (ARIN) LACNIC IX - Guatemala City - 22-26 May 2006 LACNIC IX took place in Guatemala City on 22-26 May 2006. There were about 180 participants from 26 countries. Some of the activities during the first three days of the meeting included: the LACTLD Member Meeting, a Tutorial on Network Security, NAPLA 2006, the first Network Security Event in Latin America and the Caribbean, and FLIP-6 and the IPv6 TF LAC. Thursday morning was the LACNIC Annual Members Meeting. The Open Policy Forum was Thursday afternoon and Friday morning. During the LACNIC Members meeting the Annual Report was unanimously approved. The LACNIC attorney gave a report on electronic voting; the LACNIC bylaws would need to be updated to allow electronic voting by remote participants in the meeting. The members voted to undertake the work necessary to present draft bylaws prior to the next meeting. A proposal to lower fees for medium, small and micro categories by 5, 10, and 15% respectively was approved. Also approved was a proposal to give a 50% discount to qualifying non-profit organizations. Nine policy proposals were presented during the LACNIC Open Policy Forum. The following list indicates if consensus was found to move them forward to last call. Note that per the LACNIC Policy Development Process all the proposals that moved forward will be posted to 45 days of last call for comments. * The proposal on Resource Recovery (unused resources) was moved forward. * The proposal on WHOIS Privacy was not moved forward (this would have allowed ISPs to request that reassignment data not be displayed). * The proposal to amend the Micro-Allocations to Critical Infrastructure policy was given as an informational presentation and should come back to the next meeting. This proposal is to clarify that both micro-allocations and micro-assignments can be made. * The proposal regarding the IPv6 HD Ratio (changing from .8 to .94) was moved forward. * The proposal called Size of IPv6 Assignments (adding /56 as a default and basing utilization on /56s) did not move forward at this time (a revised version was requested for the next meeting). * The proposal for IPv6 for End Users did not move forward at this time (a revised version was requested for the next meeting). * The proposal for basing IPv4 utilization on the HD Ratio was presented. It was noted that there was no support for this on the list and therefore evaluation at the meeting was not required. * The proposal for extending the timeframe for allocations from 3 months to one year was moved forward. * And finally, the proposal for 32-Bit ASNs was moved forward. Lastly, during the Open Policy Forum, Sebastian Bellagamba was reelected to the ASO AC for three more years and Christian O'Flaherty was reelected to Chair the Open Policy Forum for another two years. From memsvcs at arin.net Wed Jun 7 10:33:39 2006 From: memsvcs at arin.net (Member Services) Date: Wed, 07 Jun 2006 10:33:39 -0400 Subject: [ppml] AfriNIC 4 Report Message-ID: <4486E3C3.1020102@arin.net> Members of the ARIN staff attended the recent AfriNIC meeting. We offer you the following brief report of that meeting. Regards, Member Services American Registry for Internet Numbers (ARIN) AfriNIC 4 - Nairobi, Kenya - 16-17 May 2006 AfriNIC 4 took place in Nairobi, Kenya on 16-17 May 2006. It followed the AfNOG meeting. Some of the topics discussed during the AfriNIC meeting included resource certification, development of the My AfriNIC site (the trial is to begin in June of this year), bogon testing of 41/8, and policy proposals. Policies recently adopted by the AfriNIC Board consisted of the following: An end user assignment policy (/24 minimum), a policy for temporary/critical infrastructure assignments, an ASN criteria policy (requestors must be members in good standing), and the proposed global policy on IPv6 Allocations from IANA to the RIRs. Policy proposals presented at AfriNIC 4 included the following. There was a proposal for 4-byte ASNs; this appears to be moving forward to last call. There was also a proposal for PI IPv6 assignments to end sites. This proposal appears to be going back to the list for further discussion. Proposals moving forward are posted for 15 days of last call to the AfriNIC policy mailing list. Elections occurred during the Member Meeting; the following were elected to the AfriNIC Board: Eastern Region: Ntege Badru (Primary) and Brian Longwe (Alternate). Southern Region: Alan Barret (Primary) and Almada Sylvio (Alternate). From Michael.Dillon at btradianz.com Tue Jun 20 04:51:38 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 20 Jun 2006 09:51:38 +0100 Subject: [ppml] IAB Routing and Addressing workshop Message-ID: The IAB is organizing a Routing and Addressing workshop in the Fall of 2006. Since that topic has gotten a lot of airplay on PPML I am copying the announcement that was made on the NANOG list. ------ Greetings, The IAB is sponsoring a workshop on "Scalable Routing and Addressing Architectures for the Internet" in order to foster interchange between the operator, standards, vendor, and research communities on this important topic. You are being invited to participate in this effort. This workshop effort will consist of mailing list discussions in advance of, and after a face to face meeting. The technical goals of this effort are outlined below. We believe these are the critical elements to fostering a constructive discussion of important routing and addressing technical work going forward and are soliciting workshop participation to work towards those goals. Should you decide to join us in this workshop, you will be expected to attend the face to face meeting [0], contribute to (and possibly present at) that meeting, as well as follow and participate in the mailing list discussions. The most important objective of the workshop is to foster and encourage innovative thinking in an area where there has been little fundamental change for the last twelve years. As such, the primary goals of the workshop include the following two items: (i). Produce a concise problem statement that will serve as the input to future work on this topic. This problem statement will include, among other things, a list of the problems with the current routing and addressing architecture. These include (but are not limited to): - The difficulty in changing provider due to PA/CIDR addressing schemes - The lack of effective multi-homing support - Limited capability to protect against either the spoofing of individual host IP addresses or entire IP address blocks - The limited ability to secure the routing system itself, and (ii). Produce a prioritized list of requirements, all of which must be met by a next generation routing and addressing architecture. A sample list might include (in no particular order): - Retaining the connectionless datagram model of IP routing - Allow users (small and large) to freely switch between providers without substantial service interruption - Include survival of higher-layer connections and associations when connectivity to individual providers changes - Allow both users and ISPs to influence path selection according to traffic management and classification requirements - Provide better support for mobility and nomadicity - Provide architected instrumentation facilities - Allow at least one-to-many multicast - Prevent source address spoofing - Provide a rational economic basis for deployment - Secure the routing infrastructure, including the authentication of updates and the unauthorized injection of information into the routing system - Define scalability requirements for a next generation routing system - Have architected transition mechanisms and be incrementally deployable (where possible) During the workshop, scribes will be assigned to summarize the discussion. Post-workshop, scribes will be expected to participate in finalizing the workshop report. All participants will be expected to review the draft workshop report before publication. The workshop is Another thing to consider that I learned recently about privacy (or the illusion thereof)... If you are registered to vote, then, your registered name, address, telephone number, voting history (which elections you voted in) are available to the following people: 1. Any candidate running for office. 2. Any volunteer or staff the candidate chooses to give the information to. 3. Anyone who wants to read the information off of the posted voter rolls at each polling place. 4. Virtually anyone working, volunteering, or interning in the registrar of voters office. Given that, I don't think having your City, State, and Zip in the whois database in exchange for getting a block of more than 8 IPs is an unreasonable compromise. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From dmm at 1-4-5.net Tue Jun 20 11:22:56 2006 From: dmm at 1-4-5.net (David Meyer) Date: Tue, 20 Jun 2006 08:22:56 -0700 Subject: [ppml] IAB Routing and Addressing workshop In-Reply-To: References: Message-ID: <20060620152256.GA1296@1-4-5.net> On Tue, Jun 20, 2006 at 09:51:38AM +0100, Michael.Dillon at btradianz.com wrote: > The IAB is organizing a Routing and Addressing workshop in the > Fall of 2006. Since that topic has gotten a lot of airplay on PPML > I am copying the announcement that was made on the NANOG > list. Michael, Thanks for the posting here. If folks have ideas about who might be useful participants, please let me know. --dmm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Michael.Dillon at btradianz.com Wed Jun 21 07:50:50 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 21 Jun 2006 12:50:50 +0100 Subject: [ppml] IAB Routing and Addressing workshop In-Reply-To: <20060620152256.GA1296@1-4-5.net> Message-ID: David Meyer wrote on 20/06/2006 16:22:56: > > The IAB is organizing a Routing and Addressing workshop in the > Thanks for the posting here. If folks have ideas about > who might be useful participants, please let me > know. Unfortunately my posting was lacking a key bit of information. If anyone wants to send a REPLY to the IAB in regards to this message, you should either send it to David (his email is above) or hunt down the IAB website. I am just a messenger. --Michael Dillon From marc.blanchet at viagenie.ca Sun Jun 25 20:47:17 2006 From: marc.blanchet at viagenie.ca (Marc Blanchet) Date: Sun, 25 Jun 2006 20:47:17 -0400 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <200604252116.k3PLGb5D006787@cichlid.raleigh.ibm.com> References: <200604252116.k3PLGb5D006787@cichlid.raleigh.ibm.com> Message-ID: <16DC4FFB-E1B3-4658-937A-919415AEA4B9@viagenie.ca> Hi, I've submitted the first version of following document more than a year ago as an individual submission to IETF. This came from earlier discussion on a need of this kind of document for providers/ enterprises who start IPv6 deployment and also to obsolete the 6bone routing guidelines document which people still were referring to. The document has been accepted as v6ops wg document back in Dallas (march 2006). Thomas Narten told me that I should look at arin-ppml since there was some similarity with a arin-ppml thread. Please have a look at this not-yet-finished document. It will be discussed during IETF Montr?al v6ops wg meeting. BTW, the first version of it (under draft-blanchet-v6ops-...) had words on prefix length to advertise but was pushed back by one person, so I remove it then. However, I do believe some wording should be back there on prefix length and related issues. Please comment to me or v6ops mailing list. From: Internet-Drafts at ietf.org Subject: I-D ACTION:draft-ietf-v6ops-routing-guidelines-00.txt Date : 19 juin 2006 15:50:02 HAE To : i-d-announce at ietf.org Cc : v6ops at ops.ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Routing Policies Guidelines Author(s) : M. Blanchet Filename : draft-ietf-v6ops-routing-guidelines-00.txt Pages : 8 Date : 2006-6-19 Guidelines on how to manage IPv6 routes are needed for operators of networks, either providers or enterprises. This document is a followup on RFC2772 work but for the production IPv6 Internet. RFC2772 becomes historic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-routing- guidelines-00.txt Marc. Le 06-04-25 ? 17:16, Thomas Narten a ?crit : > "Tony Li" writes: > >>> What I see frustrating here is that everyone agrees we need >>> some sort of "internet community agreement" that addresses V6 >>> routing. I hear alot of people asking for this, including >>> myself. Yet I dont hear any specific forum stepping forward >>> to help facilitate this need. > >> What you're asking for is a "routing and addressing architecture". >> Currently, it's really the purview of the IETF, except that they've >> basically abdicated the role. This creates a vacuum, which, as >> you note >> cries out to be filled. There are multiple ways to make progress >> here, >> but my favorite is for ARIN to simply push the problem back to the >> IETF >> and insist on a sensible and scalable solution. > > I think that what people want has a lot to do with operations and > operational practices, an area the IETF struggles with at times. There > is v6ops WG in the IETF: > > http://www.ietf.org/html.charters/v6ops-charter.html > > Reading the charter, my takes is that what I think I'm hearing people > calling for (best practices on things like route filters, is > deaggration allowed or not and under what conditions, etc., etc.) > would be in-scope there. > > Maybe it's time to approach that group (and the ADs), see if there is > a willingness to take on such work in the IETF. What they will want to > see is a critical mass of folk agreeing on the work that needs to be > done (i.e., what kind of document and what is in it) and assurance > that there are enough volunteers to do the actual work. Even if the > work is "officially" housed there, there is no reason why the work > couldn't also be discussed in the various RIR and operations > groups. > > I think the IETF would be as good a place as any to try and do this > work. (And I'm willing to help make this happen if people think this > is worth pursuing.) > > Thomas > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml ========= IPv6 book: Migrating to IPv6, Wiley, 2006. http://www.ipv6book.ca From marla_azinger at eli.net Wed Jun 28 15:51:10 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Wed, 28 Jun 2006 12:51:10 -0700 Subject: [ppml] "Recommended Practices" procedure Message-ID: <10ECB7F03C568F48B9213EF9E7F790D202100D60@wava00s2ke2k01.corp.pvt> In response to Marc and his much needed document, I posted the following to the V6 ops WG discussion email list. Hello- I have reviewed Marc Blanchets document on IP V6 Routing Policy Guidelines Filename: draft-ietf-v6ops-routing-guidelines-00.txt I am concerned that the current draft does not include detailed routing guidelines for multihoming. This document does not include guidelines for multihoming in the current V6 routing framework. V6 can be used identically like V4 to do multihoming and this is what I would like to do with V6. I currently have customers asking for this ability and none of them wish to wait for solutions that may not be fully developed for a couple more years. Also, my customers don't want to get PI space (even under the new V6 PI policy), so this means I need to give them a /48 and set up multihoming. However, as all policy and practices sit right now, everyone filters on a /32. I ask the V6 WG to create a "best practice for multihoming" that can be utilized today. I ask that you please insert the solution to filter at /48 thus allowing "upstream providers" to provide multihoming to their customers. This solution is needed to support providers creating V6 networks and this solution can easily be added into Marc's "IP V6 Routing Policy Guidelines" document. Thank you for your time Marla Azinger IP Engineering Frontier Communications -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Marc Blanchet Sent: Sunday, June 25, 2006 5:47 PM To: ppml at arin.net Subject: Re: [ppml] "Recommended Practices" procedure Hi, I've submitted the first version of following document more than a year ago as an individual submission to IETF. This came from earlier discussion on a need of this kind of document for providers/ enterprises who start IPv6 deployment and also to obsolete the 6bone routing guidelines document which people still were referring to. The document has been accepted as v6ops wg document back in Dallas (march 2006). Thomas Narten told me that I should look at arin-ppml since there was some similarity with a arin-ppml thread. Please have a look at this not-yet-finished document. It will be discussed during IETF Montr?al v6ops wg meeting. BTW, the first version of it (under draft-blanchet-v6ops-...) had words on prefix length to advertise but was pushed back by one person, so I remove it then. However, I do believe some wording should be back there on prefix length and related issues. Please comment to me or v6ops mailing list. From: Internet-Drafts at ietf.org Subject: I-D ACTION:draft-ietf-v6ops-routing-guidelines-00.txt Date : 19 juin 2006 15:50:02 HAE To : i-d-announce at ietf.org Cc : v6ops at ops.ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Routing Policies Guidelines Author(s) : M. Blanchet Filename : draft-ietf-v6ops-routing-guidelines-00.txt Pages : 8 Date : 2006-6-19 Guidelines on how to manage IPv6 routes are needed for operators of networks, either providers or enterprises. This document is a followup on RFC2772 work but for the production IPv6 Internet. RFC2772 becomes historic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-routing- guidelines-00.txt Marc. Le 06-04-25 ? 17:16, Thomas Narten a ?crit : > "Tony Li" writes: > >>> What I see frustrating here is that everyone agrees we need >>> some sort of "internet community agreement" that addresses V6 >>> routing. I hear alot of people asking for this, including >>> myself. Yet I dont hear any specific forum stepping forward >>> to help facilitate this need. > >> What you're asking for is a "routing and addressing architecture". >> Currently, it's really the purview of the IETF, except that they've >> basically abdicated the role. This creates a vacuum, which, as >> you note >> cries out to be filled. There are multiple ways to make progress >> here, >> but my favorite is for ARIN to simply push the problem back to the >> IETF >> and insist on a sensible and scalable solution. > > I think that what people want has a lot to do with operations and > operational practices, an area the IETF struggles with at times. There > is v6ops WG in the IETF: > > http://www.ietf.org/html.charters/v6ops-charter.html > > Reading the charter, my takes is that what I think I'm hearing people > calling for (best practices on things like route filters, is > deaggration allowed or not and under what conditions, etc., etc.) > would be in-scope there. > > Maybe it's time to approach that group (and the ADs), see if there is > a willingness to take on such work in the IETF. What they will want to > see is a critical mass of folk agreeing on the work that needs to be > done (i.e., what kind of document and what is in it) and assurance > that there are enough volunteers to do the actual work. Even if the > work is "officially" housed there, there is no reason why the work > couldn't also be discussed in the various RIR and operations > groups. > > I think the IETF would be as good a place as any to try and do this > work. (And I'm willing to help make this happen if people think this > is worth pursuing.) > > Thomas > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml ========= IPv6 book: Migrating to IPv6, Wiley, 2006. http://www.ipv6book.ca _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From ipgoddess at gmail.com Wed Jun 28 15:59:44 2006 From: ipgoddess at gmail.com (Stacy Taylor) Date: Wed, 28 Jun 2006 12:59:44 -0700 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D202100D60@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D202100D60@wava00s2ke2k01.corp.pvt> Message-ID: <1c16a4870606281259k13281b4aqa1f583b1b1c6693c@mail.gmail.com> Hi Everyone! I am saving my more eloquent reply for the IETF list, but I support Marla's call for codification of the new bit boundary. We made the policy, now we have to make the practice. /Stacy Taylor TWTC On 6/28/06, Azinger, Marla wrote: > In response to Marc and his much needed document, I posted the following to the V6 ops WG discussion email list. > > Hello- I have reviewed Marc Blanchets document on IP V6 Routing Policy Guidelines Filename: draft-ietf-v6ops-routing-guidelines-00.txt > > I am concerned that the current draft does not include detailed routing guidelines for multihoming. This document does not include guidelines for multihoming in the current V6 routing framework. V6 can be used identically like V4 to do multihoming and this is what I would like to do with V6. > > I currently have customers asking for this ability and none of them wish to wait for solutions that may not be fully developed for a couple more years. Also, my customers don't want to get PI space (even under the new V6 PI policy), so this means I need to give them a /48 and set up multihoming. However, as all policy and practices sit right now, everyone filters on a /32. > > I ask the V6 WG to create a "best practice for multihoming" that can be utilized today. I ask that you please insert the solution to filter at /48 thus allowing "upstream providers" to provide multihoming to their customers. This solution is needed to support providers creating V6 networks and this solution can easily be added into Marc's "IP V6 Routing Policy Guidelines" document. > > Thank you for your time > Marla Azinger > IP Engineering > Frontier Communications > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > Marc Blanchet > Sent: Sunday, June 25, 2006 5:47 PM > To: ppml at arin.net > Subject: Re: [ppml] "Recommended Practices" procedure > > > Hi, > I've submitted the first version of following document more than a > year ago as an individual submission to IETF. This came from earlier > discussion on a need of this kind of document for providers/ > enterprises who start IPv6 deployment and also to obsolete the 6bone > routing guidelines document which people still were referring to. > The document has been accepted as v6ops wg document back in Dallas > (march 2006). Thomas Narten told me that I should look at arin-ppml > since there was some similarity with a arin-ppml thread. Please have > a look at this not-yet-finished document. It will be discussed > during IETF Montr?al v6ops wg meeting. > BTW, the first version of it (under draft-blanchet-v6ops-...) had > words on prefix length to advertise but was pushed back by one > person, so I remove it then. However, I do believe some wording > should be back there on prefix length and related issues. Please > comment to me or v6ops mailing list. > > From: Internet-Drafts at ietf.org > Subject: I-D ACTION:draft-ietf-v6ops-routing-guidelines-00.txt > Date : 19 juin 2006 15:50:02 HAE > To : i-d-announce at ietf.org > Cc : v6ops at ops.ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations Working Group of the > IETF. > > Title : IPv6 Routing Policies Guidelines > Author(s) : M. Blanchet > Filename : draft-ietf-v6ops-routing-guidelines-00.txt > Pages : 8 > Date : 2006-6-19 > > Guidelines on how to manage IPv6 routes are needed for operators of > networks, either providers or enterprises. This document is a > followup on RFC2772 work but for the production IPv6 Internet. > RFC2772 becomes historic. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-routing- > guidelines-00.txt > > > Marc. > > Le 06-04-25 ? 17:16, Thomas Narten a ?crit : > > > "Tony Li" writes: > > > >>> What I see frustrating here is that everyone agrees we need > >>> some sort of "internet community agreement" that addresses V6 > >>> routing. I hear alot of people asking for this, including > >>> myself. Yet I dont hear any specific forum stepping forward > >>> to help facilitate this need. > > > >> What you're asking for is a "routing and addressing architecture". > >> Currently, it's really the purview of the IETF, except that they've > >> basically abdicated the role. This creates a vacuum, which, as > >> you note > >> cries out to be filled. There are multiple ways to make progress > >> here, > >> but my favorite is for ARIN to simply push the problem back to the > >> IETF > >> and insist on a sensible and scalable solution. > > > > I think that what people want has a lot to do with operations and > > operational practices, an area the IETF struggles with at times. There > > is v6ops WG in the IETF: > > > > http://www.ietf.org/html.charters/v6ops-charter.html > > > > Reading the charter, my takes is that what I think I'm hearing people > > calling for (best practices on things like route filters, is > > deaggration allowed or not and under what conditions, etc., etc.) > > would be in-scope there. > > > > Maybe it's time to approach that group (and the ADs), see if there is > > a willingness to take on such work in the IETF. What they will want to > > see is a critical mass of folk agreeing on the work that needs to be > > done (i.e., what kind of document and what is in it) and assurance > > that there are enough volunteers to do the actual work. Even if the > > work is "officially" housed there, there is no reason why the work > > couldn't also be discussed in the various RIR and operations > > groups. > > > > I think the IETF would be as good a place as any to try and do this > > work. (And I'm willing to help make this happen if people think this > > is worth pursuing.) > > > > Thomas > > > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > > ========= > IPv6 book: Migrating to IPv6, Wiley, 2006. http://www.ipv6book.ca > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From randy at psg.com Wed Jun 28 17:38:36 2006 From: randy at psg.com (Randy Bush) Date: Wed, 28 Jun 2006 14:38:36 -0700 Subject: [ppml] "Recommended Practices" procedure References: <10ECB7F03C568F48B9213EF9E7F790D202100D60@wava00s2ke2k01.corp.pvt> <1c16a4870606281259k13281b4aqa1f583b1b1c6693c@mail.gmail.com> Message-ID: <17570.63196.556476.81581@roam.psg.com> > I am saving my more eloquent reply for the IETF list the ietf should not be doing policy. it took us years to get them out if the habit. randy From jason.schiller at mci.com Wed Jun 28 16:16:55 2006 From: jason.schiller at mci.com (Jason Schiller (schiller@uu.net)) Date: Wed, 28 Jun 2006 16:16:55 -0400 (EDT) Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <1c16a4870606281259k13281b4aqa1f583b1b1c6693c@mail.gmail.com> Message-ID: I agree that the draft should discuss "Recommended Practices". I feel this discussion should be driven by the service providers and their down stream commercial customers that actually have IPv4 multi-homing. At the very least the document should discuss the possibilities that range from only accept /32 or shorter PA prefixes, and no PI prefixes from Peers to allow everyone to de-aggregate down to the the /64, what the long term consequence of each policy is. ___Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Wed, 28 Jun 2006, Stacy Taylor wrote: > Date: Wed, 28 Jun 2006 12:59:44 -0700 > From: Stacy Taylor > To: "Azinger, Marla" > Cc: ppml at arin.net > Subject: Re: [ppml] "Recommended Practices" procedure > > Hi Everyone! > I am saving my more eloquent reply for the IETF list, but I support > Marla's call for codification of the new bit boundary. > We made the policy, now we have to make the practice. > /Stacy Taylor > TWTC > > On 6/28/06, Azinger, Marla wrote: > > In response to Marc and his much needed document, I posted the following to the V6 ops WG discussion email list. > > > > Hello- I have reviewed Marc Blanchets document on IP V6 Routing Policy Guidelines Filename: draft-ietf-v6ops-routing-guidelines-00.txt > > > > I am concerned that the current draft does not include detailed routing guidelines for multihoming. This document does not include guidelines for multihoming in the current V6 routing framework. V6 can be used identically like V4 to do multihoming and this is what I would like to do with V6. > > > > I currently have customers asking for this ability and none of them wish to wait for solutions that may not be fully developed for a couple more years. Also, my customers don't want to get PI space (even under the new V6 PI policy), so this means I need to give them a /48 and set up multihoming. However, as all policy and practices sit right now, everyone filters on a /32. > > > > I ask the V6 WG to create a "best practice for multihoming" that can be utilized today. I ask that you please insert the solution to filter at /48 thus allowing "upstream providers" to provide multihoming to their customers. This solution is needed to support providers creating V6 networks and this solution can easily be added into Marc's "IP V6 Routing Policy Guidelines" document. > > > > Thank you for your time > > Marla Azinger > > IP Engineering > > Frontier Communications > > > > -----Original Message----- > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > > Marc Blanchet > > Sent: Sunday, June 25, 2006 5:47 PM > > To: ppml at arin.net > > Subject: Re: [ppml] "Recommended Practices" procedure > > > > > > Hi, > > I've submitted the first version of following document more than a > > year ago as an individual submission to IETF. This came from earlier > > discussion on a need of this kind of document for providers/ > > enterprises who start IPv6 deployment and also to obsolete the 6bone > > routing guidelines document which people still were referring to. > > The document has been accepted as v6ops wg document back in Dallas > > (march 2006). Thomas Narten told me that I should look at arin-ppml > > since there was some similarity with a arin-ppml thread. Please have > > a look at this not-yet-finished document. It will be discussed > > during IETF Montr?al v6ops wg meeting. > > BTW, the first version of it (under draft-blanchet-v6ops-...) had > > words on prefix length to advertise but was pushed back by one > > person, so I remove it then. However, I do believe some wording > > should be back there on prefix length and related issues. Please > > comment to me or v6ops mailing list. > > > > From: Internet-Drafts at ietf.org > > Subject: I-D ACTION:draft-ietf-v6ops-routing-guidelines-00.txt > > Date : 19 juin 2006 15:50:02 HAE > > To : i-d-announce at ietf.org > > Cc : v6ops at ops.ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the IPv6 Operations Working Group of the > > IETF. > > > > Title : IPv6 Routing Policies Guidelines > > Author(s) : M. Blanchet > > Filename : draft-ietf-v6ops-routing-guidelines-00.txt > > Pages : 8 > > Date : 2006-6-19 > > > > Guidelines on how to manage IPv6 routes are needed for operators of > > networks, either providers or enterprises. This document is a > > followup on RFC2772 work but for the production IPv6 Internet. > > RFC2772 becomes historic. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-routing- > > guidelines-00.txt > > > > > > Marc. > > > > Le 06-04-25 ? 17:16, Thomas Narten a ?crit : > > > > > "Tony Li" writes: > > > > > >>> What I see frustrating here is that everyone agrees we need > > >>> some sort of "internet community agreement" that addresses V6 > > >>> routing. I hear alot of people asking for this, including > > >>> myself. Yet I dont hear any specific forum stepping forward > > >>> to help facilitate this need. > > > > > >> What you're asking for is a "routing and addressing architecture". > > >> Currently, it's really the purview of the IETF, except that they've > > >> basically abdicated the role. This creates a vacuum, which, as > > >> you note > > >> cries out to be filled. There are multiple ways to make progress > > >> here, > > >> but my favorite is for ARIN to simply push the problem back to the > > >> IETF > > >> and insist on a sensible and scalable solution. > > > > > > I think that what people want has a lot to do with operations and > > > operational practices, an area the IETF struggles with at times. There > > > is v6ops WG in the IETF: > > > > > > http://www.ietf.org/html.charters/v6ops-charter.html > > > > > > Reading the charter, my takes is that what I think I'm hearing people > > > calling for (best practices on things like route filters, is > > > deaggration allowed or not and under what conditions, etc., etc.) > > > would be in-scope there. > > > > > > Maybe it's time to approach that group (and the ADs), see if there is > > > a willingness to take on such work in the IETF. What they will want to > > > see is a critical mass of folk agreeing on the work that needs to be > > > done (i.e., what kind of document and what is in it) and assurance > > > that there are enough volunteers to do the actual work. Even if the > > > work is "officially" housed there, there is no reason why the work > > > couldn't also be discussed in the various RIR and operations > > > groups. > > > > > > I think the IETF would be as good a place as any to try and do this > > > work. (And I'm willing to help make this happen if people think this > > > is worth pursuing.) > > > > > > Thomas > > > > > > _______________________________________________ > > > PPML mailing list > > > PPML at arin.net > > > http://lists.arin.net/mailman/listinfo/ppml > > > > > > > > ========= > > IPv6 book: Migrating to IPv6, Wiley, 2006. http://www.ipv6book.ca > > > > > > > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From stephen at sprunk.org Wed Jun 28 20:20:40 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 28 Jun 2006 19:20:40 -0500 Subject: [ppml] "Recommended Practices" procedure References: <10ECB7F03C568F48B9213EF9E7F790D202100D60@wava00s2ke2k01.corp.pvt> <1c16a4870606281259k13281b4aqa1f583b1b1c6693c@mail.gmail.com> Message-ID: <041c01c69b12$8fc16290$6501a8c0@ssprunk> And here we find the slippery slope. A large part of the justification for (and defense of) PIv6 addressing was that the PAv6 address space would be filtered at /32 and the PIv6 space would be filtered at /48. If you want a /48 for multihoming, use the PIv6 policy to get a block. That's what it's for. IIRC, it's free if you have PIv4 space (and still cheap if you don't). Who in their right mind wouldn't want to do this? We should not be advocating as a "recommended practice" punching holes in CIDR space under any circumstances. If someone happens to find that it works, bully for them, but it's not supposed to and nobody should expect it to continue to work, much less be told it's the right thing to do. IMNSHO. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin ----- Original Message ----- From: "Stacy Taylor" To: "Azinger, Marla" Cc: Sent: Wednesday, June 28, 2006 14:59 Subject: Re: [ppml] "Recommended Practices" procedure > Hi Everyone! > I am saving my more eloquent reply for the IETF list, but I support > Marla's call for codification of the new bit boundary. > We made the policy, now we have to make the practice. > /Stacy Taylor > TWTC > > On 6/28/06, Azinger, Marla wrote: >> In response to Marc and his much needed document, I posted the following >> to the V6 ops WG discussion email list. >> >> Hello- I have reviewed Marc Blanchets document on IP V6 Routing Policy >> Guidelines Filename: draft-ietf-v6ops-routing-guidelines-00.txt >> >> I am concerned that the current draft does not include detailed routing >> guidelines for multihoming. This document does not include guidelines >> for multihoming in the current V6 routing framework. V6 can be used >> identically like V4 to do multihoming and this is what I would like to do >> with V6. >> >> I currently have customers asking for this ability and none of them wish >> to wait for solutions that may not be fully developed for a couple more >> years. Also, my customers don't want to get PI space (even under the new >> V6 PI policy), so this means I need to give them a /48 and set up >> multihoming. However, as all policy and practices sit right now, >> everyone filters on a /32. >> >> I ask the V6 WG to create a "best practice for multihoming" that can be >> utilized today. I ask that you please insert the solution to filter at >> /48 thus allowing "upstream providers" to provide multihoming to their >> customers. This solution is needed to support providers creating V6 >> networks and this solution can easily be added into Marc's "IP V6 Routing >> Policy Guidelines" document. >> >> Thank you for your time >> Marla Azinger >> IP Engineering >> Frontier Communications >> >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >> Marc Blanchet >> Sent: Sunday, June 25, 2006 5:47 PM >> To: ppml at arin.net >> Subject: Re: [ppml] "Recommended Practices" procedure >> >> >> Hi, >> I've submitted the first version of following document more than a >> year ago as an individual submission to IETF. This came from earlier >> discussion on a need of this kind of document for providers/ >> enterprises who start IPv6 deployment and also to obsolete the 6bone >> routing guidelines document which people still were referring to. >> The document has been accepted as v6ops wg document back in Dallas >> (march 2006). Thomas Narten told me that I should look at arin-ppml >> since there was some similarity with a arin-ppml thread. Please have >> a look at this not-yet-finished document. It will be discussed >> during IETF Montr?al v6ops wg meeting. >> BTW, the first version of it (under draft-blanchet-v6ops-...) had >> words on prefix length to advertise but was pushed back by one >> person, so I remove it then. However, I do believe some wording >> should be back there on prefix length and related issues. Please >> comment to me or v6ops mailing list. >> >> From: Internet-Drafts at ietf.org >> Subject: I-D ACTION:draft-ietf-v6ops-routing-guidelines-00.txt >> Date : 19 juin 2006 15:50:02 HAE >> To : i-d-announce at ietf.org >> Cc : v6ops at ops.ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the IPv6 Operations Working Group of the >> IETF. >> >> Title : IPv6 Routing Policies Guidelines >> Author(s) : M. Blanchet >> Filename : draft-ietf-v6ops-routing-guidelines-00.txt >> Pages : 8 >> Date : 2006-6-19 >> >> Guidelines on how to manage IPv6 routes are needed for operators of >> networks, either providers or enterprises. This document is a >> followup on RFC2772 work but for the production IPv6 Internet. >> RFC2772 becomes historic. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-routing- >> guidelines-00.txt >> >> >> Marc. >> >> Le 06-04-25 ? 17:16, Thomas Narten a ?crit : >> >> > "Tony Li" writes: >> > >> >>> What I see frustrating here is that everyone agrees we need >> >>> some sort of "internet community agreement" that addresses V6 >> >>> routing. I hear alot of people asking for this, including >> >>> myself. Yet I dont hear any specific forum stepping forward >> >>> to help facilitate this need. >> > >> >> What you're asking for is a "routing and addressing architecture". >> >> Currently, it's really the purview of the IETF, except that they've >> >> basically abdicated the role. This creates a vacuum, which, as >> >> you note >> >> cries out to be filled. There are multiple ways to make progress >> >> here, >> >> but my favorite is for ARIN to simply push the problem back to the >> >> IETF >> >> and insist on a sensible and scalable solution. >> > >> > I think that what people want has a lot to do with operations and >> > operational practices, an area the IETF struggles with at times. There >> > is v6ops WG in the IETF: >> > >> > http://www.ietf.org/html.charters/v6ops-charter.html >> > >> > Reading the charter, my takes is that what I think I'm hearing people >> > calling for (best practices on things like route filters, is >> > deaggration allowed or not and under what conditions, etc., etc.) >> > would be in-scope there. >> > >> > Maybe it's time to approach that group (and the ADs), see if there is >> > a willingness to take on such work in the IETF. What they will want to >> > see is a critical mass of folk agreeing on the work that needs to be >> > done (i.e., what kind of document and what is in it) and assurance >> > that there are enough volunteers to do the actual work. Even if the >> > work is "officially" housed there, there is no reason why the work >> > couldn't also be discussed in the various RIR and operations >> > groups. >> > >> > I think the IETF would be as good a place as any to try and do this >> > work. (And I'm willing to help make this happen if people think this >> > is worth pursuing.) >> > >> > Thomas >> > >> > _______________________________________________ >> > PPML mailing list >> > PPML at arin.net >> > http://lists.arin.net/mailman/listinfo/ppml >> >> >> >> ========= >> IPv6 book: Migrating to IPv6, Wiley, 2006. http://www.ipv6book.ca >> >> >> >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml >> _______________________________________________ >> PPML mailing list >> PPML at arin.net >> http://lists.arin.net/mailman/listinfo/ppml >> > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From pekkas at netcore.fi Thu Jun 29 01:03:22 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 29 Jun 2006 08:03:22 +0300 (EEST) Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <041c01c69b12$8fc16290$6501a8c0@ssprunk> References: <10ECB7F03C568F48B9213EF9E7F790D202100D60@wava00s2ke2k01.corp.pvt> <1c16a4870606281259k13281b4aqa1f583b1b1c6693c@mail.gmail.com> <041c01c69b12$8fc16290$6501a8c0@ssprunk> Message-ID: On Wed, 28 Jun 2006, Stephen Sprunk wrote: > We should not be advocating as a "recommended practice" punching holes in > CIDR space under any circumstances. If someone happens to find that it > works, bully for them, but it's not supposed to and nobody should expect it > to continue to work, much less be told it's the right thing to do. Amen to that. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From dlw+arin at tellme.com Thu Jun 29 01:28:40 2006 From: dlw+arin at tellme.com (David Williamson) Date: Wed, 28 Jun 2006 22:28:40 -0700 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <041c01c69b12$8fc16290$6501a8c0@ssprunk> References: <10ECB7F03C568F48B9213EF9E7F790D202100D60@wava00s2ke2k01.corp.pvt> <1c16a4870606281259k13281b4aqa1f583b1b1c6693c@mail.gmail.com> <041c01c69b12$8fc16290$6501a8c0@ssprunk> Message-ID: <20060629052840.GA10344@shell01.corp.tellme.com> On Wed, Jun 28, 2006 at 07:20:40PM -0500, Stephen Sprunk wrote: > We should not be advocating as a "recommended practice" punching holes in > CIDR space under any circumstances. If someone happens to find that it > works, bully for them, but it's not supposed to and nobody should expect it > to continue to work, much less be told it's the right thing to do. I agree. Depending on their configuration/hardware/sales people, some ISPs may choose to filter at /48 globally, while most will probably go for /32 except for the /48 PI space. I expect that at some future date, /48 will be the de facto filter unit. That will depend on the (slowly growing) availability of routing slots, combined with the market forces that drive ISPs. Routing best practice is to not do something that causes massive instability and your customer base to flee. This is a business problem, not a policy problem. -David From marla_azinger at eli.net Thu Jun 29 11:11:35 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Thu, 29 Jun 2006 08:11:35 -0700 Subject: [ppml] "Recommended Practices" procedure Message-ID: <10ECB7F03C568F48B9213EF9E7F790D202100D62@wava00s2ke2k01.corp.pvt> I hear many comments about "the slippery sloap". And "make them get PI if they want to multihome". However, my customer's dont want PI. Just because one person finds this as an ideal solution does not mean everyone will accept this solution. Also, a /48 is not a gigantic hole in the filtering opposed to /32. And to open up /48 for PI only is an unbalanced policy. If I had known people would be using PI as an excuse not to let Upstreams multihome with V6 I would have advocated to shut down that policy proposal. I support PI but for poeple to turn around and force feed PI is not acceptable. Marla Frontier Communications -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of David Williamson Sent: Wednesday, June 28, 2006 10:29 PM To: ppml at arin.net Subject: Re: [ppml] "Recommended Practices" procedure On Wed, Jun 28, 2006 at 07:20:40PM -0500, Stephen Sprunk wrote: > We should not be advocating as a "recommended practice" punching holes in > CIDR space under any circumstances. If someone happens to find that it > works, bully for them, but it's not supposed to and nobody should expect it > to continue to work, much less be told it's the right thing to do. I agree. Depending on their configuration/hardware/sales people, some ISPs may choose to filter at /48 globally, while most will probably go for /32 except for the /48 PI space. I expect that at some future date, /48 will be the de facto filter unit. That will depend on the (slowly growing) availability of routing slots, combined with the market forces that drive ISPs. Routing best practice is to not do something that causes massive instability and your customer base to flee. This is a business problem, not a policy problem. -David _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From randy at psg.com Thu Jun 29 11:36:22 2006 From: randy at psg.com (Randy Bush) Date: Thu, 29 Jun 2006 08:36:22 -0700 Subject: [ppml] "Recommended Practices" procedure References: <10ECB7F03C568F48B9213EF9E7F790D202100D62@wava00s2ke2k01.corp.pvt> Message-ID: <17571.62326.5201.582978@roam.psg.com> > I hear many comments about "the slippery sloap". And "make them get PI if > they want to multihome". However, my customer's dont want PI. and i don't want to work for a living, cash should fall from the sky. i think the stones had a song on this subject. randy From marla_azinger at eli.net Thu Jun 29 11:38:21 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Thu, 29 Jun 2006 08:38:21 -0700 Subject: [ppml] v6 multihoming and route filters Message-ID: <10ECB7F03C568F48B9213EF9E7F790D202100D63@wava00s2ke2k01.corp.pvt> If the IETF V6ops WG doesn't give traction to this solution then this WG will push this to become resolved in other conference mediums. The charter for IETF appears to involve this type of work and to me appears to be the most appropriate place. There are a large number of people who would like to open filters to /48 so we can freely multihome. However, it is shut down comments like this that scare many people off from participating in discussion and using their voice to say what they would like to see done with routing. I may appear as one small voice, but there are allot of unheard ones out there that agree with the /48 filter. Due to the lack of another solution for upstream providers to provide multihoming, I see it as good solution. I also believe that this solution should be given serious consideration. Weigh out the pro's and con's. Not having a solution for upstream providers to provide multihoming is a very large con for not using an available solution today. Especially since without our V6 capable networks, v6 wont be routed or used at all. As for swamp. It won't be swamp if no other solution is created, and as of today their is large conflict over what solution and if that developed solution will even work. So it may never become swamp. And if it does, I'm sure we can adapt and overcome. Thank you for your time Marla Azinger Frontier Communications -----Original Message----- From: Pekka Savola [mailto:pekkas at netcore.fi] Sent: Wednesday, June 28, 2006 9:45 PM To: Azinger, Marla Cc: v6ops at ops.ietf.org Subject: Re: v6 multihoming and route filters autolearn=ham version=3.1.2 X-Spam-Checker-Version: SpamAssassin 3.1.2 (2006-05-25) on otso.netcore.fi X-esp: ESP<17>=RBL:<22> SHA:<0> UHA:<0> SLS:<0> BAYES:<-5> SenderID:<0> Spam Dictionary (TRU10):<0> Obscenities Dictionary (TRU10):<0> Scam Dictionary (TRU10):<0> Adult Dictionary (TRU10):<0> Embed HTML Dictionary (TRU10):<0> Float Dictionary (TRU10):<0> HTML Dictionary (TRU10):<0> URL Real-Time Signatures:<0> Spam Dictionary 2 (TRU10):<0> Return-Path: pekkas at netcore.fi X-OriginalArrivalTime: 29 Jun 2006 04:45:44.0168 (UTC) FILETIME=[E192EE80:01C69B36] On Wed, 28 Jun 2006, Azinger, Marla wrote: > I ask the V6 WG to create a "best practice for multihoming" that can > be utilized today. I ask that you please insert the solution to > filter at /48 thus allowing "upstream providers" to provide > multihoming to their customers. This solution is needed to support > providers creating V6 networks and this solution can easily be added > into Marc's "IP V6 Routing Policy Guidelines" document. This is unlikely to get traction in the WG. The initial draft was basically like that but was changed. Many people (myself included) opposed (and will oppose) recommeding opening filters up to /48. Let's not create a swamp out of v6 address space with more specific junk. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From randy at psg.com Thu Jun 29 11:54:25 2006 From: randy at psg.com (Randy Bush) Date: Thu, 29 Jun 2006 08:54:25 -0700 Subject: [ppml] v6 multihoming and route filters References: <10ECB7F03C568F48B9213EF9E7F790D202100D63@wava00s2ke2k01.corp.pvt> Message-ID: <17571.63409.795497.979134@roam.psg.com> > There are a large number of people who would like to open filters > to /48 so we can freely multihome. then they should open their filters. > Due to the lack of another solution for upstream providers to > provide multihoming, I see it as good solution. do you personally manage dfz routers at all? randy From dlw+arin at tellme.com Thu Jun 29 11:57:06 2006 From: dlw+arin at tellme.com (David Williamson) Date: Thu, 29 Jun 2006 08:57:06 -0700 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D202100D62@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D202100D62@wava00s2ke2k01.corp.pvt> Message-ID: <20060629155706.GF10344@shell01.corp.tellme.com> On Thu, Jun 29, 2006 at 08:11:35AM -0700, Azinger, Marla wrote: > I hear many comments about "the slippery sloap". And "make them get PI if they want to multihome". However, my customer's dont want PI. Just because one person finds this as an ideal solution does not mean everyone will accept this solution. > > Also, a /48 is not a gigantic hole in the filtering opposed to /32. And to open up /48 for PI only is an unbalanced policy. If I had known people would be using PI as an excuse not to let Upstreams multihome with V6 I would have advocated to shut down that policy proposal. I support PI but for poeple to turn around and force feed PI is not acceptable. How do you propose to do this? Should large service providers maintain a (likely very long) list of all known /48 PA multihomers? They could then filter on the /32 edge except for the known PI space, plus all the exceptions. That's completely impractical in the real world. Alternatively, you can simply move the minimum size edge from /32 to /48 globally. That's probably also operationally impossible, for the moment. (The routing slot argument, which I don't usually buy, is an easy one to make in this case.) At some future point, /48 filtering will be a practical possibility. That time will be determined by business pressures on ISPs. Heck, I think the ISP crowd had it backwards in their objections to PI space. Let people get whatever space (v4 or v6) they can qualify for. ARIN makes no promises about the routability of any block. If you qualify for a block that's too small for current ISP routing policy to carry, that's unfortunate. Perhaps we'll be able to route your /26 or /56 in the future. Again, market forces will make things work out for the general good, or at least the general good of the ISP's shareholders. I will again reiterate that this is a business issue, not a policy one. Routing best practices are frequently organization specific, depending on hardware, clue level, and greed, among other variables. I'll agree with Randy: I'd rather not work and have money fall from the sky. :) -David From randy at psg.com Thu Jun 29 11:59:57 2006 From: randy at psg.com (Randy Bush) Date: Thu, 29 Jun 2006 08:59:57 -0700 Subject: [ppml] "Recommended Practices" procedure References: <10ECB7F03C568F48B9213EF9E7F790D202100D62@wava00s2ke2k01.corp.pvt> <20060629155706.GF10344@shell01.corp.tellme.com> Message-ID: <17571.63741.282230.401515@roam.psg.com> > How do you propose to do this? Should large service providers maintain > a (likely very long) list of all known /48 PA multihomers? actually, there is a proposal in apnic, which i support, that real multihomers be given a /48 (or shorter if justified) out of a specific /32. seems like the best compromise we can get at the moment. randy From kloch at hotnic.net Thu Jun 29 12:30:43 2006 From: kloch at hotnic.net (Kevin Loch) Date: Thu, 29 Jun 2006 12:30:43 -0400 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <17571.63741.282230.401515@roam.psg.com> References: <10ECB7F03C568F48B9213EF9E7F790D202100D62@wava00s2ke2k01.corp.pvt> <20060629155706.GF10344@shell01.corp.tellme.com> <17571.63741.282230.401515@roam.psg.com> Message-ID: <44A40033.7030500@hotnic.net> Randy Bush wrote: >> How do you propose to do this? Should large service providers maintain >> a (likely very long) list of all known /48 PA multihomers? > > actually, there is a proposal in apnic, which i support, that > real multihomers be given a /48 (or shorter if justified) out > of a specific /32. seems like the best compromise we can get > at the moment. It would be ideal if all regions assigned PI prefixes out of the same /16 (and nothing else was in that /16 for now). - Kevin From stephen at sprunk.org Thu Jun 29 12:29:25 2006 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 29 Jun 2006 11:29:25 -0500 Subject: [ppml] "Recommended Practices" procedure References: <10ECB7F03C568F48B9213EF9E7F790D202100D62@wava00s2ke2k01.corp.pvt> Message-ID: <01a201c69b99$2fd83d40$443816ac@ssprunk> Thus spake "Azinger, Marla" > I hear many comments about "the slippery sloap". And "make them > get PI if they want to multihome". However, my customer's dont want > PI. Just because one person finds this as an ideal solution does not > mean everyone will accept this solution. What makes punching holes in PA space more attractive than PI space for them? This is not an idle question. While there are many obvious technical and business reasons for multihomers getting PI space, I'm unable to identify _any_ reasons for the end site to prefer PA. > Also, a /48 is not a gigantic hole in the filtering opposed to /32. And > to open up /48 for PI only is an unbalanced policy. It's a perfectly balanced policy. Filtering is to be done on RIR allocation boundaries, and those boundaries are currently /32 for PA and /48 for PI. This is no different than what is done in v4. In fact, the whole goal was to make v6 multihoming the same as v4! > If I had known people would be using PI as an excuse not to let > Upstreams multihome with V6 I would have advocated to shut down > that policy proposal. I support PI but for poeple to turn around and > force feed PI is not acceptable. You're missing the point. PIv6 is all about giving people the _ability_ to multihome. Multihoming in PA space (v4 or v6) is not an option for both technical and business reasons. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From tme at multicasttech.com Thu Jun 29 12:50:48 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 29 Jun 2006 12:50:48 -0400 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <17571.63741.282230.401515@roam.psg.com> References: <10ECB7F03C568F48B9213EF9E7F790D202100D62@wava00s2ke2k01.corp.pvt> <20060629155706.GF10344@shell01.corp.tellme.com> <17571.63741.282230.401515@roam.psg.com> Message-ID: <2A288AAC-8CAC-4F8D-B32F-B0BF256A8AF6@multicasttech.com> Hello; I believe that Randy is talking about APNIC Proposal Prop-035-v001, http://www.apnic.org/docs/policy/proposals/prop-035-v001.html which is based on ARIN 2005-1, which passed the last ARIN meeting. On Jun 29, 2006, at 11:59 AM, Randy Bush wrote: >> How do you propose to do this? Should large service providers >> maintain >> a (likely very long) list of all known /48 PA multihomers? > > actually, there is a proposal in apnic, which i support, that > real multihomers be given a /48 (or shorter if justified) out > of a specific /32. seems like the best compromise we can get > at the moment. > > randy > Regards Marshall > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From brian.knight at us.mizuho-sc.com Thu Jun 29 13:07:23 2006 From: brian.knight at us.mizuho-sc.com (brian.knight at us.mizuho-sc.com) Date: Thu, 29 Jun 2006 12:07:23 -0500 Subject: [ppml] "Recommended Practices" procedure Message-ID: <10793F3BC5C33C489C69893C14242C0904C6F40A@JUPITER> > What makes punching holes in PA space more attractive than PI space for > them? > > This is not an idle question. While there are many obvious technical and > business reasons for multihomers getting PI space, I'm unable to identify > _any_ reasons for the end site to prefer PA. What if the site is unable to justify PI space? My organization cannot justify any space under the adopted proposal 2005-1, and we multihome today. Unless the policy is changed or ISP's allow us to announce PA space, we can't move to v6. Personally speaking, I wouldn't mind a requirement to obtain PI space if I knew it was required to multihome and it was easy to justify such space. I don't think my organization would have a problem with it, either. I would support a measure similar to the APNIC proposal mentioned by Randy. > You're missing the point. PIv6 is all about giving people the _ability_ to > multihome. Multihoming in PA space (v4 or v6) is not an option for both > technical and business reasons. Honest questions follow. Is the goal simply to prevent carving up /32's? How will that measure control routing table size? Or, put another way: To the DFZ router operators, what is the difference if the /48 comes from the ISP or from ARIN? It seemed that many people had been comfortable with multihoming in PA space. When did that change? -Brian Knight Sr. Network Engineer Mizuho Securities USA, Futures Division http://www.mizuho-sc.com/ * Please note that I do not speak for my employer - only for myself. From tme at multicasttech.com Thu Jun 29 13:25:33 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 29 Jun 2006 13:25:33 -0400 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <10793F3BC5C33C489C69893C14242C0904C6F40A@JUPITER> References: <10793F3BC5C33C489C69893C14242C0904C6F40A@JUPITER> Message-ID: <9D5B17C9-A568-4CB6-8F49-48DF0E3ACE2A@multicasttech.com> Hello; On Jun 29, 2006, at 1:07 PM, brian.knight at us.mizuho-sc.com wrote: >> What makes punching holes in PA space more attractive than PI >> space for >> them? >> >> This is not an idle question. While there are many obvious >> technical and >> business reasons for multihomers getting PI space, I'm unable to >> identify >> _any_ reasons for the end site to prefer PA. > > What if the site is unable to justify PI space? > > My organization cannot justify any space under the adopted proposal > 2005-1, > and we multihome today. Unless the policy is changed or ISP's > allow us to > announce PA space, we can't move to v6. Why not ? Is the 2002-3 IPv4 /22 too stringent ? What would you change ? > > Personally speaking, I wouldn't mind a requirement to obtain PI > space if I > knew it was required to multihome and it was easy to justify such > space. I > don't think my organization would have a problem with it, either. > > I would support a measure similar to the APNIC proposal mentioned > by Randy. > Note that all prop-035-v001 requires is multi-homing, which was indeed one of the variants of 2005-1. Marshall >> You're missing the point. PIv6 is all about giving people the >> _ability_ > to >> multihome. Multihoming in PA space (v4 or v6) is not an option >> for both >> technical and business reasons. > > Honest questions follow. > > Is the goal simply to prevent carving up /32's? How will that measure > control routing table size? > > Or, put another way: To the DFZ router operators, what is the > difference if > the /48 comes from the ISP or from ARIN? > > It seemed that many people had been comfortable with multihoming in PA > space. When did that change? > > -Brian Knight > Sr. Network Engineer > Mizuho Securities USA, Futures Division > http://www.mizuho-sc.com/ > > * Please note that I do not speak for my employer - only for myself. > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From jason.schiller at mci.com Thu Jun 29 13:47:16 2006 From: jason.schiller at mci.com (Jason Schiller (schiller@uu.net)) Date: Thu, 29 Jun 2006 13:47:16 -0400 (EDT) Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <10793F3BC5C33C489C69893C14242C0904C6F40A@JUPITER> Message-ID: Not that I am in favor of de-aggregation but... I see the problem very simply, either it is OK to consume one slot (or more) in the global routing table to make multihoming work or it isn't. If it is OK to consume one slot (or more) in the global routing table to make multihoming that that should be equally true if the slot contains either a PA or a PI prefix. Why and end site prefers PI or PA is a very personal question with no standard answer. One possible reason is cost, another is administartion, a third is the number of organization they need to interact with, never mind if they qualify or can corectly fill out the paper work. The fact of the matter is that there are some customers that easily qualify getting their own space from the RIR and beg us to give them PA space. The only difference I see between PI and PA space is that if deaggregation occurs, you can depend on the fact that all of PI is likely to be deaggregated and not have an aggregate, and all of PA is likely to have aggregates, and may or may not be deaggregated. This is only important if you later decide that deaggegrgation was a bad idea and change the policy. You can filter out the more specific PA address and fall back to the aggregates, you can filter the more specific PI addresses and break reachibility. ___Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Thu, 29 Jun 2006 brian.knight at us.mizuho-sc.com wrote: > Date: Thu, 29 Jun 2006 12:07:23 -0500 > From: brian.knight at us.mizuho-sc.com > To: stephen at sprunk.org, marla_azinger at eli.net > Cc: ppml at arin.net > Subject: Re: [ppml] "Recommended Practices" procedure > > > What makes punching holes in PA space more attractive than PI space for > > them? > > > > This is not an idle question. While there are many obvious technical and > > business reasons for multihomers getting PI space, I'm unable to identify > > _any_ reasons for the end site to prefer PA. > > What if the site is unable to justify PI space? > > My organization cannot justify any space under the adopted proposal 2005-1, > and we multihome today. Unless the policy is changed or ISP's allow us to > announce PA space, we can't move to v6. > > Personally speaking, I wouldn't mind a requirement to obtain PI space if I > knew it was required to multihome and it was easy to justify such space. I > don't think my organization would have a problem with it, either. > > I would support a measure similar to the APNIC proposal mentioned by Randy. > > > You're missing the point. PIv6 is all about giving people the _ability_ > to > > multihome. Multihoming in PA space (v4 or v6) is not an option for both > > technical and business reasons. > > Honest questions follow. > > Is the goal simply to prevent carving up /32's? How will that measure > control routing table size? > > Or, put another way: To the DFZ router operators, what is the difference if > the /48 comes from the ISP or from ARIN? > > It seemed that many people had been comfortable with multihoming in PA > space. When did that change? > > -Brian Knight > Sr. Network Engineer > Mizuho Securities USA, Futures Division > http://www.mizuho-sc.com/ > > * Please note that I do not speak for my employer - only for myself. > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From pekkas at netcore.fi Thu Jun 29 13:58:04 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 29 Jun 2006 20:58:04 +0300 (EEST) Subject: [ppml] "Recommended Practices" procedure In-Reply-To: References: Message-ID: On Thu, 29 Jun 2006, Jason Schiller (schiller at uu.net) wrote: > If it is OK to consume one slot (or more) in the global routing table to > make multihoming that that should be equally true if the slot contains > either a PA or a PI prefix. A specific PI block could possibly eliminate that "(or more)" part, which might be a good thing. There is ample evidence of both ISPs and sites leaking out a lot of more specifics, either intentionally or not. If we go for a routing based solution (which I'm opposed to), at least it should be one that doesn't allow littering the DFZ with all kinds of junk. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From randy at psg.com Thu Jun 29 14:03:38 2006 From: randy at psg.com (Randy Bush) Date: Thu, 29 Jun 2006 11:03:38 -0700 Subject: [ppml] "Recommended Practices" procedure References: <10ECB7F03C568F48B9213EF9E7F790D202100D62@wava00s2ke2k01.corp.pvt> <20060629155706.GF10344@shell01.corp.tellme.com> <17571.63741.282230.401515@roam.psg.com> <44A40033.7030500@hotnic.net> Message-ID: <17572.5626.183309.125366@roam.psg.com> > It would be ideal if all regions assigned PI prefixes out of > the same /16 (and nothing else was in that /16 for now). perhaps a /16 is excessive for five regions at /32 each randy From jason.schiller at mci.com Thu Jun 29 14:05:31 2006 From: jason.schiller at mci.com (Jason Schiller (schiller@uu.net)) Date: Thu, 29 Jun 2006 14:05:31 -0400 (EDT) Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <20060629155706.GF10344@shell01.corp.tellme.com> Message-ID: On Thu, 29 Jun 2006, David Williamson wrote: > Heck, I think the ISP crowd had it backwards in their objections to PI > space. Let people get whatever space (v4 or v6) they can qualify for. > ARIN makes no promises about the routability of any block. If you > qualify for a block that's too small for current ISP routing policy to > carry, that's unfortunate. Perhaps we'll be able to route your /26 or > /56 in the future. Again, market forces will make things work out for > the general good, or at least the general good of the ISP's > shareholders. > > I will again reiterate that this is a business issue, not a policy > one. Routing best practices are frequently organization specific, > depending on hardware, clue level, and greed, among other variables. Unfortunately what is the best business paractice is not always what is best for the good of the Internet. This is the tragedy of the commons. Also unfortunately shareholders are quick to dismiss long term concerns for a short term revune increase. > > I'll agree with Randy: I'd rather not work and have money fall from the > sky. :) I have two questions on this money falling from the sky thing... 1. Do I have to be in a certain place to get the money? If so where? 2. Does everyone get money from the sky? And if so what will it do to the value of the money? ___Jason > > -David > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From randy at psg.com Thu Jun 29 14:05:45 2006 From: randy at psg.com (Randy Bush) Date: Thu, 29 Jun 2006 11:05:45 -0700 Subject: [ppml] "Recommended Practices" procedure References: <10ECB7F03C568F48B9213EF9E7F790D202100D62@wava00s2ke2k01.corp.pvt> <20060629155706.GF10344@shell01.corp.tellme.com> <17571.63741.282230.401515@roam.psg.com> <2A288AAC-8CAC-4F8D-B32F-B0BF256A8AF6@multicasttech.com> Message-ID: <17572.5753.931964.984854@roam.psg.com> > I believe that Randy is talking about APNIC Proposal Prop-035-v001, > http://www.apnic.org/docs/policy/proposals/prop-035-v001.html yeppers > which is based on ARIN 2005-1, which passed the last ARIN meeting. but quite dissimilar randy From randy at psg.com Thu Jun 29 14:06:38 2006 From: randy at psg.com (Randy Bush) Date: Thu, 29 Jun 2006 11:06:38 -0700 Subject: [ppml] "Recommended Practices" procedure References: <10793F3BC5C33C489C69893C14242C0904C6F40A@JUPITER> Message-ID: <17572.5806.382006.784607@roam.psg.com> > What if the site is unable to justify PI space? what if i can not justify my salary? can we get real here? randy From sleibrand at internap.com Thu Jun 29 14:56:25 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 29 Jun 2006 14:56:25 -0400 (EDT) Subject: [ppml] "Recommended Practices" procedure In-Reply-To: References: Message-ID: Another consideration is that a PA /48 need not be accepted globally to be usable for multihoming. If both your transit providers accept your /48 from you and from each other, you can be guaranteed reachability. (You may not be able to do the kind of traffic engineering you might want, though.) As a result of this, I would maintain that you (as a hypothetical enterprise wishing to multihome with PA space) should (eventually) be able to find two transit providers willing to take your money and guarantee that they'll listen to your /48 from each other. If you can't, then perhaps you need to offer them more money (or get PI space). :) Now back to "Recommended Practices", it would be fairly easy to construct a routing policy to do this across the board. On each peering link, allow pe:er::pr:ef:ix/32 le 48 yo:ur::pr:ef:ix/32 le 48 PI::ne:tb:lo:ck/XX le 48 and ev:er:yt:hi:ng::el:se/32 -Scott On 06/29/06 at 1:47pm -0400, Jason Schiller (schiller at uu.net)...: > Not that I am in favor of de-aggregation but... > > I see the problem very simply, either it is OK to consume one slot (or > more) in the global routing table to make multihoming work or it > isn't. > > If it is OK to consume one slot (or more) in the global routing table to > make multihoming that that should be equally true if the slot contains > either a PA or a PI prefix. > > Why and end site prefers PI or PA is a very personal question with no > standard answer. One possible reason is cost, another is administartion, > a third is the number of organization they need to interact with, never > mind if they qualify or can corectly fill out the paper work. The fact of > the matter is that there are some customers that easily qualify getting > their own space from the RIR and beg us to give them PA space. > > The only difference I see between PI and PA space is that if deaggregation > occurs, you can depend on the fact that all of PI is likely to be > deaggregated and not have an aggregate, and all of PA is likely to have > aggregates, and may or may not be deaggregated. > > This is only important if you later decide that deaggegrgation was a bad > idea and change the policy. You can filter out the more specific PA > address and fall back to the aggregates, you can filter the more specific > PI addresses and break reachibility. > > ___Jason > > > > > ========================================================================== > Jason Schiller (703)886.6648 > Senior Internet Network Engineer fax:(703)886.0512 > Public IP Global Network Engineering schiller at uu.net > UUNET / Verizon jason.schiller at verizonbusiness.com > > The good news about having an email address that is twice as long is that > it increases traffic on the Internet. > > On Thu, 29 Jun 2006 brian.knight at us.mizuho-sc.com wrote: > > > Date: Thu, 29 Jun 2006 12:07:23 -0500 > > From: brian.knight at us.mizuho-sc.com > > To: stephen at sprunk.org, marla_azinger at eli.net > > Cc: ppml at arin.net > > Subject: Re: [ppml] "Recommended Practices" procedure > > > > > What makes punching holes in PA space more attractive than PI space for > > > them? > > > > > > This is not an idle question. While there are many obvious technical and > > > business reasons for multihomers getting PI space, I'm unable to identify > > > _any_ reasons for the end site to prefer PA. > > > > What if the site is unable to justify PI space? > > > > My organization cannot justify any space under the adopted proposal 2005-1, > > and we multihome today. Unless the policy is changed or ISP's allow us to > > announce PA space, we can't move to v6. > > > > Personally speaking, I wouldn't mind a requirement to obtain PI space if I > > knew it was required to multihome and it was easy to justify such space. I > > don't think my organization would have a problem with it, either. > > > > I would support a measure similar to the APNIC proposal mentioned by Randy. > > > > > You're missing the point. PIv6 is all about giving people the _ability_ > > to > > > multihome. Multihoming in PA space (v4 or v6) is not an option for both > > > technical and business reasons. > > > > Honest questions follow. > > > > Is the goal simply to prevent carving up /32's? How will that measure > > control routing table size? > > > > Or, put another way: To the DFZ router operators, what is the difference if > > the /48 comes from the ISP or from ARIN? > > > > It seemed that many people had been comfortable with multihoming in PA > > space. When did that change? > > > > -Brian Knight > > Sr. Network Engineer > > Mizuho Securities USA, Futures Division > > http://www.mizuho-sc.com/ > > > > * Please note that I do not speak for my employer - only for myself. > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From brian.knight at us.mizuho-sc.com Thu Jun 29 15:00:05 2006 From: brian.knight at us.mizuho-sc.com (brian.knight at us.mizuho-sc.com) Date: Thu, 29 Jun 2006 14:00:05 -0500 Subject: [ppml] "Recommended Practices" procedure Message-ID: <10793F3BC5C33C489C69893C14242C0904C6F40D@JUPITER> Hello Marshall, > Why not ? Is the 2002-3 IPv4 /22 too stringent ? What would you change ? It is. We would qualify for space if the PIv4 prerequisite for PIv6 space was /24. (Or, of course, if multihoming was added as a prerequisite.) > Note that all prop-035-v001 requires is multi-homing, which was indeed one > of the variants of 2005-1. Thank you, I didn't realize that it had been part of 2005-1. I re-joined PPML four months ago after a 1.5yr absence, which probably explains why I missed that conversation. -Brian From owen at delong.com Thu Jun 29 15:11:58 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 29 Jun 2006 12:11:58 -0700 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <17571.63741.282230.401515@roam.psg.com> References: <10ECB7F03C568F48B9213EF9E7F790D202100D62@wava00s2ke2k01.corp.pvt > <20060629155706.GF10344@shell01.corp.tellme.com> <17571.63741.282230.401515@roam.psg.com> Message-ID: --On June 29, 2006 8:59:57 AM -0700 Randy Bush wrote: >> How do you propose to do this? Should large service providers maintain >> a (likely very long) list of all known /48 PA multihomers? > > actually, there is a proposal in apnic, which i support, that > real multihomers be given a /48 (or shorter if justified) out > of a specific /32. seems like the best compromise we can get > at the moment. > That is, in essence, what 2005-1 does in ARIN. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From tme at multicasttech.com Thu Jun 29 15:17:14 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 29 Jun 2006 15:17:14 -0400 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: References: <10ECB7F03C568F48B9213EF9E7F790D202100D62@wava00s2ke2k01.corp.pvt > <20060629155706.GF10344@shell01.corp.tellme.com> <17571.63741.282230.401515@roam.psg.com> Message-ID: Hello; On Jun 29, 2006, at 3:11 PM, Owen DeLong wrote: > > > --On June 29, 2006 8:59:57 AM -0700 Randy Bush wrote: > >>> How do you propose to do this? Should large service providers >>> maintain >>> a (likely very long) list of all known /48 PA multihomers? >> >> actually, there is a proposal in apnic, which i support, that >> real multihomers be given a /48 (or shorter if justified) out >> of a specific /32. seems like the best compromise we can get >> at the moment. >> > That is, in essence, what 2005-1 does in ARIN. > No, 2005-1 requires a /22 in IPv4. prop-035-v001 does not. As I read it, you don't even need any IPv4 usage. > Owen Marshall > > -- > If it wasn't crypto-signed, it probably didn't come from me. > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From owen at delong.com Thu Jun 29 15:20:56 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 29 Jun 2006 12:20:56 -0700 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: References: Message-ID: <737F4249BD0347A0F1319A2B@imac-en0.delong.sj.ca.us> --On June 29, 2006 2:56:25 PM -0400 Scott Leibrand wrote: > Another consideration is that a PA /48 need not be accepted globally to be > usable for multihoming. If both your transit providers accept your /48 > from you and from each other, you can be guaranteed reachability. (You > may not be able to do the kind of traffic engineering you might want, > though.) > If their upstreams don't accept it, then, no, you aren't guaranteed reachability. You're just slightly less subject to MOST of the things that take out PART of one of the providers. However, I've discussed this issue with Marla at length, and, it boils down to her belief that her customers perceive getting PI space as a complicated and expensive process. I suggested several ways she could work around this issue to both her company's and her customers benefit. She remains unconvinced. I think the cooperating filter policy suggestion is about the best way to handle this. If two ISPs want to cooperate and open holes in their PA blocks with each other, that doesn't mean anyone else has to. Yes, it does mean multihoming for those customers is slightly less reliable than for customers using PI space, but, I don't see a big downside to that. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From sleibrand at internap.com Thu Jun 29 16:53:40 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 29 Jun 2006 16:53:40 -0400 (EDT) Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <737F4249BD0347A0F1319A2B@imac-en0.delong.sj.ca.us> References: <737F4249BD0347A0F1319A2B@imac-en0.delong.sj.ca.us> Message-ID: On 06/29/06 at 12:20pm -0700, Owen DeLong wrote: > --On June 29, 2006 2:56:25 PM -0400 Scott Leibrand > wrote: > > > Another consideration is that a PA /48 need not be accepted globally to be > > usable for multihoming. If both your transit providers accept your /48 > > from you and from each other, you can be guaranteed reachability. (You > > may not be able to do the kind of traffic engineering you might want, > > though.) > > > If their upstreams don't accept it, then, no, you aren't guaranteed > reachability. You're just slightly less subject to MOST of the things > that take out PART of one of the providers. I'm sorry, I made an unstated assumption that you're buying transit from two transit providers who don't have any transit providers of their own, just peers. IOW, tier 1 NSPs. Can you enumerate any failure modes in that case, or were you just talking about reachability problems for tier 2 NSPs? > I think the cooperating filter policy suggestion is about the best way to > handle this. If two ISPs want to cooperate and open holes in their PA > blocks with each other, that doesn't mean anyone else has to. Yes, it > does mean multihoming for those customers is slightly less reliable than > for customers using PI space, but, I don't see a big downside to that. I agree. However, I would recommend suggesting it in a "Recommended Practices" document, as doing so doesn't pollute the global table, just yours and your peers'. -Scott From owen at delong.com Thu Jun 29 17:38:19 2006 From: owen at delong.com (Owen DeLong) Date: Thu, 29 Jun 2006 14:38:19 -0700 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: References: <737F4249BD0347A0F1319A2B@imac-en0.delong.sj.ca.us> Message-ID: --On June 29, 2006 4:53:40 PM -0400 Scott Leibrand wrote: > On 06/29/06 at 12:20pm -0700, Owen DeLong wrote: > >> --On June 29, 2006 2:56:25 PM -0400 Scott Leibrand >> wrote: >> >> > Another consideration is that a PA /48 need not be accepted globally >> > to be usable for multihoming. If both your transit providers accept >> > your /48 from you and from each other, you can be guaranteed >> > reachability. (You may not be able to do the kind of traffic >> > engineering you might want, though.) >> > >> If their upstreams don't accept it, then, no, you aren't guaranteed >> reachability. You're just slightly less subject to MOST of the things >> that take out PART of one of the providers. > > I'm sorry, I made an unstated assumption that you're buying transit from > two transit providers who don't have any transit providers of their own, > just peers. IOW, tier 1 NSPs. Can you enumerate any failure modes in > that case, or were you just talking about reachability problems for tier 2 > NSPs? > Even in that case, it doesn't solve the problem. One of the providers will still be the only one advertising the larger block to their peers unless they have gotten together on a shared multihoming block for customers that want to do this. In that case, if the one advertising the aggregate goes away completely, the nobody outside of the other one will be able to reach you. Thus my statement that it's workable, but, not as robust as PI space. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From tme at multicasttech.com Thu Jun 29 17:52:41 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 29 Jun 2006 17:52:41 -0400 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: References: <737F4249BD0347A0F1319A2B@imac-en0.delong.sj.ca.us> Message-ID: Hello; On Jun 29, 2006, at 4:53 PM, Scott Leibrand wrote: > On 06/29/06 at 12:20pm -0700, Owen DeLong wrote: > >> --On June 29, 2006 2:56:25 PM -0400 Scott Leibrand >> >> wrote: >> >>> Another consideration is that a PA /48 need not be accepted >>> globally to be >>> usable for multihoming. If both your transit providers accept >>> your /48 >>> from you and from each other, you can be guaranteed >>> reachability. (You >>> may not be able to do the kind of traffic engineering you might >>> want, >>> though.) >>> >> If their upstreams don't accept it, then, no, you aren't guaranteed >> reachability. You're just slightly less subject to MOST of the >> things >> that take out PART of one of the providers. > > I'm sorry, I made an unstated assumption that you're buying transit > from > two transit providers who don't have any transit providers of their > own, > just peers. IOW, tier 1 NSPs. Can you enumerate any failure modes in > that case, or were you just talking about reachability problems for > tier 2 > NSPs? > I think that any policy that relies on distinguishing between Tier 1 and Tier 2 should be automatically out of bounds. Every time the subject comes up on (say) NANOG it generates much heat but little light, and I know of no tool to enable me to check independently whether or not a salesman's claims here are accurate. Regards Marshall >> I think the cooperating filter policy suggestion is about the best >> way to >> handle this. If two ISPs want to cooperate and open holes in >> their PA >> blocks with each other, that doesn't mean anyone else has to. >> Yes, it >> does mean multihoming for those customers is slightly less >> reliable than >> for customers using PI space, but, I don't see a big downside to >> that. > > I agree. However, I would recommend suggesting it in a "Recommended > Practices" document, as doing so doesn't pollute the global table, > just > yours and your peers'. > > -Scott > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From jason.schiller at mci.com Thu Jun 29 17:15:54 2006 From: jason.schiller at mci.com (Jason Schiller (schiller@uu.net)) Date: Thu, 29 Jun 2006 17:15:54 -0400 (EDT) Subject: [ppml] "Recommended Practices" procedure In-Reply-To: Message-ID: On Thu, 29 Jun 2006, Scott Leibrand wrote: > On 06/29/06 at 12:20pm -0700, Owen DeLong wrote: > > > > I think the cooperating filter policy suggestion is about the best way to > > handle this. If two ISPs want to cooperate and open holes in their PA > > blocks with each other, that doesn't mean anyone else has to. Yes, it > > does mean multihoming for those customers is slightly less reliable than > > for customers using PI space, but, I don't see a big downside to that. > > I agree. However, I would recommend suggesting it in a "Recommended > Practices" document, as doing so doesn't pollute the global table, just > yours and your peers'. > > -Scott > Although somewhat difficult, the problem isn't getting each of the customer's upstream ISPs to send the more specifics between their peering sessions, the customer is presumably paying their upstream ISPs to carry these routes. The problem is getting all the other default free ISPs to carry the route. Sources that buy transit from someone other than the customer's upstream ISPs will be dependent on the upstream ISP that provided the PA IP space, unless they also carry the more specifics. I suppose you could charge someone to carry non-customer PA /48s. But shouldn't the same also be true for PI /48s? Provider: "Oh you want to get to company XYZ that is using PI space? Well, they aren't a customer of ours. Either you can pay us to put their /48 route in out table or contact compnay XYZ and ask them to pay us to put their /48 route in our table." Customer: "But that's extortion!" ___Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. From sleibrand at internap.com Thu Jun 29 17:58:32 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 29 Jun 2006 17:58:32 -0400 (EDT) Subject: [ppml] "Recommended Practices" procedure In-Reply-To: References: <737F4249BD0347A0F1319A2B@imac-en0.delong.sj.ca.us> Message-ID: On 06/29/06 at 5:52pm -0400, Marshall Eubanks wrote: > Hello; > > On Jun 29, 2006, at 4:53 PM, Scott Leibrand wrote: > > > I'm sorry, I made an unstated assumption that you're buying transit > > from two transit providers who don't have any transit providers of > > their own, just peers. IOW, tier 1 NSPs. Can you enumerate any > > failure modes in that case, or were you just talking about > > reachability problems for tier 2 NSPs? > > I think that any policy that relies on distinguishing between Tier 1 and > Tier 2 should be automatically out of bounds. Every time the subject > comes up on (say) NANOG it generates much heat but little light, and I > know of no tool to enable me to check independently whether or not a > salesman's claims here are accurate. I'm not proposing a policy, I'm proposing text for a "Recommended Practices" document. If we want to eliminate the "distinction" between a transit-buying and transit-free transit provider (which IMO is a valid technical distinction, egos, tier labels, and salesmen aside), then you simply need to expand the recommendation to say something like this: To multihome with PA space, you must ensure that your transit providers, and any of their transit providers (recursive), accept your /48 from each other. Still pretty simple, no? -Scott From sleibrand at internap.com Thu Jun 29 18:04:19 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 29 Jun 2006 18:04:19 -0400 (EDT) Subject: [ppml] "Recommended Practices" procedure In-Reply-To: References: Message-ID: On 06/29/06 at 5:15pm -0400, Jason Schiller (schiller at uu.net)...: > Although somewhat difficult, the problem isn't getting each of the > customer's upstream ISPs to send the more specifics between their peering > sessions, the customer is presumably paying their upstream ISPs to carry > these routes. Agreed. > The problem is getting all the other default free ISPs to carry the > route. Sources that buy transit from someone other than the customer's > upstream ISPs will be dependent on the upstream ISP that provided the PA > IP space, unless they also carry the more specifics. I would maintain that getting other default free ISPs to carry the deaggregated PA /48 is beneficial, for traffic engineering and routing optimization, but unnecessary in most cases for reachability. The only case in which it would be insufficient would be if the provider who allocated the addresses went totally offline (stopped originating their /32) or partitioned their network in such a way that they were unable to reach *any* of the peering links to the customer's other provider. (Remember, they're accepting the /48 from the other provider, presumably over all their peering links, so that's a lot of diverse paths.) I would argue that if you need resilience against that kind of failure, you should be using PI space, not PA. Even in the IPv4 world, PA multihomers can experience issues when the provider who allocated them the space has issues affecting their announcement of the aggregate. -Scott From ppml at rs.seastrom.com Fri Jun 30 09:01:40 2006 From: ppml at rs.seastrom.com (Robert E.Seastrom) Date: Fri, 30 Jun 2006 09:01:40 -0400 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: (Scott Leibrand's message of "Thu, 29 Jun 2006 17:58:32 -0400 (EDT)") References: <737F4249BD0347A0F1319A2B@imac-en0.delong.sj.ca.us> Message-ID: <87irmiajbf.fsf@valhalla.seastrom.com> Scott Leibrand writes: > On 06/29/06 at 5:52pm -0400, Marshall Eubanks wrote: > >> Hello; >> >> On Jun 29, 2006, at 4:53 PM, Scott Leibrand wrote: >> >> > I'm sorry, I made an unstated assumption that you're buying transit >> > from two transit providers who don't have any transit providers of >> > their own, just peers. IOW, tier 1 NSPs. Can you enumerate any >> > failure modes in that case, or were you just talking about >> > reachability problems for tier 2 NSPs? >> >> I think that any policy that relies on distinguishing between Tier 1 and >> Tier 2 should be automatically out of bounds. Every time the subject >> comes up on (say) NANOG it generates much heat but little light, and I >> know of no tool to enable me to check independently whether or not a >> salesman's claims here are accurate. > > I'm not proposing a policy, I'm proposing text for a "Recommended > Practices" document. If we want to eliminate the "distinction" between a > transit-buying and transit-free transit provider (which IMO is a valid > technical distinction, egos, tier labels, and salesmen aside), then you > simply need to expand the recommendation to say something like this: > > To multihome with PA space, you must ensure that your transit providers, > and any of their transit providers (recursive), accept your /48 from each > other. > > Still pretty simple, no? There's an implicit assumption here that peers (as opposed to upstream transits) do not filter. History has shown counting on this to be unwise. ---Rob From sleibrand at internap.com Fri Jun 30 09:38:35 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 30 Jun 2006 09:38:35 -0400 (EDT) Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <87irmiajbf.fsf@valhalla.seastrom.com> References: <737F4249BD0347A0F1319A2B@imac-en0.delong.sj.ca.us> <87irmiajbf.fsf@valhalla.seastrom.com> Message-ID: On 06/30/06 at 9:01am -0400, Robert E.Seastrom wrote: > Scott Leibrand writes: > > > To multihome with PA space, you must ensure that your transit providers, > > and any of their transit providers (recursive), accept your /48 from each > > other. > > > > Still pretty simple, no? > > There's an implicit assumption here that peers (as opposed to upstream > transits) do not filter. History has shown counting on this to be unwise. No, I'm not making that assumption. I'm saying that only your transit-free transit providers need to exchange your route. Everyone else can send the traffic towards the provider's /32 aggregate, and once it enters the provider's network the more-specific /48 will take over. That's not ideal for traffic engineering or route optimization, but it's adequate for reachability. -Scott From tme at multicasttech.com Fri Jun 30 10:15:49 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 30 Jun 2006 10:15:49 -0400 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: References: <737F4249BD0347A0F1319A2B@imac-en0.delong.sj.ca.us> <87irmiajbf.fsf@valhalla.seastrom.com> Message-ID: <6A6D8A24-9482-40F7-B024-A6222323EC58@multicasttech.com> Hello; On Jun 30, 2006, at 9:38 AM, Scott Leibrand wrote: > On 06/30/06 at 9:01am -0400, Robert E.Seastrom > wrote: > >> Scott Leibrand writes: >> >>> To multihome with PA space, you must ensure that your transit >>> providers, >>> and any of their transit providers (recursive), accept your /48 >>> from each >>> other. >>> >>> Still pretty simple, no? >> >> There's an implicit assumption here that peers (as opposed to >> upstream >> transits) do not filter. History has shown counting on this to be >> unwise. > > No, I'm not making that assumption. I'm saying that only your > transit-free transit providers need to exchange your route. > Everyone else How do I determine which of my transit providers are transit-free ? What do I do if one fine day no provider available to me is transit- free ? Regards Marshall > can send the traffic towards the provider's /32 aggregate, and once it > enters the provider's network the more-specific /48 will take over. > That's not ideal for traffic engineering or route optimization, but > it's > adequate for reachability. > > -Scott From sleibrand at internap.com Fri Jun 30 10:49:08 2006 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 30 Jun 2006 10:49:08 -0400 (EDT) Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <6A6D8A24-9482-40F7-B024-A6222323EC58@multicasttech.com> References: <737F4249BD0347A0F1319A2B@imac-en0.delong.sj.ca.us> <87irmiajbf.fsf@valhalla.seastrom.com> <6A6D8A24-9482-40F7-B024-A6222323EC58@multicasttech.com> Message-ID: On 06/30/06 at 10:15am -0400, Marshall Eubanks wrote: > On Jun 30, 2006, at 9:38 AM, Scott Leibrand wrote: > > > No, I'm not making that assumption. I'm saying that only your > > transit-free transit providers need to exchange your route. > > Everyone else > > How do I determine which of my transit providers are transit-free ? Ask them? Ask a trusted third party? I've never had any problem getting this information from my transit providers. > What do I do if one fine day no provider available to me is transit- > free ? Then perhaps you should start using PI space. If you can't, it's a harder problem to solve, but still doesn't require cooperation of anyone who's not receiving money (directly or indirectly) from you. Say you buy your transit from me. I recommend you get PI space, but you don't qualify, so I give you a /48 out of my /32, and announce both routes to all of my transit providers (who accept them, because I'm paying them to do so). You also run BGP with another tier 2 ISP. I exchange your /48 with that ISP, either via a peering link or via a mutual transit provider. If there are no peering links or mutual transit providers, then I must ask my transit provider to accept your /48 from your ISP's transit provider, and vice versa. Other transit-free NSPs, which don't have either me or your other ISP as customers, will send your traffic to one of my transit providers based on my /32, then on to me or your ISP based on your /48. If either of your ISP links (or the routers terminating them) go down, then your traffic will be passed along to your other ISP. The only failure scenario where you lose connectivity is if my network goes completely offline. If you believe the likelihood of such an event is higher than your risk tolerance, then you should use PI space, or get your PA space from someone with a network less likely to catastrophically fail. -Scott From tme at multicasttech.com Fri Jun 30 11:08:32 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 30 Jun 2006 11:08:32 -0400 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: References: <737F4249BD0347A0F1319A2B@imac-en0.delong.sj.ca.us> <87irmiajbf.fsf@valhalla.seastrom.com> <6A6D8A24-9482-40F7-B024-A6222323EC58@multicasttech.com> Message-ID: <00D9F84A-D457-43F9-9DC8-0D6C94D8FBA9@multicasttech.com> Hello; On Jun 30, 2006, at 10:49 AM, Scott Leibrand wrote: > On 06/30/06 at 10:15am -0400, Marshall Eubanks > wrote: > >> On Jun 30, 2006, at 9:38 AM, Scott Leibrand wrote: >> >>> No, I'm not making that assumption. I'm saying that only your >>> transit-free transit providers need to exchange your route. >>> Everyone else >> >> How do I determine which of my transit providers are transit-free ? > > Ask them? Ask a trusted third party? I've never had any problem > getting this information from my transit providers. > In my experience, claims to be "Tier 1" are pretty common. Some I believe, some I know aren't really true. And, like you, I think I know who to ask if I need to know more. More seriously, I was trying to point out that ARIN policy needs to avoid the creation of a "private club" model, where you can't do things unless you know the right people at the right level. >> What do I do if one fine day no provider available to me is transit- >> free ? > > Then perhaps you should start using PI space. If you can't, it's a > harder > problem to solve, but still doesn't require cooperation of anyone > who's > not receiving money (directly or indirectly) from you. > Oh, then I misunderstood and must apologize. I thought you were proposing this _instead_ of PI space for small multi-homers. If you are saying that this is something that you can do _as an additional option_, then I have no trouble with it. > Say you buy your transit from me. I recommend you get PI space, > but you > don't qualify, so I give you a /48 out of my /32, and announce both > routes > to all of my transit providers (who accept them, because I'm paying > them > to do so). You also run BGP with another tier 2 ISP. I exchange > your /48 > with that ISP, either via a peering link or via a mutual transit > provider. > If there are no peering links or mutual transit providers, then I > must ask > my transit provider to accept your /48 from your ISP's transit > provider, > and vice versa. Other transit-free NSPs, which don't have either > me or > your other ISP as customers, will send your traffic to one of my > transit > providers based on my /32, then on to me or your ISP based on your / > 48. > If either of your ISP links (or the routers terminating them) go down, > then your traffic will be passed along to your other ISP. > > The only failure scenario where you lose connectivity is if my network > goes completely offline. If you believe the likelihood of such an > event > is higher than your risk tolerance, then you should use PI space, > or get > your PA space from someone with a network less likely to > catastrophically > fail. > > -Scott Regards Marshall From iljitsch at muada.com Fri Jun 30 11:55:39 2006 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 30 Jun 2006 17:55:39 +0200 Subject: [ppml] v6 multihoming and route filters In-Reply-To: References: <10ECB7F03C568F48B9213EF9E7F790D202100D63@wava00s2ke2k01.corp.pvt> Message-ID: <955B63C3-3539-44E8-80F5-99EBAEBFD81B@muada.com> On 30-jun-2006, at 9:40, Fred Baker wrote: > My opinion - and please note that it is just that, not an edict of > any kinds - is that in the final analysis it is not the IETF but > operational reality that controls the issues here. There are two issues with having people inject /48s into the routing system without limitations: 1. At some point in the future, the number of routes in the DFZ could become so large that the routing system can't support it any more. This is the scaling problem that many people in the IETF are worried about. 2. A more operational and more immediate risk is leaking of more specifics. Due to the way they handle their internal and external routing, and the relationship between the two, it's not uncommon for larger networks to leak internal more specific routes into BGP. This way, an ISP with a /16 with a number of customers that each have a / 24 may leak those /24s. In IPv6 this is very dangerous, because a single ISP with a /32 can have a maximum of no less than 65536 /48s that can potentially be deaggregated. So one ISP could potentially leak a number of routes equal to a third of the global IPv4 routing table. The second issue could largely be solved by giving multihomed customers a prefix that is shorter than a /48 and then filter out / 48s but allow /47 and shorter. But that's not the way things work today. > What may have applicability is Steve Deering's concept of > Metropolitan Addressing, which it looks like someone needs to > describe in an Internet Draft (it is in the slides at ftp:// > ftp.ietf.cnri.reston.va.us/ietf-online-proceedings/95jul/ > presentations/allocation/deering.slides.ps). I've written a draft that takes this idea a bit further a couple of years ago, have a look at: http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt From ipgoddess at gmail.com Fri Jun 30 14:34:40 2006 From: ipgoddess at gmail.com (Stacy Taylor) Date: Fri, 30 Jun 2006 11:34:40 -0700 Subject: [ppml] v6 multihoming and route filters In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D202100D63@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D202100D63@wava00s2ke2k01.corp.pvt> Message-ID: <1c16a4870606301134q1bf2e373v8d620efdfbadf629@mail.gmail.com> Hello, What we are calling for is IETF support for what we perceive to be an operational inevitability. It is well known that carriers are market driven. If enough of our customers will pay for v6 multihoming, our marketing departments will offer it, and we will have to support it. All of that is obviously moot if other carriers are filtering on a shorter prefix length. The ARIN region is implementing the policy for /48s for end sites, and these prefixes will need to be routed and globally reachable. We all are leery of creating the v6 swamp, but this issue is pressing and necessary to implement v6 in the current environment. Thank you, Stacy Taylor On 6/29/06, Azinger, Marla wrote: > If the IETF V6ops WG doesn't give traction to this solution then this WG will push this to become resolved in other conference mediums. The charter for IETF appears to involve this type of work and to me appears to be the most appropriate place. > > There are a large number of people who would like to open filters to /48 so we can freely multihome. However, it is shut down comments like this that scare many people off from participating in discussion and using their voice to say what they would like to see done with routing. I may appear as one small voice, but there are allot of unheard ones out there that agree with the /48 filter. > > Due to the lack of another solution for upstream providers to provide multihoming, I see it as good solution. I also believe that this solution should be given serious consideration. Weigh out the pro's and con's. Not having a solution for upstream providers to provide multihoming is a very large con for not using an available solution today. Especially since without our V6 capable networks, v6 wont be routed or used at all. > > As for swamp. It won't be swamp if no other solution is created, and as of today their is large conflict over what solution and if that developed solution will even work. So it may never become swamp. And if it does, I'm sure we can adapt and overcome. > > Thank you for your time > Marla Azinger > Frontier Communications > > -----Original Message----- > From: Pekka Savola [mailto:pekkas at netcore.fi] > Sent: Wednesday, June 28, 2006 9:45 PM > To: Azinger, Marla > Cc: v6ops at ops.ietf.org > Subject: Re: v6 multihoming and route filters > > > autolearn=ham version=3.1.2 > X-Spam-Checker-Version: SpamAssassin 3.1.2 (2006-05-25) on otso.netcore.fi > X-esp: ESP<17>=RBL:<22> SHA:<0> UHA:<0> SLS:<0> BAYES:<-5> SenderID:<0> Spam > Dictionary (TRU10):<0> Obscenities Dictionary (TRU10):<0> > Scam Dictionary (TRU10):<0> Adult Dictionary (TRU10):<0> > Embed HTML Dictionary (TRU10):<0> Float Dictionary > (TRU10):<0> HTML Dictionary (TRU10):<0> URL Real-Time > Signatures:<0> Spam Dictionary 2 (TRU10):<0> > Return-Path: pekkas at netcore.fi > X-OriginalArrivalTime: 29 Jun 2006 04:45:44.0168 (UTC) FILETIME=[E192EE80:01C69B36] > > On Wed, 28 Jun 2006, Azinger, Marla wrote: > > I ask the V6 WG to create a "best practice for multihoming" that can > > be utilized today. I ask that you please insert the solution to > > filter at /48 thus allowing "upstream providers" to provide > > multihoming to their customers. This solution is needed to support > > providers creating V6 networks and this solution can easily be added > > into Marc's "IP V6 Routing Policy Guidelines" document. > > This is unlikely to get traction in the WG. The initial draft was > basically like that but was changed. Many people (myself included) > opposed (and will oppose) recommeding opening filters up to /48. > > Let's not create a swamp out of v6 address space with more specific > junk. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From ppml at rs.seastrom.com Fri Jun 30 14:56:22 2006 From: ppml at rs.seastrom.com (Robert E.Seastrom) Date: Fri, 30 Jun 2006 14:56:22 -0400 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <00D9F84A-D457-43F9-9DC8-0D6C94D8FBA9@multicasttech.com> (Marshall Eubanks's message of "Fri, 30 Jun 2006 11:08:32 -0400") References: <737F4249BD0347A0F1319A2B@imac-en0.delong.sj.ca.us> <87irmiajbf.fsf@valhalla.seastrom.com> <6A6D8A24-9482-40F7-B024-A6222323EC58@multicasttech.com> <00D9F84A-D457-43F9-9DC8-0D6C94D8FBA9@multicasttech.com> Message-ID: <871wt6a2w9.fsf@valhalla.seastrom.com> Marshall Eubanks writes in response to Scott Leibrand : > In my experience, claims to be "Tier 1" are pretty common. Some I > believe, some > I know aren't really true. And, like you, I think I know who to ask > if I need to know more. > > More seriously, I was trying to point out that ARIN policy needs to > avoid the creation > of a "private club" model, where you can't do things unless you know > the right people at the right level. Who is and isn't transit-free of course is subject to change from time to time; possibly at inconvenient times like the middle of your contract. I agree that ARIN policy should not be creating or appearing to create a tiered system. > Oh, then I misunderstood and must apologize. I thought you were > proposing this _instead_ of PI space for small multi-homers. If you > are saying that this is something that you can do _as an > additional option_, then I have no trouble with it. I do. It encourages people to take the path of least resistance (here, have this slice of PA space, no paperwork involved, sure we'll multihome for ya!) rather than fixing the perception that ARIN is difficult to deal with to the extent that people would short themselves from a business and technical standpoint in order to avoid it. ---rob From marla_azinger at eli.net Fri Jun 30 16:54:54 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Fri, 30 Jun 2006 13:54:54 -0700 Subject: [ppml] v6 multihoming and route filters Message-ID: <10ECB7F03C568F48B9213EF9E7F790D20295A689@wava00s2ke2k01.corp.pvt> Fred- Thank you. If it read as a threat, I'am sorry. That isnt my intent by any means. I meant it more like a factual progression. Eventually someone with some solution will need to step forward. After much debate on ppml it seemed as though many felt it should be resolved at IETF, but if its not then something needs to be decided somewhere else. I hope thats more clear, because I am not the threatening type. So sorry for any bad wording I may have sent forward. I would really like to come to IETF and meet with the working group. Thank you for asking. I will work on trying to find funding. My whole intent is to try to help the situation and help work on a solution. Not create angst. Thank you Marla Azinger -----Original Message----- From: Fred Baker [mailto:fred at cisco.com] Sent: Friday, June 30, 2006 12:40 AM To: Azinger, Marla Cc: Pekka Savola; v6ops at ops.ietf.org; ppml at arin.net Subject: Re: v6 multihoming and route filters My opinion - and please note that it is just that, not an edict of any kinds - is that in the final analysis it is not the IETF but operational reality that controls the issues here. If your customer will pay you enough to advertise a prefix that you don't own and to arrange corresponding ingress filter and route management with your upstream networks, you're going to do so regardless of what any RFC says, and it will in fact work because you will make the necessary business and routing arrangements to support it. That said, the level of effort involved will make the price fairly high, which means that you will not be doing a lot of this. A "Best Current Practice" is not something with those business constraints, I should think. By the way, threatening people is not a very convincing argument style. If you want something done, how about helping us do it, and honestly addressing the issues and concerns raised? What may have applicability is Steve Deering's concept of Metropolitan Addressing, which it looks like someone needs to describe in an Internet Draft (it is in the slides at ftp:// ftp.ietf.cnri.reston.va.us/ietf-online-proceedings/95jul/ presentations/allocation/deering.slides.ps). In short, his proposal was that a regional entity such as a civil community of some size gets a prefix and the ISPs that serve it agree to carry its routes such that a user can multihome within the community and outside it one routes to the community. This scales in the same way that Provider Addressing scales, with the caveats that each provider will have full /48 (or /56 I imagine) routes for community on the set of machines that serves it, and will need fairly explicit controls to ensure that the routing doesn't leak. Would you like to come to the working group and discuss the issues with us in Montreal? I think that would be more productive than this discussion is being right now. On Jun 29, 2006, at 3:38 PM, Azinger, Marla wrote: > If the IETF V6ops WG doesn't give traction to this solution then > this WG will push this to become resolved in other conference > mediums. The charter for IETF appears to involve this type of work > and to me appears to be the most appropriate place. > > There are a large number of people who would like to open filters > to /48 so we can freely multihome. However, it is shut down > comments like this that scare many people off from participating in > discussion and using their voice to say what they would like to see > done with routing. I may appear as one small voice, but there are > allot of unheard ones out there that agree with the /48 filter. > > Due to the lack of another solution for upstream providers to > provide multihoming, I see it as good solution. I also believe > that this solution should be given serious consideration. Weigh > out the pro's and con's. Not having a solution for upstream > providers to provide multihoming is a very large con for not using > an available solution today. Especially since without our V6 > capable networks, v6 wont be routed or used at all. > > As for swamp. It won't be swamp if no other solution is created, > and as of today their is large conflict over what solution and if > that developed solution will even work. So it may never become > swamp. And if it does, I'm sure we can adapt and overcome. > > Thank you for your time > Marla Azinger > Frontier Communications > > -----Original Message----- > From: Pekka Savola [mailto:pekkas at netcore.fi] > Sent: Wednesday, June 28, 2006 9:45 PM > To: Azinger, Marla > Cc: v6ops at ops.ietf.org > Subject: Re: v6 multihoming and route filters > > > autolearn=ham version=3.1.2 > X-Spam-Checker-Version: SpamAssassin 3.1.2 (2006-05-25) on > otso.netcore.fi > X-esp: ESP<17>=RBL:<22> SHA:<0> UHA:<0> SLS:<0> BAYES:<-5> > SenderID:<0> Spam > Dictionary (TRU10):<0> Obscenities Dictionary (TRU10):<0> > Scam Dictionary (TRU10):<0> Adult Dictionary (TRU10):<0> > Embed HTML Dictionary (TRU10):<0> Float Dictionary > (TRU10):<0> HTML Dictionary (TRU10):<0> URL Real-Time > Signatures:<0> Spam Dictionary 2 (TRU10):<0> > Return-Path: pekkas at netcore.fi > X-OriginalArrivalTime: 29 Jun 2006 04:45:44.0168 (UTC) FILETIME= > [E192EE80:01C69B36] > > On Wed, 28 Jun 2006, Azinger, Marla wrote: >> I ask the V6 WG to create a "best practice for multihoming" that can >> be utilized today. I ask that you please insert the solution to >> filter at /48 thus allowing "upstream providers" to provide >> multihoming to their customers. This solution is needed to support >> providers creating V6 networks and this solution can easily be added >> into Marc's "IP V6 Routing Policy Guidelines" document. > > This is unlikely to get traction in the WG. The initial draft was > basically like that but was changed. Many people (myself included) > opposed (and will oppose) recommeding opening filters up to /48. > > Let's not create a swamp out of v6 address space with more specific > junk. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From alh-ietf at tndh.net Fri Jun 30 16:59:07 2006 From: alh-ietf at tndh.net (Tony Hain) Date: Fri, 30 Jun 2006 13:59:07 -0700 Subject: [ppml] v6 multihoming and route filters In-Reply-To: <955B63C3-3539-44E8-80F5-99EBAEBFD81B@muada.com> Message-ID: <083d01c69c88$072b6e90$1c7ba8c0@tndh.net> Iljitsch van Beijnum wrote: > ... > 1. At some point in the future, the number of routes in the DFZ could > become so large that the routing system can't support it any more. > This is the scaling problem that many people in the IETF are worried > about. What keeps being overlooked here is that the concept of a global DFZ is artificial, and was originally specifically intended to sort out the players who could afford serious routers from the rest. There is no technical need for every organization to know the gory details of every other organization, the basis for maintain the myth is purely an ego driven desire to be considered a peer. > > > I've written a draft that takes this idea a bit further a couple of > years ago, have a look at: > > http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt That was good work looking at the alternatives. I have also been maintaining one without ties to political entities, currently draft-hain-ipv6-pi-addr-09.txt. At the end of the day we need to revisit the assumption that the only viable aggregation unit is provider based. There are trade-offs here, and with a small shift toward structured topology we could put a lid on the routing table problem. Tony From randy at psg.com Fri Jun 30 17:26:39 2006 From: randy at psg.com (Randy Bush) Date: Fri, 30 Jun 2006 11:26:39 -1000 Subject: [ppml] v6 multihoming and route filters References: <955B63C3-3539-44E8-80F5-99EBAEBFD81B@muada.com> <083d01c69c88$072b6e90$1c7ba8c0@tndh.net> Message-ID: <17573.38671.651186.219161@roam.psg.com> > What keeps being overlooked here is that the concept of a global DFZ is > artificial, and was originally specifically intended to sort out the players > who could afford serious routers from the rest. There is no technical need > for every organization to know the gory details of every other organization, > the basis for maintain the myth is purely an ego driven desire to be > considered a peer. and not a lack of a reasonable scalable v6 routing architecture? randy From sandy at tislabs.com Fri Jun 30 17:27:57 2006 From: sandy at tislabs.com (sandy at tislabs.com) Date: Fri, 30 Jun 2006 17:27:57 -0400 (EDT) Subject: [ppml] v6 multihoming and route filters Message-ID: <200606302127.k5ULRvc7006227@tislabs.com> >What keeps being overlooked here is that the concept of a global DFZ is >artificial, and was originally specifically intended to sort out the players >who could afford serious routers from the rest. What is certainly not artificial is that the capacity of the router platforms must be sufficient to handle the largest routing table they might carry. That depends on the routing architecture design, certainly. If the routing architecture is such that some ISPs could end up carrying routes to every announced prefix, then we worry about the capacity curve staying ahead of the demand curve. And people have been pointing out just how slow the capacity curve grows. Business relationships won't control this. --Sandy From marla_azinger at eli.net Fri Jun 30 17:41:01 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Fri, 30 Jun 2006 14:41:01 -0700 Subject: [ppml] "Recommended Practices" procedure Message-ID: <10ECB7F03C568F48B9213EF9E7F790D20295A68B@wava00s2ke2k01.corp.pvt> Yes, I get what you are saying. The fact being overlooked here is that no matter how it boils down, I have customers that do not want PI space. I understand that there are some enterprises that think PI space is their dream answer. But not everyone has the same dream. Marla -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Owen DeLong Sent: Thursday, June 29, 2006 12:21 PM To: Scott Leibrand; Jason Schiller (schiller at uu.net) Cc: ppml at arin.net; brian.knight at us.mizuho-sc.com Subject: Re: [ppml] "Recommended Practices" procedure --On June 29, 2006 2:56:25 PM -0400 Scott Leibrand wrote: > Another consideration is that a PA /48 need not be accepted globally to be > usable for multihoming. If both your transit providers accept your /48 > from you and from each other, you can be guaranteed reachability. (You > may not be able to do the kind of traffic engineering you might want, > though.) > If their upstreams don't accept it, then, no, you aren't guaranteed reachability. You're just slightly less subject to MOST of the things that take out PART of one of the providers. However, I've discussed this issue with Marla at length, and, it boils down to her belief that her customers perceive getting PI space as a complicated and expensive process. I suggested several ways she could work around this issue to both her company's and her customers benefit. She remains unconvinced. I think the cooperating filter policy suggestion is about the best way to handle this. If two ISPs want to cooperate and open holes in their PA blocks with each other, that doesn't mean anyone else has to. Yes, it does mean multihoming for those customers is slightly less reliable than for customers using PI space, but, I don't see a big downside to that. Owen -- If it wasn't crypto-signed, it probably didn't come from me. From randy at psg.com Fri Jun 30 17:56:12 2006 From: randy at psg.com (Randy Bush) Date: Fri, 30 Jun 2006 11:56:12 -1000 Subject: [ppml] "Recommended Practices" procedure References: <10ECB7F03C568F48B9213EF9E7F790D20295A68B@wava00s2ke2k01.corp.pvt> Message-ID: <17573.40444.346175.749864@roam.psg.com> > Yes, I get what you are saying. The fact being overlooked here is that no > matter how it boils down, I have customers that do not want PI space. i presume from your previous dreams that you meant PA and, again, it's very understood that they want PI. we all want lots of things. but we have some problems with people who think locally and act globally. and this is one of them. grazing of the commons and all that. randy From marla_azinger at eli.net Fri Jun 30 18:13:09 2006 From: marla_azinger at eli.net (Azinger, Marla) Date: Fri, 30 Jun 2006 15:13:09 -0700 Subject: [ppml] "Recommended Practices" procedure Message-ID: <10ECB7F03C568F48B9213EF9E7F790D20295A68C@wava00s2ke2k01.corp.pvt> Well put. Marla -----Original Message----- From: Jason Schiller (schiller at uu.net) [mailto:jason.schiller at mci.com] Sent: Thursday, June 29, 2006 10:47 AM To: brian.knight at us.mizuho-sc.com Cc: stephen at sprunk.org; Azinger, Marla; ppml at arin.net Subject: Re: [ppml] "Recommended Practices" procedure Not that I am in favor of de-aggregation but... I see the problem very simply, either it is OK to consume one slot (or more) in the global routing table to make multihoming work or it isn't. If it is OK to consume one slot (or more) in the global routing table to make multihoming that that should be equally true if the slot contains either a PA or a PI prefix. Why and end site prefers PI or PA is a very personal question with no standard answer. One possible reason is cost, another is administartion, a third is the number of organization they need to interact with, never mind if they qualify or can corectly fill out the paper work. The fact of the matter is that there are some customers that easily qualify getting their own space from the RIR and beg us to give them PA space. The only difference I see between PI and PA space is that if deaggregation occurs, you can depend on the fact that all of PI is likely to be deaggregated and not have an aggregate, and all of PA is likely to have aggregates, and may or may not be deaggregated. This is only important if you later decide that deaggegrgation was a bad idea and change the policy. You can filter out the more specific PA address and fall back to the aggregates, you can filter the more specific PI addresses and break reachibility. ___Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Thu, 29 Jun 2006 brian.knight at us.mizuho-sc.com wrote: > Date: Thu, 29 Jun 2006 12:07:23 -0500 > From: brian.knight at us.mizuho-sc.com > To: stephen at sprunk.org, marla_azinger at eli.net > Cc: ppml at arin.net > Subject: Re: [ppml] "Recommended Practices" procedure > > > What makes punching holes in PA space more attractive than PI space for > > them? > > > > This is not an idle question. While there are many obvious technical and > > business reasons for multihomers getting PI space, I'm unable to identify > > _any_ reasons for the end site to prefer PA. > > What if the site is unable to justify PI space? > > My organization cannot justify any space under the adopted proposal 2005-1, > and we multihome today. Unless the policy is changed or ISP's allow us to > announce PA space, we can't move to v6. > > Personally speaking, I wouldn't mind a requirement to obtain PI space if I > knew it was required to multihome and it was easy to justify such space. I > don't think my organization would have a problem with it, either. > > I would support a measure similar to the APNIC proposal mentioned by Randy. > > > You're missing the point. PIv6 is all about giving people the _ability_ > to > > multihome. Multihoming in PA space (v4 or v6) is not an option for both > > technical and business reasons. > > Honest questions follow. > > Is the goal simply to prevent carving up /32's? How will that measure > control routing table size? > > Or, put another way: To the DFZ router operators, what is the difference if > the /48 comes from the ISP or from ARIN? > > It seemed that many people had been comfortable with multihoming in PA > space. When did that change? > > -Brian Knight > Sr. Network Engineer > Mizuho Securities USA, Futures Division > http://www.mizuho-sc.com/ > > * Please note that I do not speak for my employer - only for myself. > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From pesherb at yahoo.com Fri Jun 30 18:17:15 2006 From: pesherb at yahoo.com (Peter Sherbin) Date: Fri, 30 Jun 2006 15:17:15 -0700 (PDT) Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D20295A68B@wava00s2ke2k01.corp.pvt> Message-ID: <20060630221715.4444.qmail@web54707.mail.yahoo.com> Maria, Could you pls. elaborate on customers not wanting PI: 1. How many customers 2. By customer: average monthly traffic volume, mumber of links to peers/transit providers, link sizes 3. Nature of the business 4. Geographical location Thanks, Peter --- "Azinger, Marla" wrote: > Yes, I get what you are saying. The fact being overlooked here is that no matter > how it boils down, I have customers that do not want PI space. I understand that > there are some enterprises that think PI space is their dream answer. But not > everyone has the same dream. > > Marla > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > Owen DeLong > Sent: Thursday, June 29, 2006 12:21 PM > To: Scott Leibrand; Jason Schiller (schiller at uu.net) > Cc: ppml at arin.net; brian.knight at us.mizuho-sc.com > Subject: Re: [ppml] "Recommended Practices" procedure > > > > > --On June 29, 2006 2:56:25 PM -0400 Scott Leibrand > wrote: > > > Another consideration is that a PA /48 need not be accepted globally to be > > usable for multihoming. If both your transit providers accept your /48 > > from you and from each other, you can be guaranteed reachability. (You > > may not be able to do the kind of traffic engineering you might want, > > though.) > > > If their upstreams don't accept it, then, no, you aren't guaranteed > reachability. You're just slightly less subject to MOST of the things > that take out PART of one of the providers. > > However, I've discussed this issue with Marla at length, and, it boils down > to her belief that her customers perceive getting PI space as a complicated > and expensive process. I suggested several ways she could work around this > issue to both her company's and her customers benefit. She remains > unconvinced. > > I think the cooperating filter policy suggestion is about the best way to > handle this. If two ISPs want to cooperate and open holes in their PA > blocks with each other, that doesn't mean anyone else has to. Yes, it > does mean multihoming for those customers is slightly less reliable than > for customers using PI space, but, I don't see a big downside to that. > > Owen > > > -- > If it wasn't crypto-signed, it probably didn't come from me. > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From kloch at hotnic.net Fri Jun 30 18:25:06 2006 From: kloch at hotnic.net (Kevin Loch) Date: Fri, 30 Jun 2006 18:25:06 -0400 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D20295A68B@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D20295A68B@wava00s2ke2k01.corp.pvt> Message-ID: <44A5A4C2.3020701@hotnic.net> Azinger, Marla wrote: > Yes, I get what you are saying. The fact being overlooked > here is that no matter how it boils down, I have customers that > do not want PI space. I understand that there are some enterprises > that think PI space is their dream answer. But not everyone has the same dream. I'm having a hard time imagining someone who needs to multihome badly but will not accept PI space even if they qualify for it. Can you give an example of the type of customer that would be in that situation? - Kevin From ipgoddess at gmail.com Fri Jun 30 18:43:24 2006 From: ipgoddess at gmail.com (Stacy Taylor) Date: Fri, 30 Jun 2006 15:43:24 -0700 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <44A5A4C2.3020701@hotnic.net> References: <10ECB7F03C568F48B9213EF9E7F790D20295A68B@wava00s2ke2k01.corp.pvt> <44A5A4C2.3020701@hotnic.net> Message-ID: <1c16a4870606301543m64171de6r3d2e03cc594f45ab@mail.gmail.com> Hi Everyone, Caveat: This evidence is purely anecdotal. I likewise have this experience. While I do my best to change the perceptions of my customers regarding ARIN, many persist that the registry is a monolith to be avoided. They know me, they trust me, they want my IP space. We on this list are savvy enough to understand the value of PI space, but many downstream customers are not. Thanks, /Stacy On 6/30/06, Kevin Loch wrote: > Azinger, Marla wrote: > > Yes, I get what you are saying. The fact being overlooked > > here is that no matter how it boils down, I have customers that > > do not want PI space. I understand that there are some enterprises > > that think PI space is their dream answer. But not everyone has the same dream. > > I'm having a hard time imagining someone who needs to multihome badly > but will not accept PI space even if they qualify for it. > > Can you give an example of the type of customer that would be > in that situation? > > - Kevin > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From ppml at rs.seastrom.com Fri Jun 30 19:18:56 2006 From: ppml at rs.seastrom.com (Robert E.Seastrom) Date: Fri, 30 Jun 2006 19:18:56 -0400 Subject: [ppml] "Recommended Practices" procedure In-Reply-To: <1c16a4870606301543m64171de6r3d2e03cc594f45ab@mail.gmail.com> (Stacy Taylor's message of "Fri, 30 Jun 2006 15:43:24 -0700") References: <10ECB7F03C568F48B9213EF9E7F790D20295A68B@wava00s2ke2k01.corp.pvt> <44A5A4C2.3020701@hotnic.net> <1c16a4870606301543m64171de6r3d2e03cc594f45ab@mail.gmail.com> Message-ID: <87irminsf3.fsf@valhalla.seastrom.com> "Stacy Taylor" writes: > Hi Everyone, > Caveat: This evidence is purely anecdotal. > > I likewise have this experience. While I do my best to change the > perceptions of my customers regarding ARIN, many persist that the > registry is a monolith to be avoided. They know me, they trust me, > they want my IP space. > We on this list are savvy enough to understand the value of PI space, > but many downstream customers are not. Then is the problem not an education / PR issue, to be handled by sales engineering and perhaps by ARIN itself? ---Rob From iljitsch at muada.com Fri Jun 30 20:06:19 2006 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sat, 1 Jul 2006 02:06:19 +0200 Subject: [ppml] v6 multihoming and route filters In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D202100D5D@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D202100D5D@wava00s2ke2k01.corp.pvt> Message-ID: Marla, On 28-jun-2006, at 21:32, Azinger, Marla wrote: > I currently have customers asking for this ability and none of them > wish to wait for solutions that may not be fully developed for a > couple more years. Also, my customers don't want to get PI space > (even under the new V6 PI policy), so this means I need to give > them a /48 and set up multihoming. However, as all policy and > practices sit right now, everyone filters on a /32. I see there is a long discussion on ppml that I hadn't noticed before about this subject. Scott Leibrand made some good points on both the usefulness and the limitations of multihoming using PA space. It's too bad that some others are pushing for PI. PI ALWAYS needs a place in the global routing table, while with shooting holes in PA, the more specific only needs to be visible in part of the network. As long as that part is big enough to provide reasonable multihoming benefits, this works out well of all parties involved. Unlike PI, PA multihoming is compatible with what we're trying to do in shim6, which may or may not be an advantage, but it can't hurt. (If anyone has questions about shim6, email me off-list.) Thinking in practical terms, I don't see an "allow all /48s" policy adopted by most network operators any time soon, as it commits them to something that may not give them trouble now, but has the potential to do so in the future. An alternative would be to come up with a BGP community to tag /48s that are used in multihoming so that it's possible to selectively allow those while still rejecting /48s that are deaggregated by accident. It will probably still take some time to get this adopted, but ISPs are smart enough to realize that more multihoming is more business for everyone, so I expect that something like this will be accepted unless there are problems that make this solution unattractive. I would be happy to co-author a document outlining this.