Re: [Idr] draft-walton-bgp-route-oscillation-stop as an IDR WG document

[Pierre Francois <[e-mail]>]

John,

If paths p1 and p2 were coming from the same ASBR, the problem comes back, no ?

Using the NEXT_HOP attribute will also lead to the same issue when the ASBR sets 
nexthop to self.

Regards,

Pierre.


John Scudder wrote:
> Uli,
> 
> Doesn't this text from RFC 4456 address your point?
> 
>       If a route carries the ORIGINATOR_ID attribute, then in Step f)
>       the ORIGINATOR_ID SHOULD be treated as the BGP Identifier of the
>       BGP speaker that has advertised the route.
> 
>       In addition, the following rule SHOULD be inserted between Steps
>       f) and g): a BGP Speaker SHOULD prefer a route with the shorter
>       CLUSTER_LIST length.  The CLUSTER_LIST length is zero if a route
>       does not carry the CLUSTER_LIST attribute.
> 
> Regards,
> 
> --John
> 
> On May 11, 2010, at 4:38 AM, Uli Bornhauser wrote:
> 
>> Hi Daniel, other authors, all,
>>
>> one comment, more precisely a question: What about potential problems the "BGP Persistent Route Oscillation Solutions" may cause? For example, if I did not miss an important aspect, the concept may cause situations where BGP speakers cannot choose a unique best path any more:
>>
>>                    |
>>            clusterI|clusterII
>> p1->  |----|       |
>> ------| C1 |       |
>>       |----|       |
>>             \ 1    |
>>             |----| |1  |----|
>>             | R1 |-----| R2 |
>>             |----| |   |----|
>>             / 1    |
>> p2->  |----|       |
>> ------| C1 |       |
>>       |----|       |
>>  
>> C1 and C2 both provide their best path (externally learned via different ASs, same LOCAL_PREF, AS_PATH length, etc.) to R1. R1 in turn advertises these paths (p1 and p2) to R2 according to your draft. As both paths are learned via the same session, the common BGP tie breaker process does not work at this point: Even after executing step g) [1], both paths are still in the decision process. Obviously, randomly choosing one path does not work, too. Is there a simple solution for this problem (I missed it in the draft)? I think either a modification of the selection process or new attributes are needed (which seem to be in conflict with the statement that only minor changes are needed at the most BGP speakers, cf. 5. Deployment Considerations). If I did not miss a point, this observation leads to the following question whether advertising "all Paths" / "Group Best Paths" may cause other, not that obvious problems.
>>
>> Thanks in advance for the clarification and
>>
>> Best Regards
>>
>> Uli
>>
>> [1] RFC4271 - http://www.ietf.org/rfc/rfc4271
>>
>> Am 10.05.2010 um 23:00 schrieb John Scudder:
>>
>>> Folks,
>>>
>>> We have received a request to adopt draft-walton-bgp-route-oscillation-stop as an IDR working group document.  Please send comments to the list.  The deadline for comments is May 25, 2010.
>>>
>>> --John
>>>
>>> -------- 
>>> Subject:	I-D Action:draft-walton-bgp-route-oscillation-stop-03.txt
>>> Date:	Mon, 10 May 2010 11:30:02 -0700 (PDT)
>>> From:	[e-mail]
>>> Reply-To:	[e-mail]
>>> To:	[e-mail]
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>
>>> 	Title           : BGP Persistent Route Oscillation Solutions
>>> 	Author(s)       : D. Walton, et al.
>>> 	Filename        : draft-walton-bgp-route-oscillation-stop-03.txt
>>> 	Pages           : 9
>>> 	Date            : 2010-05-10
>>>
>>> In this document we present two sets of paths for an address prefix
>>> that can be advertised by a BGP route reflector or confederation ASBR
>>> to eliminate the MED-induced route oscillations in a network.  The
>>> first set involves all the available paths, and would achieve the
>>> same routing consistency as the full IBGP mesh.  The second set,
>>> which is a subset of the first one, involves the neighbor-AS based
>>> Group Best Paths, and would be sufficient to eliminate the MED-
>>> induced route oscillations (subject to certain commonly adopted
>>> topological constrains).
>>>
>>> A URL for this Internet-Draft is:
>>>
>>> http://www.ietf.org/internet-drafts/draft-walton-bgp-route-oscillation-stop-03.txt
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>>
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>>
>>> Below is the data which will enable a MIME compliant mail reader
>>> implementation to automatically retrieve the ASCII version of the
>>> Internet-Draft.
>>>
>>>
>>> _______________________________________________
>>> Idr mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/idr
>> -- 
>> _______________________________________________________
>> ULI BORNHAUSER
>> University of Bonn - Institute of Computer Science IV
>> c/o Bonn-Aachen International Center for Information Technology B-IT 
>> Dahlmannstr. 2 - D-53113 Bonn - Germany
>>
>> Web: www.cs.bonn.edu/IV/ub
>> Email: [e-mail]			
>> Phone: [phone]
>> Fax: [phone] - 4571
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>