Re: [Pce] I-D Action: draft-tanaka-pce-stateful-pce-mbb-00.txt

["Margaria, Cyril (NSN - DE/Munich)" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of
> ext Yuji Kamite
> Sent: Monday, March 11, 2013 1:24 AM
> To: [e-mail]; [e-mail]
> 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: [e-mail]
> 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: [e-mail] [mailto:i-d-announce-
> [e-mail]] On Behalf Of [e-mail]
> Sent: Monday, February 18, 2013 9:41 PM
> To: [e-mail]
> 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
> [e-mail]
> 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