Subject: Forwarded mail
From: Susan Hares <[email-masked]>
To: [email-masked]
Date: Thu, 18 Mar 1999 14:26:27 -0500 (EST)

---------- Forwarded message ----------
Date: Mon, 15 Mar 1999 16:15:37 -0500 (EST)
From: [email-masked]
To: [email-masked]
Subject: BOUNCE [email-masked]:    Non-member submission from [Hua Kuang
    <[email-masked]>]   

>From [email-masked] Mon Mar 15 16:15:36 1999
Date: Mon, 15 Mar 1999 16:15:22 -0500 (EST)
From: Hua Kuang <[email-masked]>
To: Abha Ahuja <[email-masked]>
Cc: Tony Li <[email-masked]>,
	Curtis Villamizar <[email-masked]>, [email-masked]
Subject: Re: BGP4 issue?
Sender: [email-masked]

Hi, Abha, 

There is another related issue: AS loop detection.

BGP4 RFC1771 didn't give a definition of AS_LOOP, but request
to tear down peer connection once detected.

Seems to me that a AS receives a path attr contains its own AS#
doen't mean an AS_LOOP, since multicast uses this, RFC says the
receiving speaker set it to unreachable instead of tear down peer.
It's OK, but what is AS_LOOP that should cause the peer  down?

If leave AS_LOOP as it is now, solution 1 works fine in our implementation
and passed test of some more complicated setups.

But, still I think the AS_LOOP detection needs to be clarified, 
and solution 2 seems a better way:
when a BGP route x withdrawn from an upcoming EBGP peer, the local system
should withdraw route x from all the EBGP peers it announced  this route
to, no matter the local system has another replacement BGP route or not,
since the sent out reachable BGP route x  already affected remote peers
decision, the route x also should withdraw when it become unreachable.

BGP-3 actually mentioned this, why it gets removed in BGP-4?
implementation?

Thanks.

Hua Kuang

On Mon, 15 Mar 1999, Abha Ahuja wrote:

> 
> Hi All!
> 
> I've been looking through some BGP data and the RFCs (old and new) and
> seemed to have stumbled upon something rather vague in the BGP4 spec. 
> 
> I talked to various folks about this.  The discussion concluded after
> talking to Tony and Curtis and thus this message. 
> 
> In the following example:
> 
> 		
> 
> 	prefix x  AS A - AS C ----- AS Y ---- AS X --- YourAS
> 		    \			 	 	/			
> 		     \  			       /
> 		      \ 			      /
> 			AS B --- AS Z ------------- MyAS 
> 
> 
> 
> MyAS receives 2 paths for prefix x.  One through AS Z (preferred) and one
> through YourAS.  If MyAS receives an explicit withdraw for the route from
> AS Z, the resulting behavior is not clearly specified in the RFC.
> 
> It appears as if one of two behaviors is acceptable:
> 
> 1) (which is what I would expect) MyAS now has a new best route through YourAS and
> will announce this new route to peers INCLUDING YourAS.  YourAS will receive this from
> MyAS, detect the loop, and withdraw the old route to destination X from
MyAS.  (The
> fact that YourAS (and MyAS) will behave this way is not clear from reading the RFC).
> 
> 2) MyAS will use the route from YourAS.  MyAS will only send YourAS an
> explicit withdraw for the previous route (through ASZ) that it had
> announced (and not announce to YourAS that it is using YourAS to get to x) 
> 
> It seems that the behavior in this scenario is unclear from the
> specification (BGP-3 actually makes some claims for such a situation, but
> BGP-4 does not seem to suggest any behaviors).  Thus, much is left up to
> the specific implementation.  
> 
> If someone chooses to implement BGP in such a way that one of the two
> above suggestions is not followed, incorrect behavior will follow.  For
> example, if MyAS does not send an explicit withdrawal of the old route or
> does not announce a new path to YourAS, YourAS may choose to use the now
> invalid path through MyAS if its previous path ceases to exist (thus
> leading to big problems... *grin*).
> 
> I think that this might need to be clarified in the spec. 
> 
> I decided to send this to the list, because I thought there might be some
> interest.  I would love to hear what people have to say... especially
> regarding specific implementations of BGP...  Please send me
> comments/flames/complaints, etc... 
> 
> Please let me know if I am missing something! (or if
> the above description is too vague.) 
> 
> Thoughts?
> 
> Thanks!
> 
> -abha :)
> 
> 
> __________________________________________________________________________
> --------------------------------------------------------------------------
> abha ahuja						[email-masked]
> Merit Network, Inc.					734.764.0294
> 
> 
> 

