Re: [Pce] IPR poll on draft-ietf-pce-stateful-path-protection
I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. On Tue, Apr 23, 2019, 12:50 PM Hariharan Ananthakrishnan wrote: > Hi Authors, > > Please respond ASAP if you have not already done so. The WC LC runs till > 4/30. > > - Hari > > On Tue, Apr 9, 2019 at 7:57 PM Hariharan Ananthakrishnan > wrote: > >> Hi authors, >> >> In preparation for Working Group last call on this draft, I'd like all >> authors and contributors to confirm on the list that they are in compliance >> with IETF IPR rules. >> >> Please respond (copying the mailing list) to say one of: >> >> I am not aware of any IPR applicable to this draft that should be disclosed >> in accordance with IETF IPR rules. >> >> I am aware of IPR applicable to this draft, and it has already been >> disclosed to the IETF. >> >> I am aware of IPR applicable to this draft, but that has not yet been >> disclosed to the IETF. I will work to ensure that it will be disclosed in a >> timely manner. >> >> Thanks, >> - Hari >> >> ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] IPR Check on draft-ietf-pce-association-group
I am not aware of any IPR that applies to this draft. On Thu, Sep 6, 2018 at 7:00 PM, Julien Meuric wrote: > Dear authors of draft-ietf-pce-association-group, > > Could you please send an email to the PCE mailing list saying whether > you are aware of any IPR that applies to > draft-ietf-pce-association-group and, if so, if it has been disclosed in > compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669 and 5378 for > more details.) > If you are not aware of any IPR that applies, please reply saying "I am > not aware of any IPR that applies to this draft". > > A reply is required from each of you before we can proceed with > publication request. > > Thanks, > > Jon & Julien > ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Poll for Adoption of draft-crabbe-pce-pce-initiated-lsp-03
Support as coauthor ^_^ On Tue, Nov 12, 2013 at 6:14 AM, Julien Meuric julien.meu...@orange.com wrote: Hi all. Following the opposition expressed on merging MPLS and GMPLS documents for stateful PCE, the sense of the room was in favor of adopting the aforementionned I-D. Now we would like to get the feedback of the mailing list: do you support draft-crabbe-pce-pce-initiated-lsp-03 to become a foundation for a PCE WG document? As usual, reasons for your preference are welcome (not to say mandatory in case of opposition). Thanks, JP Julien ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Proposed updated Charter
This looks good to me Adrian. Thanks, -ed On Mon, May 6, 2013 at 3:57 AM, Adrian Farrel adr...@olddog.co.uk wrote: Hi, ** ** I have entered what I believe is your desired new charter text at http://datatracker.ietf.org/doc/charter-ietf-pce/ ** ** The diff is at http://www.ietf.org/rfcdiff?url1=http%3A%2F%2Fwww.ietf.org%2Fcharter%2Fcharter-ietf-pce-05.txtdifftype=--hwdiffsubmit=Go%21url2=http%3A%2F%2Fwww.ietf.org%2Fcharter%2Fcharter-ietf-pce-05-00.txt ** ** Looks like the only change is the new work item at the end of the list.*** * ** ** Before going to the next stage I need to hear: - that I have the changes right as intended - a few voices from the WG saying Yes, this is what we want. ** ** I realise that the topic has been discussed (possibly to death), but a few hands raised at this stage will confirm that people really intend to work on this. ** ** Thanks, Adrian ** ** ** ** *From:* pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] *On Behalf Of *JP Vasseur (jvasseur) *Sent:* 05 May 2013 09:45 *To:* pce@ietf.org *Subject:* Re: [Pce] Proposed updated Charter ** ** Dear all, ** ** We have not received any feedback (positive or negative) about the proposed text that was discussed for the most part during the last WG meeting - We will now discuss it with our Area Director. ** ** Thanks. ** ** JP and Julien. ** ** On Apr 16, 2013, at 3:51 AM, JP Vasseur (jvasseur) wrote: ** ** Dear all, ** ** As discussed in Orlando and according to the consensus in the WG to modify our charter, please find a proposed text. ** ** Please comment by April 30th. ** ** JP and Julien. ** ** *Description of Working Group* The PCE Working Group is chartered to specify the required protocols so as to enable a Path Computation Element (PCE)-based architecture for the computation of paths for MPLS and GMPLS Point to Point and Point to Multi-point Traffic Engineered LSPs. In this architecture path computation does not necessarily occur on the head-end (ingress) LSR, but on some other path computation entity that may physically not be located on each head-end LSR. The PCE WG works on application of this model within a single domain or within a group of domains (where a domain is a layer, IGP area or Autonomous System with limited visibility from the head-end LSR). At this time, applying this model to large groups of domains such as the Internet is not thought to be possible, and the PCE WG will not spend energy on that topic. The WG specifies the PCE communication Protocol (PCEP) and needed extensions for communication between LSRs (termed Path Computation Clients - PCCs) and PCEs, and between cooperating PCEs. Security mechanisms such as authentication and confidentiality are included. The WG determines requirements for extensions to existing routing and signaling protocols in support of the PCE architecture and the signaling of inter-domain paths (e.g. RSVP-TE and its GMPLS variations). Any necessary extensions will be produced in collaboration with the Working Groups responsible for the protocols. The WG also works on the mechanisms to for multi-layer path computation and PCEP extensions for communication between several network layers. The WG defines the required PCEP extensions for Wavelength Switched Optical Networks (WSON) while keeping consistency with the GMPLS architecture specified in the CCAMP WG. Work Items: - PCEP extensions for MPLS and GMPLS Traffic Engineered LSP path computation models involving PCE(s). This includes the case of computing the paths of intra and inter-domain TE LSPs. Such path computation includes the generation of primary, protection and recovery paths, as well as computations for (local/global) reoptimization and load balancing. Both intra- and inter-domain applications are covered. - In cooperation with protocol specific Working Group (e.g., MPLS, CCAMP), development of LSP signaling (RSVP-TE) extensions required to support PCE-based path computation models. - Specification of PCEP extensions for communication in the various GMPLS-controlled networks, including WSON. - Definition of PCEP extensions for path computation in multi-layer networks. - Definition of the PCEP extensions used by a stateful PCE for recommending a new path for an existing or new LSP to the PCC/PCE. Further protocol extensions must cover the case where the recommendation is not followed by the PCC/PCE. *Goals and Milestones* April 2013 Submit the GMPLS requirements to the IESG to be considered as an Informational RFC Sept 2013 Submit PCEP extensions for GMPLS to the IESG to be considered as a Proposed Standard Sept 2013 Submit inter-area/AS applicability statement to the IESG as an Informational RFC Nov
Re: [Pce] Stateful PCE Capability discovery draft: request for review adoption as a WG document
Ditto: I support this draft's adoption as a WG document. On Wed, Apr 3, 2013 at 9:08 AM, Ina Minei i...@juniper.net wrote: This is useful and straightforward functionality that is much needed for a deployment and completes the solution. I support this draft's adoption as a WG document (but I guess we will wait for the chairs to send the official poll, right?) Ina -Original Message- From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of Jan Medved (jmedved) Sent: Wednesday, March 27, 2013 3:49 PM To: pce@ietf.org Subject: [Pce] Stateful PCE Capability discovery draft: request for review adoption as a WG document Dear PCE'rs, can you please review draft-sivabalan-pce-disco-stateful and send your comments to the list? The draft is at: http://datatracker.ietf.org/doc/draft-sivabalan-pce-disco-stateful/. Also, can you please let us know if you are in favor/opposed to adopting draft-sivabalan-pce-disco-stateful as a PCE WG document? Thanks a lot in advance, Siva and Jan ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] 答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE
We currently appear to be involved in some sort of pre-fiat working group process debate. Unfortunately, I think you're injecting a particularly onerous and unnecessary sort of wg bureaucracy here, and for no discernible reason. At this point, given the lack of any substantive technical argument, I have to say that I actually feel that you're being a bit obstructionist. :-/ I hope that's not the case. Obviously the working group can have any technical discussion it wants, to within the bounds of reason and the chair's limits of tolerence. ;) So let's do that, and try to make our time together here productive. ^_^ w/r/t the specific comments: Yes, we already have introduced a delegation function and have had since the first rev of the draft. It is, IMO, defined clearly in the draft-crabbe-pce-stateful-pce-02. You should read it. If you don't think the definition is clear, then we should discuss that so we can improve the text. I continue to maintain that the main differences between receipt of computation results between 5440 and active PCEP as defined in draft-crabbe-pce-stateful-pce-02 is directionality and asynchrony. If you have a good reason for thinking that this is not the case, or have other technical issues with the delegation model, then please, by all means... On Sun, Nov 11, 2012 at 6:56 PM, Fatai Zhang zhangfa...@huawei.com wrote: Hi Jan, You said: =By requesting a path computation from a PCE, the PCC gives the PCE authority to determine the ERO, LSP Bandwidth, protection, LSP setup and hold priorities, etc. The PCE is the entity that determines these parameters - would you agree? ** ** [Fatai] Sorry, I don’t agree. The parameters (LSP bandwidth, protection, etc) are the constraints sent from PCC to PCE for **path computation**. For example, a PCC sends a PCReq to request a LSP with bandwidth 1Gpbs, and then the PCE MUST not return a path with e.g, 100Mbps, ie., the PCE **cannot determine** these parameters. The ERO is the path information (path list) that PCE returns to PCC after path computation. ** ** If you want to introduce **delegation** function (whatever we call it), the delegation definintion should be defined clearly. And then the WG will/can discuss more whether this “delegation” is needed or not (and whether this “delegation” is in the scope of the existing charter). ** ** ** ** Best Regards ** ** Fatai ** ** *发件人:* Jan Medved (jmedved) [mailto:jmed...@cisco.com] *发送时间:* 2012年11月10日 0:27 *收件人:* Fatai Zhang *抄送:* Oscar González de Dios; pce@ietf.org *主题:* Re: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE ** ** Faital, ** ** On Nov 9, 2012, at 12:20 AM, Fatai Zhang wrote: The delegation of LSP control to a PCE is *implicit* in RFC4655. When a PCC sends a PCReq message to a PCE requesting path computation (and parameter setting) for an LSP, it effectively delegates control over that LSP to the PCE. The delegation is valid for one request (and one path computation) only. [Fatai] I don't think that RFC4655 can support delegation of LSP *control* (even implicitly). A PCC sends a PCReq to a PCE, it does not mean that this LSP is delegated to the PCE. ** ** By requesting a path computation from a PCE, the PCC gives the PCE authority to determine the ERO, LSP Bandwidth, protection, LSP setup and hold priorities, etc. The PCE is the entity that determines these parameters - would you agree? ** ** Now, whether we use control, authority, power, mandate, whatever - that does not change the fact that the PCC asks the PCC to determine what the LSP parameters are, and the PCE determines what the LSP parameters are. That's what we call delegation - the PCC delegates the computation of LSP path and determination of LSP parameters to the PCE. ** ** My email states a little later: the PCC may or may not use the LSP path/parameters that it got from the PCE. We all agree that the PCC has the ultimate control over the LSP - it may take the directions from the PCE, it may not. ** ** draft-ietf-pce-stateful-pce does not change any of this. The PCC gives the PCE the control/authority/mandate/power to determine the LSP's parameter. But, rather than doing this implicitly by requesting the PCE to determine those parameters (in a PCReq message), it does it explicitly. Delegation does not change the paradigm set by RFC4655 and RFC5440 - but in addition to LSP parameters, it allows the PCE to determine the timing of the LSP setup. ** ** If you don't like the term delegation, please suggest another one. I don't particularly care what we call the mechanism. ** ** ** ** ** ** Thanks, Jan ** ** ** ** ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] 答复: 答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE
I'm surprised by your surprise. ^_^ Seriously though, I don't mean to offend you: I want to have a productive discussion here. Most of the conversation in this thread thus far is about either language, or whether the functionality is within the scope of the charter. I believe one of our chairs has already weighed in on the scope side, so I guess we're talking about either language or I'm missing some technical point you've made regarding mechanism. W/rt whether the PCE can set parameters: yes, it clearly can. This is consistent with rfc4655 IMO. As I stated previously: I continue to maintain that the main differences between receipt of computation results between 5440 and active PCEP as defined in draft-crabbe-pce-stateful-pce-02 is directionality and asynchrony. If you have a good reason for thinking that this is not the case, or have other technical issues with the delegation model, then please, by all means... On Sun, Nov 11, 2012 at 8:50 PM, Fatai Zhang zhangfa...@huawei.com wrote: I am surprised by your tone. ** ** I am touching the tech points and trying to clarity why PCE cannot ** determine** those parameters. You can correct me if I am wrong from the tech perspective. ** ** If you still use this kind of tone, sorry, I will ignore your response.*** * ** ** ** ** ** ** Best Regards ** ** Fatai ** ** *发件人:* Edward Crabbe [mailto:e...@google.com] *发送时间:* 2012年11月12日 11:59 *收件人:* Fatai Zhang *抄送:* Jan Medved (jmedved); pce@ietf.org *主题:* Re: [Pce] 答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE ** ** We currently appear to be involved in some sort of pre-fiat working group process debate. Unfortunately, I think you're injecting a particularly onerous and unnecessary sort of wg bureaucracy here, and for no discernible reason. At this point, given the lack of any substantive technical argument, I have to say that I actually feel that you're being a bit obstructionist. :-/ I hope that's not the case. ** ** Obviously the working group can have any technical discussion it wants, to within the bounds of reason and the chair's limits of tolerence. ;) So let's do that, and try to make our time together here productive. ^_^ ** ** w/r/t the specific comments: ** ** Yes, we already have introduced a delegation function and have had since the first rev of the draft. It is, IMO, defined clearly in the draft-crabbe-pce-stateful-pce-02. You should read it. If you don't think the definition is clear, then we should discuss that so we can improve the text. ** ** I continue to maintain that the main differences between receipt of computation results between 5440 and active PCEP as defined in draft-crabbe-pce-stateful-pce-02 is directionality and asynchrony. If you have a good reason for thinking that this is not the case, or have other technical issues with the delegation model, then please, by all means... ** ** ** ** On Sun, Nov 11, 2012 at 6:56 PM, Fatai Zhang zhangfa...@huawei.com wrote: Hi Jan, You said: =By requesting a path computation from a PCE, the PCC gives the PCE authority to determine the ERO, LSP Bandwidth, protection, LSP setup and hold priorities, etc. The PCE is the entity that determines these parameters - would you agree? [Fatai] Sorry, I don’t agree. The parameters (LSP bandwidth, protection, etc) are the constraints sent from PCC to PCE for **path computation**. For example, a PCC sends a PCReq to request a LSP with bandwidth 1Gpbs, and then the PCE MUST not return a path with e.g, 100Mbps, ie., the PCE **cannot determine** these parameters. The ERO is the path information (path list) that PCE returns to PCC after path computation. If you want to introduce **delegation** function (whatever we call it), the delegation definintion should be defined clearly. And then the WG will/can discuss more whether this “delegation” is needed or not (and whether this “delegation” is in the scope of the existing charter). Best Regards Fatai *发件人:* Jan Medved (jmedved) [mailto:jmed...@cisco.com] *发送时间:* 2012年11月10日 0:27 *收件人:* Fatai Zhang *抄送:* Oscar González de Dios; pce@ietf.org *主题**:* Re: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE Faital, On Nov 9, 2012, at 12:20 AM, Fatai Zhang wrote: ** ** The delegation of LSP control to a PCE is *implicit* in RFC4655. When a PCC sends a PCReq message to a PCE requesting path computation (and parameter setting) for an LSP, it effectively delegates control over that LSP to the PCE. The delegation is valid for one request (and one path computation) only. [Fatai] I don't think that RFC4655 can support delegation of LSP *control* (even implicitly). A PCC sends a PCReq
Re: [Pce] 答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE
In addition, I would like to remind that **set** != **delegation**, maybe we stray a little from the point, J Please clearly explain your perception of the difference. ** ** ** ** ** ** Best Regards ** ** Fatai ** ** *发件人:* Jan Medved (jmedved) [mailto:jmed...@cisco.com] *发送时间:* 2012年11月12日 13:09 *收件人:* Fatai Zhang *抄送:* Oscar González de Dios; pce@ietf.org *主题:* Re: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE ** ** Fatai, ** ** On Nov 11, 2012, at 6:56 PM, Fatai Zhang wrote: Hi Jan, You said: =By requesting a path computation from a PCE, the PCC gives the PCE authority to determine the ERO, LSP Bandwidth, protection, LSP setup and hold priorities, etc. The PCE is the entity that determines these parameters - would you agree? [Fatai] Sorry, I don’t agree. The parameters (LSP bandwidth, protection, etc) are the constraints sent from PCC to PCE for **path computation**. ** ** ** ** Please re-read rfc5440. A PCRep *may* contain all the above objects. There is nothing in the RFC5440 saying the PCE could not set these parameters as it sees fit - even change the BANDWIDTH parameter suggested by a PCC. For example, a PCC sends a PCReq to request a LSP with bandwidth 1Gpbs, and then the PCE MUST not return a path with e.g, 100Mbps, ie., the PCE **cannot determine** these parameters. The ERO is the path information (path list) that PCE returns to PCC after path computation. Please re-read rfc5440 - BANDWIDTH and all other LSP parameters are *optional* on PCReq. A use case where a PCC does not include BANDWIDTH on the PCReq message and leaves the determination of a path's bandwidth to the PCE is well within the spec. And as I said above, a PCRep may optionally contain bandwidth and other LSP parameters, not just the ERO. ** ** Even if we say that the only thing that the PCE does is path computation, the PCC *delegates* path computation to the PCE. That means, delegation - as a concept - has been a part of the PCE architecture from the very beginning. Therefore, your arguments above about bandwidth, etc. are moot. ** ** If you want to introduce **delegation** function (whatever we call it), the delegation definintion should be defined clearly. ** ** We don't have to introduce it, it's already in the PCE architecture. That's a fact. You may disagree. You are, of course, entitled to your own opinions, but not to your own facts. I tried to explain delegation in this email thread as clearly as I could. Please re-read it, and if you don't understand something, ask a pointed question. If you disagree with something i wrote, please address that clearly. Then we can have a meaningful discussion. But please do not try to reset the discussion to with general statements. And then the WG will/can discuss more whether this “delegation” is needed or not (and whether this “delegation” is in the scope of the existing charter). Where have you been when the WG discussed draft-ietf-pce-stateful-pce? Best Regards Fatai Thanks, Jan *发件人:* Jan Medved (jmedved) [mailto:jmed...@cisco.com] *发送时间:* 2012年11月10日 0:27 *收件人:* Fatai Zhang *抄送:* Oscar González de Dios; pce@ietf.org *主题:* Re: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE Faital, On Nov 9, 2012, at 12:20 AM, Fatai Zhang wrote: The delegation of LSP control to a PCE is *implicit* in RFC4655. When a PCC sends a PCReq message to a PCE requesting path computation (and parameter setting) for an LSP, it effectively delegates control over that LSP to the PCE. The delegation is valid for one request (and one path computation) only. [Fatai] I don't think that RFC4655 can support delegation of LSP *control* (even implicitly). A PCC sends a PCReq to a PCE, it does not mean that this LSP is delegated to the PCE. By requesting a path computation from a PCE, the PCC gives the PCE authority to determine the ERO, LSP Bandwidth, protection, LSP setup and hold priorities, etc. The PCE is the entity that determines these parameters - would you agree? Now, whether we use control, authority, power, mandate, whatever - that does not change the fact that the PCC asks the PCC to determine what the LSP parameters are, and the PCE determines what the LSP parameters are. That's what we call delegation - the PCC delegates the computation of LSP path and determination of LSP parameters to the PCE. My email states a little later: the PCC may or may not use the LSP path/parameters that it got from the PCE. We all agree that the PCC has the ultimate control over the LSP - it may take the
Re: [Pce] 答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE
AFAIK: (a): we are getting guidance from the chairs on an ongoing basis and (b): the solution and framework are coupled and are reasonably well defined currently, modulo the (largely aesthetic) considerations raised On Thu, Nov 8, 2012 at 1:11 AM, Fatai Zhang zhangfa...@huawei.com wrote: Hi Oscar, Ed and all, ** ** I totally agree with Oscar. ** ** I think we should follow the regular procedures of PCE WG (IETF as well) to define the foundation work first including FWK, requirement, applicability before dropping into the solution stuff. ** ** Guidance from WG chairs on this stateful PCE work must be appreciated. ** ** ** ** Best Regards ** ** Fatai ** ** *发件人:* pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] *代表 *Oscar González de Dios *发送时间:* 2012年11月8日 8:17 *收件人:* Edward Crabbe *抄送:* pce@ietf.org *主题:* Re: [Pce] Questions about stateful PCE, relation to WG charter and opinion about stateful PCE ** ** Hi Ed, answers inline, IMO: they're the same thing, the only difference is directionality and asynchrony. [Oscar] Agree.. Let’s see what our WG chairs say. My opinion in the matter of the stateful PCE is that we should separate the functionality is different functional elements, in the same way as it was done in the Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering (RFC 5623) between a VNTM and the PCE. In such RFC, the roles of each functional element are clearly distinguished. Let be the stateful PCE a Path Computation element using the traffic engineering database and the LSP database, and then, define another functional element (call it LSP controller, call it manager) that is in care of the control issues. This argument is orthogonal to the previous paragraph regarding the charter; let's separate the two discussions. ;) [Oscar] Agree, it’s a separate discussion. w/r/t *element* separation: I think that's a poor idea, sorry. It makes total sense to me that a given PCE would be able to negotiate and support stateful or stateless functionality. [Oscar] What I mean is to have a demarcation of the functional blocks. My problem is that I may be too picky, but I like to call things by its name… and for me still Path Computation refers to the computation function and not controlling. So path computation and control of a delegated LSP (or even initiation) are different functions, which are tightly connected to solve the problems. I guess when you refer to negotiate “stateful” functionality you are referring to negotiate the delegation+whatever control functionalities and not only the fact of using (and synchronizing) the LSP Database. The confusion may come from the fact you see the “stateful PCE” as the sum of a controller + a PCE + TEDB+LSPDB…. I like that entity, but, strictly speaking, it is more than a PCE …… But it is only a matter of naming, we all have agreed that the functionality is needed, and that PCEP is a good protocol to support it. I see this “controller” functional block as a generalization of the VNTM functional block defined in RFC 5623 for the specific case of controlling/managing an overlay network. Said that, I must say that I like the new functionalities proposed , and I think they solve problems (and people also did like them, as the stateful draft was supported by the WG people). What I do not like at all is how it is being handled. There has been a solution quickly adopted without taking any care in the architectural/functional implications. In my opinion we should handle them now. Define quickly man? The original draft went through multiple rounds of review both on list and in multiple (technically two but really three) IETF meetings before acceptance. It has received, as you said, broad support and review by many people on the list, including you. ;) It is at a relatively low rev count and is still a work in progress. [Oscar] And I do support it and like it! I meant quickly because it went through directly as a solution. Other pieces of work had to deal first with the framework/requirements and then jump in the solution, there are plenty of examples around, you can see the time of the first draft of the framework/requirements and the time of the adoption of the first WG solution…. (Interlayer, GMPLS, H-PCE)… This stateful PCE approach has a lot of implications, this is why I think we should take it with care and make it work together, with a clear architecture and make a good framework to have solid foundations. best, -ed Best Regards, Óscar ** ** -- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de
Re: [Pce] 答复: stateful PCE - moving forward next steps
Oscar; Comments in-line; In the case of current Working Group stateful PCE solution (draft-ietf-pce-stateful-pce-02), the focus is mainly on the new functions to be supported: Capability Negotiation, State Synchronization, LSP State Report , LSP Control Delegation, LSP Update Request, etc All these set of functions are independent whether it is a MPLS-TE or a GMPLS tunnel. Thus, I don't see why the scope should be limited to MPLS-TE. Thank you very much for being specific about which draft you are referring to! The framework draft, draft-ietf-pce-stateful-pce-02, is obviously NOT limited to MPLS-TE. This draft is intended to support extensions for MPLS-TE, GMPLS and other potential extensions going forward. This has been the case from the beginning. Please see my previous email about the /framework/ draft supporting MPLS-TE GMPLS as well as the several off list discussions we've had regarding same. An (re)illustration of the proposed document set relationships is included below: applicability draft | | core framework draft | | /|\ / | \ / | \ / |RSVP-TE /| / | GMPLS| | other extensions note that this is *not* a timeseries. :P Would those functions be different in GMPLS and needed separate messages and objects, I would agree in separating the solution. For example, in the current draft, there are very few objects which are MPLS-TE specific. That is intentional. Again, you are referring to the framework draft, which was intended to support both from the beginning. AFAIK we are discussing the separate extension drafts. If we are NOT discussing the separate extensions draft then we are in violent agreement: the framework should, and does support both. I have gone through the document several times to see the points which could be different in GMPLS, and I could not find them (maybe I miss something here, so If you think the number of specific MPLS-TE /GMPLS objects will be significant, please give the examples). All the new messages apply for both MPLS-TE and GMPLS, without the need of any change. Yes, this was deliberate. Please see my previous email in the thread regarding extension vs framework. For other applications of the stateful PCE, GMPLS and MPLS-TE may go in separate documents if there are many differences between them, and the documents are cleaner with separate extensions. (in fact this is the case for Google; as a company we do not care about GMPLS, we /do/ very much care about MPLS-TE.) Sorry, Ed, but the argument of a specific company position of what cares or not is by no means acceptable. Please, limit the arguments to technical and not political. Oh, I agree that the specific google instance has no bearing here; this isn't a political argument and is true no matter what company we're talking about, vendor or customer. The longer form of the argument is as follows: If you combine the *extension* drafts, you end up with both features being glommed together in one spec. If a specific vendor is in one market or the other and does not require the full spec, OR a specific customer has need of only one of the two and is pushing a vendor to implement it, combining the two into a single draft either adds additional work in unnecessarily implementing both or potentially increases the difficulty for the implementor in disentangling the two and claiming RFC compliance. Having separate *extension* drafts inherently provides the split that exists the two markets in reality. best, -ed Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] stateful PCE - moving forward next steps
I completely disagree. I think it makes a great deal of sense from both organizational and an implementation perspectives. As a designer of these protocols, it makes a great deal of sense to separate different extensions into different documents. This improves readability, makes draft revision simpler, decreases overall complexity for draft readers and just makes great deal of sense from an organizational perspective. As a consumer of these protocols, I may want to encourage vendors to implement one of these features without forcing them to implement both. (in fact this is the case for Google; as a company we do not care about GMPLS, we /do/ very much care about MPLS-TE.) On Thu, Oct 25, 2012 at 6:27 PM, Zhangxian (Xian) zhang.x...@huawei.comwrote: Hi, Dear Julien and all, IMHO, the stateful PCEP protocol extensions for both MPLS and GMPLS have lots in common. So, my understanding is that there should be one extension document. However, the preference of different parties diverges. It would be good if we can hear more from the experts on the list which is a better way to proceed. Regards, Xian -Original Message- From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of Julien Meuric Sent: 2012年10月25日 17:39 To: Ramon Casellas Cc: pce@ietf.org Subject: Re: [Pce] stateful PCE - moving forward next steps Hi Ramon, hi contributors from shadow. We appreciate the effort of all those who are working on this work. It will be interesting to discuss the progress during our meeting in Atlanta. In the meantime, do not hesitate to share with the WG using the mailing list, like your message below. One 1st comment at this stage: you seem to suggest that the idea is to have separate document for MPLS-TE and GMPLS, but you do not give rationale. Apart from our history of RFC 5440 + draft-ietf-pce-gmpls (even with its scope, the former had a hard time), is there a particular reason for this choice? Do you expect much difference between those 2 kinds of extensions? Also keep in mind that GMPLS includes PSC... Thank you, Julien On 10/20/2012 08:59, Ramon Casellas wrote: Dear PCErs, We've taken this issue off-list and discussed. A summary of our agreed upon next steps follows for WG review: 1/ - We have agreed to merge the applicability portion of the existing WG draft (draft-ietf-pce-stateful-pce) with Xian’s presented draft on this very same aspect. This new joint/merged draft, temporarily referred to as draft-zhang-pce-stateful-pce-app-03, will tentatively be ready for IETF86. It will be informational in nature, highlighting the benefits and use cases of a stateful PCE. While this split is by no means mandatory, it does address some comments raised during WG adoption. Selected text and wording from to current framework draft draft-ietf-pce-stateful-pce-02 will be moved to the applicability, notably in sections 2 and 3. 2/ - draft-ietf-pce-stateful-pce-02 is relatively mature, and a significant amount of time has been invested on it. It has been recently updated to acknowledge/reflect that PCEP (and consequently any PCEP functional extensions) needs to be extended to fully cover GMPLS networks in a way similar to how RFC5440 is extended by draft-ietf-pce-gmpls. This draft already covers most refined details such as protocol procedures messages, LSP identifiers, LSP descriptive names, etc., while leaving technology specific aspects aside. 2.a – it is worth noting that, although draft-zhang-pce-stateful-app will surely need to follow regular draft procedures, the chairs explicitly agreed to accept the post-split framework as a working group document given the acceptance of the original stateful doc. 3/ Since one of the additional comments during the WG adoption poll (e.g., by yours truly and others) was that, in its previous form, draft-ietf-pce-stateful-pce did not cover GMPLS extensions and could limit its applicability in transport networks, specific “solutions” documents addressing extensions will be developed. They will be based on the framework and will refer to it. -A consequence of this is that draft Current Path Computation Element (PCE) Protocol Extension for Stateful PCE Usage in GMPLS Networks, aka draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt will be rewritten to follow the new apps fwk and will define encodings e.g. at the message level (such as extended RBNF for a PCRpt message considering GMPLS-specific extensions). -Likewise, for RSVP-TE covering non-GMPLS cases networks, a new draft has just been submitted and will be presented (draft-crabbe-pce-stateful-pce-mpls-te-00) -Within reasonable standard procedures, the GMPLS solutions draft can just point at the relevant sections within draft-crabbe-pce-stateful-pce-mpls-te-00 and complete where appropriate / necessary. 4/ Other stateful-PCE based applications will be identified in
Re: [Pce] FW: I-D Action: draft-ietf-pce-stateful-pce-02.txt
Xian, This is not accurate I'm afraid. We have presented the original (pre-split) draft at almost every meeting for the past several years, and have had WG consensus on it's acceptance as a WG document on both list and in meetings. as well as We have discussed the split at the last three consecutive IETF meetings, and explicitly asked the chairs in Vancouver. This document is simply the core framework split from the /already accepted/ working group document, and the chairs had agreed to accept the core document as a draft given that the parent doc had already been accepted and (assuming near content parity). So yeah, there's been quite a bit of discussion on this over a number of years. :P I'm not sure that issuing an applicability draft first is mandatory SOP; there are a number of drafts that simply have an applicability section within the draft (as ours does): presenting applicability, requirements and framework sequentially. With regard to our (now public) conversation, you've misinterpreted. Last IETF we discussed moving the applicability section into the a single document with you (without conclusion I might note), which has nothing to do with this draft. We tentatively agreed to move ahead with merging the already extant applicability section of our draft into yours as well as assuming co-authorship. We also agreed that the *framework* must provide the capability to create general extensions for MPLS GMPLS etc (thus /passing mention/ of GMPLS AND the reference to *YOUR* document. cheersm -ed On Thu, Oct 18, 2012 at 2:23 AM, Zhangxian (Xian) zhang.x...@huawei.comwrote: Hi, PCE'er, I just noticed that this WG document has been updated without any WG decisions/discussions. As I recall, there is no sufficient discussion during last IETF meeting, nor any public email discussion, with regard to how to proceed with this WG document. As a young engineer involved in IETF work, a standard way for updating a WG document, from what I observe, should it be that any modifications are based on the WG discussion? During last IETF meeting, I presented a proposal with regard to stateful PCE work. To state again, we would like to see this work follows a standard PCE WG procedure. By saying a standard procedure, I mean that stateful PCE should be driven by applicability/framework/requirements, then protocol extensions. Just to give a few examples which is currently listed as PCE WG drafts as well as RFCs: pcep extension for gmpls, inter-layer, hierarchical PCE and P2MP etc. All of them moved forward with applicability/framework/requirements first. There must be a valid reason for this rationale, right? I do not see why we should treat this draft as an exception. Unfortunately, we were not given sufficient time for a WG discussion on our proposal. However, as suggested by Ed., a bunch of us (Ramon, Oscar, Fatai, Young and me) had an offline discussion with him, and the group roughly agreed to move forward to the direction that we proposed above. However, I don’t see this draft is moving to that direction from the updated WG draft, even though one of our suggestions (i.e., GMPLS should be covered) is partially captured in the updated WG draft. Therefore, I would like to request more discussion in the PCE list on how to move forward stateful PCE topic. Regards, Xian -Original Message- From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org Sent: 2012年10月16日 6:08 To: i-d-annou...@ietf.org Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : PCEP Extensions for Stateful PCE Author(s) : Edward Crabbe Jan Medved Ina Minei Robert Varga Filename: draft-ietf-pce-stateful-pce-02.txt Pages : 49 Date: 2012-10-15 Abstract: The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for synchronization or PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS tunnels via PCEP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-02
Re: [Pce] New Version Notification for draft-crabbe-pce-stateful-pce-01.txt
Dave, Thanks, good catch - we're actually trying to say that the behavior is specified in 3209 AND is desirable for the reasons given. We will correct the text. cheers, -ed On Tue, Nov 1, 2011 at 10:58 PM, Cooper, Dave dave.coo...@level3.comwrote: Hi Jan, I'd like to express my support for this draft. One note; In the 3.1.2.3 Deadlock section, the first paragraph is a little confusing. I'm unsure why the behavior is not desirable given the explanations made. Do you mean that attempts to signal a LSP's bandwidth increase, for a given priority, may lead to sub-optimal allocation of global resources if the reservations of existing LSPs already signaled are not taken into account? Thanks, Dave -Original Message- From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of Jan Medved Sent: Monday, October 31, 2011 12:02 AM To: pce@ietf.org Subject: [Pce] FW: New Version Notification for draft-crabbe-pce-stateful- pce-01.txt Hello, We submitted a new version of the Stateful PCE draft, where we addressed comments / suggestions from reviewers on the mailing list - many thanks to all who reviewed commented. We to hope to have a good discussion of the draft in Taipei. Thanks, Ed+Jan+Robert On 10/30/11 11:50 PM, internet-dra...@ietf.org internet-dra...@ietf.org wrote: A new version of I-D, draft-crabbe-pce-stateful-pce-01.txt has been successfully submitted by Jan Medved and posted to the IETF repository. Filename: draft-crabbe-pce-stateful-pce Revision: 01 Title:PCEP Extensions for Stateful PCE Creation date:2011-10-30 WG ID:Individual Submission Number of pages: 41 Abstract: The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for synchronization or PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable this functionality, providing stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP) via PCEP. The IETF Secretariat ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] 答复: Re: New Version Notification for draft-crabbe-pce-stateful-pce-01.txt
Kexin, Not true; in one case (3.1.2.3) there is insufficient capacity to meet a demand (and thus the demand set: ie: the network is underprovisioned). In the rest of the cases, there is sufficient aggregate capacity to meet the demands. The total demand time series set is given for each toy example. The problem may be that you are interpreting the column on the far left of the demand tables as an lsp id / demand index when it is a time point in the time series of demand characteristics? best, -ed On Tue, Nov 1, 2011 at 11:48 PM, tang.ke...@zte.com.cn wrote: Dear Authors, I have reviewed your draft, the motivation described in 3.1.2 is very reasonable. I have a question. Do you make the assumption in your examples that there is no sufficient network resource for all the LSPs to be set up? We updated our stateful PCE I-D recently. http://tools.ietf.org/html/draft-tang-pce-stateful-pce-02 I think we are considering the same following problems. 1. Why stateful PCE is important? 2. How to realize stateful PCE? For the 1st problem, as I mentioned above, your consideration may mainly focus on the scenario where network resources is insufficient. Our motivation is mainly to the condition that the network capacity is enougy for all the LSPs to be set up. Our objective is to avoid resources conflict because lack of the state of LSPs. Take the follow demonstration topology for example. Link capacity of A-B / B-C / A-C: 100M Bandwidth demond: LSP 1 needs 80M. LSP2 needs 80M. Source and destination of LSP1 and LSP2: Both of them is from A to B. T1: PCE computed the shortest path for LSP1 : A-B (computation result did not synchronized with PCE) T2: PCE computed the shortest path for LSP2 : A-B (PCE assume the unreserved bandwidth of A-B is still 100M, although is 20M in fact) T3: LSP1 set up successful by signaling T4: LSP2 failed to set up by signaling (no sufficient link capacity aviable on link A-B) I think the objective of the two draft are the same that stateful PCE synchronized with the state of LSPs although by different mechanism. You defined two new PCEP messages (PCRpt and PCUpd), while we extended the existing PCNtf message. Thanks, Kexin -Original Message- From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of Jan Medved Sent: Monday, October 31, 2011 12:02 AM To: pce@ietf.org Subject: [Pce] FW: New Version Notification for draft-crabbe-pce-stateful- pce-01.txt Hello, We submitted a new version of the Stateful PCE draft, where we addressed comments / suggestions from reviewers on the mailing list - many thanks to all who reviewed commented. We to hope to have a good discussion of the draft in Taipei. Thanks, Ed+Jan+Robert On 10/30/11 11:50 PM, internet-dra...@ietf.org internet-dra...@ietf.org wrote: A new version of I-D, draft-crabbe-pce-stateful-pce-01.txt has been successfully submitted by Jan Medved and posted to the IETF repository. Filename: draft-crabbe-pce-stateful-pce Revision: 01 Title: PCEP Extensions for Stateful PCE Creation date: 2011-10-30 WG ID: Individual Submission Number of pages: 41 Abstract: The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for synchronization or PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable this functionality, providing stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP) via PCEP. The IETF Secretariat ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of
Re: [Pce] Comments on draft-crabbe-pce-stateful-pce-00.txt
Robert; Hey there. :) Comments in-line. * In introduction you say that PCE to PCE is out of scope while at the bottom of section 2 you say that PCE to PCE should be done as if requesting PCE is PCC. A bit confusing. Yes this is a typo. The text in section 2 is correct: PCE to PCE communication is in scope. * Also stating that PCE to PCE is out of scope you sort of cross PCE to PCE synchronization for redundancy. I understand that in the spirit of the draft it would have to go via PCC attached to 2 or more PCEs. PCE-PCE is in scope. I'm actually not sure it *can* be out of scope given the comments in * 3.1.2 typo .. double which yep :P * 3.1.2.3 .. I am not sure what are you showing in table 6. Demand 20 seems not achievable no matter what. Please clarify. hrm. Current text is: Lack of ingress admission control coupled with the behavior in [RFC3209] effectively results in mis-signaled LSPs during periods of contention for network capacity between LSPs in a given LSP priority. This in turn causes information loss in the TED with regard to actual network state, resulting in LSPs sharing common network interfaces with mis-signaled LSPs operating in a degraded state for significant periods of time, even when unused network capacity may potentially be available. The intent here is simply to point out that , due to RSVP-TE protocol behavior and decoupling of data and control planes in resource reservation, in periods of contention for network resources well behaved flows may be harmed by poorly behaved flows for extended periods even if there is sufficient capacity to route the well behaved flows elsewhere in the network. I guess the text here isn't clear enough. I'll work on it :P * In some TE scenarios it is useful to bind the incoming port on the headend to the TE-LSP from such headend. Maybe extending PCRpt message with such field could be not a bad idea ? This is essentially the beginnings of a FEC advertisement discussion. Out of scope for the current draft, but certainly an interesting use case for discussion. * Why do you enforce to signal the RRO ? Maybe things changed but I was under assumption that RRO is optional. At least most of the original TE deployments never used RRO. For explicitly configured LSPs ERO is sufficient. Is this that this document mandates the RRO to be enabled on each LSP which you delegate control to PCE ? Otherwise you would not know about the path cspf have chosen ? If so I think this RRO mandate needs to be a bit more explicitly discussed. This is primarily a naming artifact from 5440 section 7.10 * Section 6.2 talks about PCE to PCC overload case (PCUpd rate exceeded). Cool. How about the reverse ? Good point - we'll add it. regards, -ed ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] New Version Notification for draft-crabbe-pce-stateful-pce-00.txt
Adrian; I think not mentioning 5557 is clearly an oversight on our part. We will remedy this in the next version of the draft. Optimization of resource usage is certainly an interesting use case for stateful PCE (although by no means the only one), and the draft would benefit from a comparison with what is achievable via stateful extensions relative to 5557. Global control of LSP operation sequence in 5557 is predicated on the use of what is effectively a stateful (or semi-stateful) NMS, which is either not local to the switch (in which case we are required to use another northbound interface for LSP attribute changes) or local/collocated, in which case we have some significant issues with efficiency in resource usage. Stateful adds a few features here in that: 1) the requirements for the NMS and additional northbound interface are effectively removed 2) it allows the system with the greatest visibility of the system to determine which LSPs should reoptimized and on what time interval 3) the pce controls the sequence of events across pcc's, allowing for bulk (if not global) optimization, lsp shuffling etc Thanks much for pointing out the oversight. :-/ best, -ed On Tue, Oct 18, 2011 at 5:39 AM, Adrian Farrel adr...@olddog.co.uk wrote: Hi Ed, ** ** Interesting work, thanks. As you know, the concept of stateful PCE was in our minds all through the architecture phase of PCE and is included as a concept in RFC 4655. ** ** I think stateful PCE was left on one side over the last few years because it added complexity and the use cases were far more sophisticated than applied to initial use cases. But now that PCE is established as an idea, it is interesting to look at the more advanced uses that you describe and see how stateful PCE could be a benefit. ** ** It is good that you have a section on policy, because it is likely that operators will want to tweak this function in different ways according to how they run their networks. It might be interesting to make a reference to RFC 5394 and show how that description of policy fits in. Maybe the authors of 5394 could comment? ** ** You don't mention RFC 5557. Is this because you think GCO is too complex to be valuable or because it is not one of your primary use cases? ** ** Thanks, Adrian ** ** *From:* Edward Crabbe [mailto:e...@google.com] *Sent:* 17 October 2011 06:33 *To:* pce@ietf.org *Cc:* JP Vasseur; Julien Meuric *Subject:* Fwd: New Version Notification for draft-crabbe-pce-stateful-pce-00.txt ** ** Hello; ** ** We've submitted a draft for the group's consideration. We know that stateful PCE has been discussed by the working group in the past. We believe that we have addressed some of the issues that have been raised in previous discussions and have specific use cases that make stateful PCE valuable. We hope you'll find the time to look through the draft and comment on the list before the WG meeting in Taipei, and hope that we'll be able to have a fruitful and lively discussion there. ** ** best, ** ** -Edward ** ** -- Forwarded message -- From: internet-dra...@ietf.org Date: Sun, Oct 16, 2011 at 7:51 PM Subject: New Version Notification for draft-crabbe-pce-stateful-pce-00.txt To: e...@google.com Cc: jmed...@juniper.net, e...@google.com, rva...@juniper.net A new version of I-D, draft-crabbe-pce-stateful-pce-00.txt has been successfully submitted by Edward Crabbe and posted to the IETF repository. Filename:draft-crabbe-pce-stateful-pce Revision:00 Title: PCEP Extensions for Stateful PCE Creation date: 2011-10-16 WG ID: Individual Submission Number of pages: 39 Abstract: The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for synchronization or PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable this functionality, providing stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP) via PCEP. The IETF Secretariat ** ** ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Fwd: New Version Notification for draft-crabbe-pce-stateful-pce-00.txt
Hello; We've submitted a draft for the group's consideration. We know that stateful PCE has been discussed by the working group in the past. We believe that we have addressed some of the issues that have been raised in previous discussions and have specific use cases that make stateful PCE valuable. We hope you'll find the time to look through the draft and comment on the list before the WG meeting in Taipei, and hope that we'll be able to have a fruitful and lively discussion there. best, -Edward -- Forwarded message -- From: internet-dra...@ietf.org Date: Sun, Oct 16, 2011 at 7:51 PM Subject: New Version Notification for draft-crabbe-pce-stateful-pce-00.txt To: e...@google.com Cc: jmed...@juniper.net, e...@google.com, rva...@juniper.net A new version of I-D, draft-crabbe-pce-stateful-pce-00.txt has been successfully submitted by Edward Crabbe and posted to the IETF repository. Filename:draft-crabbe-pce-stateful-pce Revision:00 Title: PCEP Extensions for Stateful PCE Creation date: 2011-10-16 WG ID: Individual Submission Number of pages: 39 Abstract: The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for synchronization or PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable this functionality, providing stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP) via PCEP. The IETF Secretariat ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
