Re: [Pce] IPR Poll on draft-zhao-pce-pcep-extension-pce-controller-sr-09

[Quintin Zhao]

Hi Hari,



I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

Thanks,

Quintin

On Mon, Nov 30, 2020 at 12:17 AM Lizhenbin  wrote:

> Hi Hari,
>
>
>
> I am not aware of any IPR applicable to this draft that should be
> disclosed in accordance with IETF IPR rules.
>
>
>
>
>
> Best regards,
>
> Zhenbin (Robin)
>
>
>
>
>
>
>
> *From:* Hariharan Ananthakrishnan [mailto:h...@netflix.com
> ]
> *Sent:* Friday, November 27, 2020 6:58 AM
> *To:* Lizhenbin ; Pengshuping (Peng Shuping) <
> pengshup...@huawei.com>; Mahend Negi ;
> qz...@ethericnetworks.com; chaozhou...@yahoo.com
> *Cc:* pce@ietf.org
> *Subject:* IPR Poll on draft-zhao-pce-pcep-extension-pce-controller-sr-09
>
>
>
> Hi Authors,
>
>
>
> In preparation for WG adoption 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 the 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 Poll on draft-ietf-pce-pcep-extension-for-pce-controller

[Quintin Zhao]

I am not aware of any IPR applicable to this draft.

Thanks,
Quintin


On Thu, Aug 6, 2020 at 9:02 PM Hariharan Ananthakrishnan 
wrote:

> Hi Authors,
>
> In preparation for WG LC 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 the 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] Subject: WG adoption poll for draft-zhao-pce-pcep-extension-for-pce-controller-08

[Quintin zhao]

Yes/Support!

Thanks,

Quintin


From: Weiqiang Cheng
To: pcemailto:pce@ietf.org>>
Cc: 
draft-zhao-pce-pcep-extension-for-pce-controllermailto:draft-zhao-pce-pcep-extension-for-pce-control...@ietf.org>>;pce-chairsmailto:pce-cha...@ietf.org>>
Subject: Re: Subject: [Pce] WG adoption poll for 
draft-zhao-pce-pcep-extension-for-pce-controller-08
Time: 2018-10-22 01:43:58


Yes/Support!
The application scenario is valuable.

B.R.
Weiqiang Cheng

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: Saturday, October 13, 2018 10:47 PM
To: pce@ietf.org
Cc: 
draft-zhao-pce-pcep-extension-for-pce-control...@ietf.org;
 pce-cha...@ietf.org
Subject: [Pce] WG adoption poll for 
draft-zhao-pce-pcep-extension-for-pce-controller-08

This is the start of a two week poll on making 
draft-zhao-pce-pcep-extension-for-pce-controller-08 a PCE working group 
document.
https://datatracker.ietf.org/doc/draft-zhao-pce-pcep-extension-for-pce-controller/

Please review the draft and send an email to the list indicating “yes/support” 
or “no/do not support”.  If indicating no, please state your reasons.  If yes, 
please also feel free to provide comments you'd like to see addressed once the 
document is a WG document.

The poll ends on Friday, October 26.

Many thanks,

Jon and Julien

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

Re: [Pce] IPR Check on draft-ietf-pce-hierarchy-extensions

[Quintin zhao]

Hi All,

No, I am not aware of any IPR that applies to this draft.

Thanks,
Quintin


From: Daniel King [mailto:d...@danielking.net] On Behalf Of dan...@olddog.co.uk
Sent: Monday, September 10, 2018 1:49 AM
To: 'Julien Meuric'; pce@ietf.org
Cc: draft-ietf-pce-hierarchy-extensi...@ietf.org
Subject: RE: [Pce] IPR Check on draft-ietf-pce-hierarchy-extensions

Dear PCE’rs,

No, I am not aware of any IPR that applies to this draft.

BR, Dan.

From: Ramon Casellas 
Sent: 06 September 2018 17:24
To: Julien Meuric 
Cc: draft-ietf-pce-hierarchy-extensi...@ietf.org; pce@ietf.org
Subject: Re: [Pce] IPR Check on draft-ietf-pce-hierarchy-extensions

Hi all,

No, I am not aware of any IPR that applies to this draft.

Thank you
Ramon


On Sep 6, 2018 6:00 PM, Julien Meuric 
mailto:julien.meu...@orange.com>> wrote:

Dear authors of draft-ietf-pce-hierarchy-extensions,

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-hierarchy-extensions 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

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

Re: [Pce] IPR on draft-ietf-pce-rfc6006bis

[Quintin zhao]

Hello Chairs, 

Yes, I am also aware of IPR which has been disclosed and updated in the IPR 
system.

Thanks,
Quintin
  


-Original Message-
From: Daniel King [mailto:d...@danielking.net] On Behalf Of dan...@olddog.co.uk
Sent: Monday, May 01, 2017 6:06 AM
To: Dhruv Dhody; 'Jonathan Hardwick'; draft-ietf-pce-rfc6006...@ietf.org
Cc: pce@ietf.org
Subject: RE: IPR on draft-ietf-pce-rfc6006bis

Hi Chairs, 

Yes, I am also aware of IPR. This has been specifically disclosed and
highlighted previously. 

Thanks, Dan.  

-Original Message-
From: Dhruv Dhody [mailto:dhruv.dh...@huawei.com] 
Sent: 24 April 2017 23:38
To: Jonathan Hardwick ;
draft-ietf-pce-rfc6006...@ietf.org
Cc: pce@ietf.org
Subject: RE: IPR on draft-ietf-pce-rfc6006bis

Hi,

Yes, I am aware of IPR and has been disclosed and updated in the IPR system=

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

Re: [Pce] Shepherd's review of draft-ietf-pce-inter-area-as-applicability-06

[Quintin zhao]

Hi Jon, 

Great, a good review! This is really helpful. Will finalize the document based 
on your comments, and most recent updates from Dhruv. Our plan is to submit the 
new version very quickly. We will find someone to perform a final English 
review as you suggest. 

Thanks!
Quintin, and authors.


--

Message: 2
Date: Tue, 7 Mar 2017 17:27:43 +
From: Jonathan Hardwick 
To: "draft-ietf-pce-inter-area-as-applicabil...@ietf.org"

Cc: "pce@ietf.org" 
Subject: [Pce] Shepherd's review of
draft-ietf-pce-inter-area-as-applicability-06
Message-ID:



Content-Type: text/plain; charset="us-ascii"

Hello

I am shepherding this draft, which has passed working group last call and is in 
the queue for sending to the IESG.  I have reviewed it to determine whether it 
really is ready to be submitted to the IESG.  This draft is an important piece 
of work for the PCE working group and I would like to thank the authors for all 
their work on it so far, but unfortunately I don't think it is ready for 
publication yet.  Probably the biggest impediment to getting drafts through the 
IESG is when the drafts lack clarity, and I feel that more clarity needs to be 
brought to this draft before we take it forward.

My comments are below.

Best regards
Jon


General Comments
This document does an important job in explaining how PCEs can best be used to 
solve problems in inter-domain path computation.  It is thorough and covers all 
the appropriate areas.

The document seems repetitive and a bit bloated by text that is not really 
relevant to the main purpose of the doc.  Some parts of the text feel redundant 
(I have pointed them out explicitly below).  Other parts of the text repeat 
statements that have already been made, or else just repeat information from 
other documents.  I have pointed out as many examples of this as I can below 
but I would like the authors to review their text themselves and try to remove 
the redundant bits of text.

Some sections of this document waffle without making a clear point about 
inter-domain path computation.  I've made specific comments below about 
passages that I feel lack a clear point.  But please could the authors review 
their own text?  The document needs to succinctly describe problems in 
inter-domain path computation and point out the ways a PCE can help solve them. 
 If there are any parts of this document that do not fulfil that brief, please 
consider removing them.

Some sections of the document need to be reviewed by an English speaker for 
grammar and clarity.  I made quite a few comments below to clarify sentences 
and improve the grammar, but I ran out of steam at around section 6.  Please 
could one of the English speaking authors finish off the job?

 
Section 1
s/remotely initiated PCE, deployment scenarios/remotely initiated PCE 
deployment scenarios/
s/it maybe necessary/it may be necessary/
" Once a path computation request is received, the PCC will send a request to 
the PCE. "  Sentence feels redundant.
s/The PCE discovery mechanism [...] allow/The PCE discovery mechanism [...] 
allows/
s/An Objective Function [...] specify the/An Objective Function [...] specifies 
the/
Section 1.6, I don't think you need to list all the OFs in RFC 5541, there's 
nothing special about them.

Section 3
s/administered by separate Service Providers, it would break/administered by 
separate Service Providers.  It would break/
s/ different Service Providers. Then cooperating PCEs/ different Service 
Providers, then cooperating PCEs/
s/ it can supply this information/ it can supply the destination domain/
s/egress domain/destination domain/

Section 4
Please define " simply-connected " or expand the term.  I think you mean 
"connected in a simple path with no branches and single links between all 
domains".
Section 4.2 text duplicates the text in section 3.1 1st paragraph. Please 
delete one of them.
s/ are composed by/ are composed of/
s/ are usually interconnected between them/ are usually interconnected/

OLD
A typical node degree ranges from 3 to 10 (4-5 is quite common), being the node 
degree the number of neighbors per node.
NEW
The node degree (the number of neighbors per node) typically ranges from 3 to 
10 (4-5 is quite common).

Second paragraph of 4.3 "Networks are sometimes..." is redundant.  It has all 
been said already.
s/ Whenever an specific/ Whenever a specific/

Section 4.4 Again it feels like all of this has been said in section 3.1 
already, except the bit about SRLGs.  I suggest combining these bits of text.  
Perhaps section 3.1 should be removed.

Section 4.5 "A non-comprehensive list" Is it important to give this list?  It 
seems to add nothing to the existing reference to RFC5540/6007 - suggest 
removing it.

