Re: 1-prefix, 1-AS question

Paul Traina <pst@cisco.com> Thu, 26 October 1995 19:41 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22005; 26 Oct 95 15:41 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa21998; 26 Oct 95 15:41 EDT
Received: from interlock.ans.net by CNRI.Reston.VA.US id aa16567; 26 Oct 95 15:41 EDT
Received: by interlock.ans.net id AA23311 (InterLock SMTP Gateway 3.0 for iwg-out@ans.net); Thu, 26 Oct 1995 14:59:46 -0400
Message-Id: <199510261859.AA23311@interlock.ans.net>
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 26 Oct 1995 14:59:46 -0400
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 26 Oct 1995 14:59:46 -0400
To: curtis@ans.net
Cc: KD2D-IANN@j.asahi-net.or.jp, bgp@ans.net
Subject: Re: 1-prefix, 1-AS question
In-Reply-To: Your message of "Thu, 26 Oct 1995 13:34:40 EDT." <199510261731.AA21116@interlock.ans.net>
Date: Thu, 26 Oct 1995 11:59:41 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Paul Traina <pst@cisco.com>

  From: Curtis Villamizar <curtis@ans.net>
  Subject: Re: 1-prefix, 1-AS question 
  
  In the future it may be possible to aggregate across provider
  boundaries so that distant sites such as the US still see just an
  aggregate pointing across the Pacific (or perhaps across the Asian
  continent, in other cases).

To paraphrase a 1950's US TV character, "What future, white man?"

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.

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?

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