# Distribution of Diverse BGP Paths RFC 6774

Yes

(Ron Bonica)

No Objection

(Barry Leiba)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Pete Resnick)
(Robert Sparks)
(Russ Housley)
(Sean Turner)
(Wesley Eddy)

Note: This ballot was opened for revision 07 and is now closed.

Ron Bonica Former IESG member
Yes
Yes (for -07)

(was Discuss) No Objection
No Objection (2012-08-09)
```Thank you for addressing my Discuss issues and my Comments.

In re-reading to check that my Discuss had been addressed I noted one further point (or rather an elaboration of a previous point). I am raising thise as a Comment rather than perpetuating my Discuss.

- - - -

I'm sorry to get hung up on the word "best" again. I am still having
trouble deciding whether "N best paths" means that there are N paths
of equivalent bestness, or whether there are N paths where some are
better than others.

E.g., In the set {9, 9, 8, 7, 6} could you set N=3 and select (9, 9, 8)
as the N highest numbers? Or would the set force you set N= 2 and only
select (9, 9) as the N highest numbers?

This distinction may be why I was getting confused about ordering. If
you are considering that all N paths are "equally best" then a lot of
my concern goes away, but it would be really helpful to make this
clarification in the text. That clarification would be something like:

In the context of this document we consider N paths to all be best
paths if they are for all purposes equally selectable as the best
path by a BGP implementation.

If, however, you are allowing "N paths where some are better than
others" then I see two subcategories:

1. The degree of bestness is sufficiently close that it would not
matter if any one of the paths was selected. This case collapses
into the previous pont, but the text needs to be ammended to
explain the selection process.

2. There is a significant distinction between members of the set of N
paths such that were the best of the best to fail, the next best
choice would be a limited choice from the full set of N. In this
case there would appear to be a need to distinguish those that are
"less best" in order to make an ordered choice.

Since stability and convergence are given as 2 of the 3 motivating
factors, if this final option (not all the best are equal) applies,
then there are two issues to address:
- definition of "best" for the sake of being advertised as one of the N
- ordering among the N

to know which next path to select if the best-best path fails. If it
should select from plane-2, then we need to know how to populate the
planes. If it should select from across all planes, then we need to
know how to distinguish the offered paths.```
Barry Leiba Former IESG member
No Objection
No Objection (for -07)

Benoît Claise Former IESG member
(was Discuss) No Objection
No Objection (2012-07-18)
```- OLD:
The BGP protocol as defined today has no mechanism to distribute other
then best path between its speakers.
NEW:
The BGP protocol as defined today has no mechanism to distribute other
than best path between its speakers.

- add an extra "," in the following section
As it has been proven that distribution of only the best path of a
route is not sufficient to meet the needs of continuously growing
number of services carried over BGP, the add-paths proposal was
submitted in 2002 to enable BGP to distribute more then one path.

Btw, you mean http://tools.ietf.org/html/rfc3345 (which was done in 2002) in this case, why not clearly mention it?

- Next paragraph mentions:
The implication of this change on a BGP implementation is that it
state to track which of the peers each path was advertised to.  This
new requirement has its own memory and processing cost.  Suffice to
say that it took over 9 years for some commercial BGP implementation
to support the new add-path behaviour in production code, in major
part due to this resource overhead.

If yes, why not clearly mention it

Same remark for
The add paths protocol extensions have to be implemented by all the
routers within an AS in order for the system to work correctly.

-
The required code modifications include enhancements such as the Fast
[I-D.pmohapat-idr-fast-conn-restore].

IS this right? Isn't it?

The required code modifications can offer the foundation for enhancements such as the Fast
[I-D.pmohapat-idr-fast-conn-restore].

-
4.  Multi plane route reflection
The idea contained in the proposal assumes the use of route
reflection within the network.  Other techniques as described in the
following sections already provide means for distribution of
alternate paths today.

The last sentence seems to come out of the blue. At least, I don't understand why it's there.

- Section 7
OLD:

2.  No requirement for upgrades to edge and core routers.  Backward
compatible with the existing BGP deployments.

NEW

2.  No requirement for upgrades to edge and core routers (as required in draft-ietf-idr-add-paths-07).  Backward
compatible with the existing BGP deployments.```
Brian Haberman Former IESG member
No Objection
No Objection (2012-07-19 for -07)
```I support both Adrian's and Benoit's DISCUSS points.

This document was much harder to read than it had to be.  As was pointed out by Hilarie and other, there are sections of the draft that are hard to parse until they are read 2 or 3 times.  I think the document would benefit from an end-to-end grammatical review.```
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -07)

Martin Stiemerling Former IESG member
No Objection
No Objection (for -07)

Pete Resnick Former IESG member
No Objection
No Objection (for -07)

Robert Sparks Former IESG member
No Objection
No Objection (for -07)

Russ Housley Former IESG member
No Objection
No Objection (for -07)

Sean Turner Former IESG member
No Objection
No Objection (for -07)

Stephen Farrell Former IESG member
No Objection
No Objection (2012-07-18 for -07)
```
I agree with Hilarie Orman's secdir review [1] both
```This document has abbreviations that do not seem to have been expanded on first use: AS, P (in the Figs), RR'