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

[Jakob Heitz <[e-mail]>]

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?

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