s/ reach the destination domain, a domain sequence/ reach the destination 
domain.  A domain sequence/
s/ is defined in [RFC3209], [RFC7897] specifies new/ is defined in [RFC3209].  
[RFC78

Re: [Pce] Home for "PCE as Central Controller"

[Quintin zhao]

Dear Jon, JP, Julien, and Lou,

Thanks for your suggestions regarding the home for "PCE as Central Controller" 
and we agree with you to discuss the PCE-CC related 
requirements/use-cases/architecture in the TEAS working group and to discuss 
the PCE-CC related PCE extensions in the PCE working group.

We will collaborate with the co-authors of ACTN related drafts to identify the 
overlapping and gaps between ACTN and PCE-CC. We will present these to the TEAS 
working group and have discussions on it during the incoming IETF94 meeting. 

Thanks again and see you in Yokohama!

Quintin

-Original Message-
From: julien.meu...@orange.com [mailto:julien.meu...@orange.com] 
Sent: 2015年10月9日 8:04
To: draft-zhao-pce-pcep-extension-for-pce-control...@ietf.org; 
draft-zhao-pce-central-controller-user-ca...@ietf.org
Cc: pce@ietf.org; t...@ietf.org
Subject: Home for "PCE as Central Controller"

Dear authors of PCE-CC I-Ds,

We are following up on Lou's (very last minute ;-) ) comment during the PCE 
meeting in Prague. The TEAS WG has just endorsed as WG item the "ACTN" work, 
(quoting the requirement I-D) "so as to facilitate network programmability, 
automation, efficient resource sharing, and end-to-end virtual service aware 
connectivity and network function virtualization services". A significant part 
of the PCE-CC proposal may fall under this umbrella. As a result, we would like 
to see the related requirements/use-cases/architecture discussed first within 
TEAS, the PCE WG remaining (obviously) in charge of any identified PCEP 
extensions.

Feel free to contacts the PCE and/or TEAS chairs if some clarifications on the 
respective charters of the WGs are needed.

Thanks,

Jon, JP & Julien


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites 
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez 
le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les 
messages electroniques etant susceptibles d'alteration, Orange decline toute 
responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law; they should not be distributed, used 
or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [Pce] Mail regarding draft-zhao-pce-pcep-extension-for-pce-controller

[Quintin zhao]

Anil,

Thanks for your detailed comments.  The inter-domain/inter-area scenario you 
discussed here is a good use case. Similarly, there are other existing MPLS 
features supported today in service provider networks where the requirements 
for LSP tunnels are complex. To satisfy more of these existing requirements and 
also to satisfy more of the new requirements resulting from new application 
oriented services,  more extensions for IGP to distribute SIDs/Segment labels 
may need to be added down the road.  Eventually either some of the existing 
MPLS features cannot be supported anymore or the future IGP protocol may look 
like a combination of current IGP and parts of LDP/RSVP-TE protocols.



Instead of extending the IGP to distribute SID/segment labels, using PCE as the 
central controller to distribute the SIDs/labels to setup LSP tunnels is an 
alternative where it has some advantages. One of these advantages  is that the 
SR-TE LSP can be supported to reduce the LSP states in the network and at the 
same time, all the other existing MPLS features including the MPLS multicast 
and new application oriented features can be supported by just extending the 
existing PCEP.



The texts you suggested here look good and we will incorporate the use case 
into the next version of the protocol extension draft and also the use case 
draft.
We would like to hear more suggestions/comments for our drafts both from SPRNG 
working group and from PCE working group.
Quintin

From: Anil Kumar S N (VRP Network BL)
Sent: Wednesday, April 01, 2015 11:54 AM
To: pce@ietf.org; Quintin zhao; Katherine Zhao; dhruv.i...@gmail.com; Udayasree 
palle; boris.zh...@telus.com; spr...@ietf.org
Cc: VinodS Kumar; Veerendranatha Reddy Vallem
Subject: Mail regarding draft-zhao-pce-pcep-extension-for-pce-controller

Hi Authors,

  Since PCE Controller has global view of the network.  There are 
services which spread across multiple AS or IGP domain.  SR domain can be 
extended across IGP domain to achieve the service requirement as SR domain can 
also span across IGP Domain. But by using IGP to distribute Segment labels has 
one drawback, Where all the external prefixes imported by an ASBR will be 
originated as prefix SID(usually generated by ASBR) in area or AS scope RI LSA 
TLV (OSPF terminology).  But will not be able to originate adjacent segment 
SIDs of other IGP domain due to this intermediate nodes on the path has to 
understand LSP information and push required SR labels which is not desired in 
segment routing (path has to be decided at the ingress).

In case of SR-TE, PCE can give end to end(across AREA or across AS) SR-TE path 
with all the TE requirement satisfied, PCE as a controller should ensure 
SR-Node labels remain unique across AS till the scope of SR domain.

I would like to add a section under "5.5.2.  PCECC Segment Routing (SR)" as 
below  :


5.5.2.3.  PCECC SR-TE IGP/SR Domain



   PCECC will ensure in allocating unique SR Node Lables across SR

   Domain. There will be cases where some service spread across multiple

   IGP domain yet with in SR Domain. One Such example is Seamless MPLS

   which provides an architecture to support a wide variety of different

   services on a single MPLS platform fully integrating access,

   aggregation and core network. In such cases PCE can help SR ingress

   router to have label stack consist of SR node label and SR Adj Labels

   from different IGP domain.



   The PCECC will send PCLabelUpd to update the SR label information which

   might belong to different IGP doamin yet belong to same SR domain to

   required nodes which fall on the path to reach till the destination.



   PCECC will ensure all TE requirements are addressed while setting up

   the explicit path and required SR label stack is updated to ingress

   node.



   The forwarding behavior will not be different as labels processed

   by  intermediate nodes. ASBR will seamlessly forward the packet

   as the FEC is updated by PCE using PCLabelUpd message.



   The Path Setup Type MUST be set for PCECC SR-TE (see Section 7.3).

   The rest of the PCEP procedures and mechanism are similar to

   [I-D.ietf-pce-segment-routing].



   PCE rely on the Adj label cleanup using the same PCLabelUpd message.


p.s.  Segment Routing Architecture [draft-ietf-spring-segment-routing-01] says  
"IGP-prefix Segment, Prefix-SID: an IGP-Prefix Segment is an IGP segment 
attached to an IGP prefix.

An IGP-Prefix Segment is always global within the SR/IGP domain"

Thanks & Regards
Anil S N

"Be liberal in what you accept, and conservative in what you send" - Jon Postel


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

[Pce] 答复: Last IPR Check on draft-ietf-pce-pcep-mib

[Quintin zhao]

Hello JP and Julien,

I am not aware any IPR related to this draft.

Regards,
Quintin


-Original Message-
From: Julien Meuric [mailto:julien.meu...@orange.com]
Sent: 22 July 2014 11:27
To: draft-ietf-pce-pcep-...@tools.ietf.org
Cc: pce@ietf.org
Subject: Last IPR Check on draft-ietf-pce-pcep-mib

Dear authors of the aforementioned document,

Has all IPR that applies to draft-ietf-pce-pcep-mib been disclosed in 
compliance with IETF IPR rules? (see RFCs 3979, 4879, 3669 and 5378 for more 
details)

A response from each of you is expected.

Regards,

JP & Julien

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

[Pce] 答复: New Version Notification for draft-zhao-pce-central-controller-user-cases-01.txt

[Quintin zhao]

Dear All,

We have submitted a new version draft of The Use Cases for Using PCE as the 
Central Controller(PCECC) of LSPs 
(http://www.ietf.org/internet-drafts/draft-zhao-pce-central-controller-user-cases-01.txt
 ). 

In this new version, the p2p LSP related sections are re-organized and more 
examples are provided. Also sections related to multicast LSP and protections 
are added.

Your comments are welcome.

Thanks,

Quintin (on behalf of the co-authors)


-邮件原件-
发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
发送时间: 2014年7月4日 15:29
收件人: Katherine Zhao; Zekung Ke; Katherine Zhao; Quintin zhao; Zekung Ke; 
Quintin zhao
主题: New Version Notification for 
draft-zhao-pce-central-controller-user-cases-01.txt


A new version of I-D, draft-zhao-pce-central-controller-user-cases-01.txt
has been successfully submitted by Quintin Zhao and posted to the IETF 
repository.

Name:   draft-zhao-pce-central-controller-user-cases
Revision:   01
Title:  The Use Cases for Using PCE as the Central Controller(PCECC) of 
LSPs
Document date:  2014-07-04
Group:  Individual Submission
Pages:  24
URL:
http://www.ietf.org/internet-drafts/draft-zhao-pce-central-controller-user-cases-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-zhao-pce-central-controller-user-cases/
Htmlized:   
http://tools.ietf.org/html/draft-zhao-pce-central-controller-user-cases-01
Diff:   
http://www.ietf.org/rfcdiff?url2=draft-zhao-pce-central-controller-user-cases-01

Abstract:
   In certain networks deployment scenarios, service providers would
   like to keep all the existing MPLS functionalities in both MPLS and
   GMPLS network while removing the complexity of existing signaling
   protocols such as LDP and RSVP-TE.  In this document, we propose to
   use the PCE as a central controller so that LSP can be calculated/
   signaled/initiated/downloaded/managed through a centralized PCE
   server to each network devices along the LSP path while leveraging
   the existing PCE technologies as much as possible.

   This draft describes the use cases for using the PCE as the central
   controller where LSPs are calculated/setup/initiated/downloaded/
   maintained through extending the current PCE architectures and
   extending the PCEP.


  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

Re: [Pce] Possible Errata regarding RFC6006

[Quintin zhao]

Udayasree,

The fragmentation is only for the request message only,  see section 3.3.1 of 
RFC 6006:

“The F-bit is added to the flag bits of the RP object to indicate to
   the receiver that the request is part of a fragmented request, or is
   not a fragmented request.”


There is no fragmentation function supported in reply message, so there is no 
need to have a error code for the reply message.

Regards,
Quintin

From: Udayasree palle [mailto:udayasree.pa...@huawei.com]
Sent: 2013?12?13? 7:40
To: draft-ietf-pce-pcep-p2mp-extensi...@tools.ietf.org
Cc: julien.meu...@orange.com; j...@cisco.com; adr...@olddog.co.uk; pce@ietf.org
Subject: Possible Errata regarding RFC6006

Hi All,
   Please check and let me know your suggestion

Regards,
Udayasree


From: Udayasree palle
Sent: 10 December 2013 15:38
To: 'draft-ietf-pce-pcep-p2mp-extensi...@tools.ietf.org'
Cc: julien.meu...@orange.com; 
j...@cisco.com; 
adr...@olddog.co.uk; 
pce@ietf.org
Subject: Posasible Errata regarding draft-ietf-pce-pcep-p2mp-extensions

Hi All,


3.15.  P2MP PCEP-ERROR Objects and Types

Error-Type=18; Error-Value=1: if a PCE has not received the last
   piece of the fragmented message, it should send an error message to
   the sender to signal that it has received an incomplete message
   (i.e., "Fragmented request failure").  The PCE MUST send a PCErr
   message with a PCEP-ERROR object (Error-Type=18) and an Error-Value
   (Error-Value=1).

The fragmentation is done for both request and reply messages, but it looks 
like the error value is defined only for request.

Suggested Text:
   Make it generic

-Remove the word ‘request’

-Replace PCE with PCEP speaker

-Update IANA


Error-Type=18; Error-Value=1: if a PCEP speaker has not received the last
   piece of the fragmented message, it should send an error message to
   the sender to signal that it has received an incomplete message
   (i.e., "Fragmented failure").  The PCEP speaker MUST send a PCErr
   message with a PCEP-ERROR object (Error-Type=18) and an Error-Value
   (Error-Value=1).

Or

Add a new Error-Value!

How to handle this?

Regards,
Udayasree

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

Re: [Pce] Stateful PCE applicability

[Quintin Zhao]

Hi,

I believe that there is a need to document the applicability of Stateful PCE
.  The latest version of draft-zhang-pce-stateful-pce-app satisfies this
need.

Regards,

Quintin

From: pce-bounces at ietf.org [mailto:pce-bounces at ietf.org] On Behalf Of
JP Vasseur (jvasseur)
Sent: Saturday, June 22, 2013 3:20 AM
To: Ina Minei; pce at ietf.org
Subject: Re: [Pce] Stateful PCE applicability

 

Thanks Ina - good question : WG, please voice your opinion 

 

Thanks JP.

 

On Jun 21, 2013, at 9:16 AM, Ina Minei wrote:






Dear chairs and working group,

 

In light of the recent working group re-charter which now includes stateful
PCE, we wanted to hear the opinions of the group on

 

1.   the need for an applicability document for stateful PCE and

 

2.   whether draft-zhang-pce-stateful-pce-app satisfies this need, or
any gaps it might have

 

Thank you,

 

Ina and Xian

 

 

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

[Pce] FW: Last IPR Check on draft-ietf-pce-pcep-inter-domain-p2mp-procedures

[Quintin Zhao]

-Original Message-
From: Quintin Zhao [mailto:quintin.z...@huawei.com] 
Sent: 2013年5月21日 11:59
To: 'Julien Meuric';
'draft-ietf-pce-pcep-inter-domain-p2mp-procedu...@tools.ietf.org'
Subject: RE: Last IPR Check on
draft-ietf-pce-pcep-inter-domain-p2mp-procedures

Dear Julien,

I am not aware any other IPR other than the IPR disclosed already.

Thanks,
Quintin


-Original Message-
From: Julien Meuric [mailto:julien.meu...@orange.com] 
Sent: 2013年5月21日 4:54
To: draft-ietf-pce-pcep-inter-domain-p2mp-procedu...@tools.ietf.org
Cc: pce@ietf.org
Subject: Last IPR Check on draft-ietf-pce-pcep-inter-domain-p2mp-procedures

Dear authors of the aforementioned document,

Has all IPR that applies to
draft-ietf-pce-pcep-inter-domain-p2mp-procedures been disclosed in
compliance with IETF IPR rules? (see RFCs 3979, 4879, 3669 and 5378 for more
details)

Note that an associated IPR was disclosed in last February.

A response from each of you is expected.

Regards,

JP & 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 PCE WG？

[Quintin Zhao]

Support.

Quintin


---
From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of JP
Vasseur (jvasseur)
Sent: Tuesday, March 12, 2013 1:48 AM
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.

-- next part --
An HTML attachment was scrubbed...
URL:


--

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


End of Pce Digest, Vol 102, Issue 16



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

[Pce] Subject: IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-pce-pcep-inter-domain-p2mp-procedures-03

[Quintin Zhao]

Julien and JP,

 

There is a new IPR disclosure (https://datatracker.ietf.org/ipr/2004/) just
published for draft-ietf-pce-pcep-inter-domain-p2mp-procedures-03. Please
pay note that the IPR license terms in the disclosure as we think they are
more favorable than FRAND.

 

We are very sorry that this disclosure came late.  There are a few IPRs we
were working on in the area of PCE-P2MP drafts and we accidently mixed them
up, we thought we have made the IPR claim for the PCE-P2MP procedure draft,
then we found out that the disclosures we made so far are only for
RFC6006(IPR ID#1336 https://datatracker.ietf.org/ipr/1339/ and ID#1669
https://datatracker.ietf.org/ipr/1339/), but in fact the PCE-P2MP procedure
draft should have a separate IPR claim for itself.

 

I hope that the working group will be OK to continue with this work despite
the IPR disclosure, but it is up to you as chairs to judge the consensus on
this. Again, sorry for the confusion.

 

 

Thanks, Quintin.  

 

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

Re: [Pce] Pce Digest, Vol 100, Issue 5

[Quintin Zhao]

Adrian,

Thanks and I will be glad to join you and Dan to work on this.

Quintin



Message: 1
Date: Thu, 17 Jan 2013 16:46:29 -
From: "Adrian Farrel" 
To: "'Quintin Zhao'" 
Cc: pce@ietf.org
Subject: Re: [Pce] A new draft on an architecture for
application-based   network operations
Message-ID: <013301cdf4d2$3692eb00$a3b8c100$@olddog.co.uk>
Content-Type: text/plain; charset="us-ascii"

Hi Quintin,
 
Thanks for this text. Looks good. Dan and I will work to fold it into the
document. 
 
It is quite a substantial piece of text. Do you mind if we name you as a
Contributing Author?
 
Wrt a scenario for GCO and VNT, that also sounds interesting. Slightly
worried
that it may get a bit complicated, but if you are capable of documenting it,
I
think it would be a fine addition to the document.
 
Thanks,
Adrian
 
From: Quintin Zhao [mailto:quintin.z...@huawei.com] 
Sent: 16 January 2013 23:06
To: adr...@olddog.co.uk; 'Daniel King'
Cc: pce@ietf.org
Subject: Re: [Pce] A new draft on an architecture for application-based
network
operations
 
Dear Dan and Adrian, 
 
As we discussed I focused on providing text for GCO. The text and diagrams
may
not be formatted correctly so I also attach text file. If it would be good,
I
will create some more text for a GCO and VNT scenario. 
 
3.5 Global Concurrent Optimization
 
Global Concurrent Optimization (GCO) is defined in [RFC5557] and represents
a
key technology for maximizing network efficiency by computing a set of
traffic
engineered paths concurrently. A GCO path computation request will
simultaneously consider the entire topology of the network, and existing
LSPs,
when computing new services (TE LSPs) or an existing set of services.
 
 
A GCO may be requested in a number of scenarios, these include:
 
o Routing of new services where the PCE should consider existing
  services or network topology.  
 
o A reoptimization of existing services due to fragmented network
  resources or sub-optimized placement of sequential computed services. 
 
o Recovery of connectivity for bulk services in the event of a
  large network failure. 
 
[RFC5557] states that a GCO is primarily an NMS or a PCE-Server-based
solution,
due to nature of GCO path computation requests and the need for network and
service synchronization. Therefore the ABNO architecture represents a
suitable
framework for implementing GCO capable path 
computation functionality.   
 
It may be possible that a service provider would want to compute and deploy
new
services based on predicted traffic matrix. The GCO functionality and
capability
to perform concurrent computation, provides a significant network
optimization
advantage to avoid blocking and utilize network resources optimally. 
 
The following use case shows how the ABNO architecture and components are
used
to deploy GCO-enabled services. Furthermore, this use case also includes a
capability to consider multi-layer network (MLN) concurrency, in order to
optimize network efficiency or meet client network connectivity or bandwidth
requirements. 
 
3.5.1 GCO with MLN Use Case
 
The following IP over optical network represents a typical Client and Server
network:
 
 
 +-+
 | NMS |
 | |
 +--+--+
|
 +--+---+
 |  ABNO|
 |  |
 +---+-++
 | |
 | |
 +---+--+
/IP/MPLS (Client) Network Layer  \
   +--+
   |
  ++---+
 /   Optical (Server) Network Layer \
++
 
 Figure x: Network Architecture
 
The above network uses an IP/MPLS network layer which is Packet Switching
Capable (PSC). The optical layer is Lambda Switching Capable (LSC). The IP
packets are aggregated into lambda optical channels using TE LSP tunnels.
The lambda optical channels using within the optical network layer may be
fixed
or convertible.
 
When considering the GCO path computation problem, we can split the
requirements
into two categories of concurrency optimization objectives, these are:
 
o Minimize aggregate Bandwidth Consumption (MBC).
 
o Minimize the load of the Most Loaded Link (MLL).
 
o Minimize Cumulative Cost of a set of paths (MCC).
 
The use case assumes the GCO request will be offline and be initiated from
an
NMS, that is it will take significant time to compute the service and the
paths
reported as part of 

Re: [Pce] A new draft on an architecture for application-based network operations

[Quintin Zhao]

 appropriate policy for the request and consults the TED for
the packet network layer. If required, the PCE may compute two bulk service
requests based on the requested objective (MBC, MLL or MCC). To compute a
set of services for the GCO application, PCEP supports synchronization
VECtor (SVEC) lists for synchronized dependent path computations requests as
defined in [RFC5440] and described in [RFC6007]. 

 

Once the requested GCO service path computation completes, the PCE sends the
resulting paths back to the ABNO Controller. The response includes a fully
computed explicit path for each service (TE LSP) that needs to be
established. The ABNO Controller will forward the candidate paths back to
the NMS for user approval before being provisioned within the relevant
network layer. 

 

3. Coordination of MLN resources using VNTM and Path Computation in the
Optical Layer

 

The ABNO architecture supports both immediate connectivity requirements and
advanced scheduling (reservation) of resources. Given a service request that
exceeds the current capability of the current packet layer the PCE may
invoke the VNTM for the creation of necessary links in the virtual network
topology to meet the requirements of immediate or scheduled resources. This
interaction is documented in Figure 11 ( Invocation of VNTM and Optical
Layer Path Computation). 

 

Triggers for VNT reconfiguration, such as traffic demand changes, network
failures, and topological configuration changes may require a set of
existing TE LSPs to be re-computed, or new virtual TE links to be added to
the VNT. 

 

4. Provisioning in the Optical Layer

 

These may be immediate or scheduled optical resources (lambdas) dependent on
if the initial service requests are immediate or scheduled. 

 

5. Reoptimization of Existing Services (Defragmentation of Network)

 

If it is not possible to provision new resources to meet the bulk service
request then it may be possible via traffic grooming of existing LSPs
(either packet or optical) to optimize the capacity utilization of the
network layer. 

 

   1. The packet or optical PCE will compute the new service 

   request and provide a response to the ABNO Controller with the order 

   in which existing TE LSPs should be reoptimized so as to minimize 

   traffic disruption. 

 

   2. The PCE will compute the make-before-break replacement service. 

   The PCE will also need to indicate for each request the order in which 

   the old TE LSP should be removed and the order in which the new TE LSP 

   should be setup.  

   

   If the removal order is lower than the setup order, then the 

   make-before-break may not be performed for the request.

 

   3. Once the initial defragmentation of the network resources has been 

   performed then the new bulk request for services can be performed.

 

Thanks Quintin!  

 

 

 

*   To: "'Daniel King'" mailto:daniel@DOMAIN.HIDDEN> >, "'Quintin Zhao'" mailto:quintin.zhao@DOMAIN.HIDDEN> > 
*   Subject: Re: [Pce] A new draft on an architecture for
application-based network operations 
*   From: "Adrian Farrel" mailto:adrian@DOMAIN.HIDDEN> > 
*   Date: Fri, 7 Dec 2012 15:13:08 - 
*   Cc: pce at ietf.org <mailto:pce@DOMAIN.HIDDEN>  
*   Delivered-to: pce at ietfa.amsl.com <mailto:pce@DOMAIN.HIDDEN>  
*   In-reply-to: <008601cdd48a$674f7b90$35ee72b0$ at olddog.co.uk
<mailto:008601cdd48a%24674f7b90%2435ee72b0%24@DOMAIN.HIDDEN> > 
*   List-archive: <http://www.ietf.org/mail-archive/web/pce> 
*   List-help: <mailto:pce-requ...@ietf.org?subject=help> 
*   List-id: Path Computation Element  
*   List-post: <mailto:pce@ietf.org> 
*   List-subscribe: <https://www.ietf.org/mailman/listinfo/pce>,
<mailto:pce-requ...@ietf.org?subject=subscribe> 
*   List-unsubscribe: <https://www.ietf.org/mailman/options/pce>,
<mailto:pce-requ...@ietf.org?subject=unsubscribe> 
*   References: <50c0f8a1.2218b40a.2c1e.48c1SMTPIN_ADDED_BROKEN at
mx.google.com
<mailto:50c0f8a1.2218b40a.2c1e.48c1SMTPIN_ADDED_BROKEN@DOMAIN.HIDDEN> >
<008601cdd48a$674f7b90$35ee72b0$ at olddog.co.uk
<mailto:008601cdd48a%24674f7b90%2435ee72b0%24@DOMAIN.HIDDEN> > 
*   Reply-to: adrian at olddog.co.uk <mailto:adrian@DOMAIN.HIDDEN>  
*   Thread-index: AQFrZjbRxLc5+InYH8ThqvcxIMjyVAEBEe1kmMpCNpA= 

  _  

Hi Quintin,
 
Following up with some more detail on top of Dan's email.
 
>> The draft is very good and is helpful coordinate PCE and TE technologies
>> between applications and network. I focused on some sections and have
>> following questions and suggestions. 
 
Thanks for reading and commenting.
Answers in line.
 
>> (1) Applicability of ABNO Architecture. 
>> Your document abstract and introduction discusses scenarios including
>> content and da

Re: [Pce] A new draft on an architecture for application-based network operations

[Quintin Zhao]

Dear Dan and Adrian, 

 

The draft is very good and is helpful coordinate PCE and TE technologies
between applications and network. I focused on some sections and have
following questions and suggestions. 

 

(1) Applicability of ABNO Architecture. 

Your document abstract and introduction discusses scenarios including
content and data-center interconnection ("Services such as content
distribution, distributed databases, or inter-data center connectivity place
a set of new requirements on the operation of networks."). I think the
architecture is also relevant to lots of other environments: mobile
backhaul, core transport, packet switch network, etc. Do you agree? 

 

(2) ABNO Controller.

Section 2.2.13 (ABNO controller) needs to be discussed in more detail. Do
you think multiple ABNO controllers or just one ABNO controller will be
required? Maybe an implementation will use a ABNO Controller per
"application" (Service Coordinator/NMS/OSS)? 

 

(3) PCE or PCE's?

Figure 1 shows *a* PCE. It is expected that multiple PCE' would be used,
this is important for VNTM Use Case. Maybe you can show more PCE's in the
figure 1 or describe it?

 

(4) Network Resiliency.

I am interested in ABNO managing network failures that may be protected with
shared mesh protection at the network which could be MPLS TP or WDM. ABNO
would provide a shared path protection which optimizes as network conditions
change. This is based on client layer requirements of reliability and
protection restoration time. To make this possible the shared mesh
protection paths would need to be client layer traffic aware and have
customer SLA information. Do you think this is a good use case?

 

(5) Custom (Abstracted) Topologies.   

Could ABNO provide abstracted topologies via the north-bound interface to
the requester (provisioning tool)? In China we have the customers who would
like IPv6 deployment in IPv4 backbone. If provider can assign specific nodes
and links to be used for logically isolated IPv6 plane, then the ABNO (I2RS
and BGP-LS) architecture could be used to provide abstracted topology based
on the preferred equipment for carrying tunneled IPv6 traffic. Is this
another use case that may be useful?

 

(6) Manageability and Security.  

Are you going to provide Manageability and Security sections in future
versions of the ABNO document or another document? It is an important area
for ABNO that needs further discussion. 

 

Thanks!

Quintin

 

 

--

 

Message: 1

Date: Sat, 1 Dec 2012 22:58:58 -

From: "Daniel King" 

To: 

Subject: [Pce] A new draft on an architecture for application-based

 network  operations

Message-ID: <002401cdd017$7331c840$599558c0$@olddog.co.uk>

Content-Type: text/plain;  charset="us-ascii"

 

Hi PCE'rs,

 

Adrian and I posted an I-D which is a rather grandiose attempt to pull

together a number of existing architectural components (PCE, VNTM, I2RS,

policy, etc., etc.). This is a sort of meta-SDN PCE-based architect-thingy.

It needed a name, so we called it Application-Based Network Operations

(ABNO), warning it's not house trained and may answer to various other

names:

 

A PCE-based Architecture for Application-based Network Operations

http://tools.ietf.org/html/draft-farrkingel-pce-abno-architecture-00

 

As some of you will know this is the result of numerous discussions we have

had with a number of people over the last three months.  Where pieces of the

puzzle seem to have been coagulating, we thought it might be nice to build a

framework in which the jelly (jello) can set. It is at a really early stage,

so we are convinced you will all throw stuff at us, but what the hell!

 

As it stands, the current draft includes:

 

- A brief description of abstraction functional components and the

interfaces between them. 

- An attempt to supply pointers to existing work (tool kit) where that may

be applicable and there are some use case examples to give a feel for how it

all works.

- Various ABNO use cases. 

 

A number of areas need further discussion, especially the use cases. We

decided to submit with the few we do have, in order to generate some

feedback - anyone who wants to supply use case(s) and text, would receive

hero status. 

 

We have pitched the document as a PCE working group document because PCE is

a central component, but the document doesn't really fall inside the PCE

charter. For the time being it might be best to send comments direct to us

rather than clutter up any WG mailing list with discussions that are outside

the charter (but if some WG chair wants to claim the work, then...)

 

Thanks,

Dan and Adrian

 

 

 

--

 

___

Pce mailing list

Pce@ietf.org

https://www.ietf.org/mailman/listinfo/pce

 

 

End of Pce Digest, Vol 99, Issue 1

**

 

Re: [Pce] IPR Check on draft-ietf-pce-hierarchy-fwk

[Quintin Zhao]

I'm not aware of any IPR on this draft.

Thanks,
Quintin


> -Original Message-
> From: julien.meu...@orange.com [mailto:julien.meu...@orange.com]
> Sent: 08 June 2012 15:42
> To: Daniel King; Adrian Farrel; Quintin Zhao; Fatai Zhang
> Cc: pce@ietf.org
> Subject: IPR Check on draft-ietf-pce-hierarchy-fwk
> 
> Dear co-authors of the aforementioned I-D,
> 
> Are you aware of any IPR that applies to draft-ietf-pce-hierarchy-fwk?
> If so, has this IPR been disclosed in compliance with IETF IPR rules?
> (see RFCs 3979, 4879, 3669 and 5378 for more details)
> 
> A response from each of you is expected.
> 
> Regards,
> 
> JP & Julien
> 
> 
> __
> ___
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce
> message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline toute responsabilite si ce message a ete
altere,
> deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
delete
this
> message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for
messages
that
> have been modified, changed or falsified.
> Thank you.



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

Re: [Pce] Adoption of draft-king-pce-hierarchy-fwk-06

[Quintin Zhao]

Yes/support!

Thanks,

Quintin


-Original Message-
From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of Julien
Meuric
Sent: 20 September 2011 16:08
To: pce@ietf.org
Subject: [Pce] Adoption of draft-king-pce-hierarchy-fwk-06

Hi PCE WG.

The framework for hierarchical PCE has been there for long, discussed
several times and was pending the charter update. This is a poll for
adopting draft-king-pce-hierarchy-fwk-06 as WG document. Please reply to
this message to express either your support, i.e. you consider the I-D is a
good foundation to address the issue, or your objection, which you are
expected to clarify.

Thank you,

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] New Version of draft-zhao-pce-pcep-inter-domain-p2mp-procedures

[Quintin Zhao]

Hi Julien,

In order to get a "good enough" result instead of getting an optimal result
in the dynamic scenario,
we have mentioned a possible procedure in the last paragraph of section 7.2
from the current version of the draft, 
where the transit PCEs should be configurable to control the number of paths
sent upstream. 

Then the challenge is to find the right number (or the "good enough" number)
of path sent upstream we can configure at the transit PCEs. 
It depends on a lot of factors, such as the network topology and the
definition of the "good enough". :-)  

Any suggestions regarding to procedures/heuristics that might help to get a
"good enough" number are welcome.

Thanks for your time!

Quintin


-
Message: 1
Date: Thu, 17 Feb 2011 18:21:18 +0100
From: Julien Meuric 
Subject: Re: [Pce] New Version  of
draft-zhao-pce-pcep-inter-domain-p2mp-procedures
To: pce@ietf.org
Message-ID: <4d5d590e.6040...@orange-ftgroup.com>
Content-Type: text/plain; charset=windows-1252; format=flowed

Hi.

Chair hat off, so non-authoritative answer. :-)

I tend to agree that "good enough" is enough, especially with respect to 
an expensive optimality which might not be my fellow's optimality...

Thanks,

Julien


Le 16/02/2011 22:27, Daniel King a ?crit :
> Although you make an excellent point, is it necessary to have the 
> optimal core tree? We should defer to the operators to an 
> authoritative response. My personal opinion is that ?good enough? is 
> probably suitable.


--

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


End of Pce Digest, Vol 78, Issue 10
***

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

Re: [Pce] Adoption of draft-margaria-pce-gmpls-pcep-extensions-01?

[Quintin Zhao]

Yes.

Quintin

? 2010-8-4???12:10? Julien Meuric ???

> Hi all.
> 
> During the PCE meeting in Maastricht, we had a consensus in the room in
favor of adopting draft-margaria-pce-gmpls-pcep-extensions-01 as WG
document. Considering that we already have the GMPLS requirements as WG
draft and that it is a foundation for any WSON work which might follow the
GMPLS extensions in CCAMP, now it is time to express your minds on this
list.
> 
> Do you support the adoption of draft-margaria-pce-gmpls-pcep-extensions-01
as WG document?
> 
> Properly argued answered are always valuable, especially in case of "no".
As you are going to review the I-D before answering, any comments you will
send to improve its content are very welcome.
> 
> Thanks,
> 
> 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


End of Pce Digest, Vol 72, Issue 2
**

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

Re: [Pce] Implementations of draft-ietf-pce-pcep-p2mp-extensions-07

[Quintin Zhao]

JP,

 

We have implemented draft-ietf-pce-pcep-p2mp-extensions and found no major
issues. I recently noticed a minor typo that I would like to update in the
draft.  We would also like to offer other implementers to discuss
interoperability with us. 

 

Thanks, 

Quintin

 

 


-

From: JP Vasseur 

Subject: [Pce] Implementations of

draft-ietf-pce-pcep-p2mp-extensions-07

To: pce@ietf.org

Message-ID: <70b39356-b518-4934-96f6-801118dbd...@cisco.com>

Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

 

Dear all,

 

Before requesting publication of draft-ietf-pce-pcep-p2mp- extensions-07, we
would appreciate any feed-back on existing implementations.

 

Thanks.

 

JP.

 

 

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

[Pce] New Version Notification for draft-zhao-pce-pcep-inter-domain-p2mp-procedures-03

[Quintin Zhao]

PCE'rs, 

The authors of draft-zhao-pce-pcep-inter-domain-p2mp-procedures have posted
a new version. This version includes the following updates:

- Clarification of work and update of Abstract;
- Reordered and cleaned up Introduction text;
- Cleaned up Terminology;
- Expanded Problem Statement and added some requirements;
- Cleaned up Definition of X-VSPT.

We have made more corrections throughout the document and updated the
references.

Thank you!  
Quintin

-Original Message-
From: IETF I-D Submission Tool [mailto:idsubmiss...@ietf.org] 
Sent: Thursday, February 04, 2010 7:37 PM
To: qz...@huawei.com
Cc: z...@cisco.com; ts...@cisco.com; dan...@olddog.co.uk;
david.amzal...@bt.com; fabien.verhae...@gmail.com; ke-kum...@kddi.com
Subject: New Version Notification for
draft-zhao-pce-pcep-inter-domain-p2mp-procedures-03


A new version of I-D,
draft-zhao-pce-pcep-inter-domain-p2mp-procedures-03.txt has been successfuly
submitted by Quintin Zhao and posted to the IETF repository.

Filename:draft-zhao-pce-pcep-inter-domain-p2mp-procedures
Revision:03
Title:   PCE-based Computation Procedure To Compute Shortest
Constrained P2MP Inter-domain Traffic Engineering Label Switched Paths
Creation_date:   2010-02-04
WG ID:   Independent Submission
Number_of_pages: 20

Abstract:
The ability to compute paths for constrained point-to-multipoint 
(P2MP) Traffic Engineering Label Switched Paths(TE LSPs) across 
multiple domains has been identified as a key requirement for the
deployment of P2MP services in MPLS and GMPLS networks. The Path
Computation Element (PCE) has been recognized as an appropriate
technology for the determination of inter-domain paths of P2MP TE
LSPs. 

This document describes the procedures and extensions to the PCE
communication Protocol (PCEP) to handle requests and responses for
the computation of inter-domain paths for P2MP TE LSPs.
 



The IETF Secretariat.


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

Re: [Pce] Request WG Adoption of draft-zhao-pce-pcep-inter-domain-p2mp-procedures

[Quintin Zhao]

Julien, 

The authors of draft-zhao-pce-pcep-inter-domain-p2mp-procedures have
discussed (thanks to co-authors for comments!) the strategy for the work and
our plan is as follows: 

1. Review the requirements. Our operator co-authors are very useful for
having these discussions, but we would like feedback from the WG as well;

2. Create a single hybrid solution. We feel we can create a good solution
that utilizes the strengths of BRPC and Core Tree technologies; 

3. Continue to compare requirements against selected solution and modify as
necessary;

5. Implement and complete!

Our purpose is to converge on a single solution. We do not think multiple
inter-domain P2MP solutions are wanted or necessary. We agree that we have a
lot of time ahead of us in developing our solution. We have already received
comments from the WG and we would like more feedback. 
 
Thank you!
Quintin

-Original Message-
From: Quintin Zhao [mailto:qz...@huawei.com] 
Sent: Friday, January 08, 2010 3:22 PM
To: 'julien.meu...@orange-ftgroup.com'
Cc: 'pce@ietf.org'; 'jvass...@cisco.com'
Subject: RE: Request WG Adoption of
draft-zhao-pce-pcep-inter-domain-p2mp-procedures

Hi Julien,  

Yes, we still believe that we have a lot of work ahead them regarding this
work item. We hope that adoption of this work item by the WG would make the
work more visible and generate further interest in developing the overall
solution. 

I believe we have a broad consensus across the co-authors for how to move
this work forward. Please give me a few days to confirm our plan with my
co-authors and then I will mail you and the WG our intended strategy. 

Regards,
Quintin

-Original Message-
From: julien.meu...@orange-ftgroup.com
[mailto:julien.meu...@orange-ftgroup.com] 
Sent: Thursday, January 07, 2010 8:57 AM
To: qz...@huawei.com
Cc: pce@ietf.org; jvass...@cisco.com
Subject: RE: Request WG Adoption of
draft-zhao-pce-pcep-inter-domain-p2mp-procedures

Hi Quintin.

It is a significant step that authors of both drafts agreed on working
on a single document and we congratulate all of you for that.

During IETF 76, you also mentioned "Lots of work and analysis ahead" and
a need to "continue to review requirements and select the technique that
best meets the requirements". Indeed, the current version of the
document looks more like a solution list than an actual merge of former
proposals. Considering the complexity induced by an inter-domain P2MP
extension, we would appreciate before taking any decision that you
elaborate on the way you intend to move forward towards a common
solution.

Thanks

Julien

____

From: Quintin Zhao [mailto:qz...@huawei.com] 

Hi Co-Chairs and PCE WG,

Different parties have been working on solutions for computing P2MP
paths across multi-domain networks. At IETF 75 we were requested by JP,
to formulate a plan and resolve any issues in order to move the work
forward. After calls and emails between draft-ali-pce-brpc-p2mp-ext and
draft-zhao-pce-pcep-inter-domain-p2mp-procedure authors, we felt there
was concurrence to merge the solutions and work together on a unified
solution. At IETF 76 we presented our initial/combined PCE-based
Shortest Constrained P2MP Inter-domain TE-LSP solution
(draft-zhao-pce-pcep-inter-domain-p2mp-procedures-02). 

We would like to know if the co-chairs and WG would be in favor of the
document becoming a WG draft?

Regards,

Quintin


*
This message and any attachments (the "message") are confidential and
intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed
or falsified.
If you are not the intended addressee of this message, please cancel it
immediately and inform the sender.


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

Re: [Pce] FW: Inter-domain-p2mp-procedures

[Quintin Zhao]

Greg,

 

Thanks for the clarification!

 

Quintin

 

  _  

From: Greg Mirsky [mailto:gregimir...@gmail.com] 
Sent: Thursday, January 14, 2010 3:42 PM
To: Quintin Zhao
Cc: pce@ietf.org
Subject: Re: [Pce] FW: Inter-domain-p2mp-procedures

 

Hi Quintin,
sorry for delayed reply. If we take Fig.1 from RFC 4090 and remove link
[R3]-[R8], then that will change R1's Backup:

 [R1]--[R2]--[R3]-[R4]--[R5]






  \   \/\  /


[R6]--[R7][R8]---[R9]

Protected LSP: [R1->R2->R3->R4->R5]
R1's Backup: [R1->R6->R7->R8->R4]
R2's Backup: [R2->R7->R8->R4]
R4's Backup: [R4->R9->R5]

 

As result of lower meshiness of the network the Merge point is moved from R3
to R4.
If only Link protection desired, then, with the topology as above:

R1's Backup: [R1->R6->R7->R2]
R2's Backup: [R2->R7->R8->R4]


Thus we see, that protecting even an immediate link is not always possible
to merge onto Next Hop LSR and depends on level of connectivity (meshiness)
of the network. In my view, using p2mp LSP to provide local protection for
the p2mp LSP is more generic approach.

Kind regards,
Greg

On Fri, Jan 8, 2010 at 8:58 AM, Quintin Zhao  wrote:

Hi Greg,

 

Thanks for the comments and suggestions! 

 

Can you elaborate a little more on what you mean here?

 

“I think that because we can not guarantee that the immediate LSR will be
the merging point of p2p backup LSP one can not assume that a single p2p can
be used to provide protection for local link failure case.”

 

Quintin

 

  _  

From: Greg Mirsky [mailto:gregimir...@gmail.com] 
Sent: Tuesday, January 05, 2010 6:20 PM
To: JP Vasseur
Cc: Quintin Zhao; pce@ietf.org


Subject: Re: [Pce] Inter-domain-p2mp-procedures

 

Hi Quintin and JP,
in regard to applicability of p2p FRR protection of links of p2mp LSP I
agree with JP that such applicability is questionable and very much depends
on network topology, its meshiness. I think that because we can not
guarantee that the immediate LSR will be the merging point of p2p backup LSP
one can not assume that a single p2p can be used to provide protection for
local link failure case. I believe that strong case can be made to recommend
use p2mp for local link protection as well as when node protection required.

Regards,
Greg

2009/12/23 JP Vasseur 

Hi,



On Dec 21, 2009, at 3:49 AM, Quintin Zhao wrote:

JP,

Good question! I guess that I should use "more complex to be implemented"
instead of "less applicable" in my previous email when I refer to using FRR
for P2MP node protection.

 

Well this is arguable though ..

 

What I was trying to mean is that p2p backup is easily to be used for the
link protection for p2mp. To use FRR for the node protection in p2mp, it is
not that straight forward comparing to p2p node protection, especially from
the point view of bandwidth cost and label allocation.

 

Well it all depends on how you compute your P2P backup, and this may be used
for a very short period of time. There are excellent off-line algorithms to
achieve
some good level of efficiency.

 

For example, to use
the p2p tunnel to backup the branch node, we need multiple p2p tunnels to
protect a single branch node. If the p2mp backup tunnel is used for the
branch node protection, then the upstream label allocation might be needed.

 

Which is not a major issue. See long discussions on the list some time ago
on the
subject matter.

Thanks.

JP.

 



Regards,
Quintin

-Original Message-----
From: JP Vasseur [mailto:jvass...@cisco.com]
Sent: Saturday, December 19, 2009 4:51 AM
To: Quintin Zhao
Cc: pce@ietf.org
Subject: Re: [Pce] Inter-domain-p2mp-procedures

Hi,

On Dec 18, 2009, at 9:41 PM, Quintin Zhao wrote:


JP,

Thanks for your comments and suggestions.

I agree with you that for a quickly recovery, FRR is a good choice.
For the
p2mp TE LSP, if the failures are about link failures, FRR can be
used for
the recovery. If the failures are about the p2mp nodes which can be
the
root/branch/bud/leaf nodes, FRR might not be an easy way to cover
these
cases.¡¡


What makes you think that the use of FRR is less applicable to node
failures ?
(for which you could either use a set of P2P backup or a single P2MP
backup)

Thanks

JP.

This may lead to other possible solutions and the pre-computed
backup sub-tree or the whole backup tree might be needed for the
possible
solutions. As you mentioned, using the FRR itself will eventually
need the
head end reoptimization using a make before break.

The pre-computed backup p2mp path/sub-path or the new computed path
during
reoptimization process using make before breaks are the optimal path
subject
to the OF and all other current constrains when the path is computed
by the
PCE. I agree with you that we can not draw the conclusion on the
potentially
level of sub-optimality of performing local reroute as op

Re: [Pce] Request WG Adoption of draft-zhao-pce-pcep-inter-domain-p2mp-procedures

[Quintin Zhao]

Hi Julien,  

Yes, we still believe that we have a lot of work ahead them regarding this
work item. We hope that adoption of this work item by the WG would make the
work more visible and generate further interest in developing the overall
solution. 

I believe we have a broad consensus across the co-authors for how to move
this work forward. Please give me a few days to confirm our plan with my
co-authors and then I will mail you and the WG our intended strategy. 

Regards,
Quintin

-Original Message-
From: julien.meu...@orange-ftgroup.com
[mailto:julien.meu...@orange-ftgroup.com] 
Sent: Thursday, January 07, 2010 8:57 AM
To: qz...@huawei.com
Cc: pce@ietf.org; jvass...@cisco.com
Subject: RE: Request WG Adoption of
draft-zhao-pce-pcep-inter-domain-p2mp-procedures

Hi Quintin.

It is a significant step that authors of both drafts agreed on working
on a single document and we congratulate all of you for that.

During IETF 76, you also mentioned "Lots of work and analysis ahead" and
a need to "continue to review requirements and select the technique that
best meets the requirements". Indeed, the current version of the
document looks more like a solution list than an actual merge of former
proposals. Considering the complexity induced by an inter-domain P2MP
extension, we would appreciate before taking any decision that you
elaborate on the way you intend to move forward towards a common
solution.

Thanks

Julien

____

From: Quintin Zhao [mailto:qz...@huawei.com] 

Hi Co-Chairs and PCE WG,

Different parties have been working on solutions for computing P2MP
paths across multi-domain networks. At IETF 75 we were requested by JP,
to formulate a plan and resolve any issues in order to move the work
forward. After calls and emails between draft-ali-pce-brpc-p2mp-ext and
draft-zhao-pce-pcep-inter-domain-p2mp-procedure authors, we felt there
was concurrence to merge the solutions and work together on a unified
solution. At IETF 76 we presented our initial/combined PCE-based
Shortest Constrained P2MP Inter-domain TE-LSP solution
(draft-zhao-pce-pcep-inter-domain-p2mp-procedures-02). 

We would like to know if the co-chairs and WG would be in favor of the
document becoming a WG draft?

Regards,

Quintin


*
This message and any attachments (the "message") are confidential and
intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed
or falsified.
If you are not the intended addressee of this message, please cancel it
immediately and inform the sender.


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

[Pce] FW: Inter-domain-p2mp-procedures

[Quintin Zhao]

Hi Greg,

 

Thanks for the comments and suggestions! 

 

Can you elaborate a little more on what you mean here?

 

“I think that because we can not guarantee that the immediate LSR will be
the merging point of p2p backup LSP one can not assume that a single p2p can
be used to provide protection for local link failure case.”

 

Quintin

 

  _  

From: Greg Mirsky [mailto:gregimir...@gmail.com] 
Sent: Tuesday, January 05, 2010 6:20 PM
To: JP Vasseur
Cc: Quintin Zhao; pce@ietf.org
Subject: Re: [Pce] Inter-domain-p2mp-procedures

 

Hi Quintin and JP,
in regard to applicability of p2p FRR protection of links of p2mp LSP I
agree with JP that such applicability is questionable and very much depends
on network topology, its meshiness. I think that because we can not
guarantee that the immediate LSR will be the merging point of p2p backup LSP
one can not assume that a single p2p can be used to provide protection for
local link failure case. I believe that strong case can be made to recommend
use p2mp for local link protection as well as when node protection required.

Regards,
Greg

2009/12/23 JP Vasseur 

Hi,



On Dec 21, 2009, at 3:49 AM, Quintin Zhao wrote:

JP,

Good question! I guess that I should use "more complex to be implemented"
instead of "less applicable" in my previous email when I refer to using FRR
for P2MP node protection.

 

Well this is arguable though ..

 

What I was trying to mean is that p2p backup is easily to be used for the
link protection for p2mp. To use FRR for the node protection in p2mp, it is
not that straight forward comparing to p2p node protection, especially from
the point view of bandwidth cost and label allocation.

 

Well it all depends on how you compute your P2P backup, and this may be used
for a very short period of time. There are excellent off-line algorithms to
achieve
some good level of efficiency.

 

For example, to use
the p2p tunnel to backup the branch node, we need multiple p2p tunnels to
protect a single branch node. If the p2mp backup tunnel is used for the
branch node protection, then the upstream label allocation might be needed.

 

Which is not a major issue. See long discussions on the list some time ago
on the
subject matter.

Thanks.

JP.

 



Regards,
Quintin

-Original Message-
From: JP Vasseur [mailto:jvass...@cisco.com]
Sent: Saturday, December 19, 2009 4:51 AM
To: Quintin Zhao
Cc: pce@ietf.org
Subject: Re: [Pce] Inter-domain-p2mp-procedures

Hi,

On Dec 18, 2009, at 9:41 PM, Quintin Zhao wrote:


JP,

Thanks for your comments and suggestions.

I agree with you that for a quickly recovery, FRR is a good choice.
For the
p2mp TE LSP, if the failures are about link failures, FRR can be
used for
the recovery. If the failures are about the p2mp nodes which can be
the
root/branch/bud/leaf nodes, FRR might not be an easy way to cover
these
cases.¡¡


What makes you think that the use of FRR is less applicable to node
failures ?
(for which you could either use a set of P2P backup or a single P2MP
backup)

Thanks

JP.

This may lead to other possible solutions and the pre-computed
backup sub-tree or the whole backup tree might be needed for the
possible
solutions. As you mentioned, using the FRR itself will eventually
need the
head end reoptimization using a make before break.

The pre-computed backup p2mp path/sub-path or the new computed path
during
reoptimization process using make before breaks are the optimal path
subject
to the OF and all other current constrains when the path is computed
by the
PCE. I agree with you that we can not draw the conclusion on the
potentially
level of sub-optimality of performing local reroute as opposed to
global
reoptimization.

Also we can not draw the conclusion if these backup path or
optimized path
after the failure is better or worse than the primary path. These
pre-computed backup paths/sub-paths or the optimized paths under the
failure
condition are the best path which can be used for the recovery of the
failure while satisfying all the conditions.

Regards,
Quintin


-Original Message-
From: JP Vasseur [mailto:jvass...@cisco.com]
Sent: Thursday, December 17, 2009 1:26 PM
To: Quintin Zhao
Cc: pce@ietf.org
Subject: Re: [Pce] Inter-domain-p2mp-procedures

Hi,

Note that this is a fairly well-known issue. The aim of local repair
has always been to quickly recover from the failure. The degree of
resources guarantees and optimality depends on the amount of resources
dedicated to backup, several assumptions with regards to potential
simultaneous failures, the algorithms used to pre-compute backup
tunnels, etc ... The approach taken by P2P FRR has been to first
locally reroute and trigger a head-end reoptimization using a make
before break. I do not think that you can draw any conclusion on the
potentially level of sub-optimality of performing local reroute as
opposed to global reoptimization. It depends on a number of factors.

JP.

On Dec 14, 2009, at 10:15 PM, Quintin

[Pce] Request WG Adoption of draft-zhao-pce-pcep-inter-domain-p2mp-procedures

[Quintin Zhao]

Hi Co-Chairs and PCE WG,

 

Different parties have been working on solutions for computing P2MP paths
across multi-domain networks. At IETF 75 we were requested by JP, to
formulate a plan and resolve any issues in order to move the work forward.
After calls and emails between draft-ali-pce-brpc-p2mp-ext and
draft-zhao-pce-pcep-inter-domain-p2mp-procedure authors, we felt there was
concurrence to merge the solutions and work together on a unified solution.
At IETF 76 we presented our initial/combined PCE-based Shortest Constrained
P2MP Inter-domain TE-LSP solution
(draft-zhao-pce-pcep-inter-domain-p2mp-procedures-02). 

 

We would like to know if the co-chairs and WG would be in favor of the
document becoming a WG draft?

 

Regards,

Quintin

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

[Pce] FW: Inter-domain-p2mp-procedures

[Quintin Zhao]

JP,

Good question! I guess that I should use "more complex to be implemented"
instead of "less applicable" in my previous email when I refer to using FRR
for P2MP node protection.

What I was trying to mean is that p2p backup is easily to be used for the
link protection for p2mp. To use FRR for the node protection in p2mp, it is
not that straight forward comparing to p2p node protection, especially from
the point view of bandwidth cost and label allocation. For example, to use
the p2p tunnel to backup the branch node, we need multiple p2p tunnels to
protect a single branch node. If the p2mp backup tunnel is used for the
branch node protection, then the upstream label allocation might be needed. 


Regards,
Quintin

-Original Message-
From: JP Vasseur [mailto:jvass...@cisco.com] 
Sent: Saturday, December 19, 2009 4:51 AM
To: Quintin Zhao
Cc: pce@ietf.org
Subject: Re: [Pce] Inter-domain-p2mp-procedures

Hi,

On Dec 18, 2009, at 9:41 PM, Quintin Zhao wrote:

>
> JP,
>
> Thanks for your comments and suggestions.
>
> I agree with you that for a quickly recovery, FRR is a good choice.   
> For the
> p2mp TE LSP, if the failures are about link failures, FRR can be  
> used for
> the recovery. If the failures are about the p2mp nodes which can be  
> the
> root/branch/bud/leaf nodes, FRR might not be an easy way to cover  
> these
> cases.　

What makes you think that the use of FRR is less applicable to node  
failures ?
(for which you could either use a set of P2P backup or a single P2MP  
backup)

Thanks

JP.

> This may lead to other possible solutions and the pre-computed
> backup sub-tree or the whole backup tree might be needed for the  
> possible
> solutions. As you mentioned, using the FRR itself will eventually  
> need the
> head end reoptimization using a make before break.
>
> The pre-computed backup p2mp path/sub-path or the new computed path  
> during
> reoptimization process using make before breaks are the optimal path  
> subject
> to the OF and all other current constrains when the path is computed  
> by the
> PCE. I agree with you that we can not draw the conclusion on the  
> potentially
> level of sub-optimality of performing local reroute as opposed to  
> global
> reoptimization.
>
> Also we can not draw the conclusion if these backup path or  
> optimized path
> after the failure is better or worse than the primary path. These
> pre-computed backup paths/sub-paths or the optimized paths under the  
> failure
> condition are the best path which can be used for the recovery of the
> failure while satisfying all the conditions.
>
> Regards,
> Quintin
>
>
> -Original Message-
> From: JP Vasseur [mailto:jvass...@cisco.com]
> Sent: Thursday, December 17, 2009 1:26 PM
> To: Quintin Zhao
> Cc: pce@ietf.org
> Subject: Re: [Pce] Inter-domain-p2mp-procedures
>
> Hi,
>
> Note that this is a fairly well-known issue. The aim of local repair
> has always been to quickly recover from the failure. The degree of
> resources guarantees and optimality depends on the amount of resources
> dedicated to backup, several assumptions with regards to potential
> simultaneous failures, the algorithms used to pre-compute backup
> tunnels, etc ... The approach taken by P2P FRR has been to first
> locally reroute and trigger a head-end reoptimization using a make
> before break. I do not think that you can draw any conclusion on the
> potentially level of sub-optimality of performing local reroute as
> opposed to global reoptimization. It depends on a number of factors.
>
> JP.
>
> On Dec 14, 2009, at 10:15 PM, Quintin Zhao wrote:
>
>>
>> Hello PCE'rs,
>>
>> I would like to follow-up on some discussions from our PCE WG
>> session last
>> month. Specifically regarding Dajiang's failure and recomputation
>> observations on our draft. We are very interested to hear comments
>> regarding
>> the need for computing secondary paths in the event of failure.
>> Currently
>> our thinking is to recompute the sub-tree based in the domain where
>> the
>> failure has occurred. In this case we would not need to perform a
>> recalculation of the entire tree. We could also recompute the entire
>> tree,
>> and avoid the failed areas, as long as the TED has the updated
>> topology.
>> Realistically one might have a backup core tree pre-computed so you
>> can
>> switch over in the event of failure. There are also other
>> considerations.
>> Would a partial recomputation provide a "worse" SPT or MCT tree, or
>> would a
>> full tree recomputation provide a "better" SPT or MCT? I can think of
>> scenarios for both a parti

Re: [Pce] Inter-domain-p2mp-procedures

[Quintin Zhao]

JP,

Thanks for your comments and suggestions.

I agree with you that for a quickly recovery, FRR is a good choice.  For the
p2mp TE LSP, if the failures are about link failures, FRR can be used for
the recovery. If the failures are about the p2mp nodes which can be the
root/branch/bud/leaf nodes, FRR might not be an easy way to cover these
cases.　This may lead to other possible solutions and the pre-computed
backup sub-tree or the whole backup tree might be needed for the possible
solutions. As you mentioned, using the FRR itself will eventually need the
head end reoptimization using a make before break.

The pre-computed backup p2mp path/sub-path or the new computed path during
reoptimization process using make before breaks are the optimal path subject
to the OF and all other current constrains when the path is computed by the
PCE. I agree with you that we can not draw the conclusion on the potentially
level of sub-optimality of performing local reroute as opposed to global
reoptimization.

Also we can not draw the conclusion if these backup path or optimized path
after the failure is better or worse than the primary path. These
pre-computed backup paths/sub-paths or the optimized paths under the failure
condition are the best path which can be used for the recovery of the
failure while satisfying all the conditions.
 
Regards,
Quintin


-Original Message-
From: JP Vasseur [mailto:jvass...@cisco.com] 
Sent: Thursday, December 17, 2009 1:26 PM
To: Quintin Zhao
Cc: pce@ietf.org
Subject: Re: [Pce] Inter-domain-p2mp-procedures

Hi,

Note that this is a fairly well-known issue. The aim of local repair  
has always been to quickly recover from the failure. The degree of  
resources guarantees and optimality depends on the amount of resources  
dedicated to backup, several assumptions with regards to potential  
simultaneous failures, the algorithms used to pre-compute backup  
tunnels, etc ... The approach taken by P2P FRR has been to first  
locally reroute and trigger a head-end reoptimization using a make  
before break. I do not think that you can draw any conclusion on the  
potentially level of sub-optimality of performing local reroute as  
opposed to global reoptimization. It depends on a number of factors.

JP.

On Dec 14, 2009, at 10:15 PM, Quintin Zhao wrote:

>
> Hello PCE'rs,
>
> I would like to follow-up on some discussions from our PCE WG  
> session last
> month. Specifically regarding Dajiang's failure and recomputation
> observations on our draft. We are very interested to hear comments  
> regarding
> the need for computing secondary paths in the event of failure.  
> Currently
> our thinking is to recompute the sub-tree based in the domain where  
> the
> failure has occurred. In this case we would not need to perform a
> recalculation of the entire tree. We could also recompute the entire  
> tree,
> and avoid the failed areas, as long as the TED has the updated  
> topology.
> Realistically one might have a backup core tree pre-computed so you  
> can
> switch over in the event of failure. There are also other  
> considerations.
> Would a partial recomputation provide a "worse" SPT or MCT tree, or  
> would a
> full tree recomputation provide a "better" SPT or MCT? I can think of
> scenarios for both a partial and full recomputation, so perhaps we  
> need to
> implement both but allow the PCC to decide when to issue a partial  
> or full
> recomputation based on some criterion.
>
> Thanks,
>
> Quintin
>
> ___
> 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] Inter-domain-p2mp-procedures

