Re: [Pce] Adoption of draft-lee-pce-wson-rwa-ext as a new PCE WG Document ?

[Ramon Casellas]

There was a good consensus in adopting draft-lee-pce-wson-rwa-ext as a 
PCE WG document but as usual, we would like to confirm on the mailing 
list.

Yes, support (as a co-author)
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Adoption of draft-dhody-pce-pcep-service-aware as a new WG document ?

[Ramon Casellas]

There was a good consensus in adopting 
draft-dhody-pce-pcep-service-aware 
 as 
a PCE WG document but as usual, we would like to confirm on the

Yes, support

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Adoption of draft-dhody-pce-pcep-service-aware as a new WG document ?

[Udayasree]

 

Yes! Support! 

 

Udayasree

 

On Tue, Mar 12, 2013 at 1:43 AM, JP Vasseur (jvasseur) 
wrote:

Dear all, 

 

There was a good consensus in adopting draft-dhody-pce-pcep-service-aware
  as a
PCE WG document but as usual, we would like to confirm on the mailing list.

Please express your opinion Yes/No (comments welcome too).

 

Thanks.

 

JP and 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] Adoption of draft-dhody-pce-pcep-service-aware as a new WG document ?

[Ong, Lyndon]

Support.

Lyndon
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] 答复: Adoption of draft-lee-pce-wson-rwa-ext as a new PCE WG Document ?

[Fatai Zhang]

Yes/Support as a co-author.





Thanks



Fatai






发件人: pce-boun...@ietf.org [pce-boun...@ietf.org] 代表 JP Vasseur (jvasseur) 
[jvass...@cisco.com]
发送时间: 2013年3月12日 4:17
到: pce@ietf.org
主题: [Pce] Adoption of draft-lee-pce-wson-rwa-ext as a new PCE WG Document ?

Dear all,

There was a good consensus in adopting draft-lee-pce-wson-rwa-ext as a PCE WG 
document but as usual, we would like to confirm on the mailing list.
Please express your opinion Yes/No (comments welcome too).

Thanks.

JP and Julien.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] 答复: Adoption of draft-dhody-pce-pcep-service-aware as a new WG document ?

[Fatai Zhang]

Yes/Support.







 Thanks



Fatai






发件人: pce-boun...@ietf.org [pce-boun...@ietf.org] 代表 JP Vasseur (jvasseur) 
[jvass...@cisco.com]
发送时间: 2013年3月12日 4:13
到: pce@ietf.org
主题: [Pce] Adoption of draft-dhody-pce-pcep-service-aware as a new WG document ?

Dear all,

There was a good consensus in adopting 
draft-dhody-pce-pcep-service-aware
 as a PCE WG document but as usual, we would like to confirm on the mailing 
list.
Please express your opinion Yes/No (comments welcome too).

Thanks.

JP and Julien.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Adoption of draft-dhody-pce-pcep-service-aware as a new WG document ?

[Huaimo Chen]

Support!

BR,
Huaimo

From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of JP 
Vasseur (jvasseur)
Sent: Monday, March 11, 2013 4:14 PM
To: pce@ietf.org
Subject: [Pce] Adoption of draft-dhody-pce-pcep-service-aware as a new WG 
document ?

Dear all,

There was a good consensus in adopting 
draft-dhody-pce-pcep-service-aware
 as a PCE WG document but as usual, we would like to confirm on the mailing 
list.
Please express your opinion Yes/No (comments welcome too).

Thanks.

JP and Julien.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Adoption of draft-lee-pce-wson-rwa-ext as a new PCE WG Document ?

[Huaimo Chen]

Support!

BR,
Huaimo

From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of JP 
Vasseur (jvasseur)
Sent: Monday, March 11, 2013 4:18 PM
To: pce@ietf.org
Subject: [Pce] Adoption of draft-lee-pce-wson-rwa-ext as a new PCE WG Document ?

Dear all,

There was a good consensus in adopting draft-lee-pce-wson-rwa-ext as a PCE WG 
document but as usual, we would like to confirm on the mailing list.
Please express your opinion Yes/No (comments welcome too).

Thanks.

JP and Julien.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] 答复: Adoption of draft-dhody-pce-pcep-service-aware as a new WG document ?

[Zhangxian (Xian)]

Yes/Support.



Regards,



Xian


