[ppml] "Recommended Practices" procedure
Jason Schiller (schiller@uu.net)
jason.schiller at mci.com
Thu Apr 27 18:07:58 EDT 2006
Marla,
Currently we filter on the /32 boundry except for legacy /35s and critical
infrastructure.
I don't disagree with you about providers filtering on the /48 boundry for
PI either.
But I don't see how anyone can defend allowing PI multihomers 1 slot
(/48) in the routing table, but not allowing PA multi-homers one slot
(/48) in the routing table.
Either de-aggregation is an acceptible solution to multi-homing, or it
isn't. Whether the end-site uses a PI address or a PA address should make
no difference.
Secondly, when customers start to whine about wanting to slice up their
announcement to the global routing table the boundry may slip a bit.
___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, 27 Apr 2006, Azinger, Marla wrote:
> Date: Thu, 27 Apr 2006 14:21:21 -0700
> From: "Azinger, Marla" <marla_azinger at eli.net>
> To: "Jason Schiller (schiller at uu.net)" <jason.schiller at mci.com>,
> Christopher Morrow <christopher.morrow at gmail.com>
> Cc: ppml at arin.net
> Subject: RE: [ppml] "Recommended Practices" procedure
>
> I concur with Jason's comments below. So it appears in order to push this forward it will require the creation of a "document" that is made carefully with input from ARIN/NANOG participants. Then the document hopefully having a positive consensus of support can be taken to IETF for possibly being published as a IETF blessed document.
>
> Also, Chris to your one comment:
> "Today, MOST providers will accept and re-advertise a /24 route, this
> > seems to be a 'globally agreed upon' boundary. This is good and bad
> > (debate later). In v6 this hasn't really been set yet, though with
> > 2005-1 passing (potentially, depending on AC I suppose?) the boundary
> > will be /48... it'll quickly be 'all /48' as well I predict."
>
> For V6 I have been asking around and it appears that almost all large transits if not all are filtering at the /32. If the PI Policy goes through then I believe ONLY the /48's and more specific that FALL WITHIN the "Set aside block by ARIN", will have filters opened up for them to go through. So if you dont receive an Allocation from the PI section, then you will still be filtered out at the /32.
>
> This is yet another reason why I am pushing for a document that supports more specifics to be routed so that we may use the technology that exists. Hopefully this would only be a short term solution. I would hope this would motivate the Shim 6 or 8+8 groups to work faster towards a solution for multihoming.
>
> Thank you
> Marla
>
>
>
> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
> Jason Schiller (schiller at uu.net)
> Sent: Wednesday, April 26, 2006 8:57 PM
> To: Christopher Morrow
> Cc: ppml at arin.net
> Subject: Re: [ppml] "Recommended Practices" procedure
>
>
> Chris,
>
> Yes... and no
>
> So the problem is that each of the forums have the pros and cons... ITEF
> is global, but BCPs will have to continously be obsoleted, and not easily
> referenced. IETF maybe lacks enough operators support.
>
> ARIN seems to have a good consensus building forum, and has the IP address
> policy people. Routing policy seems intertwined with IP address
> policy. ARIN is not global, and would require some sort of Policy
> Resource Organization (PRO) to synchronize policy between RIRs.
>
> The OGs have more operators and may have more useful input on what the
> concerns about a given routing policy might be. The NOGs lack any support
> for publishing, or even consensus building, and is not global.
>
> Somehow a mixture of the three seems most optimal...
>
> ___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, 26 Apr 2006, Christopher Morrow wrote:
>
> > Date: Wed, 26 Apr 2006 23:14:15 -0400
> > From: Christopher Morrow <christopher.morrow at gmail.com>
> > To: ppml at arin.net
> > Subject: Re: [ppml] "Recommended Practices" procedure
> >
> > On 4/25/06, Marshall Eubanks <tme at multicasttech.com> wrote:
> > > Well, I am not going to say that I disagree about that either, but
> > > it's pretty clear to me that there are interested people here who do
> > > not generally
> > > come to NANOGs or ARIN meetings. Of course, many of them don't come
> > > to IETF's either...
> >
> > is there not a reason to pursue it at both? The problem that Jason
> > (and I think Marla) are dancing around is that in an RIR based
> > solution, or any solution that is not 'globally agreed upon', lends
> > itself to a failed solution.
> >
> > Today, MOST providers will accept and re-advertise a /24 route, this
> > seems to be a 'globally agreed upon' boundary. This is good and bad
> > (debate later). In v6 this hasn't really been set yet, though with
> > 2005-1 passing (potentially, depending on AC I suppose?) the boundary
> > will be /48... it'll quickly be 'all /48' as well I predict.
> >
> > > On Apr 25, 2006, at 6:13 PM, Jason Schiller (schiller at uu.net) wrote:
> > >
> > > > Not that I dis-agree, but why not a BOF at the next NANOG?
> > > >
> > > > ___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 Tue, 25 Apr 2006, Marshall Eubanks wrote:
> > > >
> > > >> Date: Tue, 25 Apr 2006 18:08:43 -0400
> > > >> From: Marshall Eubanks <tme at multicasttech.com>
> > > >> To: "Azinger, Marla" <marla_azinger at eli.net>
> > > >> Cc: Thomas Narten <narten at us.ibm.com>, ppml at arin.net
> > > >> Subject: Re: [ppml] "Recommended Practices" procedure
> > > >>
> > > >> This issue had a big discussion about this at the RIPE-52 meeting now
> > > >> on-going in Istanbul, and I believe
> > > >> that a resolution similar to 2005-1 is likely to result from it. Are
> > > >> you going to ignore them and the other communities.
> > > >>
> > > >> I would suggest a BOF at the Montreal IETF. Here are the parameters
> > > >> for doing this :
> > > >>
> > > >> -----
> > > >> -- Cut-off date for requesting a session: Monday, June 5 at 17:00
> > > >> ET
> > > >> (21:00
> > > >> UTC/GMT).
> > > >> -- Preliminary agenda published for comment: Friday, June 9 by
> > > >> midnight ET.
> > > >> -- Cut-off date for requests to reschedule a session: Wednesday,
> > > >> June
> > > >> 14 at
> > > >> 09:00 ET (13:00 UTC/GMT).
> > > >> -- Final schedule published: Monday, June 19 before midnight ET.
> > > >>
> > > >> Submitting Requests for Working Group and BOF Sessions
> > > >>
> > > >> Please submit requests to schedule your Working Group sessions using
> > > >> the "IETF
> > > >> Meeting Session Request Tool," a Web-based tool for submitting all of
> > > >> the
> > > >> information that the Secretariat requires to schedule your sessions.
> > > >> -----
> > > >>
> > > >> Regards
> > > >> Marshall
> > > >>
> > > >> On Apr 25, 2006, at 5:47 PM, Azinger, Marla wrote:
> > > >>
> > > >>> Also, I feel as though ARIN/NANOG discussion and forum would lead
> > > >>> to a more balanced internet community solution. Keeping a document
> > > >>> that can reside in a specific "reachable" place would be nice. If
> > > >>> it were to reside as a Best business Practice Document with ARIN/
> > > >>> NANOG then I feel the ability to "change" it when needed would also
> > > >>> be easier to accomplish.
> > > >>>
> > > >>> Marla
> > > >>>
> > > >>> -----Original Message-----
> > > >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On
> > > >>> Behalf Of
> > > >>> Thomas Narten
> > > >>> Sent: Tuesday, April 25, 2006 2:17 PM
> > > >>> To: tony.li at tony.li
> > > >>> Cc: ppml at arin.net
> > > >>> Subject: Re: [ppml] "Recommended Practices" procedure
> > > >>>
> > > >>>
> > > >>> "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
> > > >>> _______________________________________________
> > > >>> 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
> > >
> > _______________________________________________
> > 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