# Distribution of Diverse BGP Paths draft-ietf-grow-diverse-bgp-path-dist-08

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) Unknown

Adrian Farrel Former IESG member
(was Discuss) No Objection
No Objection (2012-08-09) Unknown
```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

Why is this important? Well, the consumer of the advertisements needs
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) Unknown

Benoît Claise Former IESG member
(was Discuss) No Objection
No Objection (2012-07-18) Unknown
```- 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
must now maintain per path, instead of per prefix, peer advertisement
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.

Here, the last sentence speaks about http://tools.ietf.org/html/draft-ietf-idr-add-paths-07?
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
Connectivity Restoration Using BGP Add-path
[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
Connectivity Restoration Using BGP Add-path
[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) Unknown
```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) Unknown

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

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

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

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

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

Stephen Farrell Former IESG member
No Objection
No Objection (2012-07-18 for -07) Unknown
```
I agree with Hilarie Orman's secdir review [1] both
about the difficulty of reading this and the possible
security issues and would encourage the authors
to consider the points she raised.

[1] http://www.ietf.org/mail-archive/web/secdir/current/msg03409.html```
Stewart Bryant Former IESG member
No Objection
No Objection (2012-07-18 for -07) Unknown
```This document has abbreviations that do not seem to have been expanded on first use: AS, P (in the Figs), RR'

"For a given destination "D" ASBR1 and ASBR2 will each have an external path P1 and P2 respectively." is an assumption  not a statement as far as I can see.```
Wesley Eddy Former IESG member
No Objection
No Objection (for -07) Unknown