发件人: pce-boun...@ietf.org [pce-boun...@ietf.org] 代表 JP Vasseur (jvasseur) 
[jvass...@cisco.com]
发送时间: 2013年3月12日 4:13
到: pce@ietf.org
主题: [Pce] Adoption of draft-dhody-pce-pcep-service-aware as a new WG document ?

Dear all,

There was a good consensus in adopting 
draft-dhody-pce-pcep-service-aware
 as a PCE WG document but as usual, we would like to confirm on the mailing 
list.
Please express your opinion Yes/No (comments welcome too).

Thanks.

JP and Julien.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Adoption of draft-dhody-pce-pcep-service-aware as a new WGdocument ?

[Kenji Kumaki]

Yes/support (as co-author)

Thanks,
Kenji

<03b78081b371d44390ed6e7badbb4a772332f...@xmb-rcd-x02.cisco.com>
 の、
   "[Pce] Adoption of draft-dhody-pce-pcep-service-aware as a 
new WGdocument ?" において、
   ""JP Vasseur (jvasseur)" "さんは書きまし
た：

> 
> 
> Dear all,
> 
> There was a good consensus in adopting draft-dhody-pce-pcep-service-aware<
http://tools.ietf.org/html/draft-dhody-pce-pcep-service-aware-05.txt> as a PCE
 WG document but as usual, we would like to confirm on the mailing list.
> Please express your opinion Yes/No (comments welcome too).
> 
> Thanks.
> 
> JP and 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

[Pce] 答复: Adoption of draft-lee-pce-wson-rwa-ext as a new PCE WG Document ?

[Lidan (Dan)]

Yes, support!

Dan

发件人: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] 代表 JP Vasseur (jvasseur)
发送时间: 2013年3月12日 4:18
收件人: pce@ietf.org
主题: [Pce] Adoption of draft-lee-pce-wson-rwa-ext as a new PCE WG Document ?

Dear all,

There was a good consensus in adopting draft-lee-pce-wson-rwa-ext as a PCE WG 
document but as usual, we would like to confirm on the mailing list.
Please express your opinion Yes/No (comments welcome too).

Thanks.

JP and Julien.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] 答复: Adoption of draft-dhody-pce-pcep-service-aware as a new WG document ?

[Lidan (Dan)]

Yes, Support!

Dan


发件人: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] 代表 JP Vasseur (jvasseur)
发送时间: 2013年3月12日 4:14
收件人: pce@ietf.org
主题: [Pce] Adoption of draft-dhody-pce-pcep-service-aware as a new WG document ?

Dear all,

There was a good consensus in adopting 
draft-dhody-pce-pcep-service-aware
 as a PCE WG document but as usual, we would like to confirm on the mailing 
list.
Please express your opinion Yes/No (comments welcome too).

Thanks.

JP and Julien.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] 答复: Adoption of draft-dhody-pce-pcep-service-aware as a new WG document ?

[Zhangxian (Xian)]

Yes, support.



Regards,



Xian


发件人: pce-boun...@ietf.org [pce-boun...@ietf.org] 代表 JP Vasseur (jvasseur) 
[jvass...@cisco.com]
发送时间: 2013年3月12日 4:13
到: pce@ietf.org
主题: [Pce] Adoption of draft-dhody-pce-pcep-service-aware as a new WG document ?

Dear all,

There was a good consensus in adopting 
draft-dhody-pce-pcep-service-aware
 as a PCE WG document but as usual, we would like to confirm on the mailing 
list.
Please express your opinion Yes/No (comments welcome too).

Thanks.

JP and Julien.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] 答复: Adoption of draft-lee-pce-wson-rwa-ext as a new PCE WG Document ?

[Zhangxian (Xian)]

Yes/Support.



Regards,



Xian


发件人: pce-boun...@ietf.org [pce-boun...@ietf.org] 代表 JP Vasseur (jvasseur) 
[jvass...@cisco.com]
发送时间: 2013年3月12日 4:17
到: pce@ietf.org
主题: [Pce] Adoption of draft-lee-pce-wson-rwa-ext as a new PCE WG Document ?

Dear all,

There was a good consensus in adopting draft-lee-pce-wson-rwa-ext as a PCE WG 
document but as usual, we would like to confirm on the mailing list.
Please express your opinion Yes/No (comments welcome too).

Thanks.

JP and Julien.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Adoption of draft-dhody-pce-pcep-service-aware as a new WG document ?

[Durga_uunet]

Yes, support!


