Fast Reroute Extensions to RSVP-TE for LSP Tunnels
RFC 4090
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2020-01-21
|
07 | (System) | Received changes through RFC Editor sync (added Verified Errata tag) |
|
2018-12-20
|
07 | (System) | Received changes through RFC Editor sync (changed abstract to 'This document defines RSVP-TE extensions to establish backup label-switched path (LSP) tunnels for local repair of … Received changes through RFC Editor sync (changed abstract to 'This document defines RSVP-TE extensions to establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds, in the event of a failure. Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either method or both and to interoperate in a mixed network. [STANDARDS-TRACK]') |
|
2015-10-14
|
07 | (System) | Notify list changed from <swallow@cisco.com>, <loa@pi.se> to (None) |
|
2015-04-30
|
Naveen Khan | Posted related IPR disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to RFC 4090 | |
|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Thomas Narten |
|
2012-08-22
|
(System) | Posted related IPR disclosure: Koninklijke KPN N.V.'s Statement about IPR related to RFC 4090 | |
|
2009-04-15
|
(System) | Posted related IPR disclosure: Cisco System's Statement of IPR related to RFC 4090 | |
|
2008-05-15
|
(System) | Posted related IPR disclosure: Ericsson AB's Statement about IPR related to RFC 4090 | |
|
2005-05-31
|
07 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
|
2005-05-31
|
07 | Amy Vezza | [Note]: 'RFC 4090' added by Amy Vezza |
|
2005-05-27
|
07 | (System) | RFC published |
|
2004-10-19
|
07 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
|
2004-10-15
|
07 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2004-10-15
|
07 | Amy Vezza | IESG has approved the document |
|
2004-10-15
|
07 | Amy Vezza | Closed "Approve" ballot |
|
2004-10-14
|
07 | Alex Zinin | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Alex Zinin |
|
2004-10-14
|
07 | Alex Zinin | Note field has been cleared by Alex Zinin |
|
2004-10-11
|
07 | (System) | [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin |
|
2004-10-11
|
07 | (System) | [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner |
|
2004-10-11
|
07 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens |
|
2004-10-11
|
07 | Scott Hollenbeck | [Ballot Position Update] Position for Scott Hollenbeck has been changed to No Objection from Undefined by Scott Hollenbeck |
|
2004-10-11
|
07 | Scott Hollenbeck | [Ballot Position Update] New position, Undefined, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
|
2004-10-08
|
07 | Thomas Narten | [Ballot Position Update] Position for Thomas Narten has been changed to No Objection from Discuss by Thomas Narten |
|
2004-10-06
|
07 | Alex Zinin | [Note]: 'Checking with Thomas.' added by Alex Zinin |
|
2004-09-07
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2004-09-07
|
07 | (System) | New version available: draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt |
|
2004-08-24
|
07 | Alex Zinin | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::External Party by Alex Zinin |
|
2004-08-24
|
07 | Alex Zinin | comments from Kireeti on using enterprise code in vendor specific C-types need to be addressed. |
|
2004-06-24
|
06 | (System) | New version available: draft-ietf-mpls-rsvp-lsp-fastreroute-06.txt |
|
2004-06-02
|
07 | Alex Zinin | State Changes to IESG Evaluation::External Party from IESG Evaluation::AD Followup by Alex Zinin |
|
2004-06-02
|
07 | Alex Zinin | Sent a question to the wg chairs and authors. Pending reply. OK, checking that all comments, including those from IESG have been addressed... Here's a … Sent a question to the wg chairs and authors. Pending reply. OK, checking that all comments, including those from IESG have been addressed... Here's a comment about the IANA section: > Michelle, > > What would be nice is if the RSVP numbers (since they seem willing to > change them, even though they are in production use, if I read between > the lines right), would align with the number spaces projected in > draft-kompella-rsvpchange-01.txt that TSV is about to Last Call. > > Also some IANA-related comments in his review that I agree with and > I think should probably be a Discuss on the document. > > Allison > > >> >> Alex, >> >> In the IANA Considerations section, there are numbers that >> are used in productions networks. Are these numbers being >> suggested as the assignments? >> >> Does any RSVP type person need to look at this? >> >> 10. IANA Guidelines >> >> IANA [RFC-IANA] will assign RSVP C-class numbers for FAST_ROUTE and >> DETOUR objects. Currently, in production networks, FAST_REROUTE uses >> C-class 205, and DETOUR uses C-class 63. >> >> Thanks, >> >> Michelle >> IANA Kireeti, is the current IANA section below consistent with the RSVP-change document? 11. IANA Section IANA [RFC-IANA] will assign RSVP Class-Num 205 for the FAST_REROUTE and RSVP Class-Num 63 for the DETOUR object. This matches the current usage in production networks. IANA will assign C-Type 1 for the standard FAST_REROUTE object format defined in section 5.1 and list C-Type 7 as reserved as it is still used by pre-standard implementations. IANA will assign C-Types 7 and 8 to the IPv4 and IPv6 DETOUR object formats as defined in section 5.2. I am also wondering why we are defining the numbers in the draft before IANA actually allocates them, as opposed to putting them in as "recommended" values. I still remember the oops we had with RSVP not so long ago. The following comment: > Comment: > The background section reads weird when this gets published as an RFC. > It talks about "this draft" a few times and it talks about "the goal is > to standardize". hasn't been addressed. |
|
2004-05-11
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2004-05-11
|
05 | (System) | New version available: draft-ietf-mpls-rsvp-lsp-fastreroute-05.txt |
|
2004-04-02
|
07 | Alex Zinin | Late comments received, fwd'ed to the WG chairs: I've received somre more comments on this draft, and they should be fixed, I think: 5.2.1 … Late comments received, fwd'ed to the WG chairs: I've received somre more comments on this draft, and they should be fixed, I think: 5.2.1 Avoid Node ID (1 - n) IP address identifying the immediate downstream node that the PLR is trying to avoid. Router ID of downstream node is preferred. This field is mandatory, and is used by the MP for merging rules discussed below. What Router ID is meant here? Given that OSPF Router ID is not an IP address, the definition needs to be fixed. 2nd in 5.2.2 Avoid Node ID (1 - n) A 128-bit unicast host address identifying the immediate downstream node that the PLR is trying to avoid. Router ID of downstream node is preferred. This field is mandatory, and is used by the MP for merging rules discussed below. Ditto here. Also note that OSPFv3 Router ID is still a 32-bit number. |
|
2004-03-22
|
(System) | Posted related IPR disclosure: Cisco's Statement about IPR claimed in draft-ietf-mpls-rsvp-lsp-fastreroute | |
|
2004-02-16
|
04 | (System) | New version available: draft-ietf-mpls-rsvp-lsp-fastreroute-04.txt |
|
2003-11-21
|
07 | Alex Zinin | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Alex Zinin |
|
2003-11-21
|
07 | Alex Zinin | sent comments to the WG chairs. pending resolution |
|
2003-11-21
|
07 | Amy Vezza | Removed from agenda for telechat - 2003-11-20 by Amy Vezza |
|
2003-11-20
|
07 | Amy Vezza | [Ballot Position Update] New position, No Objection, has been recorded for by Amy Vezza |
|
2003-11-20
|
07 | Amy Vezza | [Ballot Position Update] New position, No Objection, has been recorded for by Amy Vezza |
|
2003-11-20
|
07 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
|
2003-11-20
|
07 | Allison Mankin | [Ballot comment] I gave this a protesting no objection - my concern is that the extended usage of the ERO to access bypass paths in … [Ballot comment] I gave this a protesting no objection - my concern is that the extended usage of the ERO to access bypass paths in the network heightens the risks of ERO. We are very concerned about source route risks in IP, but have neglected the topic in RSVP-TE. |
|
2003-11-20
|
07 | Thomas Narten | [Ballot discuss] Document seems to support IPv6, but the DETOUR object seems to support IPv4 only. Is the Avoid Noid ID not really an IP … [Ballot discuss] Document seems to support IPv6, but the DETOUR object seems to support IPv4 only. Is the Avoid Noid ID not really an IP address? > 11. Intellectual Property Considerations > > Cisco Systems and Juniper Networks may have intellectual property > rights claimed in regard to some of the specification contained in > this document Replace with standard IPR text. Michelle, What would be nice is if the RSVP numbers (since they seem willing to change them, even though they are in production use, if I read between the lines right), would align with the number spaces projected in draft-kompella-rsvpchange-01.txt that TSV is about to Last Call. Also some IANA-related comments in his review that I agree with and I think should probably be a Discuss on the document. Allison > > Alex, > > In the IANA Considerations section, there are numbers that > are used in productions networks. Are these numbers being > suggested as the assignments? > > Does any RSVP type person need to look at this? > > 10. IANA Guidelines > > IANA [RFC-IANA] will assign RSVP C-class numbers for FAST_ROUTE and > DETOUR objects. Currently, in production networks, FAST_REROUTE uses > C-class 205, and DETOUR uses C-class 63. > > Thanks, > > Michelle > IANA > > |
|
2003-11-20
|
07 | Allison Mankin | [Ballot Position Update] New position, No Objection, has been recorded for by Allison Mankin |
|
2003-11-20
|
07 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded for by Jon Peterson |
|
2003-11-20
|
07 | Bert Wijnen | [Ballot comment] I am a no(further)Objections. Comment: The background section reads weird when this gets published as an RFC. It talks about "this draft" a … [Ballot comment] I am a no(further)Objections. Comment: The background section reads weird when this gets published as an RFC. It talks about "this draft" a few times and it talks about "the goal is to standardize". |
|
2003-11-20
|
07 | Bert Wijnen | [Ballot Position Update] New position, No Objection, has been recorded for by Bert Wijnen |
|
2003-11-19
|
07 | Thomas Narten | [Ballot comment] I don't understand the IANA stuff. Section 4.1 mentions: > Class = TBD (use form 11bbbbbb for compatibility) > … [Ballot comment] I don't understand the IANA stuff. Section 4.1 mentions: > Class = TBD (use form 11bbbbbb for compatibility) > C-Type = 1 That seems fine. But later in the section, > For informational purposes, a different C-type value and format for > the FAST_REROUTE object are specified below. This is used by > existing implementations. The meaning of the fields is the same as > described for C-Type 1. But, there is no corresponding C-Class defined (since it is actually TBD). Is the assumption that C-Class must be 63? I guess this will all work out if the IANA makes the following assignments as requested: > 10. IANA Guidelines > > IANA [RFC-IANA] will assign RSVP C-class numbers for FAST_ROUTE and > DETOUR objects. Currently, in production networks, FAST_REROUTE uses > C-class 205, and DETOUR uses C-class 63. Shouldn't the C-Types be mentioned here as well? |
|
2003-11-19
|
07 | Thomas Narten | [Ballot discuss] Document seems to support IPv6, but the DETOUR object seems to support IPv4 only. Is the Avoid Noid ID not really an IP … [Ballot discuss] Document seems to support IPv6, but the DETOUR object seems to support IPv4 only. Is the Avoid Noid ID not really an IP address? > 11. Intellectual Property Considerations > > Cisco Systems and Juniper Networks may have intellectual property > rights claimed in regard to some of the specification contained in > this document Replace with standard IPR text. |
|
2003-11-19
|
07 | Thomas Narten | [Ballot discuss] Document seems to support IPv6, but the DETOUR object seems to support IPv4 only. Is the Avoid Noid ID not really an IP … [Ballot discuss] Document seems to support IPv6, but the DETOUR object seems to support IPv4 only. Is the Avoid Noid ID not really an IP address? |
|
2003-11-19
|
07 | Thomas Narten | [Ballot Position Update] New position, Discuss, has been recorded for by Thomas Narten |
|
2003-11-19
|
07 | Ted Hardie | [Ballot Position Update] New position, No Objection, has been recorded for by Ted Hardie |
|
2003-11-19
|
07 | Harald Alvestrand | [Ballot comment] Comment removed after discussion with security ADs (see log). There's reason to worry, but no more reason to worry with this document than … [Ballot comment] Comment removed after discussion with security ADs (see log). There's reason to worry, but no more reason to worry with this document than without it, and that justifies the "no new security considerations" language. |
|
2003-11-19
|
07 | Harald Alvestrand | [Ballot comment] This document "introduces no new security considerations". That seems a bit weak, since there are some new attack variants possible when protection is … [Ballot comment] This document "introduces no new security considerations". That seems a bit weak, since there are some new attack variants possible when protection is used (such as attacking an unused path for wiretap or redirect, then causing a failure of of the main path in order to redirect traffic onto the compromised bckup). But these may be considered just minor variants of existing attacks - so if the security ADs don't think it's an issue, I won't. |
|
2003-11-19
|
07 | Harald Alvestrand | [Ballot Position Update] Position for Harald Alvestrand has been changed to No Objection from Undefined by Harald Alvestrand |
|
2003-11-19
|
07 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for by Russ Housley |
|
2003-11-19
|
07 | Margaret Cullen | [Ballot comment] This draft has too many authors. |
|
2003-11-19
|
07 | Margaret Cullen | [Ballot Position Update] New position, No Objection, has been recorded for by Margaret Wasserman |
|
2003-11-19
|
07 | Amy Vezza | [Ballot Position Update] New position, No Objection, has been recorded for by Amy Vezza |
|
2003-11-19
|
07 | Ned Freed | [Ballot comment] Nonstandard IPR section talks explicitly about Cisco having IPR in this area. Is this OK? I thought the idea was not to embed … [Ballot comment] Nonstandard IPR section talks explicitly about Cisco having IPR in this area. Is this OK? I thought the idea was not to embed IPR claims in RFCs. |
|
2003-11-19
|
07 | Ned Freed | [Ballot Position Update] New position, No Objection, has been recorded for by Ned Freed |
|
2003-11-19
|
07 | Harald Alvestrand | [Ballot Position Update] Position for Harald Alvestrand has been changed to Undefined from Yes by Harald Alvestrand |
|
2003-11-19
|
07 | Harald Alvestrand | Rather than bothering with reporting as a bug that the ballot was issued, I pushed the "Issue this ballot" button. |
|
2003-11-19
|
07 | Harald Alvestrand | [Ballot Position Update] New position, Yes, has been recorded for Harald Alvestrand |
|
2003-11-19
|
07 | Harald Alvestrand | Ballot has been issued by Harald Alvestrand |
|
2003-11-19
|
07 | Harald Alvestrand | Created "Approve" ballot |
|
2003-11-19
|
07 | (System) | Ballot writeup text was added |
|
2003-11-19
|
07 | (System) | Last call text was added |
|
2003-11-19
|
07 | (System) | Ballot approval text was added |
|
2003-11-18
|
(System) | Posted related IPR disclosure: ECI's Statement about IPR Claimed in draft-ietf-mpls-rsvp-lsp-fastreroute | |
|
2003-11-04
|
07 | Alex Zinin | Placed on agenda for telechat - 2003-11-20 by Alex Zinin |
|
2003-11-04
|
07 | Alex Zinin | State Changes to IESG Evaluation from AD Evaluation by Alex Zinin |
|
2003-11-04
|
07 | Alex Zinin | The rev provides explanation on why there are two mechanisms in the document, Pinged Shahram Davari, no reply for a week. Taking back to the … The rev provides explanation on why there are two mechanisms in the document, Pinged Shahram Davari, no reply for a week. Taking back to the IESG. |
|
2003-11-04
|
07 | Alex Zinin | The rev provides explanation on why there are two mechanisms in the document, Pinged Shahram Davari, no reply for a week. Taking back to the … The rev provides explanation on why there are two mechanisms in the document, Pinged Shahram Davari, no reply for a week. Taking back to the IESG. |
|
2003-10-27
|
07 | Alex Zinin | State Changes to AD Evaluation from AD is watching by Alex Zinin |
|
2003-08-22
|
07 | Alex Zinin | State Changes to AD is watching from Waiting for AD Go-Ahead::Revised ID Needed by Alex Zinin |
|
2003-07-02
|
03 | (System) | New version available: draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt |
|
2003-04-22
|
07 | Alex Zinin | Document went back to the WG to address the IETF LC comments. |
|
2003-04-22
|
07 | Alex Zinin | State Changes to Waiting for AD Go-Ahead :: Revised ID Needed from Waiting for Writeup by Zinin, Alex |
|
2003-04-21
|
07 | Jacqueline Hargest | State Changes to Waiting for Writeup from In Last Call by Hargest, Jacqueline |
|
2003-03-30
|
07 | Alex Zinin | WG chairs have to follow up on the IETF LC comments. Pinged chairs on 03/27/2003 and 03/28/2003. |
|
2003-03-30
|
07 | Alex Zinin | Comments during IETF LC (from Shahram Davari <Shahram_Davari@pmc-sierra.com>): Section 6.1.1 and 6.1.2 mention two very different method for backup path identification and signaling. … Comments during IETF LC (from Shahram Davari <Shahram_Davari@pmc-sierra.com>): Section 6.1.1 and 6.1.2 mention two very different method for backup path identification and signaling. It is not clear which one should be implemented for compliance to this draft. For interoperability reason ONE of them should be Mandatory and the other one optional. ... Also Facility back-up and Detour both do protection. Which one must be implemented to comply with this draft? For interoperability reasons it seems that one of them should be Mandatory and the other one Optional. |
|
2003-03-22
|
07 | Alex Zinin | taking over after Scott |
|
2003-03-22
|
07 | Alex Zinin | Shepherding AD has been changed to Zinin, Alex from Bradner, Scott |
|
2003-03-07
|
07 | Jacqueline Hargest | Status date has been changed to 2003-3-25 from |
|
2003-03-05
|
07 | Jacqueline Hargest | State Changes to In Last Call from Last Call Requested by Hargest, Jacqueline |
|
2003-03-05
|
07 | (System) | Last call sent |
|
2003-03-04
|
07 | Scott Bradner | 2003-03-04 - request last call - due date 2003-03-25 |
|
2003-03-04
|
07 | Scott Bradner | State Changes to Last Call Requested from Publication Requested by Bradner, Scott |
|
2003-03-04
|
07 | Scott Bradner | 2003-03-04 - request to publish as PS |
|
2003-03-04
|
07 | Scott Bradner | Intended Status has been changed to Proposed Standard from None |
|
2003-03-04
|
07 | Scott Bradner | State Changes to Publication Requested from AD is watching by Bradner, Scott |
|
2003-03-03
|
02 | (System) | New version available: draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt |
|
2002-11-06
|
01 | (System) | New version available: draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt |
|
2002-05-02
|
07 | Scott Bradner | 2002-05-02 - from Loa Andersson<br>author says a new version soon |
|
2002-04-27
|
07 | Scott Bradner | Draft Added by Scott Bradner |
|
2002-02-26
|
00 | (System) | New version available: draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt |