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

[Ballot comment]
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.

[Ballot comment]
Thank you for addressing my Discuss issues and my Comments.

In rereading to check that my Discuss had been addressed I noted some further points. I am raising these as Comments rather than perpetuating my Discuss.

--- I will enter them into the Tracker shortly

[Ballot comment]
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.

[Ballot discuss]
Section 3 says many of the right things, yet it is still appears to be
the case that this document does compete (intention or not) with add-
paths. Would you consider strengthening the text by adding something to
the effect of...

  Provides an interim solution until the standardisation and
  implementation of add-paths, and until support for that function
  can be deployed across the network.

---

Section 4

  Diverse path route reflectors need the new ability to calculate and
  propagate the Nth best path instead of the overall best path.  An
  implementation is encouraged to enable this new functionality on a
  per neighbor basis.

I would like to be clear on this. As phrased "Nth best path" implies
there is an ordering. "Propagate" implies that that ordering is also
distributed along with the path itself.

Preserving ordering over BGP routes is not so easy (blame the MED path
attribute) so I wondered:

- Is ordering needed or do you just need the N best paths?
- If ordering is needed, how do you ensure it is propagated?

This also makes me wonder whether in a multi-vendor environment there is
a need for all participating routers to have the same understanding of
"best". If that is the case, isn't this a document that changes on-wire
behavior (viz. which paths are advertised) and needs conformance in
order to make a coherent deployment? That would make it standards track
(see also my comment on RFC 2119).

---

I can't find a description of what happens when the primary route is
withdrawn. Is there a risk that this will trigger a cascade across the
planes? Suppose you have two planes. Plane 1 advertises the primary
route, Plane 2, secondary. When the primary route for some destination
goes unreachable (say, because its next-hop disappears from the IGP)
both the Plane 1 and Plane 2 RRs come to know about it roughly at the
same time, though Plane 2 may actually hear first for whatever reason.
Plane 1 will advance the backup route to primary and advertise it.
Plane 2 will advance the route to primary, decide there is no backup
any more for it to advertise, and withdraw its route. The problem is
if Plane 2 acts first and withdraws the (formerly-) backup route before
Plane 1 advertises it. Could this be addressed by building in a N*K
delay into Plane N routers? This doesn't seem to be addressed in the
I-D, and it probably should be.

[Ballot comment]
Section 4.3

  That will allow to distribute more then single best
  BGP path from a given route server to such IX peer.

s/then/than the/

Please expand IX on first use

---

I assume that RFC 2119 language has not been used because this document
does not define any new protocol procedures (merely config/deployment
options). I am not sure whether that is the best approach since there
are some key behaviors that you want implementations/deployments to
adhere to in order for the behavior you are describing.

If you decide to continue to not use RFC 2119 language, then you should
remove the reference.

[Ballot comment]


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

[Ballot discuss]
-

  The need to disseminate more paths than just the best path is
  primarily driven by three requirements.  First is the problem of BGP
  oscillations [I-D.ietf-idr-route-oscillation].

Searching for ietf-idr-route-oscillation, I realized that this is now RFC3345, published in 2002 !!!
Have you run the idnits on this draft?
This error is obviously flagged, but there are a couple of extra ones:
  == Unused Reference: 'RFC2119' is defined on line 843, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC5226' is defined on line 853, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC4984' is defined on line 898, but no explicit
    reference was found in the text


-  "This is achieved by including as a part of the NLRI an additional
  four octet value called the Path Identifier."

It took me a while to understand that you actually refer to
draft-ietf-idr-add-paths-07 in the section 2.1
Very confusing, since I read, in sequence:
  "This proposal does not specify any changes to the BGP protocol
  definition.  It does not require upgrades to provider edge or core
  routers nor does it need network wide upgrades.  The only upgrade
  required is the new functionality on the new or current route
  reflectors."
  ...
  "This is achieved by including as a part of the NLRI an additional
  four octet value called the Path Identifier."

Please be explicit.

- The relationship with draft-ietf-idr-add-paths-07 is unclear to me.
If we have draft-ietf-idr-add-paths-07, do we still need this solution?
My conclusion from the section 2 is no!
It's only after reading through section 3 that I finally understood: your propose " The diverse BGP path dissemination proposal" as an alternate solution to  draft-ietf-idr-add-paths-07, right?
Your draft title and abstract are very misleading.
First paragraph says: As defined and widely deployed today BGP has no mechanisms to distribute alternate paths   
Second paragraph: This document presents an alternative mechanism for solving the problem based on the concept of parallel route reflector planes.

