Requirements for the Graceful Shutdown of BGP Sessions
RFC 6198

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

Lars Eggert No Objection

Comment (2010-10-04 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Section 5., paragraph 2:
>    As a result, provided an alternate path is available in the AS, the
>    packets are rerouted before the BGP session termination and fewer
>    packets (possibly none) are lost during the BGP convergence process
>    since at any time, all routers have a valid path.

  There is obviously the unstated assumption here that the available
  capacity on the new path can sustain the current load on the old path.
  Otherwise, there will definitely be packet loss. This isn't something
  that BGP can necessarily guarantee.


Section 5., paragraph 5:
>    a)   A mechanism to advertise the maintenance action to all affected
>    routers is REQUIRED. Such mechanism may be either implicit or
>    explicit. Note that affected routers can be located both in the local
>    AS and in neighboring ASes. Note also that the maintenance action can
>    either be the shutdown of a BGP session or the establishment of a BGP
>    session.
>    The mechanism SHOULD minimize packet loss when a path is removed or
>    advertised. In particular, it SHOULD be ensured that the old path is
>    not removed from the routing tables of the affected routers before
>    the new path is known.

  A "mechanism to advertise" can't really "minimize packet loss". It's
  the *reaction* to that advertisement that you need to make this
  requirement for.

(Jari Arkko; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Ron Bonica; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Adrian Farrel; former steering group member) (was Discuss) No Objection

No Objection (2010-10-20)
No email
send info
All comments addressed in revision -05

(Dan Romascanu; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Peter Saint-Andre; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Robert Sparks; former steering group member) No Objection

No Objection (2010-10-06 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I don't object to this document moving forward if the working group and sponsoring AD believe it will be useful in informing future protocol work, but I worry about its utility. The document has 16 SHOULDs and 2 SHOULD NOTs, and only 2 MUSTs (one of which really doesn't add anything):

  In the end, once the planned maintenance is finished the nominal BGP routing **MUST** be reestablished.
  Security Considerations Security considerations **MUST** be addressed by the proposed solutions.

Are there really no other hard requirements the group could come to consensus on?

The document talks about only covering "a subset of the cases". Does it mean "these requirements" when it says "the cases"? If not, what cases is it referring to?




(Russ Housley; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Sean Turner; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Stewart Bryant; former steering group member) (was Discuss) No Objection

No Objection (2011-02-02)
No email
send info

(Tim Polk; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info