PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths
draft-ietf-pce-pcep-inter-domain-p2mp-procedures-08
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2014-08-08
|
08 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2014-08-06
|
08 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2014-07-25
|
08 | (System) | RFC Editor state changed to RFC-EDITOR from AUTH |
2014-07-23
|
08 | (System) | RFC Editor state changed to AUTH from EDIT |
2014-06-24
|
08 | Amy Vezza | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2014-06-24
|
08 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2014-06-23
|
08 | (System) | RFC Editor state changed to EDIT |
2014-06-23
|
08 | (System) | Announcement was received by RFC Editor |
2014-06-23
|
08 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2014-06-23
|
08 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2014-06-23
|
08 | (System) | IANA Action state changed to In Progress |
2014-06-23
|
08 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2014-06-23
|
08 | Amy Vezza | IESG has approved the document |
2014-06-23
|
08 | Amy Vezza | Closed "Approve" ballot |
2014-06-21
|
08 | Adrian Farrel | Ballot writeup was changed |
2014-06-21
|
08 | Adrian Farrel | Ballot approval text was generated |
2014-06-21
|
08 | Adrian Farrel | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2014-06-17
|
08 | Kathleen Moriarty | [Ballot comment] Thank you for addressing my question with additional text in the security considerations section. |
2014-06-17
|
08 | Kathleen Moriarty | [Ballot Position Update] Position for Kathleen Moriarty has been changed to No Objection from Discuss |
2014-06-17
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2014-06-17
|
08 | Daniel King | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2014-06-17
|
08 | Daniel King | New version available: draft-ietf-pce-pcep-inter-domain-p2mp-procedures-08.txt |
2014-06-12
|
07 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2014-06-12
|
07 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2014-06-12
|
07 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2014-06-12
|
07 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2014-06-11
|
07 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2014-06-11
|
07 | Kathleen Moriarty | [Ballot discuss] The Requirements section discusses the need for confidentiality, but this is not mentioned in the Security Considerations section which just covers DoS attacks … [Ballot discuss] The Requirements section discusses the need for confidentiality, but this is not mentioned in the Security Considerations section which just covers DoS attacks primarily. Since confidentiality is a requirement, can you elaborate on how the solution covers this? I see the discussion in Section 8 on "protection", but that doesn't seem to cover security protections when I read into the references on what seems to be the scope of the term "protection' used in this draft. From Section 5: It is also important that the solution can preserve confidentiality across domains, which is required when domains are managed by different Service Providers via Path-Key mechanism [RFC5520]. |
2014-06-11
|
07 | Kathleen Moriarty | [Ballot Position Update] New position, Discuss, has been recorded for Kathleen Moriarty |
2014-06-11
|
07 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2014-06-10
|
07 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2014-06-10
|
07 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2014-06-06
|
07 | Christer Holmberg | Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Christer Holmberg. |
2014-06-06
|
07 | Adrian Farrel | [Ballot comment] Just a Comment to track the editorial nits raised by Christer Holmberg in his GenArt review |
2014-06-06
|
07 | Adrian Farrel | Ballot comment text updated for Adrian Farrel |
2014-06-05
|
07 | Jean Mahoney | Request for Telechat review by GENART is assigned to Christer Holmberg |
2014-06-05
|
07 | Jean Mahoney | Request for Telechat review by GENART is assigned to Christer Holmberg |
2014-06-04
|
07 | Barry Leiba | [Ballot comment] I like the proposed experiment (and that it is an experiment), and I think this document's well written. Thanks for discussing the point … [Ballot comment] I like the proposed experiment (and that it is an experiment), and I think this document's well written. Thanks for discussing the point below with me. The result of the discussion is that the working group considers the number of bits to be sufficient to allocate this one, and can always allocate an experimental bit later if this seems to become common. Former DISCUSS point, resolved: I have one simple point of DISCUSSion about the code point assignment in the RP Object Flag Field registry. I see from the archive that it does appear to have been discussed in the working group -- there's an unfortunate lack of any record of discussion after working group adoption (though much discussion before), but the registration request was removed in -04, and then put back in in -06 after Adrian's review. Here's my question: The RP Object Flag Field registry only has 18 bits left, and you aim to take one of them for this experiment, for which the shepherd writeup notes that "Implementation beyond prototype is not clear." Do you really want to take up a permanent bit just for this, even if the experiment turns out to fail (or to be unimplemented or undeployed)? Might it be better to allocate a bit for experimental use, and to use that for this experiment, allowing use of that same bit for other experiments as well? It would mean that if this one does take off, you'd have to switch later to a non-experimental bit. Or are you really quite sure that this *will* take off, and you'll need the bit for sure? (Or, alternatively, are you quite sure that 18 bits is well and truly enough, and you don't care?) |
2014-06-04
|
07 | Barry Leiba | [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss |
2014-06-03
|
07 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2014-06-03
|
07 | Barry Leiba | [Ballot discuss] I like the proposed experiment (and that it is an experiment), and I think this document's well written. I have one simple point … [Ballot discuss] I like the proposed experiment (and that it is an experiment), and I think this document's well written. I have one simple point of DISCUSSion about the code point assignment in the RP Object Flag Field registry. I see from the archive that it does appear to have been discussed in the working group -- there's an unfortunate lack of any record of discussion after working group adoption (though much discussion before), but the registration request was removed in -04, and then put back in in -06 after Adrian's review. Here's my question: The RP Object Flag Field registry only has 18 bits left, and you aim to take one of them for this experiment, for which the shepherd writeup notes that "Implementation beyond prototype is not clear." Do you really want to take up a permanent bit just for this, even if the experiment turns out to fail (or to be unimplemented or undeployed)? Might it be better to allocate a bit for experimental use, and to use that for this experiment, allowing use of that same bit for other experiments as well? It would mean that if this one does take off, you'd have to switch later to a non-experimental bit. Or are you really quite sure that this *will* take off, and you'll need the bit for sure? (Or, alternatively, are you quite sure that 18 bits is well and truly enough, and you don't care?) |
2014-06-03
|
07 | Barry Leiba | [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba |
2014-06-03
|
07 | Adrian Farrel | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2014-06-03
|
07 | Adrian Farrel | Ballot has been issued |
2014-06-03
|
07 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
2014-06-03
|
07 | Adrian Farrel | Created "Approve" ballot |
2014-06-03
|
07 | Adrian Farrel | Placed on agenda for telechat - 2014-06-12 |
2014-06-03
|
07 | Adrian Farrel | Ballot writeup was changed |
2014-06-03
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2014-06-03
|
07 | Quintin Zhao | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2014-06-03
|
07 | Quintin Zhao | New version available: draft-ietf-pce-pcep-inter-domain-p2mp-procedures-07.txt |
2014-05-30
|
06 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Tina Tsou. |
2014-05-28
|
06 | Jouni Korhonen | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Jouni Korhonen. |
2014-05-28
|
06 | Adrian Farrel | Changed consensus to Yes from Unknown |
2014-05-28
|
06 | Adrian Farrel | Need to address nits from SecDir review |
2014-05-28
|
06 | Adrian Farrel | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2014-05-26
|
06 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2014-05-19
|
06 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2014-05-19
|
06 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-pce-pcep-inter-domain-p2mp-procedures-06. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-pce-pcep-inter-domain-p2mp-procedures-06. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. We received the following comments/questions from the IANA's reviewer: IANA understands that, upon approval of this document, there is a single action which IANA must complete. In the RP Object Flag Field subregistry of the Path Computation Element Protocol (PCEP) Numbers registry located at: http://www.iana.org/assignments/pcep/ A new registration will be made as follows: Bit: [ TBD-at-registration ] (next available bit is 17) Description: Core-tree computation (C-bit) Reference: [ RFC-to-be ] IANA understands that this is the only action required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. |
2014-05-18
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jouni Korhonen |
2014-05-18
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jouni Korhonen |
2014-05-15
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2014-05-15
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2014-05-15
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Tina Tsou |
2014-05-15
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Tina Tsou |
2014-05-12
|
06 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2014-05-12
|
06 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (PCE-based Computation Procedure To Compute … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (PCE-based Computation Procedure To Compute Shortest Constrained P2MP Inter-domain Traffic Engineering Label Switched Paths) to Experimental RFC The IESG has received a request from the Path Computation Element WG (pce) to consider the following document: - 'PCE-based Computation Procedure To Compute Shortest Constrained P2MP Inter-domain Traffic Engineering Label Switched Paths' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-05-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The ability to compute paths for constrained point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across multiple domains has been identified as a key requirement for the deployment of P2MP services in MPLS and GMPLS-controlled networks. The Path Computation Element (PCE) has been recognized as an appropriate technology for the determination of inter-domain paths of P2MP TE LSPs. This document describes an experiment to provide procedures and extensions to the PCE communication Protocol (PCEP) for the computation of inter-domain paths for P2MP TE LSPs. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pce-pcep-inter-domain-p2mp-procedures/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pce-pcep-inter-domain-p2mp-procedures/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2004/ |
2014-05-12
|
06 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2014-05-12
|
06 | Amy Vezza | Last call announcement was changed |
2014-05-11
|
06 | Adrian Farrel | Last call was requested |
2014-05-11
|
06 | Adrian Farrel | Ballot approval text was generated |
2014-05-11
|
06 | Adrian Farrel | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2014-05-11
|
06 | Adrian Farrel | Last call announcement was changed |
2014-05-11
|
06 | Adrian Farrel | Last call announcement was generated |
2014-05-11
|
06 | Adrian Farrel | Ballot writeup was changed |
2014-05-11
|
06 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2014-05-11
|
06 | Daniel King | New version available: draft-ietf-pce-pcep-inter-domain-p2mp-procedures-06.txt |
2013-10-10
|
05 | Adrian Farrel | AD Review ======== Hello authors of draft-ietf-pce-pcep-inter-domain-p2mp-procedures, I have received the publication request from your document shepherd and performed my usual AD review prior … AD Review ======== Hello authors of draft-ietf-pce-pcep-inter-domain-p2mp-procedures, I have received the publication request from your document shepherd and performed my usual AD review prior to initiating IETF last call and IESG evaluation. The purpose of my review is to iron out any issues that we can within the WG before moving ahead for the wider review. Thank you for pushing this work as experimental and recognising the need for more development before moving to the standards track. This document is nearly ready, but has a small collection of issues that I would like you to look at. Many of these can be handled as editorial and resolved with small changes to the text. A few are slightly larger and might need a little discussion. Please treat all of these points as open for discussion and negotiation. Thanks for your work, Adrian --- Please do a scrub for acronyms and make sure they are expanded on first use in the main body of text. LSR P2P --- Section 2 Sub-tree: used to minimize packet duplication when P2P TE sub-LSPs traverse common links. Tells me what it is used for but not what it is. Can you add an explanation of what it is? And what is a sub-LSP? --- Section 3 I'm surprised that you say... However, [RFC6006] does not provide the necessary mechanisms and procedures to request the computation of inter-domain P2MP TE LSPs. I should have thought the request was very simple and exactly as defined in RFC 6006. That is, a PCC requests the computation of a P2MP LSP and supplies the source, the destinations, and any other relevant constraints. There is, in fact, nothing in a PCReq that limits or opens a computation request to apply to one or more domains. --- Section 3 As described in [RFC5671] the computation of a P2MP tree requires three major pieces of information. The first is the path from the ingress LSR of a P2MP TE LSP to each of the egress LSRs, the second is the traffic engineering related parameters, and the third is the branch capability information. This didn't feel right, so I went back to 5671 and on re-reading, I can't find this reference. Maybe I missed it and you can point me to it. It seems to me that you may be mixing the process with the information. I think it would be reasonable to say you need to know the network topology that can connect the ingress with each of the egresses, but the whole point of the exercise is to determine the paths from source to destination. (Knowing the paths in advance is faintly reminiscent of a computation technique for building a type of P2MP tree (shortest-path- to-destination) that is only optimal in some dimensions. --- Section 3 Generally, an inter-domain P2MP tree (i.e., a P2MP tree with source and at least one destination residing in different domains) is particularly difficult to compute even for a distributed PCE architecture. For instance, while the BRPC may be well-suited for P2P paths, P2MP path computation involves multiple branching path segments from the source to the multiple destinations. As such, inter-domain P2MP path computation may result in a plurality of per-domain path options that may be difficult to coordinate efficiently and effectively between domains. That is, when one or more domains have multiple ingress and/or egress boundary nodes, there is currently no known technique for one domain to determine which boundary node of another domain will be utilized for the inter-domain P2MP tree, and no way to limit the computation of the P2MP tree to those utilized boundary nodes. There seems to be a contradiction between these two paragraphs. In the first you say that you could use BRPC but that it would be difficult. In the second you say there is no known technique. As it happens (and as a thought exercise), BRPC can be used relatively simply to solve this problem. The issue, as you have correctly noted, is that the amount of data gets very large, and coordination with many destination domains is complex. But recall that BRPC assumes that the domain sequence is predetermined, so the problem is not insurmountable. That does not mean that I think using BRPC for this problem is necessarily a good idea. Only that you should not state that it is impossible to use it. --- Section 3 Computing P2P TE LSPs individually is not an acceptable solution for computing a P2MP tree. While I am inclined to agree with you, your statement is too bold. It is actually a perfectly viable solution that produces "good enough" results in many situation. It may also be modified by placing some restrictions on the later computations to improve the optimality of the resultant tree. So I think you need something along the lines of... Computing P2P TE LSPs individually does not guarantee the generation of an optimal P2MP tree for every definition of "optimal" in every topology. --- Section 3 P2MP Minimum Cost Tree (MCT), i.e. a computation which guarantees the least cost resulting tree, is an NP-complete problem. Is MCT NP-complete? Do you have a reference? I can find reference for Steiner being NP-complete, and Steiner is certainly a related problem. --- Section 5 1. The computed P2MP TE LSP SHOULD be optimal when only considering the paths among the BNs. I wonder why this is a requirement. Consider the figure below with source (root) s and destinations (leaves) d1 through d3. let W, X, Y, and Z be BNs. : : d1 : : / a-b-c-d-e-W----g----Y-j-k-l-m-d2 / : : / \ s------f----X--h---i--Z------o d3 : : : : As stated this requirement prefers to use WY than XZ, yet using XZ will result in the optimal tree by most normal measures. Probably I am not interpreting your requirement correctly. But maybe it could be clarified so that I would be more likely to get it right? Perhaps you were trying to limit yourself to the "core tree". If so, please consider the following figure. : : d1 : : / a-----b---W----g----Y-j-k-l-m-d2 / : : / \ s---c---d---X--h---i--Z------o d3 : : : : In this case, the optimal core tree is sabWgY But the optimal tree is scdXhiZom{d1,d2,d3} --- Section 5 2. Grafting and pruning of multicast destinations in a domain SHOULD have no impact on other domains and on the paths among BNs. It is fine to say that you have this as an objective, but I don't think it is a requirement "specific to P2MP". It looks more like a constraint that you wish to apply to your solution. Even then, there are three issues you fail to note: a. If you graft a destination in a domain that is not already part of the domain tree, then there will be an impact in another domain. b. If you prune the last destination from within a domain there will be an impact in another domain. c. You are only making this statement at the time of graft/prune, and not at the time of tree (or sub-tree) reoptimization. It would almost certainly be better to rephrase this statement more clearly in terms of what you are trying to achieve rather than the result of that. It would appear that you do not want grafting a new destination to cause the creation of an additional entry point to a domain that already has an entry point. That is, you want the graft to be contained to the subtree that is within a domain, and you accept that the potential reduction in optimality of doing this (although I note that you rejected the idea of setting up the P2MP tree in this way). --- Section 5 5. It SHOULD be possible to specify the domain entry and exit nodes. 6. Specifying which nodes are be used as branch nodes SHOULD be supported. Way too much passive voice. Who can specify to whom in what message? --- Section 6 In addition to the OFs, the following constraint optimization may also be beneficial for P2MP path computation: What is a "constraint optimization" if not an Objective Function? --- Section 6 3. It SHOULD be possible to force the branches for all leaves within a domain to be in that domain. I think you probably mean that is must be possible to limit the number of entry points for a domain to be 1. This looks identical to the previous point. --- Section 7 The following sections describe the core tree-based procedures to satisfy the requirements specified in the previous section. A core tree-based solution provides an optimal inter-domain P2MP TE LSP. No it doesn't as shown in the trivial example above. But that is OK if (and only if!) your objective here is not to derive optimal inter-domain P2MP TE LSPs, but to make an optimal core-tree and let the final sub-trees go hang. That may be pretty acceptable (especially or the transit carriers) and if you were to reposition the document in that way, it would be fine. --- Section 7.2 The algorithms to compute the optimal large core tree are outside scope of this document. What is a "large core tree" and how does it differ from a "core tree"? --- I am pretty confused by the point of section 7.2. What I think see is a complexity trade-off that recognises that it may be easier to build a core tree first and then splice in leaves that live in each domain. but it should be pretty clear that this trade-off sacrifices optimality with the potential of doing so fairly badly. Additionally, I think that some of your objectives (section 6) are hidden in the description in 7.2 where you have simply said "Apply the OF to each of these M core trees and find the optimal Core Tree." And this leaves me with two key points: - Why can't the PCE use its own algorithms to look at the set of VSPTs to build the optimal core tree? Why do you require it to walk every possible path set? - Why can't exactly the mechanism that you have described be applied to the full set of leaves? Or maybe to some mixture to leaves and BNs? Surely it is up to the PCE to make this choice. I don't want to say to you "I wouldn't have done it like this", but I think that to resolve my concerns you need to be clear in the document about what trade-offs you are making and why, and you need to explain what choices are open to the PCE. --- 7.4.1 My reading of http://www.iana.org/assignments/pcep/pcep.xhtml#rp-object is that no bits are assigned for experimentation. How will your C bit be kept safe in the field without colliding with some new PCEP feature release? --- 7.4.2 The procedure as described in this document requires the domain-tree to be known in advance. This information may be provided dynamically as documented in the Hierarchical PCE (H-PCE) [RFC6805] framework, or obtained through the IGP/BGP routing information. I don't think this reads right. Maybe: "The information from which this domain-tree may be derived..." --- 7.4.2 Surely [DOMAIN-SEQ] is being used as a normative reference. --- 7.4.2 The use of PCE sequence rather than domain-sequence, is based on deployment and implementation preference. I think most readers will find this statement cryptic. 1. What is the difference between domain-sequence and PCE-sequence? 2. In the case of deployment making a difference you can probably give some guidance. 3. In the case of implementation preference, isn't there some major risk of non-interoperability? --- Section 7.5 is fine except for the way it is expressed. It says that the ingress/root PCE will be required to have sessions with every PCE providing a subtree. It says, "and here is a way to operate so it doesn't." You just need to fix the text so it reads better. --- Section 7.6 I don't think that is a good or necessary use of "SHOULD". --- Section 7.6 1. The BRPC procedure for each leaf node can be launched in parallel by the ingress/root PCE if the dynamic computation of the Core Tree is enabled. 2. Intra-domain P2MP paths can also be computed in parallel by the PCEs once the entry and exit nodes within a domain are known This seems to be a change in direction from the previous text. Does 1 actually mean s/each leaf node/each leaf BN/ ? Does 2 actually mean s/Intra-domain P2MP paths/Intra-domain sub-trees/ ? |
2013-10-10
|
05 | Adrian Farrel | State changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2013-10-09
|
05 | Adrian Farrel | Ballot writeup was changed |
2013-10-09
|
05 | Adrian Farrel | Ballot writeup was generated |
2013-10-03
|
05 | Adrian Farrel | State changed to AD Evaluation from Publication Requested |
2013-09-24
|
05 | Julien Meuric | IETF WG state changed to Submitted to IESG for Publication |
2013-09-24
|
05 | Julien Meuric | IESG state changed to Publication Requested |
2013-09-24
|
05 | Julien Meuric | State Change Notice email list changed to pce-chairs@tools.ietf.org, draft-ietf-pce-pcep-inter-domain-p2mp-procedures@tools.ietf.org |
2013-09-24
|
05 | Julien Meuric | Responsible AD changed to Adrian Farrel |
2013-09-24
|
05 | Julien Meuric | Working group state set to Submitted to IESG for Publication |
2013-09-24
|
05 | Julien Meuric | IESG state set to Publication Requested |
2013-09-24
|
05 | Julien Meuric | IESG process started in state Publication Requested |
2013-09-24
|
05 | Julien Meuric | Intended Status changed to Experimental from None |
2013-09-24
|
05 | Julien Meuric | Changed document writeup |
2013-09-24
|
05 | Julien Meuric | Document shepherd changed to Julien Meuric |
2013-07-14
|
05 | Daniel King | New version available: draft-ietf-pce-pcep-inter-domain-p2mp-procedures-05.txt |
2013-06-12
|
04 | Julien Meuric | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2013-05-22
|
04 | Julien Meuric | IETF WG state changed to In WG Last Call from WG Document |
2013-05-15
|
04 | Daniel King | New version available: draft-ietf-pce-pcep-inter-domain-p2mp-procedures-04.txt |
2013-02-26
|
(System) | Posted related IPR disclosure: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-pce-pcep-inter-domain-p2mp-procedures-03 | |
2013-02-25
|
03 | Daniel King | New version available: draft-ietf-pce-pcep-inter-domain-p2mp-procedures-03.txt |
2012-05-02
|
02 | Dhruv Dhody | New version available: draft-ietf-pce-pcep-inter-domain-p2mp-procedures-02.txt |
2011-10-30
|
01 | (System) | New version available: draft-ietf-pce-pcep-inter-domain-p2mp-procedures-01.txt |
2011-09-14
|
00 | (System) | New version available: draft-ietf-pce-pcep-inter-domain-p2mp-procedures-00.txt |