[Quintin Zhao]

Dhruv,

 

Thanks for your comments and suggestions.

 

For the pre-computed backup tree, I think that it should be best tree
available during the computation time period while satisfying the
link/node/path diversity constrains. 

 

For the backup tree's Path-diversity, this might be depending on the
failures we are trying to protect. If we only want to protect the link
failures, then the backup tree may only need the link diversity from the
primary tree.  For the node failures, then we may need the backup tree which
has the node diversity from the primary tree. We also may need the link
direction diversity backup tree from the primary backup tree for certain
scenarios. We will add a paragraph in the draft to specify all the path
diversity level we should support when we compute the backup tree.

 

Yes, the inter-domain p2mp procedure need to support all re-optimization
scenarios specified in draft-ietf-pce-pcep-p2mp-extensions in the procedure
draft. We will specify this in the new version of the draft.

 

Thanks,

Quintin

 

 

-Original Message-

From: Quintin Zhao [mailto:qz...@huawei.com] 

 

--

 

Message: 2

Date: Tue, 15 Dec 2009 12:08:52 +0530

From: dhruv dhody 

Subject: Re: [Pce] Inter-domain-p2mp-procedures

To: 'Quintin Zhao' , pce@ietf.org

Message-ID: <000a01ca7d51$44bb50b0$1f011...@china.huawei.com>