Brgds, DG.

Sent from my iPhone

On Mar 11, 2013, at 4:13 PM, "JP Vasseur (jvasseur)"  wrote:

> Dear all,
> 
> There was a good consensus in adopting draft-dhody-pce-pcep-service-aware as 
> a PCE WG document but as usual, we would like to confirm on the mailing list.
> Please express your opinion Yes/No (comments welcome too).
> 
> Thanks.
> 
> JP and 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] Adoption of draft-dhody-pce-pcep-service-aware as a new WG document ?

[Margaria, Cyril (NSN - DE/Munich)]

Yes/support


Best regards / Mit freundlichen Grüßen
Cyril Margaria

From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of ext JP 
Vasseur (jvasseur)
Sent: Monday, March 11, 2013 9:14 PM
To: pce@ietf.org
Subject: [Pce] Adoption of draft-dhody-pce-pcep-service-aware as a new WG 
document ?

Dear all,

There was a good consensus in adopting 
draft-dhody-pce-pcep-service-aware
 as a PCE WG document but as usual, we would like to confirm on the mailing 
list.
Please express your opinion Yes/No (comments welcome too).

Thanks.

JP and Julien.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Adoption of draft-dhody-pce-pcep-service-aware as a new WG document ?

[Ogaki, Kenichi]

Yes, support!

All the best,
Kenichi

On 3/12/13 5:13 AM, JP Vasseur (jvasseur) wrote:

Dear all,

There was a good consensus in adopting draft-dhody-pce-pcep-service-aware
 as a PCE 
WG document but as usual, we would like to confirm on the
mailing list.
Please express your opinion Yes/No (comments welcome too).

Thanks.

JP and 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] Adoption of draft-dhody-pce-pcep-service-aware as a new WG document ?

[Dhruv Dhody]

Yes! Support!

Dhruv (as a co-author)


On Tue, Mar 12, 2013 at 1:43 AM, JP Vasseur (jvasseur)
wrote:

>  Dear all,
>
>  There was a good consensus in adopting 
> draft-dhody-pce-pcep-service-aware
>  as
> a PCE WG document but as usual, we would like to confirm on the mailing
> list.
> Please express your opinion Yes/No (comments welcome too).
>
>  Thanks.
>
>  JP and 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] Adoption of draft-dhody-pce-pcep-service-aware as a new WG document ?

[Mcdysan, David E]

Support pce working group adoption of this draft.

IMHO, it solves most of the problems and meets most requirements of

http://www.ietf.org/id/draft-fuxh-mpls-delay-loss-te-problem-statement-01.txt

and builds upon the foundations of the IGP extensions to do so as described in

http://www.ietf.org/id/draft-fuxh-mpls-delay-loss-te-framework-06.txt


Dave

From: "JP Vasseur (jvasseur)" mailto:jvass...@cisco.com>>
Date: Monday, March 11, 2013 3:13 PM
To: Pce mailto:pce@ietf.org>>
Subject: [Pce] Adoption of draft-dhody-pce-pcep-service-aware as a new WG 
document ?

Dear all,

There was a good consensus in adopting 
draft-dhody-pce-pcep-service-aware
 as a PCE WG document but as usual, we would like to confirm on the mailing 
list.
Please express your opinion Yes/No (comments welcome too).

Thanks.

JP and Julien.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Adoption of draft-dhody-pce-pcep-service-aware as a new WG document ?

[Edward Crabbe]

Support.




On Mon, Mar 11, 2013 at 1:13 PM, JP Vasseur (jvasseur)
wrote:

>  Dear all,
>
>  There was a good consensus in adopting 
> draft-dhody-pce-pcep-service-aware
>  as
> a PCE WG document but as usual, we would like to confirm on the mailing
> list.
> Please express your opinion Yes/No (comments welcome too).
>
>  Thanks.
>
>  JP and 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] Adoption of draft-dhody-pce-pcep-service-aware as a new WG document ?

[Vishwas Manral]

Yes, support as co-author.

-Vishwas

On Mon, Mar 11, 2013 at 4:13 PM, JP Vasseur (jvasseur)
wrote:

>  Dear all,
>
>  There was a good consensus in adopting 
> draft-dhody-pce-pcep-service-aware
>  as
> a PCE WG document but as usual, we would like to confirm on the mailing
> list.
> Please express your opinion Yes/No (comments welcome too).
>
>  Thanks.
>
>  JP and 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] Adoption of draft-lee-pce-wson-rwa-ext as a new PCE WG Document ?

