Skip to main content

Requirements for the Graceful Shutdown of BGP Sessions
RFC 6198

Yes

(Jari Arkko)
(Ron Bonica)

No Objection

(Dan Romascanu)
(Gonzalo Camarillo)
(Peter Saint-Andre)
(Russ Housley)
(Sean Turner)
(Stewart Bryant)
(Tim Polk)

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

Lars Eggert
No Objection
Comment (2010-10-04)
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 IESG member
Yes
Yes ()

                            
Ron Bonica Former IESG member
Yes
Yes ()

                            
Adrian Farrel Former IESG member
(was Discuss) No Objection
No Objection (2010-10-20)
All comments addressed in revision -05
Dan Romascanu Former IESG member
No Objection
No Objection ()

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection ()

                            
Peter Saint-Andre Former IESG member
No Objection
No Objection ()

                            
Robert Sparks Former IESG member
No Objection
No Objection (2010-10-06)
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 IESG member
No Objection
No Objection ()

                            
Sean Turner Former IESG member
No Objection
No Objection ()

                            
Stewart Bryant Former IESG member
(was Discuss) No Objection
No Objection (2011-02-02)

                            
Tim Polk Former IESG member
(was Discuss) No Objection
No Objection ()