Content-Type: text/plain; charset="us-ascii"

 

Hello Quintin, 

 

 

 

I have following comments - 

 

 

 

For Pre-computed Backup Core Tree

 

1) Is the Backup tree, the next Best core-tree [MCT or SPT]?

 

2) How path-diverse should the Backup tree be? 

 

 

 

We may need to support all re-optimization scenarios similar to P2MP

Intra-domain cases [explained in draft-ietf-pce-pcep-p2mp-extensions]. 

 

 

 

Thanks & Regards,

 

Dhruv

 

Huawei Technologies Co.,Ltd.

 

Bangalore, India

 

 

 



***

 

This e-mail and attachments contain confidential information from HUAWEI,

which is intended only for the person or entity whose address is listed

above. Any use of the information contained herein in any way (including,

but not limited to, total or partial disclosure, reproduction, or

dissemination) by persons other than the intended recipient's) is

prohibited. If you receive this e-mail in error, please notify the sender by

phone or email immediately and delete it!

 

 

 

 

On Dec 14, 2009, at 10:15 PM, Quintin Zhao wrote:

 

> 

> Hello PCE'rs,

> 

> I would like to follow-up on some discussions from our PCE WG  

> session last

> month. Specifically regarding Dajiang's failure and recomputation

> observations on our draft. We are very interested to hear comments  

