Re: Draft on the textual representation of AS Numbers

----- Original Message -----
From: "Jeffrey Haas" <jhaas <at> pfrc.org>
To: "tom.petch" <cfinss <at> dial.pipex.com>
Cc: "Paul Jakma" <paul <at> clubi.ie>; "idr" <idr <at> ietf.org>
Sent: Sunday, August 31, 2008 2:56 AM
Subject: Re: [Idr] Draft on the textual representation of AS Numbers

> On Sat, Aug 30, 2008 at 06:45:50PM +0200, tom.petch wrote:
> > I think that one of the great inventions that helped the progress of IPv4
was
> > dotted decimal, so simple that it is under-rated.  I do not want long AS
numbers
> > to be the experiment that demonstrates how great a convention dotted decimal
is
>
> I wasn't there and this is *complete* speculation:

I agree, but then much if not most of this thread is speculation.

Will the growth in AS numbers continue at it present rate, or will there be a
sudden upsurge taking us over 100,000?

Will the AS number remain structureless, or will a structure be imposed, 8-24,
16-16, 12-20, ...?

Will there be problems with the presentation of six digit numbers?

Will the presentation stay decimal based, or will there be a case for
hexadecimal?

Re: Draft on the textual representation of AS Numbers

On Sep 1, 2008, at 10:14 AM, tom.petch wrote:
> Will the growth in AS numbers continue at it present rate, or will  
> there be a
> sudden upsurge taking us over 100,000?

