Hi, 

I find the problem statement interesting, how much control plane intelligence 
you want/need to put in the active stateful with instantiation.

My personal opinion is that controlling all the small aspects of the control 
plane may complicate too much the PCE.
The control plane is good at  handling autonomously the signaling, in this use 
case the active PCE (with  and without instantion) should limit itself to 
recommending the paths.


I understand the reason for the fully PCE controlled MBB is for coordination in 
multi-segment e2e tunnel. Could you illustrate the problem? Is it when you have 
several inter-control-domains link? From PCC point of view you  would not 
change the endpoints, so the MBB should be quite agnostic to the switching 
procedure.

I think that one option is missing : the PCE tells the Control plane "use this 
new route", and its up to the control plane to use the MBB or other signaling 
mechanism/protection mechanism available/configured.

From a technical point of view I think the additional information would be the 
ADMIN_STATUS of the LSP instead of the data control. One alternative (but less 
MBB/RSVP-TE) aligned would be to use the O bit of the PROTECTION_ATTRIBUTE TLC 
of the LSPA object (as defined draft-ietf-pce-stateful-pce-02 -section 6.2 and 
draft-crabbe-pce-stateful-pce-mpls-te-00, LSPA object) 

Finally: I am missing the error/restart procedures : control session closed, 
control plane restart, timers, ..etc
I think taking into account those error procedures would point into the 
direction of letting the control plane taking care of the existing signaling 
procedures.



Best regards / Mit freundlichen Grüßen
Cyril Margaria


> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> ext Yuji Kamite
> Sent: Monday, March 11, 2013 1:24 AM
> To: [email protected]; [email protected]
> Subject: Re: [Pce] I-D Action: draft-tanaka-pce-stateful-pce-mbb-00.txt
> 
> Hi all PCEres,
> 
> Attached I share the summary slides.  Your feedback is much
> appreciated.
> 
> This can partly be positioned as feedback to current stateful PCE's
> base specs, so we really welcome suggestion from their editors too.
> 
> Regards,
> -Yuji
> 
> 
> -----Original Message-----
> From: Yuji Kamite(上手祐治)
> Sent: Friday, March 08, 2013 5:11 PM
> To: [email protected]
> Subject: FW: I-D Action: draft-tanaka-pce-stateful-pce-mbb-00.txt
> 
> Hi folks,
> 
> Because of the shortness of presenting time in Orlando, let me briefly
> introduce our document recently posted here:
> 
> This I-D is trying to give a full detail of procedures of applying
> stateful-PCE to "make-before-break (M-B-B)" signaling in RSVP-TE.
> 
> Two types of methods are described.  They can be chosen depending on
> SP's intended operation.
>   (A) One-stroke mode:  basic and simple method, full-automatic
> procedure
>   (B) Granular mode:  advanced method, step-by-step sequencing
> procedure
> 
> At this moment, stateful-PCE's base spec document (WG I-D) doesn't
> have a clear description about how to conduct M-B-B from stateful-PCE.
> That's why we  provided (A) "One-stroke mode", which would be a sort of
> complementary proposal to PCE WG.
> 
> (B) "Granular mode" is positioned as another method to help
> operators/controllers do more flexible control in traffic switching
> timing, which is effective in several new use cases.
> 
> M-B-B is a quite fundamental operation in today's MPLS network
> deployment, so we'd like to gaugue WG's interest in it under stateful-
> PCE's context.
> 
> We'd appreciate your comments and feedback.
> Best regards,
> 
> Yuji Kamite
> NTT Communications
> 
> 
> -----Original Message-----
> From: [email protected] [mailto:i-d-announce-
> [email protected]] On Behalf Of [email protected]
> Sent: Monday, February 18, 2013 9:41 PM
> To: [email protected]
> Subject: I-D Action: draft-tanaka-pce-stateful-pce-mbb-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
>       Title           : Make-Before-Break MPLS-TE LSP restoration and
> reoptimization procedure using Stateful PCE
>       Author(s)       : Yosuke Tanaka
>                           Yuji Kamite
>       Filename        : draft-tanaka-pce-stateful-pce-mbb-00.txt
>       Pages           : 15
>       Date            : 2013-02-18
> 
> Abstract:
>    Stateful PCE (Path Computation Element) and its corresponding
>    protocol extensions provide a mechanism that enables PCE to do
>    stateful control of MPLS Traffic Engineering Label Switched Paths
> (TE
>    LSP).  Stateful PCE supports manipulating the existing LSP's state
>    and attributes (e.g., bandwidth and route) and also creating totally
>    new LSPs in the network.
> 
>    In the current MPLS TE network using RSVP-TE, LSPs are often
>    controlled by "make-before-break (M-B-B)" signaling by headend for
>    the purpose of LSP restoration and reoptimization.  In most cases,
> it
>    is an essential operation to reroute LSP traffic without any data
>    disruption.
> 
>    This document specifies the procedure of applying Stateful PCE's
>    control to make-before-break RSVP-TE signaling.  In this document,
>    two types of restoration/reoptimization procedures are defined, one-
>    stroke mode and granular mode.  This document also specifies the
>    usage and handling of stateful PCEP (PCE Communication Protocol)
>    messages, expected behavior of PCC as RSVP-TE headend and several
>    extensions of additional objects.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-tanaka-pce-stateful-pce-mbb
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-tanaka-pce-stateful-pce-mbb-00
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce

Reply via email to