> regarding

> the need for computing secondary paths in the event of failure.  

> Currently

> our thinking is to recompute the sub-tree based in the domain where  

> the

> failure has occurred. In this case we would not need to perform a

> recalculation of the entire tree. We could also recompute the entire  

> tree,

> and avoid the failed areas, as long as the TED has the updated  

> topology.

> Realistically one might have a backup core tree pre-computed so you  

> can

> switch over in the event of failure. There are also other  

> considerations.

> Would a partial recomputation provide a "worse" SPT or MCT tree, or  

> would a

> full tree recomputation provide a "better" SPT or MCT? I can think of

> scenarios for both a partial and full recomputation, so perhaps we  

> need to

> implement both but allow the PCC to decide when to issue a partial  

> or full

> recomputation based on some criterion.

> 

> Thanks,

> 

> Quintin

> 

> ___

> 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] Inter-domain-p2mp-procedures

[Quintin Zhao]

Hello PCE'rs, 

I would like to follow-up on some discussions from our PCE WG session last
month. Specifically regarding Dajiang's failure and recomputation
observations on our draft. We are very interested to hear comments regarding
the need for computing secondary paths in the event of failure. Currently
our thinking is to recompute the sub-tree based in the domain where the
failure has occurred. In this case we would not need to perform a
recalculation of the entire tree. We could also recompute the entire tree,
and avoid the failed areas, as long as the TED has the updated topology.
Realistically one might have a backup core tree pre-computed so you can
switch over in the event of failure. There are also other considerations.
Would a partial recomputation provide a "worse" SPT or MCT tree, or would a
full tree recomputation provide a "better" SPT or MCT? I can think of
scenarios for both a partial and full recomputation, so perhaps we need to
implement both but allow the PCC to decide when to issue a partial or full
recomputation based on some criterion.   

