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

[Uli Bornhauser <[e-mail]>]

Hi Jakob,

Am 12.05.2010 um 16:18 schrieb Jakob Heitz:

> I remember an attribute: attr_set in an expired draft that solves this problem
> http://tools.ietf.org/id/draft-pmohapat-idr-fast-conn-restore-00.txt
> Whatever happened to it?

yes, applied correctly, the Border Router Attribute Set could solve the problem. However, the modifications sketched in this draft are not completely unproblematic, too. I sketched a problematic example in an email I send to the list on Dec. 04th, 2008.

Best Regards

Uli

> -- 
> Jakob Heitz.
> 
>  
> 
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Uli Bornhauser
> Sent: Wednesday, May 12, 2010 3:14 AM
> To: John Scudder
> Cc: Inter-Domain Routing List
> Subject: Re: [Idr] draft-walton-bgp-route-oscillation-stop as an IDR WG document
> 
> Hi John, Pierre, all,
> 
>>> 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
> 
> John, yes, you are of course absolutely right. My example was a little bit too simple. 
> 
> Am 11.05.2010 um 17:29 schrieb Pierre Francois:
> 
>> 
>> John,
>> 
>> If paths p1 and p2 were coming from the same ASBR, the problem comes back, no ?
> 
> 
> However, it seems easy to modify the example so that the basic problem remains: 
> 
>               |
> p1->  |----|  |
> ------|    |  |
>       |----|  |
>             \ /
>              \
> AS1         / \
> -----------/  |----|  1  |----|
>               | R1 |-----| R2 |
> -----------\  |----|     |----|
> AS2         \ /
>              /
>             / \
> p2->  |----|  |
> ------|    |  |
>       |----|  |
> 
> Let assume that p1 and p2 are advertised from external ASs to the Route Reflector R1. In this case, according to RFC4456, the Originator ID is not set by the Reflector R1:
> 
>    ORIGINATOR_ID is a new optional, non-transitive BGP attribute of Type
>    code 9.  This attribute is 4 bytes long and it will be created by an
>    RR in reflecting a route.  This attribute will carry the BGP
>    Identifier of the originator of the route in the local AS.  A BGP
>    speaker SHOULD NOT create an ORIGINATOR_ID attribute if one already
>    exists.  A router that recognizes the ORIGINATOR_ID attribute SHOULD
>    ignore a route received with its BGP Identifier as the ORIGINATOR_ID.
> 
> We have no *local* originator and RR1 does not "reflect" a path in the closer sense. Thus, the originator ID is not specified in the path advertisements. So Pierre is right if the ASBR is a Route Reflector. Because the best path cannot be determined uniquely in all configurations, [1] may induce a problematic side-effect. If the ASBR is a common client, it only advertises its (one unique) best path, cf. [1]. In that case, the problem I have in mind should not occur.
> 
> Regards
> 
> Uli
> 
> [1] http://www.ietf.org/id/draft-walton-bgp-route-oscillation-stop-03.txt
> 
>> 
>> Using the NEXT_HOP attribute will also lead to the same issue when the ASBR sets nexthop to self.
>> 
>> Regards,
>> 
>> Pierre.
>> 
>> 
>> John Scudder wrote:
>>> 
>>> 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
>> 
> 
> -- 
> _______________________________________________________
> 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

-- 
_______________________________________________________
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