draft-ietf-idr-avoid-transition-03.txt   draft-ietf-idr-avoid-transition-04.txt 
Network Working Group E. Chen Network Working Group E. Chen
Internet Draft S. Sangli Internet Draft S. Sangli
Expiration Date: May 2006 Cisco Systems Expiration Date: June 2006 Cisco Systems
Avoid BGP Best Path Transitions from One External to Another Avoid BGP Best Path Transitions from One External to Another
draft-ietf-idr-avoid-transition-03.txt draft-ietf-idr-avoid-transition-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 36 skipping to change at page 2, line 36
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. The Algorithm 3. The Algorithm
Consider the case in which the existing best path A is from an Consider the case in which the existing best path A is from an
external peer, and another external path B is then selected as the external peer, and another external path B is then selected as the
new best path by the route selection algorithm described in [BGP]. new best path by the route selection algorithm described in [BGP].
When neither Path A nor Path B is eliminated by the route selection When comparing all the paths in route selection, if neither Path A
algorithm prior to Step f) - BGP identifier comparison (Sect. 9.1.2.2 nor Path B is eliminated by the route selection algorithm prior to
[BGP]), we propose that the existing best path (Path A) be kept as Step f) - BGP identifier comparison (Sect. 9.1.2.2 [BGP]), we propose
the best path (thus avoiding switching the best path to Path B). that the existing best path (Path A) be kept as the best path (thus
avoiding switching the best path to Path B).
This algorithm SHOULD NOT be applied when either path is from a BGP This algorithm SHOULD NOT be applied when either path is from a BGP
Confederation peer. Confederation peer.
In addition, the algorithm SHOULD NOT be applied when both paths are In addition, the algorithm SHOULD NOT be applied when both paths are
from peers with identical BGP identifier (i.e., there exist parallel from peers with identical BGP identifier (i.e., there exist parallel
BGP sessions between two BGP speakers). As the peering addresses for BGP sessions between two BGP speakers). As the peering addresses for
the parallel sessions are typically allocated by one AS (possibly the parallel sessions are typically allocated by one AS (possibly
with route selection considerations), the algorithm (if applied) with route selection considerations), the algorithm (if applied)
could impact the existing routing setup. Furthermore, by not applying could impact the existing routing setup. Furthermore, by not applying
 End of changes. 3 change blocks. 
6 lines changed or deleted 7 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/