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

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.

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

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.

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

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.