Food for thought:
- ASNs can be reused at different locations by IXPs, barring perhaps
certain business or administrative reasons. Ask Equinix.
- For IXPs that already have 16-bit ASNs for route servers, this saves
additional
allocations from RIRs and mitigates concerns for the IXP getting pote
On Feb 5, 2014, at 9:21 AM, Jeffrey Haas wrote:
> The wide comms draft (and flex comms, where some of the ideas were pulled in
> from) was intended to address the messier case where the meaning of a
> community was already structured. To pick on one of the items in the list:
> http://www.onesc.
On Wed, Feb 05, 2014 at 09:02:52AM -0500, Jared Mauch wrote:
>
> On Feb 5, 2014, at 8:52 AM, Jeffrey Haas wrote:
>
> >> This draft does not cater for the use case of describing a 32-bit ASN
> >> peering
> >> with a 32-bit route server, which would require a 4-byte Global
> >> Administrator
> >
On Feb 5, 2014, at 8:52 AM, Jeffrey Haas wrote:
>> This draft does not cater for the use case of describing a 32-bit ASN peering
>> with a 32-bit route server, which would require a 4-byte Global Administrator
>> as well as a 4-byte Local Administrator sub-field.
>
> I think that's the first cl
Martin,
On Wed, Feb 05, 2014 at 10:06:31AM +0100, Martin Pels wrote:
> > Wide communities is the wrong tool here. You want this:
> > http://tools.ietf.org/html/draft-ietf-idr-as4octet-extcomm-generic-subtype-06
>
> This draft does not cater for the use case of describing a 32-bit ASN peering
> wi
> The token to simplify is currently mine. The messy bit was an attempt
> to try to push policy algebra into the packet format.
jeezus!
> Cleaning up the document will take probably another two rounds but a
> terse description of where it should be going is "template based
> structured communitie
Jeffrey,
On Tue, 4 Feb 2014 22:53:40 -0500
Jeffrey Haas wrote:
>
>
> Sent from my iPad
>
> > On Jan 25, 2014, at 1:37 PM, Nick Hilliard wrote:
> >
> >> On 25/01/2014 15:48, Sebastian Spies wrote:
> >> To make things worse: even if the IXPs ASN is 2-byte, I would assume,
> >> that RS impleme
Sent from my iPad
On Jan 25, 2014, at 5:50 PM, Randy Bush wrote:
>> http://tools.ietf.org/search/draft-raszuk-wide-bgp-communities-03
>> To me, that draft looks hugely complicated, like everything you
>> could possibly think of was thrown in.
>
>
>
> do we have a chat with robert or push an
Sent from my iPad
> On Jan 25, 2014, at 1:37 PM, Nick Hilliard wrote:
>
>> On 25/01/2014 15:48, Sebastian Spies wrote:
>> To make things worse: even if the IXPs ASN is 2-byte, I would assume,
>> that RS implementors chose to interpret extended community strings as
>> always being in the format
On Sat, 25 Jan 2014 14:56:16 +0100, Sebastian Spies said:
> ASNs. First of all, we have no data or experience about 4-byte ASN
> adoption and are therefore unable to evaluate, if we should rush for the
> last available numbers.
2-byte ASN depletion - the other white meat
pgpGzY2hmFQkH.pgp
On 25/01/2014 22:50, Randy Bush wrote:
> do we have a chat with robert or push an alternative so that the wg is
> pushed to compromise?
i get the impression that Robert realises that the current draft is
unworkably complicated.
Nick
> http://tools.ietf.org/search/draft-raszuk-wide-bgp-communities-03
> To me, that draft looks hugely complicated, like everything you
> could possibly think of was thrown in.
do we have a chat with robert or push an alternative so that the wg is
pushed to compromise?
randy
contained just useful stuff.
--
Jakob Heitz.
Date: Sat, 25 Jan 2014 18:37:42 +
From: Nick Hilliard
To: Sebastian Spies , nanog@nanog.org
Subject: Re: Route Server Filters at IXPs and 4-byte ASNs
Message-ID: <52e40476.20...@foobar.org>
Conten
On 25/01/2014 15:48, Sebastian Spies wrote:
> To make things worse: even if the IXPs ASN is 2-byte, I would assume,
> that RS implementors chose to interpret extended community strings as
> always being in the format 4-byte:2-byte (see RFC5668).
some ixp operators (e.g. me) are rather enthusiastic
Am 25.01.2014 16:38, schrieb Bryan Socha:
> Re-reading, I was thinking of someone connecting to an IXP, not a new
> IXP needing a 2Byte.This is an interesting situation and you are
> correct, my comment was off topic.
Sorry for not mentioning the beef: Extended Communities effectively
leave 6
Re-reading, I was thinking of someone connecting to an IXP, not a new IXP
needing a 2Byte.This is an interesting situation and you are correct,
my comment was off topic.
*Bryan Socha*
Network Engineer
646.450.0472 | *br...@serverstack.com *
*ServerStack* | Scale Big
On Sat, Jan 25, 2014 a
On Sat, Jan 25, 2014 at 10:04:30AM -0500, Bryan Socha wrote:
> I have over 100,000 servers located in routing diverse datacenters
> with 4byte ASN numbers and have not had 1 problem or complaint related
> to the ASN for not able to communicate with the datacenter. The first
> 1 did make me really
I have over 100,000 servers located in routing diverse datacenters with
4byte ASN numbers and have not had 1 problem or complaint related to the
ASN for not able to communicate with the datacenter. The first 1 did make
me really nervous for all of the reasons already mentioned but turned out
to be
Dear Sebastian,
On Sat, Jan 25, 2014 at 02:56:16PM +0100, Sebastian Spies wrote:
> So here's the thing: IXPs usually implement N:M filtering based on
> standard community strings. As standard BGP communities support only 4
> bytes, this only works for IXPs with 2-byte ASNs and peers with 2-byte
>
>
> What happens, if the IXP uses a 4-byte ASN? RFC5668 (4-Octet AS Specific
> BGP Extended Community) defines : 2bytes>.
>
> I have been asking some IXP operators, about their practice and their
> reply was "4-byte ASNs are supported by our RS". What's your experience?
> Did you see IXPs, that do
Hi there,
as 2-byte ASNs are close to depletion (see NRO announcement this week),
we have come across a topic, that might influence the adoption of 4-byte
ASNs. First of all, we have no data or experience about 4-byte ASN
adoption and are therefore unable to evaluate, if we should rush for the
las
21 matches
Mail list logo