Thanks, 

Quintin 

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

[Pce] Adopting draft-yasukawa-pce-vpn-req-05.txt as a new WG document ?

[Quintin Zhao]

I am in favor to adopt it as a PCE WG document.

Quintin Zhao



--

Message: 1
Date: Sun, 1 Mar 2009 20:27:39 +0100
From: JP Vasseur 
Subject: [Pce] Adopting draft-yasukawa-pce-vpn-req-05.txt as a new WG
document ?
To: pce@ietf.org
Message-ID: <451ea112-7fc7-45ef-8755-c2d656a4d...@cisco.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

Dear WG,

draft-yasukawa-pce-vpn-req-05.txt has been "presented" several times  
during WG meetings and has been smoothy progressing.

Would you be in favor/opposed to adopt it as a PCE WG document ?

Thanks.

JP.


--

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


End of Pce Digest, Vol 55, Issue 1
**


***

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

Re: [Pce] Comment on draft-ietf-pce-pcep-p2mp-extensions

[Quintin Zhao]

Nic and Adrian,

Thanks for your suggestions!
 
By using the existing SVEC functionality, PCC can request the secondary P2MP
LSP path computation to protect the whole P2MP path tree by specifying the
S/N/L bit in the SVEC object. 

If we understand the new requirements you suggested for S2L sub-path
diversity, you want the PCC to be able to ask the PCE to compute secondary
P2MP path tree with partial path diversity for certain leaves or certain S2L
sub-path. 

