Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)
draft-ietf-ccamp-loose-path-reopt-02
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2006-07-24
|
02 | Bill Fenner | State Change Notice email list have been change to ccamp-chairs@tools.ietf.org from kireeti@juniper.net, adrian@olddog.co.uk, dbrungard@att.com |
2006-05-06
|
02 | Ross Callon | State Change Notice email list have been change to kireeti@juniper.net, adrian@olddog.co.uk, dbrungard@att.com from kireeti@juniper.net, adrian@olddog.co.uk |
2006-05-02
|
02 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2006-05-01
|
02 | Amy Vezza | IESG state changed to Approved-announcement sent |
2006-05-01
|
02 | Amy Vezza | IESG has approved the document |
2006-05-01
|
02 | Amy Vezza | Closed "Approve" ballot |
2006-04-29
|
02 | Ross Callon | State Changes to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed by Ross Callon |
2006-04-28
|
02 | Amy Vezza | State Changes to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation by Amy Vezza |
2006-04-28
|
02 | (System) | Removed from agenda for telechat - 2006-04-27 |
2006-04-27
|
02 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens |
2006-04-27
|
02 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley |
2006-04-27
|
02 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund by Magnus Westerlund |
2006-04-27
|
02 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko by Jari Arkko |
2006-04-27
|
02 | Bill Fenner | [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner |
2006-04-26
|
02 | Ted Hardie | [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie |
2006-04-26
|
02 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded for Lisa Dusseault by Lisa Dusseault |
2006-04-26
|
02 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley |
2006-04-26
|
02 | Brian Carpenter | [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter |
2006-04-26
|
02 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded for Dan Romascanu by Dan Romascanu |
2006-04-26
|
02 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert by Lars Eggert |
2006-04-25
|
02 | Michelle Cotton | IANA Comments: Upon approval of this document the IANA will perform the following actions: IANA will assign a new flag named "Path re-evaluation request" in … IANA Comments: Upon approval of this document the IANA will perform the following actions: IANA will assign a new flag named "Path re-evaluation request" in the SESSION-ATTRIBUTE object (C-Type 1 and 7) specified in [RFC3209]. Suggested value is (to be confirmed by IANA) 0x20. We understand this to take place in the following sub-registry found at http://www.iana.org/assignments/rsvp-parameters: 207 SESSION_ATTRIBUTE [RFC3209] Class Types or C-Types: 1 LSP_TUNNEL_RA [RFC3209] 7 LSP Tunnel [RFC3209] IANA will also assign three new error sub-code values for the RSVP PERR Notify message (Error code=25). Suggested values are (to be confirmed by IANA): 6 Preferable path exists 7 Local link maintenance required 8 Local node maintenance required We understand this to take place in the following sub-registry found at http://www.iana.org/assignments/rsvp-parameters: 25 Notify Error [RFC3209] This Error Code has the following globally-defined Error Value sub-codes: 1 = RRO too large for MTU [RFC3209] 2 = RRO Notification [RFC3209] 3 = Tunnel locally repaired [RFC3209] 4 = Control Channel Active State [RFC3473] 5 = Control Channel Degraded State [RFC3473] |
2006-04-25
|
02 | Sam Hartman | [Ballot comment] Why is this document informational? It specifies a protocol It seems like experimental or a note explaining why it is informational would be … [Ballot comment] Why is this document informational? It specifies a protocol It seems like experimental or a note explaining why it is informational would be useful. |
2006-04-25
|
02 | Sam Hartman | [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman |
2006-04-25
|
02 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded for Cullen Jennings by Cullen Jennings |
2006-04-21
|
02 | Ross Callon | [Ballot Position Update] New position, Yes, has been recorded for Ross Callon |
2006-04-21
|
02 | Ross Callon | Ballot has been issued by Ross Callon |
2006-04-21
|
02 | Ross Callon | Created "Approve" ballot |
2006-04-21
|
02 | Ross Callon | PROTO chairs writeup by Adrian Farrel: draft-ietf-ccamp-loose-path-reopt-02.txt > 1. Have the chairs personally reviewed this version of the Internet > Draft (ID), and in particular, … PROTO chairs writeup by Adrian Farrel: draft-ietf-ccamp-loose-path-reopt-02.txt > 1. Have the chairs personally reviewed this version of the Internet > Draft (ID), and in particular, do they believe this ID is ready to > forward to the IESG for publication? Yes with some reservations. I did a lot of review work on the I-D to make it more readable and in English. More could be done, but I think that we have reached the cost/benefit point. The RFC Ed will do the last step. Technically it is OK. I am not completely happy about all of the details, but I managed to push back on some of the work to get it more stable. However, since this is now implemented and deployed, I feel that publication is probably important. Note that there is IPR claimed in this I-D. See http://www.ietf.org/ietf/IPR/nortel-ipr-draft-ietf-ccamp-loose-path-reopt-00.txt Nortel was sent a question (not a request!) about relaxing the terms or the claim did not yield results. As a result of the IPR claim, there was discussion in CCAMP and with SOB, and the I-D was "degraded" to Informational. A note (section 1) was been added to explain how the procedures are entirely optional. Relevant emails can be found in the CCAMP list by searching the Subject for "draft-ietf-ccamp-loose-path-reopt" > 2. Has the document had adequate review from both key WG members and key > non-WG members? Do you have any concerns about the depth or breadth of > the reviews that have been performed? Review in the working group has been limited. Mainly the review came from the chairs. Given the positioning of the I-D as Informational, this is probably not an issue. The I-D has been through Gen-Art review and was updated. It has also been through IESG review (so perhaps the AD did a write-up before?) > 3. Do you have concerns that the document needs more review from a > particular (broader) perspective (e.g., security, operational > complexity, someone familiar with AAA, etc.)? No, not really. The only question I have remaining is whether this should be forced to be Experimental. There is (AFAIK) only one implementation, but some deployment. I believe that this is important function that is necessary in certain multi-domain environments (i.e. using a single, end-to-end LSP) when re-optimisation in a downstream domain is desirable. Other solutions (such as LSP stitching, LSP hierarchy, active PCE) provide ways of not requiring this function. > 4. Do you have any specific concerns/issues with this document that you > believe the ADs and/or IESG should be aware of? For example, perhaps you > are uncomfortable with certain parts of the document, or have concerns > whether there really is a need for it. In any event, if your issues have > been discussed in the WG and the WG has indicated it that it still > wishes to advance the document, detail those concerns in the > write-up. Concerns are all voiced above. > 5. How solid is the WG consensus behind this document? Does it represent > the strong concurrence of a few individuals, with others being silent, > or does the WG as a whole understand and agree with it? WG is almost entirely silent apart from the authors. The work is quite old (several version before being a WG draft) and well-established. I suspect that the lack of "interest" reflects the fact that inter-domain TE is still a relatively futuristic application. > 6. Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in separate > email to the Responsible Area Director. Nothing threatened or rumoured. > 7. Have the chairs verified that the document adheres to all of the ID > Checklist items ? The chairs have done their best. > 8. Is the document split into normative and informative references? > - Are there normative references to IDs, where the IDs are not also > ready for advancement or are otherwise in an unclear state? (note > here that the RFC editor will not publish an RFC with normative > references to IDs, it will delay publication until all such IDs are also > ready for publication as RFCs.) Split is good. All references are stable as RFCs. > 9. What is the intended status of the document? (e.g., Proposed > Standard, Informational?) Informational See above. > For Standards Track and BCP documents, the IESG approval announcement > includes a write-up section with the following sections: > > Technical Summary > Working Group Summary > Protocol Quality Although this is informational, I believe a protocol write-up is helpful. Technical Summary End-to-end LSPs may be set up spanning multiple domains. In this case, loose hops are often used in the explicit route object within signaling because the head-end is unable to compute the path through downstream domains since it does not have TE visibility into those domains. If there is a change in the circumstances in a downstream domain, it may be desirable to reoptimise the LSP through that domain. However, the nature of RSVP-TE used in MPLS-TE and GMPLS is such that a transit node cannot initiate dynamic, hitless re-routing of an LSP. Such procedures must be initiated by the ingress (head-end) router. This document defines a mechanism for the reoptimization of loosely routed MPLS-TE and GMPLS LSPs. It defines a mechanism that allows a TE LSP head-end LSR to trigger a new path re-evaluation on every hop having a next hop defined as a loose or abstract hop, and allows a mid-point LSR to signal to the head-end LSR that a better path exists (compared to the current path in use), or that the TE LSP must be reoptimized because of some maintenance required on the TE LSP path. The mechanism applies to the cases of intra and inter-domain (IGP area or Autonomous System) packet and non-packet TE LSPs following a loosely routed path. Working Group Summary There was no dissent within the WG to progress this document. Consensus was quiet. See above for a description of the IPR issues and their resolution. There was some good technical debate during WG last call, but only then. The debate led to the refinement of the technical solution with no unresolved points. Protocol Quality There is an existing implementation which has several deployments. Only one vendor has so far indicated support for this extension. The extension is a relatively minor extension to an RSVP-TE. It is designed to be backwards compatible so that it will not represent a risk to existing deployments. Dimitri and I did most of the review work that led to important changes. A relatively large number of people are cited in the Acknowledgements section. Adrian |
2006-04-20
|
02 | Ross Callon | Shepherding AD has been changed to Ross Callon from Alex Zinin |
2006-04-20
|
02 | Ross Callon | State Changes to IESG Evaluation from AD Evaluation by Ross Callon |
2006-04-20
|
02 | Ross Callon | Placed on agenda for telechat - 2006-04-27 by Ross Callon |
2006-04-20
|
02 | Ross Callon | State Changes to AD Evaluation from Waiting for Writeup by Ross Callon |
2006-04-20
|
02 | Ross Callon | Shepherding AD has been changed to Ross Callon from Alex Zinin |
2006-02-09
|
02 | (System) | New version available: draft-ietf-ccamp-loose-path-reopt-02.txt |
2005-11-25
|
02 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
2005-10-31
|
02 | Amy Vezza | Last call sent |
2005-10-31
|
02 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2005-10-28
|
02 | Alex Zinin | State Changes to Last Call Requested from AD Evaluation by Alex Zinin |
2005-10-28
|
02 | Alex Zinin | Last Call was requested by Alex Zinin |
2005-10-28
|
02 | (System) | Ballot writeup text was added |
2005-10-28
|
02 | (System) | Last call text was added |
2005-10-28
|
02 | (System) | Ballot approval text was added |
2005-09-06
|
02 | Alex Zinin | State Changes to AD Evaluation from Publication Requested by Alex Zinin |
2005-05-26
|
02 | Dinara Suleymanova | Draft Added by Dinara Suleymanova in state Publication Requested |
2005-05-25
|
01 | (System) | New version available: draft-ietf-ccamp-loose-path-reopt-01.txt |
2005-01-28
|
(System) | Posted related IPR disclosure: Nortel Networks Statement on IPR claimed in draft-ietf-ccamp-loose-path-reopt-00.txt | |
2004-09-01
|
00 | (System) | New version available: draft-ietf-ccamp-loose-path-reopt-00.txt |