Long-Lived Graceful Restart for BGP
draft-ietf-idr-long-lived-gr-06

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, andrew-ietf@liquid.tech, draft-ietf-idr-long-lived-gr@ietf.org, idr-chairs@ietf.org, idr@ietf.org, jhaas@juniper.net, rfc-editor@rfc-editor.org
Subject: Protocol Action: 'Support for Long-lived BGP Graceful Restart' to Proposed Standard (draft-ietf-idr-long-lived-gr-06.txt)

The IESG has approved the following document:
- 'Support for Long-lived BGP Graceful Restart'
  (draft-ietf-idr-long-lived-gr-06.txt) as Proposed Standard

This document is the product of the Inter-Domain Routing Working Group.

The IESG contact persons are Jim Guichard, Andrew Alston and John Scudder.

A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-long-lived-gr/

Ballot Text

Technical Summary

   In this document, we introduce a new BGP capability termed "Long-
   lived Graceful Restart Capability" so that stale routes can be
   retained for a longer time upon session failure than is provided for
   by BGP Graceful Restart (RFC 4724).  A well-known BGP community
   "LLGR_STALE" is introduced for marking stale routes retained for a
   longer time.  A second well-known BGP community, "NO_LLGR", is
   introduced to mark routes for which these procedures should not be
   applied.  We also specify that such long-lived stale routes be
   treated as the least-preferred, and their advertisements be limited
   to BGP speakers that have advertised the new capability.  Use of this
   extension is not advisable in all cases, and we provide guidelines to
   help determine if it is.

   We update RFC 6368 by specifying that the LLGR_STALE community must
   be propagated into, or out of, the path attributes exchanged between
   PE and CE.

Working Group Summary

   Was there anything in the WG process that is worth noting?
   For example, was there controversy about particular points 
   or were there decisions where the consensus was
   particularly rough? 

While technical feedback from the working group was limited, there was broad consensus from the working group and no dissent on this document.

Document Quality

   Are there existing implementations of the protocol?  Have a 
   significant number of vendors indicated their plan to
   implement the specification?  Are there any reviewers that
   merit special mention as having done a thorough review,
   e.g., one that resulted in important changes or a
   conclusion that the document had no substantive issues?  If
   there was a MIB Doctor, Media Type, or other Expert Review,
   what was its course (briefly)?  In the case of a Media Type
   Review, on what date was the request posted?

The document is an extension of a long-deployed extension, and all issues raised have been addressed by the authors.
There are also multiple implementations of this specific draft.

Personnel

   The Document Shepherd for this document is Jeffrey Haas. The Responsible
   Area Director is Andrew Alston.

RFC Editor Note