[Leeyoung]

Yes, support.

Young (co-author)

From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of JP 
Vasseur (jvasseur)
Sent: Monday, March 11, 2013 3:18 PM
To: pce@ietf.org
Subject: [Pce] Adoption of draft-lee-pce-wson-rwa-ext as a new PCE WG Document ?

Dear all,

There was a good consensus in adopting draft-lee-pce-wson-rwa-ext as a PCE WG 
document but as usual, we would like to confirm on the mailing list.
Please express your opinion Yes/No (comments welcome too).

Thanks.

JP and Julien.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Adoption of draft-dhody-pce-pcep-service-aware as a new WG document ?

[Leeyoung]

Yes, support.

Young

From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of JP 
Vasseur (jvasseur)
Sent: Monday, March 11, 2013 3:14 PM
To: pce@ietf.org
Subject: [Pce] Adoption of draft-dhody-pce-pcep-service-aware as a new WG 
document ?

Dear all,

There was a good consensus in adopting 
draft-dhody-pce-pcep-service-aware
 as a PCE WG document but as usual, we would like to confirm on the mailing 
list.
Please express your opinion Yes/No (comments welcome too).

Thanks.

JP and Julien.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Adoption of draft-lee-pce-wson-rwa-ext as a new PCE WG Document ?

[JP Vasseur (jvasseur)]

Dear all,

There was a good consensus in adopting draft-lee-pce-wson-rwa-ext as a PCE WG 
document but as usual, we would like to confirm on the mailing list.
Please express your opinion Yes/No (comments welcome too).

Thanks.

JP and Julien.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Adoption of draft-dhody-pce-pcep-service-aware as a new WG document ?

[JP Vasseur (jvasseur)]

Dear all,

There was a good consensus in adopting 
draft-dhody-pce-pcep-service-aware
 as a PCE WG document but as usual, we would like to confirm on the mailing 
list.
Please express your opinion Yes/No (comments welcome too).

Thanks.

JP and Julien.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Comments on draft-ali-pce-remote-initiated-gmpls-lsp-00

[Zafar Ali (zali)]

Hi Margaria: 

Sorry for delayed response. Please see in-line.

Thanks

Regards Š Zafar


-Original Message-
From: , "cyril.marga...@nsn.com" 
Date: Thursday, February 21, 2013 7:44 AM
To: "draft-ali-pce-remote-initiated-gmpls-...@tools.ietf.org"
, "pce@ietf.org"

Subject: Comments on draft-ali-pce-remote-initiated-gmpls-lsp-00
Resent-From: 
Resent-To: , , Oscar de Dios
, VICTOR ALVAREZ , zali 
Resent-Date: Thursday, February 21, 2013 7:44 AM

>Hi,
>
>I have the following comments on the draft.
>1.  Abstract : you are not  only addressing GMPLS, but also
>multi-layer

Yes.

>2.  Section 1 "Introduction" : This is good you reference RFC6107,
>which defined this object for "MPLS and GMPLS", the multilayer extensions
>are not GMPLS specific, I think this should be either separated or put in
>an "active stateful PCE" solution (Which could be a merge of your
>document and draft-crabbe-pce-pce-initiated-lsp)

We would be open to document rearrangement(s), if it simplify the process.
But from applicability view point, you are right this aspect is equally
applicable to both MPLS and GMPLS initiated LSPs (as noted in the draft).

>3.  Section 2 : There is already 2 applicability documents, I think
>those use case should be integrated there, especially as I find them good.

Again we are open to document rearrangement in favor of simplification of
the process. 

>4.  Section 3 : this lists match the requierement of the
>draft-ietf-pce-gmpls-aps-req, you could simply refer to it and the
>solution document.

We can put in a reference.

>5.  Section 4 : this is RFC6107 related, this is non-GMPLS specific

Correct. This is equally applicable to MPLS and GMPLS LSPs.

>6.  Section 5.1 : I should say I disagree : it is not required to
>have generalized endpoints, RFC5440 ENDPOINTS are sufficient, especially
>if you want to create an FA. Moreoever draft-crabbe-pce-pce-initiated-lsp
>already support this object and thus the GENERALIZED-ENDPOINTS OT.

Unnum end-point TLV may be a gap but it will be great to have an offline
chat on this at IETF or via email.