We will address these new requirements in our next version of the draft.
 
Quintin

-Original Message-
From: Adrian Farrel [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 19, 2008 3:49 PM
To: Nic Neate; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; pce@ietf.org; [EMAIL PROTECTED]
Subject: Re: [Pce] Comment on draft-ietf-pce-pcep-p2mp-extensions

Ah, that is an interesting and valid point, Nic.

And I think one might also consider "directional diversity" for your ring 
example.

A
- Original Message - 
From: "Nic Neate" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; ; 
<[EMAIL PROTECTED]>
Sent: Wednesday, November 19, 2008 8:28 PM
Subject: [Pce] Comment on draft-ietf-pce-pcep-p2mp-extensions


Hi,

I have a suggestion for a small extension to the PCEP P2MP draft.

I believe the base PCEP specification currently has three options for 
calculating diverse protection paths: link diverse, node diverse and SRLG 
diverse (draft-ietf-pce-pcep section 7.13.2).

In P2MP, S2L sub-path diverse is another important case.  I think it would 
be good to allow the PCC to request computation of S2L sub-path diverse 
protection paths.

This is useful when doing 1+1 protection in a ring topology, for example.

Nic








> ___
> 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] new version of draft-ietf-pce-pcep-p2mp-extensions

[Quintin Zhao]