Date: Mon, 15 Mar 1999 18:19:20 -0500 (EST)
From: Susan Hares <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: BOUNCE [email-masked]:    Non-member submission from [Hua Kuang <[email-masked]>]    (fwd)
Sender: [email-masked]

---------- Forwarded message ----------
Date: Mon, 15 Mar 1999 16:15:37 -0500 (EST)
From: [email-masked]
To: [email-masked]
Subject: BOUNCE [email-masked]:    Non-member submission from [Hua Kuang <[email-masked]>]   

>From [email-masked] Mon Mar 15 16:15:36 1999
Date: Mon, 15 Mar 1999 16:15:22 -0500 (EST)
From: Hua Kuang <[email-masked]>
To: Abha Ahuja <[email-masked]>
Cc: Tony Li <[email-masked]>,
	Curtis Villamizar <[email-masked]>, [email-masked]
Subject: Re: BGP4 issue?
Sender: [email-masked]

Hi, Abha, 

There is another related issue: AS loop detection.

BGP4 RFC1771 didn't give a definition of AS_LOOP, but request
to tear down peer connection once detected.

Seems to me that a AS receives a path attr contains its own AS#
doen't mean an AS_LOOP, since multicast uses this, RFC says the
receiving speaker set it to unreachable instead of tear down peer.
It's OK, but what is AS_LOOP that should cause the peer  down?

If leave AS_LOOP as it is now, solution 1 works fine in our implementation
and passed test of some more complicated setups.

But, still I think the AS_LOOP detection needs to be clarified, 
and solution 2 seems a better way:
when a BGP route x withdrawn from an upcoming EBGP peer, the local system
should withdraw route x from all the EBGP peers it announced  this route
to, no matter the local system has another replacement BGP route or not,
since the sent out reachable BGP route x  already affected remote peers
decision, the route x also should withdraw when it become unreachable.

BGP-3 actually mentioned this, why it gets removed in BGP-4?
implementation?

Thanks.

Hua Kuang

On Mon, 15 Mar 1999, Abha Ahuja wrote:

> 
> Hi All!
> 
> I've been looking through some BGP data and the RFCs (old and new) and
> seemed to have stumbled upon something rather vague in the BGP4 spec. 
> 
> I talked to various folks about this.  The discussion concluded after
> talking to Tony and Curtis and thus this message. 
> 
> In the following example:
> 
> 		
> 
> 	prefix x  AS A - AS C ----- AS Y ---- AS X --- YourAS
> 		    \			 	 	/			
> 		     \  			       /
> 		      \ 			      /
> 			AS B --- AS Z ------------- MyAS 
> 
> 
> 
> MyAS receives 2 paths for prefix x.  One through AS Z (preferred) and one
> through YourAS.  If MyAS receives an explicit withdraw for the route from
> AS Z, the resulting behavior is not clearly specified in the RFC.
> 
> It appears as if one of two behaviors is acceptable:
> 
> 1) (which is what I would expect) MyAS now has a new best route through YourAS and
> will announce this new route to peers INCLUDING YourAS.  YourAS will receive this from
> MyAS, detect the loop, and withdraw the old route to destination X from
MyAS.  (The
> fact that YourAS (and MyAS) will behave this way is not clear from reading the RFC).
> 
> 2) MyAS will use the route from YourAS.  MyAS will only send YourAS an
> explicit withdraw for the previous route (through ASZ) that it had
> announced (and not announce to YourAS that it is using YourAS to get to x) 
> 
> It seems that the behavior in this scenario is unclear from the
> specification (BGP-3 actually makes some claims for such a situation, but
> BGP-4 does not seem to suggest any behaviors).  Thus, much is left up to
> the specific implementation.  
> 
> If someone chooses to implement BGP in such a way that one of the two
> above suggestions is not followed, incorrect behavior will follow.  For
> example, if MyAS does not send an explicit withdrawal of the old route or
> does not announce a new path to YourAS, YourAS may choose to use the now
> invalid path through MyAS if its previous path ceases to exist (thus
> leading to big problems... *grin*).
> 
> I think that this might need to be clarified in the spec. 
> 
> I decided to send this to the list, because I thought there might be some
> interest.  I would love to hear what people have to say... especially
> regarding specific implementations of BGP...  Please send me
> comments/flames/complaints, etc... 
> 
> Please let me know if I am missing something! (or if
> the above description is too vague.) 
> 
> Thoughts?
> 
> Thanks!
> 
> -abha :)
> 
> 
> __________________________________________________________________________
> --------------------------------------------------------------------------
> abha ahuja						[email-masked]
> Merit Network, Inc.					734.764.0294
> 
> 
> 

Date: Mon, 15 Mar 1999 14:10:05 -0800 (PST)
From: Tony Li <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: BGP4 issue?
Sender: [email-masked]

