Advertisement of Multiple Paths in BGP
draft-ietf-idr-add-paths-15
Yes
(Alia Atlas)
No Objection
(Alexey Melnikov)
(Ben Campbell)
(Deborah Brungard)
(Jari Arkko)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)
Recuse
(Alvaro Retana)
Note: This ballot was opened for revision 13 and is now closed.
Alia Atlas Former IESG member
Yes
Yes
(for -13)
Unknown
Joel Jaeggli Former IESG member
(was No Objection)
Yes
Yes
(2016-05-04 for -14)
Unknown
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.
Alexey Melnikov Former IESG member
(was Discuss)
No Objection
No Objection
(2016-05-03 for -14)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(2016-05-03 for -14)
Unknown
Was also wondering about "bestpath."
Ben Campbell Former IESG member
No Objection
No Objection
(for -14)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -14)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -14)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2016-05-02 for -14)
Unknown
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.
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2016-05-02 for -14)
Unknown
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?
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -14)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2016-05-03 for -14)
Unknown
- 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 Former IESG member
No Objection
No Objection
(for -14)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -14)
Unknown
Alvaro Retana Former IESG member
Recuse
Recuse
(for -14)
Unknown