Hi all,

We made an update for this draft. The main update in this new version is
based on the new requirement specified in section 2.1.7 of
draft-ietf-pce-p2mp-req-00.txt. 

The requirement is: 

A single P2MP LSP may have very many destinations, and the computed path
(tree) may be very extensive. In these cases it is possible that the entire
Path Computation Request or Response cannot fit within one PCE message.
Therefore, it MUST be possible for a single request or response to be
conveyed by a sequence of PCE messages.

In this new version of the draft, we propose to use SVEC/synctimer mechanism
both for PCReq message and PCRep message in case of too large P2MP Path
Computation Request or Response. 


Thanks,
Quintin
 

> 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  : Extensions to the Path Computation  Element Communication
Protocol
> (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths
> Author(s) : Q. Zhao, D. King, F. Verhaeghe, T. Takeda, M. Chaitou, J. Le
Roux,
> Z. Ali
> Filename : draft-ietf-pce-pcep-p2mp-extensions-01.txt
> Pages  : 29
> Date  : 2008-11-3
> 
> Point-to-point Multiprotocol Label Switching (MPLS) and Generalized
MPLS
> (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may
>be established using signaling techniques, but their paths may first
>be determined.  The Path Computation Element (PCE) has been
>identified as an appropriate technology for the determination of the
>paths of P2MP TE LSPs.
> 
>This document describes extensions to the PCE communication Protocol
>(PCEP) to handle requests and responses for the computation of paths
>for P2MP TE LSPs.
> 
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-p2mp-extensions-01.t
xt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> ___
> 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] Poll on further WG I-Ds

[Quintin Zhao]

Hi all, 

I would like to support all three documents as WG I-Ds. 

Regards,
Quintin


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian
Farrel
Sent: 11 August 2008 12:40
To: pce@ietf.org
Subject: [Pce] Poll on further WG I-Ds

Hi,

Following up some actions from Dublin...

Can you please express an opinion on whether the following thress I-Ds are
ready to 
be /should be adopted as PCE working group I-Ds.

draft-zhao-pcep-p2mp-extension
draft-otani-pce-gmpls-aps-req
draft-nishioka-pce-svec-list

Thanks,
Adrian
___
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] Quick Poll on PCE Rechartering

[Quintin Zhao]

Yes.

Quintin

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of JP
Vasseur

Dear WG,

We discussed about our rechartering during the PCE WG yesterday and
there
was a large consensus for including P2MP (requirements and PCEP protocol
extensions). It is at this point pre-mature to include further items but
the
discussion should continue on the ML.

Before finalizing the new proposed charter, we wanted to first confirm
the
consensus on the mailing list.

In support ?

Thanks.

JP.


--

___
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