|  BGP4 RFC1771 didn't give a definition of AS_LOOP, but request
|  to tear down peer connection once detected.

Please refer to the latest draft, not to the RFC.  There have been many
changes. 

|  But, still I think the AS_LOOP detection needs to be clarified, 
|  and solution 2 seems a better way:
|  when a BGP route x withdrawn from an upcoming EBGP peer, the local system
|  should withdraw route x from all the EBGP peers it announced  this route
|  to, no matter the local system has another replacement BGP route or not,
|  since the sent out reachable BGP route x  already affected remote peers
|  decision, the route x also should withdraw when it become unreachable.
|  
|  BGP-3 actually mentioned this, why it gets removed in BGP-4?
|  implementation?

Well, for one thing, sending a withdraw followed by a route would be
received as a flap, and is an unnecessary waste of CPU time.  Thus, it
seems reasonable to either explicitly withdraw or send a new update.  Doing
both is within the bounds of the spec, but as discussed above, to be
discouraged.

Important quotes:

6.3:
          The information carried by the AS_PATH attribute is checked for AS
          loops. AS loop detection is done by scanning the full AS path (as
          specified in the AS_PATH attribute), and checking that the autonomous
          system number of the local system does not appear in the AS path. If
          the autonomous system number appears in the AS path the route may be
          stored in the Adj-RIB-In, but unless the router is configured to
          accept routes with its own autonomous system in the AS path, the
          route shall not be passed to the BGP Decision Process. Operations of
          a router that is configured to accept routes with its own autonomous
          system number in the AS path are outside the scope of this document.

9.1.3:
          For the benefit of future support of inter-AS multicast capabilities,
          a BGP speaker that participates in inter-AS multicast routing shall
          advertise a route it receives from one of its external peers and if
          it installs it in its Loc-RIB, it shall advertise it back to the peer
          from which the route was received. For a BGP speaker that does not
          participate in inter-AS multicast routing such an advertisement is
          optional.

Given these passages, I don't believe that any change to the spec is
required.

Tony

Date: Mon, 15 Mar 1999 03:02:26 -0500 (EST)
From: Abha Ahuja <[email-masked]>
To: Tony Li <[email-masked]>, Curtis Villamizar <[email-masked]>
Cc: Abha Ahuja <[email-masked]>, [email-masked]
Subject: BGP4 issue?
Sender: [email-masked]

Hi All!

I've been looking through some BGP data and the RFCs (old and new) and
seemed to have stumbled upon something rather vague in the BGP4 spec. 

I talked to various folks about this.  The discussion concluded after
talking to Tony and Curtis and thus this message. 

In the following example:

	prefix x  AS A - AS C ----- AS Y ---- AS X --- YourAS
		    \			 	 	/			
		     \  			       /
		      \ 			      /
			AS B --- AS Z ------------- MyAS 

MyAS receives 2 paths for prefix x.  One through AS Z (preferred) and one
through YourAS.  If MyAS receives an explicit withdraw for the route from
AS Z, the resulting behavior is not clearly specified in the RFC.

It appears as if one of two behaviors is acceptable:

1) (which is what I would expect) MyAS now has a new best route through YourAS and
will announce this new route to peers INCLUDING YourAS.  YourAS will receive this from
MyAS, detect the loop, and withdraw the old route to destination X from MyAS.  (The
fact that YourAS (and MyAS) will behave this way is not clear from reading the RFC).

2) MyAS will use the route from YourAS.  MyAS will only send YourAS an
explicit withdraw for the previous route (through ASZ) that it had
announced (and not announce to YourAS that it is using YourAS to get to x) 

It seems that the behavior in this scenario is unclear from the
specification (BGP-3 actually makes some claims for such a situation, but
BGP-4 does not seem to suggest any behaviors).  Thus, much is left up to
the specific implementation.  

If someone chooses to implement BGP in such a way that one of the two
above suggestions is not followed, incorrect behavior will follow.  For
example, if MyAS does not send an explicit withdrawal of the old route or
does not announce a new path to YourAS, YourAS may choose to use the now
invalid path through MyAS if its previous path ceases to exist (thus
leading to big problems... *grin*).

I think that this might need to be clarified in the spec. 

I decided to send this to the list, because I thought there might be some
interest.  I would love to hear what people have to say... especially
regarding specific implementations of BGP...  Please send me
comments/flames/complaints, etc... 

Please let me know if I am missing something! (or if
the above description is too vague.) 

Thoughts?

Thanks!

-abha :)

__________________________________________________________________________
--------------------------------------------------------------------------
abha ahuja						[email-masked]
Merit Network, Inc.					734.764.0294