Alternate to what? Now, I understand that it's alternate to draft-ietf-idr-add-paths-07
Please rewrite the abstract. Somehow it should extract information from the section 3 and from one of paragraphs in section 2.1:

  While it needs to be clearly acknowledged that the add-path mechanism
  provides the most general way to address the problem of distributing
  many paths between BGP speakers, this document provides a much easier
  to deploy solution that requires no modification to the BGP protocol
  where only a few additional paths may be required.  The alternative
  method presented is capable of addressing critical service provider
  requirements for disseminating more than a single path across an AS
  with a significantly lower deployment cost

And clearly mention the name of your proposal "The diverse BGP path dissemination proposal", which I see from time to time in the draft.
Btw, should this be the document title?

[Ballot comment]
- 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.

[Ballot comment]
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.

IANA has reviewed draft-ietf-grow-diverse-bgp-path-dist-07, which is
currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Distribution of diverse BGP paths.) to Informational RFC


The IESG has received a request from the Global Routing Operations WG
(grow) to consider the following document:
- 'Distribution of diverse BGP paths.'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-07-19. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The BGP4 protocol specifies the selection and propagation of a single
  best path for each prefix.  As defined and widely deployed today BGP
  has no mechanisms to distribute alternate paths which are not
  considered best path between its speakers.  This behaviour results in
  number of disadvantages for new applications and services.

  This document presents an alternative mechanism for solving the
  problem based on the concept of parallel route reflector planes.
  Such planes can be built in parallel or they can co-exist on the
  current route reflection platforms.  Document also compares existing
  solutions and proposed ideas that enable distribution of more paths
  than just the best path.

  This proposal does not specify any changes to the BGP protocol
  definition.  It does not require upgrades to provider edge or core
  routers nor does it need network wide upgrades.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-grow-diverse-bgp-path-dist/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-grow-diverse-bgp-path-dist/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

-- Informational

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The BGP4 protocol specifies the selection and propagation of a single
  best path for each prefix.  As defined and widely deployed today BGP
  has no mechanisms to distribute alternate paths which are not
  considered best path between its speakers.  This behaviour results in
  number of disadvantages for new applications and services.

  This document presents an alternative mechanism for solving the
  problem based on the concept of parallel route reflector planes.
  Such planes can be built in parallel or they can co-exist on the
  current route reflection platforms.  Document also compares existing
  solutions and proposed ideas that enable distribution of more paths
  than just the best path.

  This proposal does not specify any changes to the BGP protocol
  definition.  It does not require upgrades to provider edge or core
  routers nor does it need network wide upgrades.

Working Group Summary

The draft was well supported in the working group, with active conversation
on the mailing list.  Numerous people contributed and commented on the draft
as part of the process.

Document Quality

The document has had contribution from both vendors, researchers and
operators.  The proposal does not require any changed to the BGP protocol,
but does require an implementation of the functionality specified.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Document Shepherd -- Peter Schoenmaker
Area Directory -- Ron Bonica


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd has read and reviewed the document, along with the
commentents and input from the working group, as the document progressed.
The document does a comprehensive job of explaining how a implementation
could exploit the behavior of BGP to add functionality that would benefit
network operations.  There is no change in any protocols.  In addition
because the changes are implementation specific, the document sufficiently
covers the desired behavior and requirements.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

The document shepherd is satisified with the reviews.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

The document has been reviewed by operations and BGP experts.  Although
there are no holes with the BGP review it should be noted the document
is entirely based on the BGP Protocol.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

The document shepherd has no concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

The document shepherd does not believe there any discolsures required
for this document.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been filed.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

There is strong consensus.  There was active support, and no dissenters.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

There have been no threat of appeal.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The document contains several reference 'nits.'  I would propose the
document go forward.  A final version with the corrected references
can be submitted after further reviews.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No specific formal review is required.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.


All normative references are RFCs.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

This document will not change any status of existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

No IANA action is required for this document.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new IANA registries are required.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No formal language is used in this document.