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 |