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

[Pierre Francois <[e-mail]>]

Uli,

 > 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].

Haaa, right.

Note that with this ASBR behavior we miss the nice side gain of solving MED 
Disrespect states although we were almost at it thanks to this draft.

Let us assume that a group best path p1 is not the best path of the ASBR that 
receives it, because it prefers another eBGP path received from another 
neighboring AS, say, based on router-id.

p1 will not be advertised to the RRs and hence will not be reflected to those 
routers who have other paths coming from the same neighboring AS as p1.

These routers, not knowing about p1, could pick as best a path p2 from the same 
neighboring AS, although p2 has an higher MED value than p1, because they don't 
know about p1.

If [1] was suggesting that the ASBR could also propagate (non best) AS Group 
best paths with add-paths, p1 would be advertised to the RRs, which would 
reflect them to those who initially picked p2, so that they will be forced to 
respect the MED and pick another path.

If we do allow non-RR ASBRs to propagate non best AS Group Best path in 
add-paths, we absolutely need the attr_set attribute from
draft-pmohapat-idr-fast-conn-restore-00 . But we need it for all
the good reasons listed in the draft, anyway.

Regards,

Pierre.

> 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] <mailto:[e-mail]>
>>>>> Reply-To: [e-mail] <mailto:[e-mail]>
>>>>> To: [e-mail] <mailto:[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] <mailto:[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 <http://www.cs.bonn.edu/IV/ub>
>>>> Email: [e-mail] <mailto:[e-mail]>
>>>> Phone: [phone]
>>>> Fax: [phone] - 4571
>>>>
>>>> _______________________________________________
>>>> Idr mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/idr
>>> _______________________________________________
>>> Idr mailing list
>>> [e-mail] <mailto:[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 <http://www.cs.bonn.edu/IV/ub>
> Email: [e-mail] <mailto:[e-mail]>
> Phone: [phone]
> Fax: [phone] - 4571
>