Skip to main content

Graceful Restart Mechanism for BGP with MPLS
RFC 4781

Revision differences

Document history

Date Rev. By Action
2018-12-20
05 (System)
Received changes through RFC Editor sync (changed abstract to 'A mechanism for BGP that helps minimize the negative effects on routing caused by BGP restart …
Received changes through RFC Editor sync (changed abstract to 'A mechanism for BGP that helps minimize the negative effects on routing caused by BGP restart has already been developed and is described in a separate document ("Graceful Restart Mechanism for BGP"). This document extends this mechanism to minimize the negative effects on MPLS forwarding caused by the Label Switching Router's (LSR's) control plane restart, and specifically by the restart of its BGP component when BGP is used to carry MPLS labels and the LSR is capable of preserving the MPLS forwarding state across the restart.

The mechanism described in this document is agnostic with respect to the types of the addresses carried in the BGP Network Layer Reachability Information (NLRI) field. As such, it works in conjunction with any of the address families that could be carried in BGP (e.g., IPv4, IPv6, etc.). [STANDARDS-TRACK]')
2015-10-14
05 (System) Notify list changed from mpls-chairs@ietf.org to (None)
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Brian Carpenter
2009-02-09
(System) Posted related IPR disclosure: Juniper's Statement of IPR related to RFC 4781
2007-01-24
05 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2007-01-24
05 Amy Vezza [Note]: 'RFC 4781' added by Amy Vezza
2007-01-18
05 (System) RFC published
2006-07-24
05 Bill Fenner State Change Notice email list have been change to mpls-chairs@tools.ietf.org from <swallow@cisco.com>, <loa@pi.se>
2005-08-30
05 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2005-08-24
05 Amy Vezza IESG state changed to Approved-announcement sent
2005-08-24
05 Amy Vezza IESG has approved the document
2005-08-24
05 Amy Vezza Closed "Approve" ballot
2005-08-24
05 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2005-08-17
05 Brian Carpenter [Ballot Position Update] Position for Brian Carpenter has been changed to No Objection from Discuss by Brian Carpenter
2005-08-16
05 (System) Sub state has been changed to AD Follow up from New Id Needed
2005-08-16
05 (System) New version available: draft-ietf-mpls-bgp-mpls-restart-05.txt
2005-07-22
05 (System) Removed from agenda for telechat - 2005-07-21
2005-07-21
05 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2005-07-21
05 (System) [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen by IESG Secretary
2005-07-21
05 (System) [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by IESG Secretary
2005-07-21
05 (System) [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by IESG Secretary
2005-07-21
05 (System) [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by IESG Secretary
2005-07-21
05 (System) [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by IESG Secretary
2005-07-21
05 (System) [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by IESG Secretary
2005-07-21
05 (System) [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by IESG Secretary
2005-07-21
05 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by Amy Vezza
2005-07-21
05 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Amy Vezza
2005-07-21
05 Brian Carpenter
[Ballot discuss]
I hate to do this since Harald went no-ob, but section 9 contains descriptions of two
IPR disclosures, and I thought those were …
[Ballot discuss]
I hate to do this since Harald went no-ob, but section 9 contains descriptions of two
IPR disclosures, and I thought those were not allowed - only the general notice that
there are disclosures is allowed.

Attached is a quite critical review by John Loughney. I think he's correct on all
counts. I would hesitate to make these add up to a DISCUSS however, but the RFC Editor
will have a lot to do.

    Brian

-----

I believe this document needs at least an editorial revision before it is ready for publication.
The nit-checker found lots of problems ....  Additionally, I found the draft
difficult to read and parse.  This draft is a standards track, but it doesn't really clearly
state what someone needs to implement.  It seems much more like operational guidence.  I'm happy
to work with the authors to clear any of the points raised in the draft, if needed.


More specific comments:


1) Abstract reads more like an introduction, and there is no introduction. I'd suggest
    writing a shorter abstract, and leaving the current abstract as an introduction
    would be a good thing.  Note that the current abstract has references, which abstracts
    generally should not.  Plus, the abstract is 4 paragraphs long, which seems a bit much
    for an abstract.


2) The Motivation section seems to be introductory material and I don't quite see the motivation
    for this mechanism.  Perhaps the section should be renamed.  I don't think that the
    document requires a Motivation section, but some text on why a 'graceful restart mechanism for
    BGP with MPLS' is a good thing to have would be nice.


[BC: by moving much of the abstract to the begiining of the Motivation section, and
renaming it Introduction, these two problems could be palliated.]


3) I had a hard time parsing the first paragraph of the motivation.  It seems that you are trying
    to define what you mean by "MPLS forwarding state" - maybe more clearly stated or presented
    in such a way that its clearer - I was thinking of something like a bulleted list.


4) The last paragraph of section 1 says:


    "The mechanism described in this document is applicable to all LSRs,
    both those with the ability to preserve forwarding state during BGP
    restart and those without ..."


    -> however, you mention that it only minimizes the impact of the control
        plane restart if their neighbors are capable of preserving state.  What
        happens if they are not capable?  Does this mechanism, then bring any
        benefit?

2) Security Consideration says:

    The security considerations pertaining to the original BGP protocol
    remain relevant.

  ->  I think a reference would be needed to the correct document where
      I could find the security considerations to BGP would be needed.
2005-07-21
05 Amy Vezza [Ballot Position Update] New position, Discuss, has been recorded for Brian Carpenter by Amy Vezza
2005-07-21
05 Michelle Cotton IANA Comments:
NO IANA Considerations section
We understand this document to have NO IANA Actions.
2005-07-13
05 Alex Zinin Placed on agenda for telechat - 2005-07-21 by Alex Zinin
2005-07-13
05 Alex Zinin State Changes to IESG Evaluation from Waiting for Writeup by Alex Zinin
2005-07-13
05 Alex Zinin [Ballot Position Update] New position, Yes, has been recorded for Alex Zinin
2005-07-13
05 Alex Zinin Ballot has been issued by Alex Zinin
2005-07-13
05 Alex Zinin Created "Approve" ballot
2005-03-21
05 (System) State has been changed to Waiting for Writeup from In Last Call by system
2005-02-22
05 Amy Vezza Last call sent
2005-02-22
05 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2005-02-21
05 Alex Zinin Last Call was requested by Alex Zinin
2005-02-21
05 Alex Zinin State Changes to Last Call Requested from AD Evaluation::AD Followup by Alex Zinin
2005-02-21
05 (System) Ballot writeup text was added
2005-02-21
05 (System) Last call text was added
2005-02-21
05 (System) Ballot approval text was added
2005-01-20
05 (System) Sub state has been changed to AD Follow up from New Id Needed
2005-01-20
04 (System) New version available: draft-ietf-mpls-bgp-mpls-restart-04.txt
2004-05-27
05 Alex Zinin State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::External Party by Alex Zinin
2004-05-27
05 Alex Zinin adjusting state
2004-05-18
05 Alex Zinin
AD-review comments:

Meta-issue:

> 5. Alternative procedures for the restarting LSR

The document does not clearly define the normative parts of the spec that the …
AD-review comments:

Meta-issue:

> 5. Alternative procedures for the restarting LSR

The document does not clearly define the normative parts of the spec that the
implementations HAVE to adhere to. It seems to me that two possible mechanisms
are simply a result of this. I'm thinking if the doc could be substantially
improved if it said something along these lines:

1. In the normative part, say that as a general guideline the restarting LSR
    should attempt to reuse the labels assigned before the restart, or otherwise
    assign new labels, announce them to the neighbors, and be able to maintain both
    old and new label bindings for some period of time.

2. As a non-normative part of the spec, describe the algorithms that could
    be used on the LSR, with corresponding description of pros and cons (i.e.
    like appl statements), and the implementations do not have to implement
    exactly these as long as their externally visible behavior conforms to
    bullet 1 above.

More specific comments:

> draft-ietf-mpls-bgp-mpls-restart-03.txt

> 4. Procedures for the restarting LSR
>
>    After the LSR restarts, it follows the procedures as specified in
>    [1]. In addition, if the LSR is able to preserve its MPLS forwarding
>    state across the restart, the LSR advertises this to its neighbors by
>    appropriately setting the Flag field in the Graceful Restart
                              ^^^^
                should it be "Flags for Address Family", since there's
                also the "Restart Flags" field there?

>    Capability for all applicable AFI/SAFI pairs.


> 4.1. Case 1
>
>    The following applies when (a) the best route selected by the
>    restarting LSR was received with a label, (b) that label is not an
>    Implicit NULL, and (c) the LSR advertises this route with itself as
>    the next hop.

>    In this case the restarting LSR searches its MPLS forwarding state
>    (the one preserved across the restart) for an entry with <outgoing
>    label, Next-Hop> equal to the one in the received route.

The next hop in the received route will be the BGP-type indirect next hop, while
the next hop in the MPLS forwarding state is intuitively expected to be a direct
one. The document should be clearer on how to get the direct next-hop for the
look-up operation (i.e., resolve the BGP next hop, what are the possible
implications, like IGP convergence, etc.) Same should be applicable to Case 2
as well.

> If such an
>    entry is found, the LSR no longer marks the entry as stale. In
>    addition if the entry is of type <incoming label, (outgoing label,
>    next hop)> rather than <prefix, (outgoing label, next hop)>, the LSR
>    uses the incoming label from the entry when advertising the route to
>    its neighbors.

"The LSR uses the incoming label" may be too strong. It seems possible (due to
different timing) for a restarting LSR to have allocated a specific label value
for another NLRI, e.g., when the best-path decision compared to the pre-restart
state changes from a unlabeled route to a labeled one. The text should probably
say something like "attempt to assign the label value found in the forwarding
state to... If the label has already been allocated, then..." Ditto for Case 2.

> If the found entry has no incoming label, or if no
>    such entry is found, the LSR just picks up some unused label when
>    advertising the route to its neighbors (assuming that there are
>    neighbors to which the LSR has to advertise the route with a label).

"picks up some unused label when advertising" may be interpreted as if an
implementation may put a random label value from within the unused label range
every time a route is announced, as opposed to allocating a label value and
using it consistently. Is this what the text is intended to say?
Ditto for Case 2.

Ed: "Next-Hop"/"next hop" when used in the MPLS forwarding state context should
be normalized.

> 4.3. Case 3
>
>    The following applies when the restarting LSR does not set BGP Next
>    Hop to self.
>
>    In this case the restarting LSR, when advertising its best route for
>    a particular NLRI just uses the label that was received with that
>    route. And if the route was received with no label, the LSR
>    advertises the route with no label as well.

Should the text also say that the restarting LSR does not have to allocate
a label in this case?

> 5. Alternative procedures for the restarting LSR

Do we really need two algorithms inside a STD spec, while one is clearly enough?
Given its limitations ("LSR has (at least) as many unallocated as allocated
labels"), it should probably be moved to an appendix as a possible solution with
known disadvantages.

> draft-ietf-mpls-bgp-mpls-restart-03.txt

> 4. Procedures for the restarting LSR
>
>    After the LSR restarts, it follows the procedures as specified in
>    [1]. In addition, if the LSR is able to preserve its MPLS forwarding
>    state across the restart, the LSR advertises this to its neighbors by
>    appropriately setting the Flag field in the Graceful Restart
                              ^^^^
                should it be "Flags for Address Family", since there's
                also the "Restart Flags" field there?

>    Capability for all applicable AFI/SAFI pairs.


> 4.1. Case 1
>
>    The following applies when (a) the best route selected by the
>    restarting LSR was received with a label, (b) that label is not an
>    Implicit NULL, and (c) the LSR advertises this route with itself as
>    the next hop.

>    In this case the restarting LSR searches its MPLS forwarding state
>    (the one preserved across the restart) for an entry with <outgoing
>    label, Next-Hop> equal to the one in the received route.

The next hop in the received route will be the BGP-type indirect next hop, while
the next hop in the MPLS forwarding state is intuitively expected to be a direct
one. The document should be clearer on how to get the direct next-hop for the
look-up operation (i.e., resolve the BGP next hop, what are the possible
implications, like IGP convergence, etc.) Same should be applicable to Case 2
as well.

> If such an
>    entry is found, the LSR no longer marks the entry as stale. In
>    addition if the entry is of type <incoming label, (outgoing label,
>    next hop)> rather than <prefix, (outgoing label, next hop)>, the LSR
>    uses the incoming label from the entry when advertising the route to
>    its neighbors.

"The LSR uses the incoming label" may be too strong. It seems possible (due to
different timing) for a restarting LSR to have allocated a specific label value
for another NLRI, e.g., when the best-path decision compared to the pre-restart
state changes from a unlabeled route to a labeled one. The text should probably
say something like "attempt to assign the label value found in the forwarding
state to... If the label has already been allocated, then..." Ditto for Case 2.

> If the found entry has no incoming label, or if no
>    such entry is found, the LSR just picks up some unused label when
>    advertising the route to its neighbors (assuming that there are
>    neighbors to which the LSR has to advertise the route with a label).

"picks up some unused label when advertising" may be interpreted as if an
implementation may put a random label value from within the unused label range
every time a route is announced, as opposed to allocating a label value and
using it consistently. Is this what the text is intended to say?
Ditto for Case 2.

Ed: "Next-Hop"/"next hop" when used in the MPLS forwarding state context should
be normalized.

> 4.3. Case 3
>
>    The following applies when the restarting LSR does not set BGP Next
>    Hop to self.
>
>    In this case the restarting LSR, when advertising its best route for
>    a particular NLRI just uses the label that was received with that
>    route. And if the route was received with no label, the LSR
>    advertises the route with no label as well.

Should the text also say that the restarting LSR does not have to allocate
a label in this case?
2004-03-31
05 Alex Zinin State Changes to AD Evaluation::External Party from AD Evaluation by Alex Zinin
2004-03-31
05 Alex Zinin Asked IDR WG chairs to organize review of the doc in IDR.
2004-03-25
05 Alex Zinin State Changes to AD Evaluation from Publication Requested by Alex Zinin
2004-03-25
05 Alex Zinin Have comments. Writing up...
2004-03-09
05 Alex Zinin State Changes to Publication Requested from AD is watching by Alex Zinin
2004-02-02
03 (System) New version available: draft-ietf-mpls-bgp-mpls-restart-03.txt
2003-04-16
05 Alex Zinin Shepherding AD has been changed to Zinin, Alex from Bradner, Scott
2002-10-31
05 Scott Bradner
2002-10-31 - IESG discussion
being returned to WG to be resubmitted after the IDR WG
finishes the BGP restart work (to be sure what that …
2002-10-31 - IESG discussion
being returned to WG to be resubmitted after the IDR WG
finishes the BGP restart work (to be sure what that doc
does not change in a way that would require modes to this ID)
2002-10-31
05 Scott Bradner by Bradner, Scott
2002-10-31
05 Scott Bradner State Changes to AD is watching  :: 0 from IESG Evaluation by Bradner, Scott
2002-10-26
05 Scott Bradner 2002-10-26 - on 2002-10-31 IESG agenda
2002-10-26
05 Scott Bradner by sob
2002-10-23
05 Jacqueline Hargest State Changes to IESG Evaluation from In Last Call by jhargest
2002-10-22
05 Scott Bradner 2002-10-22 - writeup submitted
2002-10-22
05 Scott Bradner by sob
2002-10-16
05 Jacqueline Hargest Due date has been changed to 2002-10-30 from <br>by jhargest
2002-10-16
05 Jacqueline Hargest State Changes to In Last Call  -- 0 from Last Call Requested by jhargest
2002-10-16
05 Scott Bradner by sob
2002-10-16
05 Scott Bradner 2002-10-15 - last call requested
2002-10-16
05 Scott Bradner by sob
2002-10-16
05 Scott Bradner State Changes to Last Call Requested  -- 0 from Publication Requested  -- New ID Needed by sob
2002-10-14
02 (System) New version available: draft-ietf-mpls-bgp-mpls-restart-02.txt
2002-10-14
(System) Posted related IPR disclosure: Juniper's patent statement pertaining to BGP MPLS Graceful Restart (draft-ietf-mpls-bgp-mpls-restart)
2002-10-14
(System) Posted related IPR disclosure: Redback's patent statement pertaining to BGP MPLS Graceful Restart (draft-ietf-mpls-bgp-mpls-restart)
2002-10-13
05 Scott Bradner
2002-10-13 - note to WG chairs

the specific IPR statements must be removed from the ID and sent to
iesg-secretary@ietf.org for publication on teh IPR …
2002-10-13 - note to WG chairs

the specific IPR statements must be removed from the ID and sent to
iesg-secretary@ietf.org for publication on teh IPR web page

also - the IPR text from rfc 2026 sec 10 must be added to the ID

please have the ID revised and republished
2002-10-13
05 Scott Bradner by sob
2002-10-13
05 Scott Bradner State Changes to Publication Requested  -- New ID Needed from Publication Requested by sob
2002-10-13
05 Scott Bradner 2002-10-13 - publication as PS requested
2002-10-13
05 Scott Bradner Intended Status has been changed to Proposed Standard from None
2002-10-13
05 Scott Bradner State Changes to Publication Requested from WG/Author by sob
2002-09-30
05 Scott Bradner Due date has been changed to 2002-10-13 from <br>by sob
2002-09-30
05 Scott Bradner 2002-09-30 - WG last call - to end 2002-10-13
2002-09-30
05 Scott Bradner by sob
2002-09-26
01 (System) New version available: draft-ietf-mpls-bgp-mpls-restart-01.txt
2002-05-03
05 Scott Bradner 2002-05-03 - from Loa Andersson<br>need co-ordination with a bgp restart draft that is in bgp wg last call
2002-05-03
05 Scott Bradner A new comment added<br>by sob
2002-05-02
05 Scott Bradner 2002-05-02 - from Loa Andersson<br>Not on any queue that I can find. Probing authors
2002-04-27
05 Scott Bradner Draft Added by Scott Bradner
2002-02-13
00 (System) New version available: draft-ietf-mpls-bgp-mpls-restart-00.txt