Advertisement of Multiple Paths in BGP
RFC 7911

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

(Alia Atlas) Yes

(Joel Jaeggli) (was No Objection) Yes

Comment (2016-05-04 for -14)
No email
send info
as far as I'm concerned this documents the way it's deployed and used today so there's no reason it should go forward.

(Jari Arkko) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Alissa Cooper No Objection

Comment (2016-05-03 for -14)
No email
send info
Was also wondering about "bestpath."

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2016-05-03 for -14)
No email
send info
- 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.

Suresh Krishnan No Objection

Mirja Kühlewind No Objection

Comment (2016-05-02 for -14)
No email
send info
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?

(Terry Manderson) No Objection

Alexey Melnikov (was Discuss) No Objection

(Kathleen Moriarty) No Objection

Comment (2016-05-02 for -14)
No email
send info
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.

Alvaro Retana Recuse