Skip to main content

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