I'd be (more than) willing to bet Geoff's life that we'll go over  
100,000 ASes, even without a significant change in usage patterns.   
Going over 1,000,000 is more speculative (but I'd still be willing to  
bet Geoff's life ).

However, I'm not sure this matters all that much.  Presumably if  
presentation of AS numbers becomes problematic, routing software  
vendors will come out with tools to make input/verification of those  
AS numbers easier.

Regards,
-drc

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr

Re: Draft on the textual representation of AS Numbers

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr

Re: Draft on the textual representation of AS Numbers

On 30/08/2008, at 12:02 AM, Paul Jakma wrote:

> On Thu, 28 Aug 2008, tom.petch wrote:
>
>> And I do not see even-six digit numbers as easy to read, transcribe
>> and input accurately, I think that structure is needed at the level
>> of eg 142421 or 133322 to reduce the risks of transcription error.
>
> We already have ways of spacing decimal digits to increase
> legibility. The exact details differ between locales, but I believe
> SI recognises ',' or '.' to group on 10^(3n) boundaries (one more
> popular with British-influenced locales, the other for the more
> francophilic locales):
>
> 	142,421
> 	142.421
>
> Standard library routines exist to, at least, display numbers in such
> forms, in various languages.

errrrk - Is this post seriously proposing the use of a notation that
uses commas to create a grouping of 3 digit clusters?

please, "no" to this format!

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr

Re: Draft on the textual representation of AS Numbers

On 02/09/2008, at 5:39 AM, David Conrad wrote:

> On Sep 1, 2008, at 10:14 AM, tom.petch wrote:
>> Will the growth in AS numbers continue at it present rate, or will
>> there be a
>> sudden upsurge taking us over 100,000?
>
> I'd be (more than) willing to bet Geoff's life that we'll go over
> 100,000 ASes, even without a significant change in usage patterns.
> Going over 1,000,000 is more speculative (but I'd still be willing to
> bet Geoff's life ).

gee thanks David - I guess.

100,000 seems like life as normal for me too. 1 million is a bit of a  
stretch, but 100,000 seemed like a bit of a stretch 10 years ago.

>
>
> However, I'm not sure this matters all that much.  Presumably if
> presentation of AS numbers becomes problematic, routing software
> vendors will come out with tools to make input/verification of those
> AS numbers easier.
>

heh heh - never! I'll bet David's life that the CLI for the popular  
vendor's products will look precisely the same in 5 years time as it  
does now. Indeed I'll bet David's life that if aforesaid vendor is  
still in business 20 years from now it will be same CLI then too. 

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr

Re: Draft on the textual representation of AS Numbers

On Tue, 2 Sep 2008, Geoff Huston wrote:

> errrrk - Is this post seriously proposing the use of a notation that
> uses commas to create a grouping of 3 digit clusters?

It was an observation (easily seen in this thread, including in your 
email after the above ;) ), that humans already have ways to space 
out large decimal numbers, which can be applied where they deem it 
appropriate.

I'm not in favour of the adoption of /any/ official seperator for 
ASNs and I hope we continue with the use of the traditional 'asplain' 
format. That said, whatever way people write ASNs in the privacy of 
their own NOCs is their own business.

regards,
--

-- 
Paul Jakma	paul <at> clubi.ie	paul <at> jakma.org	Key ID: 64A2FF6A
Fortune:
A conclusion is simply the place where someone got tired of thinking.
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr

BGP MRAI Configuration

Folks,

We are pursuing some work along the lines of studying BGP
scalability in terms of churn evolution. One of the key mechanisms
used by BGP to dampen the churn is the MRAI timer (Minimum Route
Advertisement Interval).

From different vendors' specifications we find that:

1- Cisco enables MRAI by default for both route announcements and route
withdrawals.
2- Juniper has a  similar parameter called out-delay which is disabled
by default.

Of course these are default configurations,  and we don't know if
ISPs use them without any change. We would appreciate any input on the
following questions:

A- Is it common that ISPs change MRAI default configurations? If yes,
then what decides the MRAI settings for both e-BGP and i-BGP sessions?
B- Does anybody use a configuration where only route announcements are
rate limited, and not explicit route withdrawals?
C- Are there configurations where rate limiting is applied only to a
subset of session?

Best regards,

Ahmed Elmokashfi
Simula Research Laboratory.

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr

Re: BGP MRAI Configuration

Hi Ahmed,

This may not answer your questions, but you might be interested in a
discussion on this list and the RRG list in June 2007 about the MRAI
timer, path hunting and the history of how the RFCs changed.

I keep links to this discussion at:

http://www.firstpr.com.au/ip/sram-ip-forwarding/#BGP_hunting_MRAI_disc

The discussion started on the RRG:

  http://psg.com/lists/rrg/2007/maillist.html#00146

and moved to the IDR list:

  http://www.ietf.org/mail-archive/web/idr/current/msg02414.html

Tony Li gave his understanding of path hunting:

  http://www.ietf.org/mail-archive/web/idr/current/msg02422.html

    - Robin

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr

Re: BGP MRAI Configuration

On Tue, Sep 02, 2008 at 10:28:20PM +1000, Robin Whittle wrote:
> Tony Li gave his understanding of path hunting:
> 
>   http://www.ietf.org/mail-archive/web/idr/current/msg02422.html

The biggest words of wisdom, IMO, are these:

"As always, I think that the RFC is a fine goal, and that implementors
frequently take short cuts that may or may not be warranted. I'm not
throwing rocks at them because frankly, many of those rocks would end up
back in my lap. As I noted earlier, implementing MRAI per the letter of
the spec is non-trivial, and I sympathize with those who decided not to
implement it."

The BGP timers are non-trivial when you think about them in terms of
*per-peer*.  RFC 4271 got some wiggle room from previous versions of the
spec:

: This can only be achieved by keeping a separate timer for each common
: set of destinations.  This would be unwarranted overhead.  Any technique
: that ensures[...]

Thus, when analyzing MRAI implementations, it's a good idea to observe
what happens to multiple peers when reachability has cause to churn.
The behavior is probably not what you'd expect.

One unfortunate thing about RFC 4271 is that it didn't catch a bit of
common wisdom that MRAI shouldn't apply to explicit withdrawals.  The
"bad news should travel faster" observation wasn't proved to some
people's satisfaction.

-- Jeff
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr

BACKUP well-known community?

Hi all,

Gao and Rexford [1] show that BGP will converge if ASes observe a  
number of guidelines in their policy configurations. These guidelines  
are fairly reasonable, but guideline C requires that all paths that go  
through a backup link are marked as such and receive a lower local  
preference in ALL ASes. They suggest using a community to convey this  
information. However, such a community doesn't exist today.

Shouldn't we create one?

Iljitsch

[1] L. Gao, J. Rexford. Stable Internet Routing Without Global  
Coordination. Proc. ACM SIGMETRICS, June 2000.
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr