[ppml] "Recommended Practices" procedure
Jason Schiller (schiller@uu.net)
jason.schiller at mci.com
Wed Jun 28 16:16:55 EDT 2006
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 <ipgoddess at gmail.com>
> To: "Azinger, Marla" <marla_azinger at eli.net>
> 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 <marla_azinger at eli.net> 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" <tli at tropos.com> 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
>
More information about the ARIN-PPML
mailing list