Re: 1-prefix, 1-AS question

Curtis Villamizar <curtis@ans.net> Thu, 26 October 1995 20:48 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23972; 26 Oct 95 16:48 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23968; 26 Oct 95 16:48 EDT
Received: from interlock.ans.net by CNRI.Reston.VA.US id aa17804; 26 Oct 95 16:48 EDT
Received: by interlock.ans.net id AA24949 (InterLock SMTP Gateway 3.0 for iwg-out@ans.net); Thu, 26 Oct 1995 15:57:50 -0400
Message-Id: <199510261957.AA24949@interlock.ans.net>
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 26 Oct 1995 15:57:50 -0400
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 26 Oct 1995 15:57:50 -0400
To: Paul Traina <pst@cisco.com>
Cc: curtis@ans.net, KD2D-IANN@j.asahi-net.or.jp, bgp@ans.net
Reply-To: curtis@ans.net
Subject: Re: 1-prefix, 1-AS question
In-Reply-To: Your message of "Thu, 26 Oct 1995 11:59:41 PDT." <199510261859.LAA03894@puli.cisco.com>
Date: Thu, 26 Oct 1995 16:01:37 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Curtis Villamizar <curtis@ans.net>

In message <199510261859.LAA03894@puli.cisco.com>om>, Paul Traina writes:
> 
> It seems to me to be quite reasonable to aggregate across provider
> boundaries today, thanks to our friend, the "AS_SET" as-path
> sub-type.

We (providers collectively) just don't have our act together wrt
coordinating aggregation across multiple providers.

> The only case where you would not wish to do this is if there was a
> requirement to distinguish differing routing policies.  However, given
> that that requirement is likely not global in nature, I see no great
> benefit at burdening the entire Internet with individual provider ASs.
> 
> Given my belief that you are aware of the ability of the global
> routing infrastructure to handle this situation,  is your concern due
> to a limitation in the configuration utility you are using?

Yes.  And ad hoc configuration (manual edit) makes the chance of error
and misrouting even greater.

> If so, how do you cope with second-level aggregation today?
> 
> (Continuation of this discussion belongs on CIDRD, not BGP, unless
>  there are actual BGP protocol issues at stake here.)
> 
> Paul

No protocol issues.  No continuation needed at this point.

Curtis