IETF Logo Mail Archive

Re: CA*net report

Guy Almes <almes@rice.edu> Thu, 22 March 1990 14:38 UTC

Received: by devvax.TN.CORNELL.EDU (5.59-1.12/1.3-Cornell-Theory-Center) id AA08204; Thu, 22 Mar 90 09:38:12 EST
Received: from rice.edu by devvax.TN.CORNELL.EDU (5.59-1.12/1.3-Cornell-Theory-Center) id AA08200; Thu, 22 Mar 90 09:38:06 EST
Received: from iapetus.rice.edu by rice.edu (AA09154); Thu, 22 Mar 90 08:37:55 CST
Received: by iapetus.rice.edu (AA11657); Thu, 22 Mar 90 08:38:12 CST
Date: Thu, 22 Mar 1990 08:38:12 -0600
From: Guy Almes <almes@rice.edu>
Message-Id: <9003221438.AA11657@iapetus.rice.edu>
To: dennis@gw.ccie.utoronto.ca, swb@dainichi.tn.cornell.edu
Subject: Re: CA*net report
Cc: tewg@devvax.TN.CORNELL.EDU

Dennis is right.  He looked at the BGP protocol draft and correctly under-
stood that it prohibited "third party" BGP in the case where A tells B
that C is the best next hop *and* A and C are not in the same AS.
  Our feeling is that allowing this trans-AS form of third party adverti-
sing would lead to several problems.  I'll briefly mention two:
<> conceptual simplicity.  We very much want a situation in which the
   'advertisement graph' of ASes as nodes and BGP conversations as arcs
   is congruent with the 'traffic flow graph' of ASes as nodes and traffic
   flows as arcs.
<> border gateway control.  Simply the idea that only a BGP speaker in a
   given AS should direct others to send traffic to that AS.
I had mixed feelings about this issue, particularly when faced with Dennis's
specific scheme, but on balance I think it would be a bad idea to relax this
rule.
	-- Guy

v2.23.0 | Report a Bug | By Email