Advertisement of Multiple Paths in BGP
draft-ietf-idr-add-paths-15

[Ballot comment]

- section 2: This bit wasn't entirely clear to me: "A
BGP speaker that re-advertises a route MUST generate its
own Path Identifier to be associated with the
re-advertised route." It wasn't clear to me if that
means it's disallowed to use the same path identifier or
not when re-advertising. If it's not allowed that'd seem
to warrant a "MUST NOT" statement, or to say that the
path identifier re-advertised MUST be different from
that in the received advertisement - "it's own" doesn't
quite say the same to me.

- section 5: I wasn't clear what happens in the
following case. Alice advertises prefix-A with no path
identifier, then prefix-A with some path identifier.
Next Alice withdraws prefix-A with no associated path
identifier.  What happens when I get that sequence? (It
may well be clear for those readers who know more about
BGP.)

- What is "bestpath"? If that's defined elsewhere a
reference would be good. (A quick duckduckgo only showed
me Cisco specific answers for bestpath, but others for
"best path.")

- Section 5 (last para): what would "special care" here
mean? If that'd be clear to relevant readers, that's
fine.

[Ballot comment]
1. I'd like to see the security considerations explicitly state that this could result in a denial of service attack.  The resource consumption is stated nicely, but it would be good (following RFC3552) to state the type of attack.

  "This document defines a BGP extension that allows the advertisement
  of multiple paths for the same address prefix without the new paths
  implicitly replacing any previous ones.  As a result, multiple paths
  for a large number of prefixes may be received by a BGP speaker
  potentially depleting memory resources or even causing network-wide
  instability."

Adding something like: "This could result in a denial of service attack."

2. Change the last sentence of the security considerations section in light of the first paragraph to something like:

From:
  This document introduces no new security concerns in the base
  operation of BGP [RFC4271].

To:
  Security concerns in the base operation of BGP [RFC4271] also apply.

[Ballot comment]
Two quick comments:

1) Section 6 says: „The applications are detailed in separate documents.“ Does this doc already exists? A reference would be good!

2) One clarification question: When a path with a new identifier is advertised this actually does not mean that these two paths are different, right? Some one could advertise the same path twice with different identifiers, right? Should this be explicitly mention somewhere?

[Ballot discuss]
This is a well written document. I have one small issue to discuss before voting "no objection".

At the end of section 2: why path identifier "SHOULD be treated as opaque" instead of "MUST be treated as opaque"? What are possible reasons to violate the SHOULD?

IETF Last Call comment agreed to address:

"As far as protocol encodings go, the document introduces a long-term issue, which has been explained in terms of a packet analyzer (but the same thinking applies in the scope of fuzzing attacks): https://mailarchive.ietf.org/arch/msg/idr/mHJa47QK-eX1Enk1CAI8hy_uVmI

At the very least this document should acknowledge the problem it introduces."

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-idr-add-paths-13.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the Capability Codes registry located at:

https://www.iana.org/assignments/capability-codes/

the reference for value 69 will be changed from the current draft to [ RFC-to-be ] as follows:

Value: 69
Description: ADD-PATH Capability
Reference: [ RfC-to-be ]

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-idr-add-paths@ietf.org, idr-chairs@ietf.org, idr@ietf.org, russw@riw.us, akatlas@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Advertisement of Multiple Paths in BGP) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document:
- 'Advertisement of Multiple Paths in BGP'
  as Proposed Standard

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 2016-04-29. 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


  This document defines a BGP extension that allows the advertisement
  of multiple paths for the same address prefix without the new paths
  implicitly replacing any previous ones.  The essence of the extension
  is that each path is identified by a path identifier in addition to
  the address prefix.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-idr-add-paths/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-idr-add-paths/ballot/


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

status:
AD: Alia Atlas
Shepherd: Russ White

1. Summary

The document shepherd is Russ White. The responsible Area Director is Alvaro
Retana.

This document extends BGP so a BGP speaker can advertise multiple paths
rather than a single best path to peers. It proposes a new NLRI encoding
extension to carry a Path Identifier, and a new capability to negotiate the
carrying of additional paths. These additional paths are intended to used to
eliminate path oscillation, in a number of situations where advertising
multiple paths can improve network convergence, and in a number of
situations where BGP is used in "high fan out" equal cost multipath network
topologies to provide optimal path availability.

2. Review and Consensus

The extension to BGP is straightforward; while there has been some
difficulty in coming to consensus on the benefits provided versus the
difficulty in implementing the extensions, the value of the concept has been
proven in deployment scenarios and use cases enough to justify moving
forward with this document. The document has passed through ten revisions
over a number of years, and has been discussed both on and off the relevant
lists by a number of experts in the development and deployment of BGP.

The working group has reached consensus on moving this document forward at
this point.

3. Intellectual Property

Each author has confirmed conformance with BCP 78/79. There are no IPR
disclosures on the document.

4. Other Points

There are no normative downrefs in this document. There are minimal
additions to the YANG model based on the extensions described in this draft;
as those models are not yet standardized, it is expected that these will be
included in these models as they are standardized. Changes to the IANA
registries required for the new options described in the draft have already
been properly assigned and recorded.

1. Summary

The document shepherd is Russ White. The responsible Area Director is Alvaro
Retana.

This document extends BGP so a BGP speaker can advertise multiple paths
rather than a single best path to peers. It proposes a new NLRI encoding
extension to carry a Path Identifier, and a new capability to negotiate the
carrying of additional paths. These additional paths are intended to used to
eliminate path oscillation, in a number of situations where advertising
multiple paths can improve network convergence, and in a number of
situations where BGP is used in "high fan out" equal cost multipath network
topologies to provide optimal path availability.

2. Review and Consensus

The extension to BGP is straightforward; while there has been some
difficulty in coming to consensus on the benefits provided versus the
difficulty in implementing the extensions, the value of the concept has been
proven in deployment scenarios and use cases enough to justify moving
forward with this document. The document has passed through ten revisions
over a number of years, and has been discussed both on and off the relevant
lists by a number of experts in the development and deployment of BGP.

The working group has reached concensus on moving this document forward at
this point.

3. Intellectual Property

Each author has confirmed conformance with BCP 78/79. There are no IPR
disclosures on the document.

4. Other Points

There are no normative downrefs in this document. There are minimal
additions to the YANG model based on the extensions described in this draft;
as those models are not yet standardized, it is expected that these will be
included in these models as they are standardized. Changes to the IANA
registries required for the new options described in the draft have already
been properly assigned and recorded.