>7.  Section 5.1 : I think there is a misunderstanding : the
>label-request in the endpoint is NOT the one of the LSP to be signaled.
>This is addressed by the SWITCH_LAYER
>8.  Section 5.2 : I think this is the only needed optional object.

Not sure if I followed you.

>9.  Section 5.3 : If no modification is needed, I think it would be
>better to state it in a section describing the missing information from
>draft-crabbe-pce-pce-initiated-lsp or any other solution)
Sure-
>10. Section 5.4 : As the PCEP ERO is an RSVP ERO , this section seems
>more applicability/framework related.
The point is that this needs to be covered.
>11. Section 6 : this is RFC6107 related, this is non-GMPLS specific

Correct. This is equally applicable to MPLS and GMPLS.

>
>I think the document has good material, but address several separated
>points :
>1.  Active Stateful PCE Applicability
>2.  MPLS multi-layer aspects
>3.  GMPLS (GENERALIZED-BW and SWITCH-LAYER)
>
>I think the second point may have a document on its own, but the first
>and third point  could be managed by merges.

Like mentioned above, we are open to document rearrangement(s), if it
simplify the process. At the moment this work is outside the scope of WG
charter. I am sure in due time we will have more of such discussion and
opinion from the WG. There are example where WG liked to keep GMPLS
extensions separate from (packet) MPLS work.

>
>
>Mit freundlichen Grüßen / Best Regards
>Cyril Margaria
>
>Nokia Siemens Networks Optical GmbH
>St.Martin-Str. 76
>D-81541 München
>Germany
>mailto:cyril.marga...@nsn.com
>Phone: +49-89-5159-16934
>Fax:   +49-89-5159-44-16934
>
>Nokia Siemens Networks Optical GmbH
>Geschäftsleitung / Board of Directors: Gero Neumeier, Dr. Rolf Nauerz
>Sitz der Gesellschaft: München / Registered office: Munich
>Registergericht: München / Commercial registry: Munich, HRB 197143
>
>
>

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Comments on draft-crabbe-pce-stateful-pce-protection-00

[Dhruv Dhody]

Hi,

Please find some review comments for this draft...

*(1) Introduction*
a. There are various cases here, say Passive stateful PCE where the primary
and backup path request will be encoded in a separate path request. The
handling of LSP-ID here can be described.
b. For active stateful PCE (delegated LSP) the operator may still configure
the desired protection at PCC and stateful PCE should respect it.

*(2) Path Protection Overview*
a. Multiple paths in single report and update needs to be clarified.
b. Suggest a sequence diagram here could help in understanding the events
better and the text needs more description too.
c. Handling of the LSP-ID in case of PCC or local initiation and delegation
v/s PCE-initiated can be described.

Regards,
Dhruv
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Comments on draft-tanaka-pce-stateful-pce-mbb-0

[Dhruv Dhody]

Hi,

Handling of make-before-break was indeed missing from the stateful PCE
specs and thanks for this ID, here are a few comments...

*(1)  One Stroke MBB*
a. I wish the handling of this method can be clearly specified in the base
stateful PCE draft itself.
b. How to handle the case if the signaling of the new path fails? Maybe a
PCRpt message with (O=0, Tunnel ID=T1, LSP ID=new, RRO=null)? This should
be clearly specified.
c. I am assuming that the LSP ID in the LSP object doesnt change, only the
LSP ID encoded in LSP Identifier TLV is changed? This can be clarified. I
also prefer the option of sending LSP-ID as zero and PCC generating a new
LSP-ID.
d. Another case of MBB is when some configuration is changed at the PCC,
how is this handled in case of delegated LSP.

There maybe other stateful PCE present too, you can also describe how they
handle the report message from PCC (success and failure)

*(2) Granular MBB*
An example where this is method should be used can be specified as Cyril
mentioned.

Regards,
Dhruv
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Comments on draft-crabbe-pce-stateful-pce-mpls-te-00

[Dhruv Dhody]

Hi,

Please find some review comments for this draft...

*(1) PCRpt Message*
a. There is a different in RBNF between this
and draft-ietf-pce-stateful-pce-02
b. ::=[]. The status of the paths needs to
reported separately in case of standby but we have only one LSP object here
to specify the operational status. Also LSP-ID of primary and backup would
be different.
c. Incase of the delegate, all constraints configured at PCC needs to be
sent to PCE. The PCRpt message should support this.
d. ERO is a mandatory object and incase of the LSP's first delegate message
there will be no existing path and thus no path to encode in the ERO.
Either we send empty ERO i.e ERO but with no sub-objects or make ERO
optional.
e. In case of the first delegate message how to send the destination
information? ENDPOINT object is needed.
f. Support for IRO, XRO should be supported in case of PCRpt message.

Most of the above comments are also applicable for PCUpd message.

*(2) LSP Identifier TLVs*
a. The relationship between LSP-ID in LSP Object and LSP Identifier TLV
should be described.
b. Maybe Tunnel Destination Address can be encoded too similar to
LSP_TUNNEL_IPvX sender template
c. The use of tunnel-id to describe when the traffic switches from primary
and secondary is not very clear to me, maybe you can describe this here or
in protection document in more details.

*(3) Tunnel ID TLV*
What is the need of this TLV? The description is the same as the tunnel-id
already present in the LSP Identifier TLV.

Regards,
Dhruv
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Comments on draft-ietf-pce-stateful-pce-02

[Dhruv Dhody]

Hi,

Please find the review comments for this draft (there is some overlap with
comments from Jon, Cyril etc)

*Major Comments:*
(1) State synchronisation:
a. PCE should determine the synchronisation is over as soon as possible, as
updates, request etc are blocked during synchronisation. Maybe the last
report message can have SYNC=0 (similar to F - fragmentation bit in RP
object) or as Jon suggested an empty report but then the RBNF of PCRpt
should support it.

b. I also dont like the use of word 'purge' with respect to old or stale
entries during PCEP session up/down. A mechanism to mark LSP entries as
stale and waiting for them to be refreshed after session up and deleted (or
'purged') only after some timer expiry.


(2) The PCRpt Message:
 ::= [] Where: ::=[].
Is this to specify primary and backup? In which case the status of the
paths needs to reported separately in case of standby but we have only one
LSP object here to specify the operational status. Also LSP-ID of primary
and backup would be different.

Also applicable to PCUpd message.
I feel the backup path should be updated and reported separately with each
having there own encoding for LSP object.

(3) Node Identifier TLV
PCC may use address that survives the session restart (Loopback, MPLS
LSR-ID etc), i suggest we mention this in the document and provide guidance
to implementers to do this if possible.

(4) LSP Object:
a. What is relationship between the LSP-ID in LSP object and the LSP-ID in
LSP Identifier TLVs?
b. There is no mechanism to report the 'pending' state right now? O-Bit as
zero will mean down, not pending.

(5) Make-Before-Break:
There is a need to clarify how MBB is achieved, what is the LSP-ID in case
of updates and reports?


*Minor Comments: *
(1) Abstract/Introduction
There is a consistent use of phrase "between and across PCEP sessions". Can
you clarify?

(2) Re-look the terminology section as some terms are no longer in the
document.

(3) LSP Protection
In case of delegated PCE, the desired protection may also be configured at
PCC and the active stateful PCE should support it, the stateful PCE having
full control over the protection / restoration settings can only be
achieved with instantiation capability and should be out of scope from this
document.

(4) Delegation
a. The wording "an LSP may be delegated to one or more PCEs." .. this is
incorrect, from the reading it looks as if this is happening at the same
time.

b. Active stateful PCE LSP Update (sec 5.6.2)
OLD:
A PCC may choose to compress LSP State Updates to only reflect the most up to
date state, as discussed in the previous section.
NEW:
A PCC may choose to compress LSP State Reports to only reflect the most up to
date state, as discussed in the previous section.

(5) Symbolic Path Name TLV
The length of this TLV must be greater then 0 as well as multiple of four.

(6) LSP state DB version TLV (page 40, para 2)
"Since a PCE does not send LSP updates to a PCC, a PCC should never
encounter this TLV". LSP updates here can be easily confused with the PCUpd
messages. Kindly reword this.


Regards,
Dhruv
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[Margaria, Cyril (NSN - DE/Munich)]

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: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of
> ext Yuji Kamite
> Sent: Monday, March 11, 2013 1:24 AM
> To: pce@ietf.org; draft-ietf-pce-stateful-...@tools.ietf.org
> 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: pce@ietf.org
> 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: i-d-announce-boun...@ietf.org [mailto:i-d-announce-
> boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
> Sent: Monday, February 18, 2013 9:41 PM
> To: i-d-annou...@ietf.org
> 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