[Pce] New draft: draft-zhang-pce-reqs-for-tdm-00

[Fatai Zhang]

Dear all,

A new draft was just uploaded: draft-zhang-pce-reqs-for-tdm-00.

The following is the abstract of this new ID.

Please take a look at the attached document for details.

Any comments are welcome.




Abstract:

This document describes the special requirements for applying the Path 
Computation Element (PCE) in Time-Division Multiplexing (TDM) 
networks, including Synchronous Optical Network (SONET), Synchronous Digital 
Hierarchy (SDH), and Digital Wrapper (G.709 ODUk). 

The material presented in this document is collected here for analysis. The 
intention is to separate this material into separate documents on generic GMPLS 
requirements, generic GMPLS extensions, and TDM-specific requirements and 
extensions. 
==



Thanks
 
Fatai
 
Advanced Technology Department
Wireline Networking Business Unit
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935
Network work group   Fatai Zhang
Internet DraftDan Li 
Intended status: Informational   Jianhua Gao   
Expires: September 2009   Huawei 
  March 02, 2009 


  Requirements for PCE applied  
  in Time-Division Multiplexing (TDM) Networks 
 
draft-zhang-pce-reqs-for-tdm-00.txt 


Status of this Memo 

   This Internet-Draft is submitted to IETF in full conformance with   
   the provisions of BCP 78 and BCP 79. 

   Internet-Drafts are working documents of the Internet Engineering   
   Task Force (IETF), its areas, and its working groups.  Note that   
   other groups may also distribute working documents as Internet-   
   Drafts. 

   Internet-Drafts are draft documents valid for a maximum of six months   
   and may be updated, replaced, or obsoleted by other documents at any   
   time.  It is inappropriate to use Internet-Drafts as reference   
   material or to cite them other than as work in progress. 

   The list of current Internet-Drafts can be accessed at   
   http://www.ietf.org/ietf/1id-abstracts.txt. 

   The list of Internet-Draft Shadow Directories can be accessed at   
   http://www.ietf.org/shadow.html. 

   This Internet-Draft will expire on September 02, 2009. 

Abstract 

   This document describes the special requirements for applying the 
   Path Computation Element (PCE) in Time-Division Multiplexing (TDM) 
   networks, including Synchronous Optical Network (SONET), Synchronous 
   Digital Hierarchy (SDH), and Digital Wrapper (G.709 ODUk). 

   The material presented in this document is collected here 
   for analysis. The intention is to separate this material into 
   separate documents on generic GMPLS requirements, generic 
   GMPLS extensions, and TDM-specific requirements and extensions. 


 
 
 
Zhang  Expires September 2009 [Page 1] 

Internet-Draft   draft-zhang-PCE-reqs-for-TDM-00.txtMarch 2009 


Conventions used in this document 

   The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, 
   SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this 
   document are to be interpreted as described in [RFC2119]. 

Table of Contents 


   1. Introduction..2 
  1.1. Disposition of this Document.3 
   2. Terminology...4 
   3. PCE Applications..4 
   4. Requirements..5 
  4.1. Requirements when PCC Specifies the Connection Type..5 
  4.2. Requirements when PCE Determines the Connection Type.6 
   5. Security Considerations...7 
   6. IANA Considerations...7 
   7. Acknowledgments...7 
   8. References7 
   9. Authors' Addresses8 
 
 
1. Introduction 

   As defined in [RFC4655], a Path Computation Element (PCE) is an 
   entity that is capable of computing a network path or route based on 
   a network graph, and of applying computational constraints during the 
   computation. Any node in the network can act as a Path Computation 
   Client (PCC) and request PCE to compute a path that satisfies the set 
   of constraints. When it finishes computing, the PCE will respond with 
   the path to the PCC. The communication protocol between PCE and PCC

[Pce] Discussions on PCE requirements for GMPLS

[Fatai Zhang]

Hi PCEers

We have a draft (draft-zhang-pce-reqs-for-tdm-00.txt) in the process. This 
draft describes some requirements for applying Path Computation Element (PCE) 
in Time-Division Multiplexing (TDM) networks. 

I think GMPLS-based TDM networks can be regarded as sub-set of GMPLS networks 
(for example, GMPLS-based SDH networks), so the requirements described in this 
draft (PCE for TDM) are sub-set of the requirments for PCE applied in GMPLS 
networks.

Therefore, It seems that there may be something overlapped with another draft 
(draft-ietf-pce-gmpls-aps-req-00.txt), but there is no discription on these 
requirements in draft-ietf-pce-gmpls-aps-req-00.txt.
 
In addition, I think it is not a good solution to keep PCE requirements for  
GMPLS in a few separate documents, so I think it is natural to incorporate the 
requirements into draft-ietf-pce-gmpls-aps-req-00.txt.

Any comments or suggestions are welcome and helpful.



Thanks

Fatai
 
Advanced Technology Department
Wireline Networking Business Unit
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935

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

Re: [Pce] New draft: draft-margaria-pce-gmpls-pcep-extensions-00

[Fatai Zhang]

Hi Cyril,

Thanks for your valuable comments. Please see the in-line response.



Thanks
 
Fatai
 
Advanced Technology Department
Wireline Networking Business Unit
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935



- Original Message - 
From: Margaria, Cyril (NSN - DE/Munich) cyril.marga...@nsn.com
To: ext Fatai Zhang zhangfa...@huawei.com
Cc: pce@ietf.org; sures...@huawei.com
Sent: Thursday, January 07, 2010 9:09 PM
Subject: RE: [Pce] New draft: draft-margaria-pce-gmpls-pcep-extensions-00



Hi Fatai, 

I am also happy to see work going in this direction. 
I have some questions and remarks on your draft.

Section 4.1. RP Object Extension
The NT field is specifying for which kind of network the request is. 
I think the information on the type on network could also be represented by 
SWITCH-LAYER object from draft-ietf-pce-inter-layer-ext.
This information seems also redundant with the encoding and switching type 
provided in the 4.1.1. Requested GMPLS Label Information.
Its also not clear to me what is the processing of this field, especially in 
the case of multilayer network type.

[Fatai]: Agree with you. We can just identify network type (e.g., SDH or 
WDM...) through Switching Type.
 
Regarding 4.1.1. Requested GMPLS Label Information, its stated that this 
object is used if the resources required are requested using generalized label. 
Is this to be used in a PCReq or PCRep? To which generalized labels does this 
subtlv-refers to, I can see label in the ERO and the other route object, but 
those may represent a multi-layer route, where the generalized labels might 
have different encodings. Which labels are meant here?

[Fatai]: It is used in PCReq and it refers to SDH layer.

in case a multilayer request is considered and a generalied label is used, the 
PCEP may carry labels for several layers, so only considering the first 
Requested GMPLS Label Information  subtlv may not be sufficient, on the other 
hand its 

[Fatai]: We have not considered multi-layered scenario. If Mutli-layer should 
be considered, we can re-use the extensions defined in [PCE-MLN-Ext].

For the Qos section, the section 4.4.1 does not allow different forward/reverse 
Traffic spec as in RFC5467, and its not clear how to distnguish the old QoS 
from the new Qos in case of reoptimization requests.

[Fatai]: Our draft is for SDH networks. We know usually there is no this case 
for asymmetric bandwidth bidirectional LSP in SDH networks(i.e., bidirectional 
LSP is considered with same QoS on both directions). Of cource, if we need to 
cover the requirements in RFC5467, I think we can just add [Upstream-Bandwidth] 
to identify asymmetric bandwidth. Reoptimization is already captured in RFC5440.

In 4.4.2. LSP Protection Information TLV, I think reusing the RFC4872 and 
RFC3471 LSP flags and Link flags would be more in line with RSVP-TE signaling. 
In this section its not clear on how to use the Protection information, some 
fields seems to go in the direction of a statefull PCE (Segment Recovery, 
Associated LSP ID), however its not clear how those fields are to be used and 
processed, for instance the associated LSP id can be used only if the LSP ids 
are known to the PCE.

[Fatai]: We can reference the protection object defined in RFC4872 or RFC4873, 
but we can not simply copy the object defined in RFC4872 or RFC4873 (i.e., some 
fields should be removed and add some new fields additionally). We will check 
the object again and remove Associated LSP ID.

I am looking forward to discuss those two draft with you.

Thanks, 
Cyril Margaria 



 - Original Message - 
 From: ext Fatai Zhang [mailto:zhangfa...@huawei.com] 
 Sent: Wednesday, January 06, 2010 2:34 AM
 To: Margaria, Cyril (NSN - DE/Munich)
 Cc: pce@ietf.org; sures...@huawei.com
 Subject: Re: [Pce] New draft: draft-margaria-pce-gmpls-pcep-extensions-00


 Hi Cyril,
 
 What a coincidence to see your draft after we just submited our draft 
 (draft-zhang-pce-pcep-extensions-for-sdh-00.txt) [draft-zhang-pcep-ext].
 
 Great minds think alike.  Happy to see that happened.
 
 Hope you can spare some time to review [draft-zhang-pcep-ext]. We are looking 
 forward to discussing more with you.
 
 We also invite all the experts from PCE WG to review  [draft-zhang-pcep-ext].
  
  
 
 Thanks
  
 Fatai
  
 Advanced Technology Department
 Wireline Networking Business Unit
 Huawei Technologies Co., LTD.
 Huawei Base, Bantian, Longgang,
 Shenzhen 518129 P.R.China
 Tel: +86-755-28972912
 Fax: +86-755-28972935
 
 
 
  - Original Message - 
  From: Margaria, Cyril (NSN - DE/Munich) cyril.marga...@nsn.com
  To: pce@ietf.org
  Sent: Tuesday, January 05, 2010 5:44 PM
  Subject: [Pce] New draft: draft-margaria-pce-gmpls-pcep-extensions-00
  
  
  
  Dear PCEers,
  
  We have just submitted a new drat on PCEP extensions for GMPLS. 
  The draft specifies optional extensions to the PCEP

[Pce] discussion on draft-zhang-pce-pcep-extensions-for-gmpls

[Fatai Zhang]

Hi PCEers,

To respond to the call from JP, I trigger this discussion and hope you can 
review this draft and give your comments or suggestions.

Note that this draft (draft-zhang-pce-pcep-extensions-for-gmpls) is used to 
replace another draft (draft-zhang-pce-pcep-extensions-for-sdh), which was 
discussed in the mailing list about two months ago.





Thanks
 
Fatai
 
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935



- Original Message - 
From: JP Vasseur jvass...@cisco.com
To: pce@ietf.org
Sent: Friday, March 05, 2010 6:57 PM
Subject: [Pce] Please discuss new ID on the mailing list


 Dear all,
 
 We have a number of new -00 ID posted, and would like to encourage you  
 to start polling the WG on the potential interest rather than just  
 posting and request a time slot at the next IETF meeting.
 
 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] I-D Action:draft-ietf-pce-gmpls-aps-req-02.txt

[Fatai Zhang]

Hi All,

We just submitted an updated version of this draft:

http://www.ietf.org/id/draft-ietf-pce-gmpls-aps-req-02.txt

The major updates are as follows:
(1) Added Section 3.3 to address unnumbered endpoints
(2) Added Section 3.4 to address Asymmetric Bandwidth Path Computation
(3) Updated Section 4.1 to extend switching capability to cover DCSC, PBB-TE 
and added two items for supportting unnumbered interfaces and asymmetric 
bandwidth path computation.



Best Regards
 
Fatai
 
- Original Message - 
From: internet-dra...@ietf.org
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Sent: Tuesday, July 06, 2010 3:45 PM
Subject: [Pce] I-D Action:draft-ietf-pce-gmpls-aps-req-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Path Computation Element Working Group of 
 the IETF.
 
 
 Title   : Document: draft-ietf-pce-gmpls-aps-req-02.txt
 Author(s)   : T. Otani, et al.
 Filename: draft-ietf-pce-gmpls-aps-req-02.txt
 Pages   : 11
 Date: 2010-07-06
 
 The initial effort of PCE WG is specifically focused on MPLS (Multi-
 protocol label switching). As a next step, this draft describes 
 functional requirements for GMPLS (Generalized MPLS) application of 
 PCE (Path computation element).
 
 A URL for this Internet-Draft is:
 http://www.ietf.org/internet-drafts/draft-ietf-pce-gmpls-aps-req-02.txt
 
 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] Adopting draft-king-pce-inter-area-as-applicability-02.txt as a PCE WG document

[Fatai Zhang]

Yes/Support.




Best Regards
 
Fatai
 
  - Original Message - 
  From: Giovanni Martinelli 
  To: JP Vasseur 
  Cc: olivier.dug...@orange-ftgroup.com ; pce@ietf.org ; Quintin Zhao 
  Sent: Saturday, October 16, 2010 3:23 PM
  Subject: Re: [Pce] Adopting draft-king-pce-inter-area-as-applicability-02.txt 
as a PCE WG document


  Support.

  Cheers
  G

  On 10/12/10 9:50 PM, JP Vasseur wrote: 
Thanks Dan for this new revision. Major progress, thanks, this is part of 
our milstones, good to see 
some progress. Even if there is lot of work to do on this ID, this is 
probably a good time to poll the 
WG to adopt it as the base document for inter-area-as applicability.


All, are you in favor/opposed in adopting 
draft-king-pce-inter-area-as-applicability-02.txt as a PCE Wg
document ?


Thanks.


JP.


Begin forwarded message:


  From: Daniel King dan...@olddog.co.uk

  Date: October 11, 2010 11:28:10 PM GMT+02:00

  To: pce@ietf.org

  Cc: olivier.dug...@orange-ftgroup.com, f...@tid.es, qz...@huawei.com

  Subject: [Pce] I-D 
Action:draft-king-pce-inter-area-as-applicability-02.txt



  Hi PCE'rs, 

  Please find a new version of our pce-inter-area-as-applicability draft: 

  http://www.ietf.org/id/draft-king-pce-inter-area-as-applicability-02.txt

  This document examines the applicability of the PCE architecture, 
protocols,
  and protocol extensions for computing multi-area and multi-AS paths in 
MPLS
  and GMPLS networks.

  This revision combines the addition of new co-authors and various updates
  including:

  - Discussion on domain meshes. 
  - Discussion on route diversity. 
  - Discussion on synchronized path computations. 
  - Minor readability updates. 
  - Minor grammar and nit fixes.

  The document is not complete and will require further revisions. It is
  however a good platform to build upon and as always we seek WG feedback 
and
  suggestions.

  See you in Beijing!

  Br, Dan

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




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


--


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

Re: [Pce] LABEL-SET as object and TLV in pcep-extensions-01

[Fatai Zhang]

Hi Ramon and Christian,

I agree with Ramon that we should refine the description on the Label format  
(Lebel,Label_Set, Suggested_Label)  based on the different cases  in PCReq and 
PCRep messages (e.g. Endpoints, E2E constraint, ERO, SVEC).



Thanks
 
Fatai
 
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935

- Original Message - 
From: Ramon Casellas ramon.casel...@cttc.es
To: pce@ietf.org
Sent: Thursday, January 27, 2011 10:46 PM
Subject: Re: [Pce] LABEL-SET as object and TLV in pcep-extensions-01


Dear Christian, PCErs

Thank you for your comments, this is indeed one of the open issues in 
the draft. Please see inline for some of my views.



On 26/01/2011 20:46, christian.kaas-peter...@tieto.com wrote:

 Reading the draft-ietf-pce-gmpls-pcep-extensions-01 document, the definition
 and use of LABEL-REQUEST, LABEL-SET, and SUGGESTED-LABEL-SET need further
 clarification.


We have had some discussions about this in the past, and I am afraid we 
still don't have a consensus. The main problem with the LABEL_SET object 
(and to some extent with SUGGESTED_LABEL and UPSTREAM_LABEL) is that the 
semantics are slightly different depending of the context. Let me 
explain, and apologies if this is well-known,
it is clear that in MPLS-TE (or GMPLS PSC, etc) labels are, by 
definition, local to a link between two nodes. A LABEL_SET defines which 
labels are usable in that scope. However, when deploying GMPLS for WSON 
(and other swcap such as PBB-TE) there are technological constraints 
such as the Wavelength Continuity Constraint. With this in mind, the 
LABEL_SET in WSON has been abused to imply which labels are usable end 
to end. (e.g. the LABELSET includes which labels are usable and it is 
trimmed by nodes along the path, or re-expanded when a regenerator / 
converter is used. Lack of LABELSET is typically assumed as a failure to 
find continuous wavelengths. However, in MPLS lack of LABEL_SET implies 
that any label is ok).

Since the GMPLS extensions need to apply at all layers, we have 
seemingly opposite concepts: on the one hand, MPLS defines a label as 
local to a link representing a FEC, WSON a label is implicitly a 
wavelength, end-to-end within a transparent segment without converters. 
Things can get much worse :) when considering translucent networks where 
the label has to remain constant along one or more transparent segments. 
If we assume that, regardless of how it is encoded (TLV, top level 
object, etc) , in a PCEP request the LABEL_SET is supposed to convey 
constraints in the path computation, and in a PCEP response it is 
supposed to convey attributes, without knowledge of the swcap the 
request applies to, or with extra assumptions, it is not possible to 
know what the constraints apply to.


 LABEL-SET as an object is specified in section 2.5, but half-way
 through the section, LABEL-SET is referred to as a TLV appearing in the
 ERO object (and so LABEL-SET is a TLV of an RSVP object).  Further

In my opinion, this is indeed a problem with the draft in its current 
form, but I haven't yet reported to Editors about this. I am unsure how 
a variable sized object such as the ERO can include TLVs. At what point 
does the parser stop parsing subobjects to start parsing TLVs?, the 
first TLV would be wrongly parsed as a (possibly unknown) sub-object. 
The intended use as I suggested then was as RSVP ERO sub-object, not as 
TLV.

FWIW, I am a proponent of LABEL_SET as top level object, also  ENDPOINTS 
TLV since we need to convey info say.e.g about tunability of an 
interface, and, additionally, as a new ERO subobject.

 In a PCReq, LABEL-SET can appear both as a PCEP object in its own right, and 
 as
 a PCEP TLV in the END-POINTS object, when the END-POINTS object is the new
 Generalized endpoint Object Type.  It is not clear to me, what difference
 it makes to the semantics of the PCReq, whether LABEL-SET appears as
 an object, as a TLV in END-POINTS, or indeed can appear in both places.


As you point out, there is still a lot of work to do in this area. My 
(subjective) view is as follows:

Request

a) - a LABEL_SET within ENDPOINTS (as TLV) applies at that endpoint and 
swcap and constraints the endpoint. The direct use case would be 
transceiver tunability

b) - a LABEL_SET within a request (not exactly within a PCReq, although 
people commonly refer to objects within a PCReq) was defined to cover 
the case of the labels that apply to the end-to-end path and only 
consider these labels for wavelenght allocation

c) - a LABEL_SET within a SVEC tuple could (To be done, for further 
study) convey constraints that apply to all involved requests, in line 
with previous bullet.


Response

d) - a LABEL_SET as a new ERO sub-object  (not as TLV) as I suggested 
would be the only meaningful way that a PCE could restrain the use of a 
set of labels in a link along the path. RSVP-TE could easily generate 

Re: [Pce] VENDOR-CONSTRAINT

[Fatai Zhang]

Hi Christian,

Thanks for your comments.

Could you explain a little more about what are requirements for the 
VENOR-CONSTRAINT TLV? 
Why VENOR-CONSTRAINT object can not meet these requirements? 
How many (and which) objects should be extended to include VENOR-CONSTRAINT TLV?



Thanks
 
Fatai
 
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935

  - Original Message - 
  From: christian.kaas-peter...@tieto.com 
  To: pce@ietf.org 
  Sent: Monday, May 09, 2011 2:26 PM
  Subject: [Pce] VENDOR-CONSTRAINT


  draft-ietf-pce-vendor-constraints-04 describes a new VENDOR-CONSTRAINT 
object.  I should like the draft also to introduce a VENDOR-CONSTRAINT TLV 
allowing vendor specific additions to for example the END-POINTS object.

  Christian


--


  ___
  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] VENDOR-CONSTRAINT

[Fatai Zhang]

Hi Christian,

You said If only the VENDOR-CONSTRAINT object is possible, it is necessary 
somewhere in the VENDOR-CONSTRAINT object to give additional information, so 
that it is possible to correlate the contents of the VENDOR-CONSTRAINT object 
with other objects in the message.

I don't think that it needs any additional information if only the 
VENDOR-CONSTRAINT object is used. You can look at the description for 
Enterprise-Specific Information:

===   
Enterprise-Specific Information

The detailed enterprise-specific constraint information carried by the object. 
The format and interpretation of this information is a matter for the 
enterprise identified by the Enterprise Number. Such formats and interpretation 
MAY be published by the enterprise (possibly through an informational RFC or 
through commercial documentation) so that PCCs or PCEs that are not part of the 
organization can use the information.
==

By using only the VENDOR-CONSTRAINT object, I think it can keep the PCEP 
protocol much simple without touching so many different existing objects.

Hope this can clarify your concern.


Thanks
 
Fatai
 
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935

- Original Message - 
From: christian.kaas-peter...@tieto.com
To: zhangfa...@huawei.com; pce@ietf.org
Sent: Wednesday, May 11, 2011 2:53 PM
Subject: RE: [Pce] VENDOR-CONSTRAINT


Certainly.

The VENDOR-CONSTRAINT TLV could be formatted this way (similar to
the VENDOR-CONSTRAINT object)

  0   1   2   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type|  Length |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Enterprise Number   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~ Enterprise-Specific Information   ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If only the VENDOR-CONSTRAINT object is possible, it is necessary somewhere
in the VENDOR-CONSTRAINT object to give additional information, so that
it is possible to correlate the contents of the VENDOR-CONSTRAINT object
with other objects in the message.  By having a VENDOR-CONSTRAINT TLV,
that TLV can be directly added to the object for which such additional
information is wanted.

Examples of use of VENDOR-CONSTRAINT TLV are as follows.
 * in PCNtf messages for vendor specific additions;
 * in END-POINTS object, specifically the Generalized Endpoints object type,
   with vendor specific additions
The addition of a VENDOR-CONSTRAINT TLV would free me from picking an
unused value for the Type.  The type I have picked is currently unused, 
but may be assigned in the near future, and then follows the general problem 
of updating not just future software (which is simple),
but also existing software already delivered to customers (which is not so
simple).

Christian



From: Fatai Zhang [zhangfa...@huawei.com]
Sent: Wednesday, May 11, 2011 05:14
To: Kaas-Petersen Christian; pce@ietf.org
Subject: Re: [Pce] VENDOR-CONSTRAINT

Hi Christian,

Thanks for your comments.

Could you explain a little more about what are requirements for the 
VENOR-CONSTRAINT TLV?
Why VENOR-CONSTRAINT object can not meet these requirements?
How many (and which) objects should be extended to include VENOR-CONSTRAINT TLV?



Thanks

Fatai

Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935
- Original Message -
From: 
christian.kaas-peter...@tieto.commailto:christian.kaas-peter...@tieto.com
To: pce@ietf.orgmailto:pce@ietf.org
Sent: Monday, May 09, 2011 2:26 PM
Subject: [Pce] VENDOR-CONSTRAINT

draft-ietf-pce-vendor-constraints-04 describes a new VENDOR-CONSTRAINT object.  
I should like the draft also to introduce a VENDOR-CONSTRAINT TLV allowing 
vendor specific additions to for example the END-POINTS object.

Christian



___
Pce mailing list
Pce@ietf.orgmailto: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] VENDOR-CONSTRAINT

[Fatai Zhang]

Hi Ramon,

If I understand you correctly, do you meant that you prefer only the 
VENDOR-CONSTRAINT object to one extra TLV?




Thanks
 
Fatai
 
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935

  - Original Message - 
  From: Ramon Casellas 
  To: pce@ietf.org 
  Sent: Wednesday, May 11, 2011 8:32 PM
  Subject: Re: [Pce] VENDOR-CONSTRAINT


  Cyril, all, 


  First, speaking from a personal point of view, I would say that I am not a 
big fan of VENDOR_X extensions. I would rather like to see those constraints / 
TLVs etc. open for standardization. 

  Having vendor extensions will indeed limit interoperability, e.g. having a 
VENDOR_CONTRAINT object with the P-bit set basically means that only that 
vendor (and associated partners) can do path computation for that request ?. 
This is analogue to having the whole PCEP interface as proprietary defeating 
the standardization purpose.

  It may be argued that a TLV may provide finer granularity to qualify a given 
object, rather than some more generic, packed object, but as long as the 
contents are opaque I worry that the default ignore TLV action would not be 
respecting the PCC constraints.

  sarcastic Finally, if there is an VENDOR_CONSTRAINT object, 
VENDOR_CONSTRAINT_TLV why not a VENDOR_ message? :) /sarcastic


  For the rest of the mail, please see inline


  On 11/05/2011 12:44, Margaria, Cyril (NSN - DE/Munich) wrote: 


Hi Fatai, Christian, PCE-ers, 



I think that having one extra TLV is usefull  when you want to add 
object-specific vendor constraints and not general one, the information carried 
will remain the same but in another place and more accessible.


  In this sense, it is unfortunate that not all objects are potentially TLV 
containers, (e.g. we had to define GENERALIZED_BANDWIDTH due to this) so only 
objects that are actually defined by RFC5440 as containers could have vendor 
extensions as TLVs. There is no way to add a VENDOR TLV to the bandwidth 
object, for example





Having a generic vendor specific object seems a catch-all solution that is 
likely to  include any vendor private information and might  leave too much 
room for private information.

  Agreed.




Another possible angle to carry vendor-specific constraint is not to have a 
generic object but rather a set of very specifically scoped TLVs or sub-objects.



  To some extent, yes, but then we shift the problem elsewhere. First, I am not 
sure if the standard way to proceed when a proprietary (unknown) TLV is found 
in an object (RFC 5440 $7.1,  Unrecognized TLVs MUST be ignored) would be the 
best thing to do. 
  Without that vendor-specific information I am not sure if the resulting path 
is ignoring some MUST-USE TLV. However, at least, I know what object is 
extended with vendor information by virtue of being a TLV of that object.




This can be applied to the PCEP as follow :

-  Objective function : private OF code is already defined, an 
private_of_parameter_tlv (only valid inside the OF object) would carry possible 
operator-specific parameters

-  Metric : a private metric type can be defined, with vendors 
specific body and metric value.

  Being nitpicking here .-) , but contrary to OF, metric types are assigned by 
IETF review process. Nothing precludes defining a private range but afaik it is 
not the case now.


-  For GMPLS endpoint constraint a TLV for vendor-private label 
constraint (valid for endpoints and label_set only for instance) can be defined.

-  For WSON-specifics this is for example covered in 
draft-lee-pce-wson-rwa-ext-01, which reuse the private ranges encoding from 
draft-ietf-ccamp-wson-signaling-01



  I would be less against the proliferation of vendor TLVs if there is a clear 
consensus  that those TLVs are only meaningful in the context of private 
ranges as Cyril examples. In other words, if the OF object with a code in the 
range 32768- has vendor TLVs I am fine. If I can't apply that OF code I don't 
care about the TLVs, and the processing rules for OF objects are standard and 
clear. 



For sure it's possible to put all those in one object, but I am not sure 
it's the best strategy in order to avoid all private extensions.



  Honestly, thinking that discussing whether private extensions either in 
objects or in TLVs would lead us to a best strategy in order to avoid private 
extensions seems weird :-) 

  That said, less of two evils?  the TLVs seem more granular, provide some 
information of what object they qualify, the processing rules are clear leading 
to ignore the TLV, (it is important to note that I understand that an object 
that a PCE can process with P-bit set but with unknown TLVs does not imply 
the request being rejected) but not all object support TLVs.


  Best regards
  Ramon 

Re: [Pce] VENDOR-CONSTRAINT

[Fatai Zhang]

Hi Ramon,

OK, thanks a lot.

Any more opinions from the WG?





Thanks
 
Fatai
 
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935

  - Original Message - 
  From: Ramon Casellas 
  To: Fatai Zhang ; pce@ietf.org 
  Sent: Wednesday, May 25, 2011 1:15 PM
  Subject: Re: [Pce] VENDOR-CONSTRAINT


  El 25/05/2011 4:22, Fatai Zhang escribió: 
Hi Ramon,

If I understand you correctly, do you meant that you prefer only the 
VENDOR-CONSTRAINT object to one extra TLV?


  Hello Fatai, all,

  I'm afraid not (sorry for not having expressed myself  clearly). In the case 
of vendor constraints, I think, without a strong opinion, that I would rather 
have vendor-specific TLVs that apply to a given object, rather than a top-level 
object. The reasons for this are:

  * It seems more granular and clearly identifies which object is constrained. 
Seems less opaque :)

  * The default behavior as current RFC is to ignore the TLV if not 
known/supported. This may require a flags field within the TLV to specify that 
the constrain was indeed processed.

  A good question is whether a single TLV vendor_tlv would do, or there is a 
reason to have more grained tlvs 

  There are some drawbacks of course:
  * There are objects that were defined without TLVs. With a strict 
interpretation of rfc 5440, it would not be possible to constrain such objects.

  * The constraint (semantics) involved in the TLV has to somehow relate to the 
object it is attached to. If there is no such object, the use of TLVs seems 
less flexible and an object would be needed.

  In short, there seem to be use cases for both. Preferably, use vendor tlvs. 

  Thank you and best regards
  R. 
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] request timeslot for draft-wang-pce-inter-as-extentions-01

[Fatai Zhang]

Hi all,

RFC5392 is a kind of mechamism and it is already there.

Why we need to define another solution based on some nonexistent assumption?







Fatai

Thanks
  - Original Message - 
  From: JP Vasseur 
  To: fu.xi...@zte.com.cn 
  Cc: pce-boun...@ietf.org ; pce@ietf.org ; 王磊 
  Sent: Tuesday, July 26, 2011 1:20 AM
  Subject: Re: [Pce] request timeslot for draft-wang-pce-inter-as-extentions-01


  Hi,


  On Jul 25, 2011, at 11:16 AM, fu.xi...@zte.com.cn wrote:



Hi JP, 

IMO, we don't need two methods. The method of extending IGP may impact on 
large aspect. 
Extending BRPC and PCEP defined in this draft is enough. 




  So let the WG decide which one of the methods is most appropriate


  Thanks.


  JP.


Thanks, 

Xihua 


  JP Vasseur j...@cisco.com 
  发件人:  pce-boun...@ietf.org
  2011-07-25 下午 08:30 
 收件人 王磊 hechen0...@gmail.com  
抄送 pce@ietf.org  
主题 Re: [Pce] request timeslot for 
draft-wang-pce-inter-as-extentions-01 



 



Thanks for your feed-back. It would be interesting to hear from the WG if 
indeed 
we need two methods. To each specific problem we can certainly find a 
number 
of way to solve it, but let's try to make sure that we do not specify a new 
technique 
if we can use what exist today. 

WG ? 

Thanks. 

JP. 
On Jul 25, 2011, at 12:25 AM, 王磊 wrote: 

Hi, Xuerong and PCEers

I have read the draft. It provides an alternate method that extends
BRPC and PCEP protocol to get TE information of Inter-AS biderectional
links. In my opinion, It is useful for the smooth upgrade of existing
MPLS/GMPLS networks to support Inter-AS bidirectional path
computation, because it need not any extension or modification to the
IGP (such as OSPF and IS-IS) used in MPLS/GMPLS-enabled
routers/switches. However, the method of IGP extension is also
applicable and suitable for new network-equipments. So, I think there
is no conflict between these two metods. The draft could be used in
the scenario where the IGP extension of Inter-AS biderectional links
can not be supported.

Thanks.

Lei Wang
Tsinghua University, Beijing, China
hechen0...@gmail.com or l...@tsinghua.edu.cn
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce 

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








--


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

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

[Fatai Zhang]

Hi Julien and all,

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



Thanks

Fatai


-邮件原件-
发件人: julien.meu...@orange.com [mailto:julien.meu...@orange.com] 
发送时间: 2012年6月8日 22:42
收件人: Daniel King; Adrian Farrel; Quintin zhao; Fatai Zhang
抄送: pce@ietf.org
主题: 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

[Pce] 答复: I-D Action: draft-ietf-pce-gmpls-aps-req-06.txt

[Fatai Zhang]

Hi all,

A new version of this draft (PCEP requirements for GMPLS) has been submitted.

The authors think that this draft is ready for LC.

Changes are as follows:
(1) Label constraints for PCEP requirements have been refined in Section 4.1 
and 4.2 respectively.
(2) Some editorial refinements.

Comments are welcome.



Thanks

Fatai


-邮件原件-
发件人: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] 代表 
internet-dra...@ietf.org
发送时间: 2012年6月27日 15:27
收件人: i-d-annou...@ietf.org
抄送: pce@ietf.org
主题: [Pce] I-D Action: draft-ietf-pce-gmpls-aps-req-06.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Path Computation Element Working Group of the 
IETF.

Title   : Document:
Author(s)   : Tomohiro Otani
  Kenichi Ogaki
  Diego Caviglia
  Fatai Zhang
Filename: draft-ietf-pce-gmpls-aps-req-06.txt
Pages   : 15
Date: 2012-06-27

Abstract:
   The initial effort of PCE WG is specifically focused on MPLS (Multi-
   protocol label switching). As a next step, this draft describes
   functional requirements for GMPLS (Generalized MPLS) application of
   PCE (Path computation element).



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-aps-req

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pce-gmpls-aps-req-06

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-pce-gmpls-aps-req-06


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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] 答复: I-D Action: draft-ietf-pce-vendor-constraints-06.txt

[Fatai Zhang]

Hi all,

Nothing has been changed, just refresh the date.

Note that the issue on VENDOR-CONSTRAINT-TLV has been already resolved in 
version 05. 



Thanks

Fatai

-邮件原件-
发件人: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] 代表 
internet-dra...@ietf.org
发送时间: 2012年7月9日 13:53
收件人: i-d-annou...@ietf.org
抄送: pce@ietf.org
主题: [Pce] I-D Action: draft-ietf-pce-vendor-constraints-06.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Path Computation Element Working Group of the 
IETF.

Title   : Conveying Vendor-Specific Constraints in the Path 
Computation Element Protocol
Author(s)   : Fatai Zhang
  Adrian Farrel
  Greg Bernstein
Filename: draft-ietf-pce-vendor-constraints-06.txt
Pages   : 13
Date: 2012-07-08

Abstract:
   The Path Computation Element Protocol (PCEP) is used to convey path
   computation requests and responses between Path Computation Clients
   (PCCs) and Path Computation Elements (PCEs), and also between
   cooperating PCEs. In PCEP the path computation requests carry
   details of the constraints and objective functions that the PCC
   wishes the PCE to apply in its computation.

   The mechanisms defined for indicating objective functions include
   the capability to convey vendor-specific objective functions. This
   document defines a facility to carry vendor-specific constraints in
   PCEP.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-vendor-constraints

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pce-vendor-constraints-06

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-pce-vendor-constraints-06


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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] 答复: I-D Action: draft-ietf-pce-inter-layer-ext-07.txt

[Fatai Zhang]

Hi all,

A new version has been submitted. Only one change:

Introduce a new PCEP object (SERVER-INDICATION) to replace ERO subobject in 
Section 3.5, because one comment was raised that ERO subobject should defer to 
CCAMP extension (RSVP-TE extension).

Please review this draft for details.


Thanks

Fatai


-邮件原件-
发件人: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] 代表 
internet-dra...@ietf.org
发送时间: 2012年7月13日 16:55
收件人: i-d-annou...@ietf.org
抄送: pce@ietf.org
主题: [Pce] I-D Action: draft-ietf-pce-inter-layer-ext-07.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Path Computation Element Working Group of the 
IETF.

Title   : Extensions to the Path Computation Element 
communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering
Author(s)   : Eiji Oki
  Tomonori Takeda
  Adrian Farrel
  Fatai Zhang
Filename: draft-ietf-pce-inter-layer-ext-07.txt
Pages   : 19
Date: 2012-07-13

Abstract:
   The Path Computation Element (PCE) provides path computation
   functions in support of traffic engineering in Multiprotocol Label
   Switching (MPLS) and Generalized MPLS (GMPLS) networks.

   MPLS and GMPLS networks may be constructed from layered service
   networks. It is advantageous for overall network efficiency to
   provide end-to-end traffic engineering across multiple network layers
   through a process called inter-layer traffic engineering. PCE is a
   candidate solution for such requirements.

   The PCE communication Protocol (PCEP) is designed as a communication
   protocol between Path Computation Clients (PCCs) and PCEs. This
   document presents PCEP extensions for inter-layer traffic engineering.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-inter-layer-ext

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pce-inter-layer-ext-07

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-pce-inter-layer-ext-07


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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] 答复: 答复: I-D Action: draft-ietf-pce-inter-layer-ext-07.txt

[Fatai Zhang]

Hi Ramon,

For Q1, it could be possible to return two EROs as what you said, but my 
intention is to return two EROs like: ERO-client: A-B-C-D-E-F, and ERO-Server: 
C-a-b-c-d-e-f-D+ SERVER_INDICATION; In this way, it can reduce the overlapped 
information.

For Q2, the PCEP extension does not exert on how to signal the RSVP-TE.  This 
draft only focuses on how to return the computed path, but how to create the 
computed path through signaling is out of scope of this draft (this is reason 
of the update that is to decouple the dependency betweeen PCEP and RSVP-TE 
extention). The PCC could be either head node or NMS. For example, if PCC is 
NMS, then NMS can configure the server LSP first (and then client LSP) from the 
returned path manually or dynamically. Therefore, actually, the three 
alternatives you mentioned could be possible from implementation perspective. 
Option B is my original thought and RSVP-TE extension is described in 
[draft-zhang-ccamp-gmpls-h-lsp-mln]. Repeat again, how to create the computed 
path through signaling is out of scope of this draft.


Thanks

Fatai

发件人: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] 代表 Ramon Casellas
发送时间: 2012年7月13日 18:20
收件人: pce@ietf.org
主题: Re: [Pce] 答复: I-D Action: draft-ietf-pce-inter-layer-ext-07.txt

On 07/13/2012 11:02 AM, Fatai Zhang wrote:

Hi all,



A new version has been submitted. Only one change:



Introduce a new PCEP object (SERVER-INDICATION) to replace ERO subobject in 
Section 3.5, because one comment was raised that ERO subobject should defer to 
CCAMP extension (RSVP-TE extension).



Please review this draft for details.


Hi Fatai, authors,

Thanks for updating the draft, just a couple of questions, quoting:

PCE MAY specify the server layer path information in the ERO. In this case, the 
requested PCE replies a PCRep message that includes at least two sets of ERO 
information in the path-list, one is for the client layer path information, and 
another one is the server layer path information. When SERVER-INDICATION is 
included in a PCRep message, it indicates that the path in the ERO is the 
server layer path information.

Q1)
for clarification,  I take it that it is still possible that the SERVER layer 
part or segment can still be provided simply embedded in a single ERO that 
includes both layers, right?  i.e. a single strict ERO in a MRN/MLN and that 
the corresponding region border node is responsible for detecting the far end 
etc. In other words, the use case where a single ERO includes both client and 
server layers (in a single path) would be ok, and not against the quoted 
paragraph: The response includes only 1 ERO A B C a b c d e D E F and, 
(optionally), a second path with ERO C a b c d e D + SERVER_INDICATION. (Before 
the update, we used A B C X a b c d e X D E F to tag region changes if 
needed). I take it the new text means A PCE MAY specify both the client and 
server layers separately, in dedicated EROs. In this case... is this right?


A  --- B --- C  = D --- E -- F
  | |
   a  --  b   -- c   -- d  -- e

Q2)
Also, assume A is the higher layer LSP (A -- F) ingress node and the PCC, and 
a H-LSP / FA will be stablished when the high layer Path reaches C. Assume A 
gets the PCEP response from the PCE. The issue I have now is that how would 
RSVP-TE forward the server layer to C so it is useful? would I need to merge 
the ERO?

In summary, in my implementation either:

a) I have a multi-layer ERO, without tags or banners so each node needs to 
check if it is a region boundary node, and act accordingly-

b) I have a multi-layer ERO, tagged with the sub-object (until draft -06) X. 
That subobject tells the ERO processing node that it is a boundary node, and 
both layers are embedded in a single ERO.

c) I have e.g. two EROs, split on a per server basis : client and server. How 
do I forward these to node C? what is the benefit of splitting them?

Hopefully I have formulated my question clearly :)

Thanks and best regards
Ramon
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] 答复: 答复: 答复: I-D Action: draft-ietf-pce-inter-layer-ext-07.txt

[Fatai Zhang]

Hi Ramon,

Agree. The description needs to be refined as you suggested.
===
the SERVER-INDICATION object is mandatory if the path in the response is used 
to convey server layer information.



Thanks

Fatai

发件人: Ramon Casellas [mailto:ramon.casel...@cttc.es]
发送时间: 2012年7月16日 17:12
收件人: Fatai Zhang
抄送: pce@ietf.org
主题: Re: 答复: [Pce] 答复: I-D Action: draft-ietf-pce-inter-layer-ext-07.txt

Hi Fatai,

Thanks for the clarifications, other comments inline

On 07/16/2012 08:47 AM, Fatai Zhang wrote:
Hi Ramon,

For Q1, it could be possible to return two EROs as what you said, but my 
intention is to return two EROs like: ERO-client: A-B-C-D-E-F, and ERO-Server: 
C-a-b-c-d-e-f-D+ SERVER_INDICATION; In this way, it can reduce the overlapped 
information.

It makes sense, but,just in case I missed it, my question was more in the line 
that I would also like the option to return only *one* ERO, with elements from 
both layers. The current text seems to indicate that if there is server layer 
info (which is the case if the ERO contains elements from both layers, isn't 
it?) It is not mandated by the text to have two EROs but just one will do.



PCE MAY specify the server layer path information in the ERO. In this case, the 
requested PCE replies a PCRep message that includes at least two sets of ERO 
information in the path-list, one is for the client layer path information, and 
another one is the server layer path information. When SERVER-INDICATION is 
included in a PCRep message, it indicates that the path in the ERO is the 
server layer path information.


For Q2, the PCEP extension does not exert on how to signal the RSVP-TE.


Understood.

Additionally, I also sent two more comments to the list, but apparently they 
got lost (sorry for the duplicates if you happen to get the mail after this 
one) so I copy them here

-8-8--
Two more comments / questions. To help the discussion consider the topology 
below, and  consider a legacy (rfc5440) PCC co-located in a GMPLS controller 
of a PSC node A which belongs to a MRN (dual layer, PSC over LSC)

  [PSC PSC]
+-+ +--++--+  +-
| A   |-|   B  |[PSC, LSC]  | C|--| D
+-+ +--oo--+  +-
\+--+  +--+/
 |  L1  |--| L2   |
 +--+  +--+
  [LSC LSC]


I) Quoting the draft: When the INTER-LAYER object is absent from a PCReq 
message, the receiving PCE MUST process as though inter-layer path computation 
had been explicitly disallowed. I would like to understand the rationale for 
this, so clarification would be appreciated. why can't, say, node A, if it has 
a simple PCC get an interlayer ERO (A B  L1 L2 C D) if A does not support this 
extension? I tend to think it should be possible if B is able to detect the 
region change and establish the H-LSP, etc. Node A sends a PCReq = request with 
RP(1), ENDPOINTS(A,D), BW(1Gb/s)

In other words, if I deploy a PCE that implements pce-interlayer-ext-07 in a 
MRN with a unified control plane (single instance), the PCE cannot provide a 
strict interlayer ERO to node A if A (legacy, RFC 5440) does not include the 
interlayer object, but I am not sure why.




Another question / comment, more philosophical in nature, and  potential issue 
of backwards compatibility with draft -07:
In short, I am unsure of encoding parts or segments in one of the paths in 
the pathlist of the response. If we look at RFC5440

If the path computation request can be satisfied (i.e., the PCE finds a set of 
paths that satisfy the set of constraints), the set of computed paths specified 
by means of Explicit Route Objects (EROs) is inserted in the PCRep message.   
I tend to think that, reading RFC5440, all the paths in the pathlist for the 
PCEP response corresponding to a given request should satisfy the constraints 
of the requests (and, consequently, the PCC could select any, maybe based on 
the metric) however, correct me if I am wrong,   the server layer path does not 
(for starters, the endpoints are different). Isn't this proposed extension 
slightly against the spirit of rfc5440?
What are your thoughts? (additionally, I wasn't able to find a procedure that 
describes what happens when a PCC receives a response / path with an object it 
does not recognize / support, specially in the case of SERVER-INDICATION). 
Finally, section 3.5 says that SERVER-INDICATION is optional which is, imho a 
bit confusing (I am aware it is optional in the sense that it may not appear 
for paths in the client layer). Maybe you could reword it to say something in 
the lines of the SERVER-INDICATION object is mandatory if the path in the 
response is used to convey server layer information.

Also note that the suggested IANA allocations are already assigned except 18 
iirc, by monitoring, etc

[Pce] 答复: 答复: 答复: I-D Action: draft-ietf-pce-inter-layer-ext-07.txt

[Fatai Zhang]

Hi Ramon,

More information for the response.

Version 06 describes only “one “ ERO, but it depends on ERO extension, so 
version 07 uses this alternative (multiple EROs when server layer path info is 
returned).

For Q1, in this draft, it says  “When the INTER-LAYER object is absent from a 
PCReq message, the receiving PCE MUST process as though inter-layer path 
computation had been explicitly disallowed).”, so when a PCC cannot recognize 
“SEVER-INDICATION” object, it will not include INTER-LAYER object in the PCReq 
message.  Otherwise, it means that the PCEP implementation complied to the PCEP 
extension defined in this draft and it can understand “SEVER-INDICATION” object.

Note that please don’t mix the PCEP protocol and RSVP protocol or data plane 
capability.

For Q2, agree with you.





Thanks

Fatai

发件人: Fatai Zhang
发送时间: 2012年7月17日 15:35
收件人: 'Ramon Casellas'
抄送: pce@ietf.org
主题: 答复: 答复: [Pce] 答复: I-D Action: draft-ietf-pce-inter-layer-ext-07.txt

Hi Ramon,

Agree. The description needs to be refined as you suggested.
===
the SERVER-INDICATION object is mandatory if the path in the response is used 
to convey server layer information.


Thanks

Fatai

发件人: Ramon Casellas [mailto:ramon.casel...@cttc.es]
发送时间: 2012年7月16日 17:12
收件人: Fatai Zhang
抄送: pce@ietf.org
主题: Re: 答复: [Pce] 答复: I-D Action: draft-ietf-pce-inter-layer-ext-07.txt

Hi Fatai,

Thanks for the clarifications, other comments inline

On 07/16/2012 08:47 AM, Fatai Zhang wrote:
Hi Ramon,

For Q1, it could be possible to return two EROs as what you said, but my 
intention is to return two EROs like: ERO-client: A-B-C-D-E-F, and ERO-Server: 
C-a-b-c-d-e-f-D+ SERVER_INDICATION; In this way, it can reduce the overlapped 
information.

It makes sense, but,just in case I missed it, my question was more in the line 
that I would also like the option to return only *one* ERO, with elements from 
both layers. The current text seems to indicate that if there is server layer 
info (which is the case if the ERO contains elements from both layers, isn't 
it?) It is not mandated by the text to have two EROs but just one will do.



PCE MAY specify the server layer path information in the ERO. In this case, the 
requested PCE replies a PCRep message that includes at least two sets of ERO 
information in the path-list, one is for the client layer path information, and 
another one is the server layer path information. When SERVER-INDICATION is 
included in a PCRep message, it indicates that the path in the ERO is the 
server layer path information.

For Q2, the PCEP extension does not exert on how to signal the RSVP-TE.

Understood.

Additionally, I also sent two more comments to the list, but apparently they 
got lost (sorry for the duplicates if you happen to get the mail after this 
one) so I copy them here

-8-8--
Two more comments / questions. To help the discussion consider the topology 
below, and  consider a legacy (rfc5440) PCC co-located in a GMPLS controller 
of a PSC node A which belongs to a MRN (dual layer, PSC over LSC)

  [PSC PSC]
+-+ +--++--+  +-
| A   |-|   B  |[PSC, LSC]  | C|--| D
+-+ +--oo--+  +-
\+--+  +--+/
 |  L1  |--| L2   |
 +--+  +--+
  [LSC LSC]


I) Quoting the draft: When the INTER-LAYER object is absent from a PCReq 
message, the receiving PCE MUST process as though inter-layer path computation 
had been explicitly disallowed. I would like to understand the rationale for 
this, so clarification would be appreciated. why can't, say, node A, if it has 
a simple PCC get an interlayer ERO (A B  L1 L2 C D) if A does not support this 
extension? I tend to think it should be possible if B is able to detect the 
region change and establish the H-LSP, etc. Node A sends a PCReq = request with 
RP(1), ENDPOINTS(A,D), BW(1Gb/s)

In other words, if I deploy a PCE that implements pce-interlayer-ext-07 in a 
MRN with a unified control plane (single instance), the PCE cannot provide a 
strict interlayer ERO to node A if A (legacy, RFC 5440) does not include the 
interlayer object, but I am not sure why.




Another question / comment, more philosophical in nature, and  potential issue 
of backwards compatibility with draft -07:
In short, I am unsure of encoding parts or segments in one of the paths in 
the pathlist of the response. If we look at RFC5440

If the path computation request can be satisfied (i.e., the PCE finds a set of 
paths that satisfy the set of constraints), the set of computed paths specified 
by means of Explicit Route Objects (EROs) is inserted in the PCRep message.   
I tend to think that, reading RFC5440, all the paths in the pathlist for the 
PCEP response corresponding to a given request should satisfy the constraints

Re: [Pce] I-D Action: draft-ietf-pce-vendor-constraints-07.txt

[Fatai Zhang]

Hi all,

A new version has been uploaded.

This is just a spring-clean by refining some descriptions.

Please check if this draft is ready for LC because it is very old and stable 
for quite long time.



Best Regards

Fatai


-邮件原件-
发件人: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] 代表 
internet-dra...@ietf.org
发送时间: 2012年8月27日 11:11
收件人: i-d-annou...@ietf.org
抄送: pce@ietf.org
主题: [Pce] I-D Action: draft-ietf-pce-vendor-constraints-07.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Path Computation Element Working Group of the 
IETF.

Title   : Conveying Vendor-Specific Constraints in the Path 
Computation Element Protocol
Author(s)   : Fatai Zhang
  Adrian Farrel
  Greg Bernstein
Filename: draft-ietf-pce-vendor-constraints-07.txt
Pages   : 10
Date: 2012-08-26

Abstract:
   The Path Computation Element Protocol (PCEP) is used to convey path
   computation requests and responses between Path Computation Clients
   (PCCs) and Path Computation Elements (PCEs), and also between
   cooperating PCEs. In PCEP the path computation requests carry
   details of the constraints and objective functions that the PCC
   wishes the PCE to apply in its computation.

   The mechanisms defined for indicating objective functions include
   the capability to convey vendor-specific objective functions. This
   document defines a facility to carry vendor-specific constraints in
   PCEP.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-vendor-constraints

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pce-vendor-constraints-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-vendor-constraints-07


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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] 答复: I-D Action: draft-ietf-pce-vendor-constraints-08.txt

[Fatai Zhang]

Hi all,

A quick update mainly focuses on addressing Backward Compatibility issue.




Best Regards

Fatai


-邮件原件-
发件人: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] 代表 
internet-dra...@ietf.org
发送时间: 2012年8月31日 11:17
收件人: i-d-annou...@ietf.org
抄送: pce@ietf.org
主题: [Pce] I-D Action: draft-ietf-pce-vendor-constraints-08.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Path Computation Element Working Group of the 
IETF.

Title   : Conveying Vendor-Specific Constraints in the Path 
Computation Element Protocol
Author(s)   : Fatai Zhang
  Adrian Farrel
  Greg Bernstein
Filename: draft-ietf-pce-vendor-constraints-08.txt
Pages   : 10
Date: 2012-08-30

Abstract:
   The Path Computation Element Protocol (PCEP) is used to convey path
   computation requests and responses between Path Computation Clients
   (PCCs) and Path Computation Elements (PCEs), and also between
   cooperating PCEs. In PCEP the path computation requests carry
   details of the constraints and objective functions that the PCC
   wishes the PCE to apply in its computation.

   The mechanisms defined for indicating objective functions include
   the capability to convey vendor-specific objective functions. This
   document defines a facility to carry vendor-specific constraints in
   PCEP.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-vendor-constraints

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pce-vendor-constraints-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-vendor-constraints-08


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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] 答复: stateful PCE - moving forward next steps

[Fatai Zhang]

Hi Ramon and Julien,

Thanks for your useful comments.

I agree with Julien and Ramon.  We of course need to investigate which way is a 
preference for PCE WG.

I think if it could integrate GMPLS, I would suggest moving to that direction, 
because GMPLS is generic and covers MPLS as what Julien said.

BTW, we usually prefer to generalize something in a draft/RFC, when it could be 
generalized. 

More comments from WG are appreciated.




Best Regards

Fatai


-邮件原件-
发件人: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] 代表 Ramon Casellas
发送时间: 2012年10月26日 2:38
收件人: Julien Meuric
抄送: pce@ietf.org
主题: Re: [Pce] stateful PCE - moving forward  next steps

El 25/10/2012 11:39, Julien Meuric escribió:

 One 1st comment at this stage: you seem to suggest that the idea is to 
 have separate document for MPLS-TE and GMPLS, but you do not give 
 rationale. Apart from our history of RFC 5440 + draft-ietf-pce-gmpls 
 (even with its scope, the former had a hard time), is there a 
 particular reason for this choice? Do you expect much difference 
 between those 2 kinds of extensions? Also keep in mind that GMPLS 
 includes PSC...

Dear Julien, all

Thanks for the feedback, I understand your point about GMPLS and, if I 
recall correctly, one of the reasons mentioned in previous internal 
discussions was the relative maturity of one (RFC5440) with regard to 
the other (draft-ietf-pce-gmpls).

We can indeed discuss the different alternatives during IETF85, with all 
the involved parties, authors, and the WG.  Although, initially, I had a 
slight preference to integrate GMPLS, (as I mentioned a while ago in my 
review of Ed's earlier drafts), I am fine either way.

Maybe Ed, Jan, Ina, Fatai, Young, Xian or Oscar can comment on this?

Thanks and best regards,
R.

___
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] 答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE

[Fatai Zhang]

Hi Jan,



The PCE is not limited to path computation only. The PCE can set other LSP 
parameters as well: RFC5440 defines objects for bandwidth, setup  hold 
priorities, the local protection flag, etc. More LSP parameters have been 
added in subsequent RFCs and drafts.



[Fatai] I have to indicate that PCE cannot *set* other LSP parameters. The 
parameters (eg., bandwidth, priorities, etc) you mentioned are only used for 
*path computation*.



 I may have jumped over some paragraph where it says that the role of a Path 
 Computation Element (stateful o not stateful) is to take care of the control 
 of an LSP... but I honestly cannot find such statement anywhere. So... could 
 you give me some arguments why the delegation of control is in scope of 
 current RFC 4655?



The delegation of LSP control to a PCE is *implicit* in RFC4655. When a PCC 
sends a PCReq message to a PCE requesting path computation (and parameter 
setting) for an LSP, it effectively

 delegates control over that LSP to the PCE. The delegation is valid for one 
 request (and one path computation) only.



[Fatai] I don't think that RFC4655 can support delegation of LSP *control* 
(even implicitly). A PCC sends a PCReq to a PCE, it does not mean that this LSP 
is delegated to the PCE.







Best Regards



Fatai





-邮件原件-
发件人: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] 代表 Jan Medved (jmedved)
发送时间: 2012年11月9日 9:12
收件人: Oscar González de Dios
抄送: pce@ietf.org
主题: Re: [Pce] Questions about stateful PCE, relation to WG charter and opinion 
about stateful PCE



Hi Oscar,



please see inline.



On Nov 8, 2012, at 2:28 PM, Oscar González de Dios wrote:



 [Oscar]: The state synchronization functions, aimed at (citing literally)  
 provide a checkpoint-in-time state replica of a PCC's LSP state in a PCE are 
 consistent with this statement, they are beyond simple request/response 
 interactions and collect and report information in support of a stateful PCE. 
 Thus, this function is perfectly OK with RFC 4555.



 However, I see that the LSP delegation function goes beyond reporting 
 information to support a stateful PCE. It instructs the PCE to take control 
 of the LSP, and, during the life-time of the LSP, citing literally the PCC 
 grants to a PCE the right to update LSP attributes on one or more LSPs; the 
 PCE becomes the authoritative source of the LSP's attributes as long as the 
 delegation is in effect. Thus, delegation function clearly is not used to 
 provide information to support later path computation. So... unless I have 
 mistaken the read of RFC 4655, it is explicitly mentioned that the PCE 
 architecture is aimed at solving the problem of path computation.



The PCE is not limited to path computation only. The PCE can set other LSP 
parameters as well: RFC5440 defines objects for bandwidth, setup  hold 
priorities, the local protection flag, etc. More LSP parameters have been added 
in subsequent RFCs and drafts.

 I may have jumped over some paragraph where it says that the role of a Path 
 Computation Element (stateful o not stateful) is to take care of the control 
 of an LSP... but I honestly cannot find such statement anywhere. So... could 
 you give me some arguments why the delegation of control is in scope of 
 current RFC 4655?



The delegation of LSP control to a PCE is *implicit* in RFC4655. When a PCC 
sends a PCReq message to a PCE requesting path computation (and parameter 
setting) for an LSP, it effectively delegates control over that LSP to the PCE. 
The delegation is valid for one request (and one path computation) only.



Now, the PCC may or may not use the LSP path/parameters that it got from the 
PCE. But why would the PCC not use the PCE-computed path  parameters, if we 
want the whole scheme to work? The PCC goes to the PCE for LSP path because the 
PCE can do a better job at path computation (and LSP parameter setting) that 
the PCC itself. The PCC would only throw away the PCE-computed LSP parameters 
if there was an error condition and the LSP could not be established (the PCC 
may in this case compute the path locally).



So there is delegation in 4655, although it's implicit. Delegation is not so 
obvious for stateless PCEs - basically, a if PCC does not use a PCE-computed 
path, the impact on the stateless PCE and its path computations for other PCCs 
is not big, because the stateless PCE does not keep track of LSPs.



The delegation concept is a lot stronger for stateful PCEs, where strict state 
synchronization between a PCC and a PCE is required. RFC4655 Section 6.8 
states: there is a strict synchronization between the PCE and not only the 
network states (in term of topology and resource information), but also the set 
of computed paths and reserved resources in use in the network. So if a PCC 
does not use the path computed by the PCE, it must notify the PCE, and also 
tell it about the path/parameters that were used for the LSP. This points at a 
tighter PCE 

[Pce] 答复: 答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE

[Fatai Zhang]

I am surprised by your tone.

I am touching the tech points and trying to clarity why PCE cannot *determine* 
those parameters. You can correct me if I am wrong from the tech perspective.

If you still use this kind of tone, sorry, I will ignore your response.



Best Regards

Fatai

发件人: Edward Crabbe [mailto:e...@google.com]
发送时间: 2012年11月12日 11:59
收件人: Fatai Zhang
抄送: Jan Medved (jmedved); pce@ietf.org
主题: Re: [Pce] 答复: Questions about stateful PCE, relation to WG charter and 
opinion about stateful PCE

We currently appear to be involved in some sort of pre-fiat working group 
process debate.  Unfortunately, I think you're injecting a particularly onerous 
and unnecessary sort of wg bureaucracy here, and for no discernible reason.  At 
this point, given the lack of any substantive technical argument, I have to say 
that I actually feel that you're being a bit obstructionist. :-/  I hope that's 
not the case.

Obviously the working group can have any technical discussion it wants, to 
within the bounds of reason and the chair's limits of tolerence.  ;)  So let's 
do that, and try to make our time together here productive. ^_^

w/r/t the specific comments:

Yes, we already have introduced a delegation function and have had since the 
first rev of the draft.  It is, IMO,  defined clearly in the 
draft-crabbe-pce-stateful-pce-02.  You should read it.  If you don't think the 
definition is clear, then we should discuss that so we can improve the text.

I continue to maintain that the main differences between receipt of computation 
results between 5440 and active PCEP as defined in 
draft-crabbe-pce-stateful-pce-02 is directionality and asynchrony.  If you have 
a good reason for thinking that this is not the case, or have other technical 
issues with the delegation model, then please, by all means...


On Sun, Nov 11, 2012 at 6:56 PM, Fatai Zhang 
zhangfa...@huawei.commailto:zhangfa...@huawei.com wrote:
Hi Jan,
You said:
=By requesting a path computation from a PCE, the PCC gives the PCE authority 
to determine the ERO, LSP Bandwidth, protection, LSP setup and hold priorities, 
etc. The PCE is the entity that determines these parameters - would you agree?

[Fatai] Sorry, I don’t agree. The parameters (LSP bandwidth, protection, etc) 
are the constraints sent from PCC to PCE for *path computation*. For example, a 
PCC sends a PCReq to request a LSP with bandwidth 1Gpbs, and then the PCE MUST 
not return a path with e.g, 100Mbps, ie., the PCE *cannot determine* these 
parameters.  The ERO is the path information (path list) that PCE returns to 
PCC after path computation.

If you want to introduce *delegation* function (whatever we call it), the 
delegation definintion should be defined clearly. And then the WG will/can 
discuss more whether this “delegation” is needed or not (and whether this 
“delegation” is in the scope of the existing charter).


Best Regards

Fatai

发件人: Jan Medved (jmedved) [mailto:jmed...@cisco.commailto:jmed...@cisco.com]
发送时间: 2012年11月10日 0:27
收件人: Fatai Zhang
抄送: Oscar González de Dios; pce@ietf.orgmailto:pce@ietf.org
主题: Re: [Pce] Questions about stateful PCE, relation to WG charter and opinion 
about stateful PCE

Faital,

On Nov 9, 2012, at 12:20 AM, Fatai Zhang wrote:

The delegation of LSP control to a PCE is *implicit* in RFC4655. When a PCC 
sends a PCReq message to a PCE requesting path computation (and parameter 
setting) for an LSP, it effectively
 delegates control over that LSP to the PCE. The delegation is valid for one 
 request (and one path computation) only.

[Fatai] I don't think that RFC4655 can support delegation of LSP *control* 
(even implicitly). A PCC sends a PCReq to a PCE, it does not mean that this LSP 
is delegated to the PCE.

By requesting a path computation from a PCE, the PCC gives the PCE authority to 
determine the ERO, LSP Bandwidth, protection, LSP setup and hold priorities, 
etc. The PCE is the entity that determines these parameters - would you agree?

Now, whether we use control, authority, power, mandate, whatever - that 
does not change the fact that the PCC asks the PCC to determine what the LSP 
parameters are, and the PCE determines what the LSP parameters are. That's what 
we call delegation - the PCC delegates the computation of LSP path and 
determination of LSP parameters to the PCE.

My email states a little later: the PCC may or may not use the LSP 
path/parameters that it got from the PCE. We all agree that the PCC has the 
ultimate control over the LSP - it may take the directions from the PCE, it may 
not.

draft-ietf-pce-stateful-pce does not change any of this. The PCC gives the PCE 
the control/authority/mandate/power to determine the LSP's parameter. But, 
rather than doing this implicitly by requesting the PCE to determine those 
parameters (in a PCReq message), it does it explicitly. Delegation does not 
change the paradigm set by RFC4655 and RFC5440 - but in addition to LSP 
parameters, it allows the PCE to determine

[Pce] 答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE

[Fatai Zhang]

Hi Jan,

[RFC5440] says:
If the requested bandwidth is equal to 0, the BANDWIDTH object is optional. 
Conversely, if the requested bandwidth is not equal to 0,   the PCReq message 
MUST contain a BANDWIDTH object.

I don’t think this means that PCE can set the bandwdith. All the paratermetes 
(either optional or mandatory)  sent from PCC to PCE in the PCReq are the 
contranits that will be taken into acccount for PCE to perform path compution.

In addition, I would like to remind that *set* != *delegation*, maybe we stray 
a little from the point, :)



Best Regards

Fatai

发件人: Jan Medved (jmedved) [mailto:jmed...@cisco.com]
发送时间: 2012年11月12日 13:09
收件人: Fatai Zhang
抄送: Oscar González de Dios; pce@ietf.org
主题: Re: [Pce] Questions about stateful PCE, relation to WG charter and opinion 
about stateful PCE

Fatai,

On Nov 11, 2012, at 6:56 PM, Fatai Zhang wrote:


Hi Jan,
You said:
=By requesting a path computation from a PCE, the PCC gives the PCE authority 
to determine the ERO, LSP Bandwidth, protection, LSP setup and hold priorities, 
etc. The PCE is the entity that determines these parameters - would you agree?

[Fatai] Sorry, I don’t agree. The parameters (LSP bandwidth, protection, etc) 
are the constraints sent from PCC to PCE for *path computation*.

Please re-read rfc5440. A PCRep *may* contain all the above objects. There is 
nothing in the RFC5440 saying the PCE could not set these parameters as it sees 
fit - even change the BANDWIDTH parameter suggested by a PCC.


For example, a PCC sends a PCReq to request a LSP with bandwidth 1Gpbs, and 
then the PCE MUST not return a path with e.g, 100Mbps, ie., the PCE *cannot 
determine* these parameters.  The ERO is the path information (path list) that 
PCE returns to PCC after path computation.

Please re-read rfc5440 - BANDWIDTH and all other LSP parameters are *optional* 
on PCReq. A use case where a PCC does not include BANDWIDTH on the PCReq 
message and leaves the determination of a path's bandwidth to the PCE is well 
within the spec. And as I said above, a PCRep may optionally contain bandwidth 
and other LSP parameters, not just the ERO.

Even if we say that the only thing that the PCE does is path computation, the 
PCC *delegates* path computation to the PCE. That means, delegation - as a 
concept - has been a part of the PCE architecture from the very beginning. 
Therefore, your arguments above about bandwidth, etc. are moot.

If you want to introduce *delegation* function (whatever we call it), the 
delegation definintion should be defined clearly.

We don't have to introduce it, it's already in the PCE architecture. That's a 
fact. You may disagree. You are, of course, entitled to your own opinions, but 
not to your own facts.

I tried to explain delegation in this email thread as clearly as I could. 
Please re-read it, and if you don't understand something, ask a pointed 
question. If you disagree with something i wrote, please address that clearly. 
Then we can have a meaningful discussion. But please do not try to reset the 
discussion to with general statements.


And then the WG will/can discuss more whether this “delegation” is needed or 
not (and whether this “delegation” is in the scope of the existing charter).

Where have you been when the WG discussed draft-ietf-pce-stateful-pce?



Best Regards

Fatai

Thanks,
Jan


发件人: Jan Medved (jmedved) [mailto:jmed...@cisco.com]
发送时间: 2012年11月10日 0:27
收件人: Fatai Zhang
抄送: Oscar González de Dios; pce@ietf.orgmailto:pce@ietf.org
主题: Re: [Pce] Questions about stateful PCE, relation to WG charter and opinion 
about stateful PCE

Faital,

On Nov 9, 2012, at 12:20 AM, Fatai Zhang wrote:



The delegation of LSP control to a PCE is *implicit* in RFC4655. When a PCC 
sends a PCReq message to a PCE requesting path computation (and parameter 
setting) for an LSP, it effectively
 delegates control over that LSP to the PCE. The delegation is valid for one 
 request (and one path computation) only.

[Fatai] I don't think that RFC4655 can support delegation of LSP *control* 
(even implicitly). A PCC sends a PCReq to a PCE, it does not mean that this LSP 
is delegated to the PCE.

By requesting a path computation from a PCE, the PCC gives the PCE authority to 
determine the ERO, LSP Bandwidth, protection, LSP setup and hold priorities, 
etc. The PCE is the entity that determines these parameters - would you agree?

Now, whether we use control, authority, power, mandate, whatever - that 
does not change the fact that the PCC asks the PCC to determine what the LSP 
parameters are, and the PCE determines what the LSP parameters are. That's what 
we call delegation - the PCC delegates the computation of LSP path and 
determination of LSP parameters to the PCE.

My email states a little later: the PCC may or may not use the LSP 
path/parameters that it got from the PCE. We all agree that the PCC has the 
ultimate control over the LSP - it may take the directions from the PCE, it may 
not.

draft-ietf-pce

[Pce] 答复: 答复: Questions about stateful PCE, relation to WG charter and opinion about stateful PCE

[Fatai Zhang]

Hi Robert,

Yes, you are right.



Best Regards

Fatai

发件人: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] 代表 Robert Varga
发送时间: 2012年11月10日 0:43
收件人: pce@ietf.org
主题: Re: [Pce] 答复: Questions about stateful PCE, relation to WG charter and 
opinion about stateful PCE

On 11/09/2012 09:20 AM, Fatai Zhang wrote:

Hi Jan,

Hi Fatai,





The PCE is not limited to path computation only. The PCE can set other LSP 
parameters as well: RFC5440 defines objects for bandwidth, setup  hold 
priorities, the local protection flag, etc. More LSP parameters have been 
added in subsequent RFCs and drafts.



[Fatai] I have to indicate that PCE cannot *set* other LSP parameters. The 
parameters (eg., bandwidth, priorities, etc) you mentioned are only used for 
*path computation*.

I agree. The PCE does not set *any* parameters of the LSP. Only PCC can do that 
PCC. PCE can only provide suggestions and must be fully prepared to have them 
rejected.

I am not aware of any restriction on what information a PCE is allowed to 
suggest to be modified, apart from the fact that ERO and BANDWIDTH are 
explictly included in that set (section 5.1.5 of RFC4657).

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

Re: [Pce] Ramblings of two old dogs

[Fatai Zhang]

Hi Adrian,

Very interesting and useful draft.

A few small comments from me for discussion.

(1) What Is Topology Information?
Should SRLG/SRG information be mentioned?

(2) Does H-PCE Solve The Internet?
It is obviously that the answer is NO. However, another question could be 
addressed: how many domains and how many levels (hierachical levels) can be 
handled by H-PCE?

(3) What Is A Stateful PCE For?
It says: A Stateful PCE maintains a database of LSPs that are active in the 
network (the LSP-DB).  This database allows a PCC to refer to an LSP using only 
its identifier - all other details can be retrieved by the PCE from the 
LSP-DB..

What do you mean for *active LSPs* here? Could a protecting LSP be regarded as 
*active* when it is not in the Operational state? Scheduling LSPs (in question 
22) are active or not?

(4) Is An Active PCE with LSP Delegation Just a Fancy NMS?
I agree that in many ways the answer here is yes, especially from the 
function perspective. When NMS is doing this delegation as it has been done 
in the real deployment, there is no need to do the delegation in a per-LSP 
way. So my question is: when an active PCE is used to do the delegation 
function, is it necessary in a per-LSP way? Or it could be done in the *NMS* 
way?

(5) Where Does Policy Fit In?
I think if [RFC5394] is used to set up the policies as much as possible, it can 
reduce many PCEP extensions to make PCE just focus on *computation*. 




Best Regards

Fatai

-Original Message-
From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of Adrian 
Farrel
Sent: Friday, January 18, 2013 12:46 AM
To: pce@ietf.org
Subject: [Pce] Ramblings of two old dogs

Hi,

Over the years Dan and I have been asked a number of questions about PCE and how
it fits into different uses in the network.

Although we feel that the ABNO document (draft-farrkingel-pce-abno-architecture)
goes a long way to explain the bigger picture, there are a lot of smaller,
everyday questions that need attention.

In an attempt to reduce the email we see, we have collected these into an
Informational I-D as below. Obviously, if you all send us comments and thoughts
on this document you will successfully thwart our plans :-)

Adrian and Dan

 -Original Message-
 From: i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org]
 On Behalf Of internet-dra...@ietf.org
 Sent: 17 January 2013 15:30
 To: i-d-annou...@ietf.org
 Subject: I-D Action: draft-farrkingel-pce-questions-00.txt
 
 
 A New Internet-Draft is available from the on-line Internet-Drafts
directories.
 
 
   Title   : Unanswered Questions in the Path Computation Element
 Architecture
   Author(s)   : Adrian Farrel
   Daniel King
   Filename: draft-farrkingel-pce-questions-00.txt
   Pages   : 22
   Date: 2013-01-17
 
 Abstract:
The Path Computation Element (PCE) architecture is set out in RFC
4655. The architecture is extended for multi-layer networking with
the introduction of the Virtual Network Topology Manager in RFC
5623, and generalized to Hierarchical PCE in RFC 6805.
 
These three architectural views of PCE deliberately leave some key
questions unanswered especially with respect to the interactions
between architectural components.  This document draws out those
questions and discusses them in an architectural context with
reference to other architectural components, existing protocols, and
recent IETF work efforts.
 
This document does not update the architecture documents and does not
define how protocols or components must be used.  It does, however,
suggest how the architectural components might be combined to provide
advanced PCE function.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-farrkingel-pce-questions
 
 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-farrkingel-pce-questions-00
 
 
 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.ietf.org/internet-drafts/
 
 ___
 I-D-Announce mailing list
 i-d-annou...@ietf.org
 https://www.ietf.org/mailman/listinfo/i-d-announce
 Internet-Draft directories: http://www.ietf.org/shadow.html
 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
Pce mailing list
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-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-awarehttp://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] 答复: 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

Re: [Pce] Last IPR Check on draft-ietf-pce-gmpls-aps-req-07

[Fatai Zhang]

Hi Julien,

I am not aware of any IPR to this draft.

Note that I think the IPR that you mentioned below was removed (because the 
disclosure was wrong). 





Best Regards

Fatai

-Original Message-
From: Julien Meuric [mailto:julien.meu...@orange.com] 
Sent: Tuesday, April 30, 2013 5:13 PM
To: draft-ietf-pce-gmpls-aps-...@tools.ietf.org
Cc: pce@ietf.org
Subject: Last IPR Check on draft-ietf-pce-gmpls-aps-req-07

Dear authors of the aforementioned I-D,

Are you aware of any other IPR that applies to 
draft-ietf-pce-gmpls-aps-req? If so, has all this IPR been disclosed in 
compliance with IETF IPR rules? (see RFCs 3979, 4879, 3669 and 5378 for 
more details)

Note that an IPR was disclosed on this I-D last summer.

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] Stateful PCE applicability

[Fatai Zhang]

Hi all,

Definitely, Yes for both.





Best Regards

Fatai

From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of JP 
Vasseur (jvasseur)
Sent: Saturday, June 22, 2013 4:20 PM
To: Ina Minei; pce@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] 答复: Comments on draft-ietf-pce-gmpls-pcep-extensions-08

[Fatai Zhang]

Hi all,

I think a new object type could be better and simple.

Thanks

Fatai


发件人: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] 代表 Ramon Casellas
发送时间: 2013年7月30日 17:32
收件人: Jonathan Hardwick; pce@ietf.org
主题: Re: [Pce] Comments on draft-ietf-pce-gmpls-pcep-extensions-08

On 07/30/2013 11:08 AM, Jonathan Hardwick wrote:
Cyril and I had an offline conversation about these comments.  This email is to 
document the discussion for the benefit of the mailing list.  See [JEH-MC] 
comments below.

We have one question for the WG, as follows.  If anyone has an opinion on this, 
please could you provide it to the mailing list?

---
[JEH-MC] Jon believes that this draft should relax the restriction of RFC 5440 
that the BANDWIDTH object is mandatory, in the case where a 
GENERALIZED-BANDWIDTH is supplied instead.  This would mean changing existing 
procedures, the initial mechanism was not to change RFC5440 object presence 
rule.  Cyril is fine with the proposal from Jonathan, but we would like to get 
WG and implementers feedback.


Jon, Cyril, all

In this case, I would go back to one of my initial suggestions: do not add 
GENERALIZED_BANDWIDTH and add a TLV to the BW objects, which can be ignored.

In other words, the creation of GEN_BW was justified due to:  a) do not touch 
rfc5440 b) if RFC5440 does not state that BW object can have TLVs, then they 
can't and it is fixed length.

My personal preference always was to add a TLV or a new object type for BW.  If 
we allow ourselves a liberal interpretation of rfc5440 then let's assume we can 
add a tlv...

Just my opinion, of course, and not a particularly strong one

Ramon



--

Ramon Casellas, Ph.D. -- Senior Research Associate -- Networks Division

Optical Networks and Systems Department -- http://wikiona.cttc.es

CTTC - Centre Tecnològic de Telecomunicacions de Catalunya

Parc Mediterrani de la Tecnologia (PMT) - Edifici B4

Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain

Tel.: +34 93 645 29 00 ext 2168-- Fax. +34 93 645 29 01
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] 答复: Poll for Adoption of draft-zhang-pce-hierarchy-extensions-04

[Fatai Zhang]

Support as co-author.

Fatai



-邮件原件-
发件人: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] 代表 Julien Meuric
发送时间: 2013年8月1日 17:31
收件人: pce@ietf.org
主题: [Pce] Poll for Adoption of draft-zhang-pce-hierarchy-extensions-04

Hi again.

Following the poll in the room during yesterday meeting, we would like to get 
the feedback of the mailing list: do you support
draft-zhang-pce-hierarchy-extensions-04 as a foundation for a WG document?

Please express your support or opposition on the PCE mailing list (for the 
latter, comments would be useful).

Regards,

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] Last IPR Check on draft-ietf-pce-vendor-constraints

[Fatai Zhang]

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





Best Regards

Fatai


-Original Message-
From: Julien Meuric [mailto:julien.meu...@orange.com] 
Sent: Monday, October 14, 2013 8:36 PM
To: draft-ietf-pce-vendor-constrai...@tools.ietf.org
Cc: pce@ietf.org
Subject: Last IPR Check on draft-ietf-pce-vendor-constraints

Dear authors of the aforementioned document,

Are you aware of any IPR that applies to 
draft-ietf-pce-vendor-constraints? If so, has all 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

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

[Pce] Collecting comments for draft-ietf-pce-inter-layer-ext

[Fatai Zhang]

Hi all,

I think you noticed that this draft has been expired for quite long time.

I think it is time to move forward this draft.

If you have any comments, please share to the authors or the list.




Best Regards

Fatai

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

Re: [Pce] Poll for Adoption of draft-zhang-pce-pcep-stateful-pce-gmpls-03

[Fatai Zhang]

Support as co-author.





Best Regards

Fatai


-Original Message-
From: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of Julien 
Meuric
Sent: Tuesday, November 12, 2013 10:18 PM
To: pce@ietf.org
Subject: [Pce] Poll for Adoption of draft-zhang-pce-pcep-stateful-pce-gmpls-03

Hi again.

Following the support expressed in the room during our meeting in 
Vancouver, we would like to get the feedback of the mailing list: do you 
support draft-zhang-pce-pcep-stateful-pce-gmpls-03 to become a 
foundation for a PCE WG document?

As usual, reasons for your preference are welcome (not to say mandatory 
in case of opposition).

Thanks,

JP  Julien

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

[Pce] 答复: Adoption of draft-ali-pce-remote-initiated-gmpls-lsp-03.txt as PCE WG Document ?

[Fatai Zhang]

Support.


Thanks

Fatai




-邮件原件-
发件人: Pce [mailto:pce-boun...@ietf.org] 代表 JP Vasseur (jvasseur)
发送时间: 2014年3月4日 18:52
收件人: pce@ietf.org
主题: [Pce] Adoption of draft-ali-pce-remote-initiated-gmpls-lsp-03.txt as PCE WG 
Document ?

Dear WG,

As discussed during the PCE WG meeting today where we had some support for 
adopting draft-ali-pce-remote-initiated-gmpls-lsp-03.txt 
as a PCE WG.

Would you be in favor/opposed (and why if you want to justify) of adopting 
draft-ali-pce-remote-initiated-gmpls-lsp-03.txt as a WG document ?

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-minei-pce-stateful-sync-optimizations as PCE WG Document?

[Fatai Zhang]

Support.


Thanks

Fatai



-邮件原件-
发件人: Pce [mailto:pce-boun...@ietf.org] 代表 Julien Meuric
发送时间: 2014年3月5日 2:12
收件人: pce@ietf.org
主题: [Pce] Adoption of draft-minei-pce-stateful-sync-optimizations as PCE WG 
Document?

Dear WG,

As discussed during the PCE WG meeting today, we had some support for adopting 
draft-minei-pce-stateful-sync-optimizations-01 as a PCE WG item.

Would you be in favor/opposed (and why if you want to justify) of adopting it 
as a WG document?

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-lopez-pce-pceps-02 as PCE WG Document ?

[Fatai Zhang]

Support.


Thanks

Fatai


-邮件原件-
发件人: Pce [mailto:pce-boun...@ietf.org] 代表 JP Vasseur (jvasseur)
发送时间: 2014年3月4日 17:48
收件人: pce@ietf.org
主题: [Pce] Adoption of draft-lopez-pce-pceps-02 as PCE WG Document ?

Dear WG,

As discussed during the PCE WG meeting today where we had good support for 
adopting draft-lopez-pce-pceps-02 as a WG document, as usual, we would like to 
confirm on the mailing list.

Would you be in favor/opposed (and why if you want to justify) of adopting 
draft-lopez-pce-pceps-02 as a WG document ?

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] 答复: Last IPR Check on draft-ietf-pce-gmpls-pcep-extensions

[Fatai Zhang]

Hi all,

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


Thanks

Fatai



-邮件原件-
发件人: Julien Meuric [mailto:julien.meu...@orange.com] 
发送时间: 2014年7月22日 23:28
收件人: draft-ietf-pce-gmpls-pcep-extensi...@tools.ietf.org
抄送: pce@ietf.org
主题: Last IPR Check on draft-ietf-pce-gmpls-pcep-extensions

Dear authors of the aforementioned document,

Has all IPR that applies to draft-ietf-pce-gmpls-pcep-extensions 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

Re: [Pce] Request for early allocation of code points for draft-ietf-pce-inter-layer-ext status of draft

[Fatai Zhang]

Hi Oscar,

I don't think we need to ask early allocation of code points, which is for the 
special case (ie., early allocation is not the normal procedure) and the right 
values will be allocated during RFC publication stage (ie., the clash will 
disappear) .

The authors of this draft including me are taking care of this draft and we 
always welcome any review comments from the WG.

Note that the WG chairs told in the previous meeting that they would like to 
move forward 
[draft-ietf-pce-gmpls-pcep-extensionshttp://tools.ietf.org/wg/pce/draft-ietf-pce-gmpls-pcep-extensions/]
 first, and then move forward this draft.

Any further comments are apprecicated.


Best Regards

Fatai

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of OSCAR GONZALEZ DE DIOS
Sent: Thursday, September 04, 2014 6:00 PM
To: draft-ietf-pce-inter-layer-...@tools.ietf.org
Cc: pce@ietf.org
Subject: [Pce] Request for early allocation of code points for 
draft-ietf-pce-inter-layer-ext  status of draft

Dear authors of draft-ietf-pce-inter-layer-ext,

The draft draft-ietf-pce-inter-layer-ext, in its version 8 right now, 
introduces a set of new PCEP objects, which require object-class values. 
Current recommended values clash with already allocated values.

As suggested in the last IETF meeting in Toronto, the use of the early 
allocation procedure is recommended to handle the code points (when the draft 
is stable). Would it be possible that authors of the draft ask for early 
allocation of code points for draft-ietf-pce-inter-layer-ext ?

On the other hand, I see that the draft has been stable for a while and even 
has expired. Who is taking care of the updates of the draft? Is the draft going 
to last call in the near future? Are you expecting a review?

Best Regards,

Óscar





Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede 
contener información privilegiada o confidencial y es para uso exclusivo de la 
persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
notificado de que la lectura, utilización, divulgación y/o copia sin 
autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente 
por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential 
information intended only for the use of the individual or entity named above. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission in error, do not 
read it. Please immediately reply to the sender that you have received this 
communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode 
conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa 
ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica 
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização 
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem 
por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
proceda a sua destruição
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Preaching about code points in drafts

[Fatai Zhang]

Hi Adrian,

I think the steps you proposed really make sense. 

I have one comment for clarification on step (2a) and (4), did you mean that it 
only needs to use TBD rather than the suggested values? 

In addtion, for the new drafts (or non-existing drafts with clash), can I 
re-order your steps as follows? :-)

1. Do not adopt any I-D as a working group draft if it specifies code points.

2. In the future, when implementations of an I-D become advanced enough to be 
close shipping or starting interop testing, use RFC 7120 to get code points 
allocated.




Best Regards

Fatai


-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Adrian Farrel
Sent: Thursday, September 18, 2014 10:43 AM
To: pce@ietf.org
Cc: pce-cha...@tools.ietf.org
Subject: [Pce] Preaching about code points in drafts

PCE working group,

draft-ietf-pce-rfc7150bis is fixing a clash between an IANA allocation for RFC
7150 and an unallocated code point documented in a working group Internet-Draft
that had been picked up and used by multiple implementations.

Another clash has just been pointed out to me between RFC 7150 and
draft-ietf-pce-gmpls-pcep-extensions.

The specifying of unallocated values in PCE I-Ds has got to stop before
significant clashes happen in the field. Cease! Desist! It is not necessary, and
there is a simple solution to get code points if you need them.

Steps to be followed:

1. Identify all I-Ds that state or recommend values for code points (see below).

2. Decide whether the values shown are needed to support existing
implementations.
2a. If so, make an immediate request to the WG chairs for early allocation of
the code points using the procedures of RFC 7120.
2b. If not, make an immediate revision of the I-D removing the specific code
point values.

3. In the future, when implementations of an I-D become advanced enough to be
close shipping or starting interop testing, use RFC 7120 to get code points
allocated.

4. Do not adopt any I-D as a working group draft if it specifies code points.

Current drafts

draft-ietf-pce-pce-initiated-lsp specifies unallocated values
draft-ietf-pce-pcep-stateful-pce-gmpls suggests values
draft-ietf-pce-remote-initiated-gmpls-lsp specifies an unallocated value
draft-ietf-pce-stateful-pce suggests multiple unallocated values
draft-ietf-pce-stateful-sync-optimizations specifies and suggests multiple
unallocated values

Recently-expired drafts

draft-ietf-pce-gmpls-pcep-extensions specifies multiple unallocated values
draft-ietf-pce-inter-layer-ext recommends multiple unallocated values


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] Preaching about code points in drafts

[Fatai Zhang]

Hi, 

Sorry, I should say (2b) and (4), :-)




Best Regards

Fatai


-Original Message-
From: Fatai Zhang 
Sent: Thursday, September 18, 2014 4:32 PM
To: 'adr...@olddog.co.uk'; pce@ietf.org
Cc: pce-cha...@tools.ietf.org
Subject: RE: [Pce] Preaching about code points in drafts

Hi Adrian,

I think the steps you proposed really make sense. 

I have one comment for clarification on step (2a) and (4), did you mean that it 
only needs to use TBD rather than the suggested values? 

In addtion, for the new drafts (or non-existing drafts with clash), can I 
re-order your steps as follows? :-)

1. Do not adopt any I-D as a working group draft if it specifies code points.

2. In the future, when implementations of an I-D become advanced enough to be 
close shipping or starting interop testing, use RFC 7120 to get code points 
allocated.




Best Regards

Fatai


-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Adrian Farrel
Sent: Thursday, September 18, 2014 10:43 AM
To: pce@ietf.org
Cc: pce-cha...@tools.ietf.org
Subject: [Pce] Preaching about code points in drafts

PCE working group,

draft-ietf-pce-rfc7150bis is fixing a clash between an IANA allocation for RFC
7150 and an unallocated code point documented in a working group Internet-Draft
that had been picked up and used by multiple implementations.

Another clash has just been pointed out to me between RFC 7150 and
draft-ietf-pce-gmpls-pcep-extensions.

The specifying of unallocated values in PCE I-Ds has got to stop before
significant clashes happen in the field. Cease! Desist! It is not necessary, and
there is a simple solution to get code points if you need them.

Steps to be followed:

1. Identify all I-Ds that state or recommend values for code points (see below).

2. Decide whether the values shown are needed to support existing
implementations.
2a. If so, make an immediate request to the WG chairs for early allocation of
the code points using the procedures of RFC 7120.
2b. If not, make an immediate revision of the I-D removing the specific code
point values.

3. In the future, when implementations of an I-D become advanced enough to be
close shipping or starting interop testing, use RFC 7120 to get code points
allocated.

4. Do not adopt any I-D as a working group draft if it specifies code points.

Current drafts

draft-ietf-pce-pce-initiated-lsp specifies unallocated values
draft-ietf-pce-pcep-stateful-pce-gmpls suggests values
draft-ietf-pce-remote-initiated-gmpls-lsp specifies an unallocated value
draft-ietf-pce-stateful-pce suggests multiple unallocated values
draft-ietf-pce-stateful-sync-optimizations specifies and suggests multiple
unallocated values

Recently-expired drafts

draft-ietf-pce-gmpls-pcep-extensions specifies multiple unallocated values
draft-ietf-pce-inter-layer-ext recommends multiple unallocated values


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] [CCAMP] Initial version for liaison text: New Liaison Statement, "Achieving Packet Network Optimization using DWDM Interfaces"

[Fatai Zhang]

 
GMPLS Traffic Engineering, may be a good reference for this document.

·In section 4.4 when talking about SDN, Openflow is mentioned as a 
standard protocol to interact between packet nodes and DWDM nodes. We would 
like to suggest add PCE Protocol (PCEP) as another example, as it is currently 
used in IETF. Besides, it is suggest to reference to RFC 3413 about SNMP, and 
RFC 4208 about GMPLS UNI.

·In section 4.5, [R-36] is not clear whether to be applied to the 
north-bound of SDN controller, or between the packet NE and SDN controller. We 
prefer the latter one.



It seems to us the requirements proposed in the current document could be 
addressed by the referenced RFCs defined for GMPLS, so we would like to make 
sure if you have identified any gaps, which need an update on GMPLS/PCEP to 
satisfy these requirements. IETF CCAMP is discussing to define a framework for 
Management and Control of DWDM optical interface parameters and GMPLS protocols 
that need to be updated, which might be relevant to your project, but this work 
in CCAMP is still in individual drafts stage. We would like to receive your 
input.





Thanks

Daniele



> -Original Message-

> From: CCAMP [mailto:ccamp-boun...@ietf.org] On Behalf Of Zhenghaomian

> Sent: martedì 27 ottobre 2015 18:17

> To: 'cc...@ietf.org<mailto:cc...@ietf.org>'; 
> pce@ietf.org<mailto:pce@ietf.org>; TEAS WG

> Subject: [CCAMP] Initial version for liaison text //答复: CALL FOR

> VOLUNTEER - New Liaison Statement, "Achieving Packet Network

> Optimization using DWDM Interfaces"

>

> Hi, All,

>

> After reviewing the liaison and document from BBF, we would like to provide

> the following text as an initial version for response. Please help review, 
> your

> comments are highly welcomed.

>

> =for

> discussion

> The working groups in IETF routing area would like to thank you for sending

> this liaison. We much appreciate BBF on the effort of packet over optical, and

> sending the document to IETF CCAMP, TEAS and PCE WGs for review. This

> project defines a set of control plane requirements that the Physically

> Separated Model should be satisfied. We are generally fine about the

> content, with some minor suggestions listed as follow for your reference:

>

> • When referring to PCE and related issues, e.g., in [R-26] and [R-27], it

> seems only stateless PCE (RFC4655) and corresponding PCEP (RFC5520) are

> included in the current version. As IETF PCE working group is investigating on

> stateful PCE, PCE Initiation and PCE as a Central Controller, which are 
> planned

> to be published in the future, it is better to specify which kind of PCE is 
> now

> referred by this documents. Moreover, RFC 5623, PCE-based inter-layer

> MPLS and GMPLS Traffic Engineering, may be a good reference for this

> document.

> • In section 4.4 when talking about SDN, Openflow is mentioned as a

> standard protocol to interact between packet nodes and DWDM nodes. We

> would like to suggest add PCE Protocol (PCEP) as another example, as it is

> currently used in IETF. Besides, it is suggest to reference to RFC 3413 about

> SNMP, and RFC 4208 about GMPLS UNI.

> • In section 4.5, [R-36] is not clear whether to be applied to the north-bound

> of SDN controller, or between the packet NE and SDN controller. We prefer

> the latter one.

>

> It seems to us the requirements proposed in the current document could be

> addressed by the referenced RFCs defined for GMPLS, so we would like to

> make sure if you have identified any gaps, which need an update on GMPLS

> to satisfy these requirements. IETF CCAMP is discussing to define a

> framework for Management and Control of DWDM optical interface

> parameters and GMPLS protocols that need to be updated, which might be

> relevant to your project, but this work in CCAMP is still in individual drafts

> stage. We would like to receive your input.

> ======

> 

>

> Thanks.

>

> Best wishes,

> Haomian

>

> -邮件原件-

> 发件人: Zhenghaomian

> 发送时间: 2015年10月21日 11:11

> 收件人: Daniele Ceccarelli; Fatai Zhang

> 抄送: cc...@ietf.org<mailto:cc...@ietf.org>

> 主题: 答复: CALL FOR VOLUNTEER - New Liaison Statement, "Achieving

> Packet Network Optimization using DWDM Interfaces"

>

> Daniele, Fatai and All,

>

> I would like to volunteer for generating the response liaison, as the topic is

> highly related to my research work. I will review the document and share my

> comments early next week. Please also feel free to share you

[Pce] Seeking comments on [draft-ietf-pce-inter-layer-ext]

[Fatai Zhang]

Hi all,

As discussed in BA meeting, the authors are going to refresh this draft, which 
has been expired for long time.

WG review and any comments would be appreciated.





Thanks

Fatai

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

[Pce] 答复: I-D Action: draft-ietf-pce-inter-layer-ext-09.txt

[Fatai Zhang]

Hi all,

As promised in BA meeting, a new version of [inter-layer] has been refreshed, 
with only dates and some editorial changes. 

To Chairs, it is up to you to think about how to move forward this draft, :-)

Anyway, any comments from the WG are still welcome. 



Thanks

Fatai


-邮件原件-
发件人: Pce [mailto:pce-boun...@ietf.org] 代表 internet-dra...@ietf.org
发送时间: 2016年4月25日 17:53
收件人: i-d-annou...@ietf.org
抄送: pce@ietf.org
主题: [Pce] I-D Action: draft-ietf-pce-inter-layer-ext-09.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Computation Element of the IETF.

Title   : Extensions to the Path Computation Element 
communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering
Authors : Eiji Oki
  Tomonori Takeda
  Adrian Farrel
  Fatai Zhang
Filename: draft-ietf-pce-inter-layer-ext-09.txt
Pages   : 18
Date: 2016-04-25

Abstract:
   The Path Computation Element (PCE) provides path computation
   functions in support of traffic engineering in Multiprotocol Label
   Switching (MPLS) and Generalized MPLS (GMPLS) networks.

   MPLS and GMPLS networks may be constructed from layered service
   networks. It is advantageous for overall network efficiency to
   provide end-to-end traffic engineering across multiple network layers
   through a process called inter-layer traffic engineering. PCE is a
   candidate solution for such requirements.

   The PCE communication Protocol (PCEP) is designed as a communication
   protocol between Path Computation Clients (PCCs) and PCEs. This
   document presents PCEP extensions for inter-layer traffic engineering.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-inter-layer-ext/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-pce-inter-layer-ext-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-inter-layer-ext-09


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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] 答复: Whither Stateless PCE?

[Fatai Zhang]

Hi Stephane,

Could you clarify what is interoperability issue in multivendor environment 
(multivendor in one administrative domain?)?

Do you mean there is interoperability issue when vendor 1 supports stateless 
PCE and vendor 2 supports stateful PCE?






Thanks

Fatai

发件人: Pce [mailto:pce-boun...@ietf.org] 代表 stephane.litkow...@orange.com
发送时间: 2016年4月9日 1:04
收件人: DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA); 
adr...@olddog.co.uk; 'Dhruv Dhody'
抄送: pce@ietf.org
主题: Re: [Pce] Whither Stateless PCE?

Hi,

I fully agree that stateful PCE draft needs to be more clear about how a PCC 
retrieves a path when the delegation starts and the LSP has just been 
configured (does it need to compute locally first and then delegate, or do 
PCReq as Olivier proposed …).
I want to add my voice to what Olivier said about the inconsistent behaviors we 
see today in implementations leading to lack of interoperability.
The most important point is that we need to find a solution as soon as possible 
as some people wants to deploy it in multivendor environment and find 
workaround (btw vendor1 and vendor 2) to fix it interop is not the right way to 
go …
This is a question that the WG must work on and close asap.

Best Regards,

Stephane


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of 
olivier.dug...@orange.com
Sent: Friday, April 08, 2016 18:29
To: Aissaoui, Mustapha (Nokia - CA); 
adr...@olddog.co.uk; 'Dhruv Dhody'
Cc: pce@ietf.org
Subject: Re: [Pce] Whither Stateless PCE?

Hello all,

IMHO the discussion must be split into is 2 different subjects:

1/ PCInit message could be seen as an independent message compared to other 
PCReq/PCRep, PCRpt and PCUp. Indeed, the PCE uses the PCInit message after a 
request that comes from another interface (e.g. a RestConf API) instead of 
PCReq that comes from the router itself through PCEP. In fact, when you 
configure a tunnel on the router, only the path computation part is requested 
to the PCE. Complements of tunnel configuration still remain in the router 
configuration. In case of PCInit, all information must be provided to the 
router. This could be for example the traffic steering. So, IMHO, it is normal 
that the PCInit message evolves through extensions different from the other 
PCEP messages, and in particular PCReq, as it is not triggered by the same 
entity, i.e. an external component instead the PCC router itself.

2/ But, this will not make PCReq message obsolete. Indeed, RFC5440 will 
continue to be mandatory for stateful both passive and active mode even if it 
needs clarification in the draft. Let me explain. In passive stateful, a 
PCReq/PCRep sequence is drawn in Figure 7 of the pce stateful draft prior to 
the PCRpt message Now, the ambiguity comes from the active stateful mode and 
figure 8. Why is the PCReq/PCRep sequence not mentioned? Of course the tunnel 
is delegated in this mode, but, the delegation object has been added as an 
extension to the PCReq message in the same draft. So, IMHO, at the creation of 
the tunnel, the draft must precise that a PCReq/PCRep exchange with 
delegation=1 must be used prior to the PCRpt to be coherent with RFC 5440 and 
passive stateful mode.

The problem occured during our evaluation of commercial products on which we 
made interoperability tests. Indeed we observed different behaviours that are 
due to the draft ambiguity and conduct to some interoperability issues. The 
different cases are as follow:
 - a/ - PCReq/PCRep exchange to obtain a valid ERO before the PCRpt message
 - b/ - PCReq message to obtain a valid ERO but with no reaction from the PCE 
which is not conform to RFC5440
 - c/ - PCRpt with empty ERO (looks strange. What is the meaning of an Empty 
ERO ? a loose path ? no path ? )/PCupd to get a valid path which overlaps with 
standard RFC5440 PCReq/PCRep.
 - d/ - PCRpt with empty ERO and no PCUpd leaving the tunnel down.

Thus, PCC/PCE that used PCRpt/PCupd messages for active stateful mode are 
incompatible with PCC/PCE that used standard PCReq/PCrep exchange. We could not 
mix both behaviours (PCC that use PCReq message with PCE that react to PCRpt 
with empty ERO and reciprocally). The problem occurs only at the creation of 
the tunnel. Once created and up the tunnel is reported and updated by means of 
PCRpt / PCupd messages correctly in all cases.

To summarize: PCInit message could leave independently from other messages. 
PCReq is the basis of PCE and is mandatory in all use cases included the active 
stateful mode, but this need to be clarify in the pce stateful draft.

Regards

Olivier
Le 07/04/2016 23:22, Aissaoui, Mustapha (Nokia - CA) a écrit :
Hi Adrian,
I raised in December 2014 the technical issue in draft-ietf-pce-stateful-pce 
that a PCC must be able to convey the original parameters (constraints) of the 
LSP path (Bandwidth, Metric, and LSPA objects) using a PCReq message to a PCE 
and 

[Pce] 答复: Working group last call (including final IPR check) for draft-ietf-pce-wson-rwa-ext

[Fatai Zhang]

Hi Jonathan,
I am not aware of any IPR that applies to this draft.
As a co-author, I believe the document is ready for publication.


Thanks

Fatai

De: Jonathan Hardwick 
<jonathan.hardw...@metaswitch.com<mailto:jonathan.hardw...@metaswitch.com>>
Fecha: miércoles, 30 de noviembre de 2016, 12:34
Para: Leeyoung <leeyo...@huawei.com<mailto:leeyo...@huawei.com>>, Ramon 
Casellas <ramon.casel...@cttc.es<mailto:ramon.casel...@cttc.es>>, Fatai Zhang 
<zhangfa...@huawei.com<mailto:zhangfa...@huawei.com>>, Cyril Margaria 
<cyril.marga...@gmail.com<mailto:cyril.marga...@gmail.com>>, Greg Bernstein 
<gr...@grotto-networking.com<mailto:gr...@grotto-networking.com>>, Oscar 
Gonzalez de Dios 
<oscar.gonzalezded...@telefonica.com<mailto:oscar.gonzalezded...@telefonica.com>>
CC: "pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>" 
<pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>>, Daniele Ceccarelli 
<daniele.ceccare...@ericsson.com<mailto:daniele.ceccare...@ericsson.com>>
Asunto: FW: Working group last call (including final IPR check) for 
draft-ietf-pce-wson-rwa-ext

Dear authors

Please remember to reply to the IPR poll below (copying the PCE list) by 6 
December.

Many thanks
Jon


From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
Sent: 22 November 2016 17:31
To: pce@ietf.org<mailto:pce@ietf.org>; 
draft-ietf-pce-wson-rwa-...@ietf.org<mailto:draft-ietf-pce-wson-rwa-...@ietf.org>
Cc: pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>; Daniele Ceccarelli 
<daniele.ceccare...@ericsson.com<mailto:daniele.ceccare...@ericsson.com>>
Subject: Working group last call (including final IPR check) for 
draft-ietf-pce-wson-rwa-ext

Dear PCE working group,

This email starts a working group last call for draft-ietf-pce-wson-rwa-ext-05.
https://datatracker.ietf.org/doc/draft-ietf-pce-wson-rwa-ext/

Please read the document and reply to the PCE mailing list whether you believe 
this document is ready to be published, or not (including any comments on why 
not).  The last call will end on Tuesday 6 December.

We are also polling for knowledge of any undisclosed IPR that applies to 
draft-ietf-pce-wson-rwa-ext-05, to ensure that IPR has been disclosed in 
compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more 
details) prior to moving forward.  If you are a document author, please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The document won't progress without answers from all the 
authors.  No IPR disclosures currently exist against this document.

Many thanks
Jon, Julien and JP


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

[Pce] 答复: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

[Fatai Zhang]

Hi all,

I share the same understanding as Dieter and Francesco.

I don’t see much value of the stateful path computation, because the computed 
path cannot be guaranteed and it brings much overhead as Francesco pointed.

I think it makes sense if the resource of the stateful path should be reserved 
(or allocatedButNotInUse used by Dieter).




Thanks

Fatai

发件人: CCAMP [mailto:ccamp-boun...@ietf.org] 代表 Francesco Lazzeri
发送时间: 2016年11月7日 16:50
收件人: Igor Bryskin; Dieter Beller
抄送: m...@ietf.org; CCAMP (cc...@ietf.org); Scharf, Michael (Nokia - DE); 
pce@ietf.org; TEAS WG (t...@ietf.org)
主题: Re: [CCAMP] [mpls] 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00


The point here is for how long the provider should keep the computed path and 
its request parameters (in fact if we want to have a possibly better path, at 
any change inside provider topology, resource status and usage, the provider 
should check if the computed path is still feasible and/or redo path 
computation to find a better path). This could be an overhead, in my view.

Furthermore, I can’t see how the provider could export the abstract TE-link, as 
this is inside the client topology; in fact, if the client is asking for a path 
between A and B (A and B inside provider topology), having A’ (in client 
topology) connected to A and B’ (in client topology) connected to B, the 
relevant abstract TE link (the forwarding adjacency) should be built between A’ 
and B’, that is in the client topology; therefore the client should be in 
charge of managing it, as the provider is not aware of A’ and B’.

BR
Francesco

From: CCAMP [mailto:ccamp-boun...@ietf.org] On Behalf Of Igor Bryskin
Sent: 04 November, 2016 7:12 PM
To: Dieter Beller >
Cc: m...@ietf.org; CCAMP 
(cc...@ietf.org) 
>; Scharf, Michael (Nokia - DE) 
>; TEAS WG 
(t...@ietf.org) >; 
pce@ietf.org
Subject: Re: [CCAMP] [mpls] 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Dieter,

A client may ask for a path not to be used immediately (e.g. to present as an 
abstract TE link to its own client, in some failure restoration scheme or as a 
part of disaster recovery network topology re-configuration) without committing 
any network resources. In this case the client would want to know at least  
if/when the path has stopped being feasible any longer or (ideally) a better 
path is available.

This is similar to exposing to a client an abstract TE topology with an 
uncommitted abstract TE link (i.e. TE link that does not have a committed TE 
tunnel supporting it and advertises potentiality). Once such link is provided, 
the provider is expected to send updates when/if the TE link attributes change. 
For uncommitted/potential TE link such updates could be provided based on event 
driven re-computation of the potentiality the TE link represents.
The point is that an uncommitted abstract TE link and COMPUTE_ONLY TE tunnel 
can represent (each in its own way) the same network potentiality

Cheers,
Igor



From: Dieter Beller [mailto:dieter.bel...@nokia.com]
Sent: Friday, November 04, 2016 1:49 PM
To: Igor Bryskin
Cc: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP 
(cc...@ietf.org); pce@ietf.org; 
TEAS WG (t...@ietf.org); 
m...@ietf.org
Subject: Re: [mpls] 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi Igor,

could you please clarify how useful a stateful path without resource allocation 
is. I can't see the benefits of this use case.


Thanks,
Dieter
On 04.11.2016 14:25, Igor Bryskin wrote:
Hi Dieter,

A provider may compute path(s) for a TE tunnel, and then (without any resource 
allocation) may start monitoring/ensuring the path validity/optimality by 
re-computing them in an event driven manner. For example, it can trigger the 
re-computation of the path(s) when detecting a change in a state of a TE link 
the current path(s) are going through.  Depending on the results additional 
notifications may be sent to the client.

Note that this is in addition to the reasons you correctly identified for 
implementing stateful path computation (such as compute_and_reserve).

Cheers,
Igor


From: Beller, Dieter (Nokia - DE) [mailto:dieter.bel...@nokia.com]
Sent: Thursday, November 03, 2016 6:27 PM
To: Leeyoung
Cc: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; CCAMP 
(cc...@ietf.org); pce@ietf.org; 
TEAS WG (t...@ietf.org); 
m...@ietf.org
Subject: Re: [mpls] 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00


Hi all,



when we talk 

[Pce] 答复: [mpls] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

[Fatai Zhang]

Hi Igor,

I think the client will still meet the case that there is no available path for 
the client.

The provider will have no chance to re-plan the path when the client knows the 
unfeasibility ahead of short time (e.g., milliseconds before it really needs 
the path) or the client knows the unfeasibility ahead of much time (e.g., hours 
or days) before it really needs, but there is no sufficient available resource 
for the provider to re-plan unless the operators add more physical nodes or 
links.

I think the stateful path computation is a kind of “best effort”, and it might 
be suitable for IP service, but for the transport service, the protection 
capability(as you mentioned a failure recovery or congestion avoidance strategy 
or disaster topology re-configuration) MUST be guaranteed (at least for one 
single failure) if the client really relies on that.

I think the simple way to guarantee the protection (or whatever) capability is 
to reserve the resource for the desired path and the reserved resource could be 
shared among multiple path (This is the concept of Shared Mesh Protection I 
introduced in ITU-T SG15 a few years ago, but here we can just reserve the 
resource from the control plane perspective rather than reserve the resource on 
the data plane through SMP mechanism).



Thanks

Fatai

发件人: Igor Bryskin
发送时间: 2016年11月9日 23:56
收件人: Francesco Lazzeri; Fatai Zhang; Dieter Beller
抄送: m...@ietf.org; CCAMP (cc...@ietf.org); Scharf, Michael (Nokia - DE); 
pce@ietf.org; TEAS WG (t...@ietf.org)
主题: RE: [mpls] 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Francesco,

Please, see in-line.

Igor



From: Teas [mailto:teas-boun...@ietf.org] On Behalf Of Francesco Lazzeri
Sent: Wednesday, November 09, 2016 10:27 AM
To: Igor Bryskin; Fatai Zhang; Dieter Beller
Cc: m...@ietf.org<mailto:m...@ietf.org>; CCAMP 
(cc...@ietf.org<mailto:cc...@ietf.org>); Scharf, Michael (Nokia - DE); 
pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (t...@ietf.org<mailto:t...@ietf.org>)
Subject: Re: [Teas] [mpls] 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Igor,


1)  IMHO simplicity pays back. Instead than maintaining all these states, 
notifying clients all the times something changes, and repeating 
path-computation as needed, isn’t better for a client (and provider) to ask 
what is needed when it’s needed, and get the best result back at that moment ?
IB>> What happens it the provider at this moment says: “ No, I have nothing for 
you” ?  What if the path was relied upon by the client for a failure recovery 
or congestion avoidance strategy or disaster topology re-configuration?
   FL>> Probably the same in case the provider notifies “Hey, I have no 
longer anything for you”.

IB>> But this would be a bit too late, wouldn’t it? Wouldn’t it be better if 
the client has learnt about the previously returned path unfeasibility ahead of 
time, so that it could re-plan it’s failure recovery scheme?

If there is no (more) path, there is no path. The client could only try and 
crankback looking for some different path or report an alarm.

IB>> Relying on crankbaks in an unpredictable way is not exactly a good 
solution, right?

The scenario that seems more applicable to your proposal is a pre-planned 
restoration mechanism where we have a worker path in-service and a protection 
path just computed (but not reserving network resources, in order to share them 
among several protection paths), in a multi-domain network. In that case, 
reserving te-tunnels like you suggest, could give an advantage, as the 
end-to-end cranckback could occur when the notification with “no-path” is 
triggered by the provider (that means the protection path or some of its 
segments is no longer valid) and not when the path deployment is triggered by 
the client (that means the worker path is gone and we need the protection 
immediately). Is this the case you are considering ?

IB>> Exactly. All the scenarios you can think of where you don’t know when and 
where a problem may happen and you want to maintain flexibility and share the 
network resources to protect as much as you can

In other cases, as when used during an end-to-end path computation with 
immediate deployment to reduce the possibility of conflicts among concurrent 
procedures, it seems to me less important or applicable, as all these 
procedures will likely be orchestrated by the same entity, which could well 
avoid conflicts.

IB>> All cases where the provider wants to expose a potentiality without 
committing resources to cover for the client multiple use cases and provide at 
the same time some degree (albeit not perfect) predictability.




2)  Regarding the abstract link in the overlay topology, I still can’t see 
what the provider will advertise. If it’s a new link representing the 
forwarding adjacency between A’ and B’, how it will be represented by the 
pro

[Pce] 答复: Working group last call (including final IPR check) for draft-ietf-pce-inter-layer-ext-09

[Fatai Zhang]

Hi all,

I am not aware of any IPR that applies to this document.

(Sorry, if my response did not go the list because of mail server problem).


Thanks

Fatai

发件人: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
发送时间: 2016年8月24日 19:30
收件人: pce@ietf.org; draft-ietf-pce-inter-layer-...@ietf.org
抄送: pce-cha...@ietf.org
主题: Working group last call (including final IPR check) for 
draft-ietf-pce-inter-layer-ext-09

Dear PCE working group,

This email starts a working group last call for 
draft-ietf-pce-inter-layer-ext-09.
https://datatracker.ietf.org/doc/draft-ietf-pce-inter-layer-ext/

Please read the document and reply to the PCE mailing list whether you believe 
this document is ready to be published, or not (including any comments on why 
not).  The last call will end on Friday 9 September.

We are also polling for knowledge of any undisclosed IPR that applies to 
draft-ietf-pce-inter-layer-ext-09, to ensure that IPR has been disclosed in 
compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more 
details) prior to moving forward.  If you are a document author, please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The document won't progress without answers from all the 
authors.  No IPR disclosures currently exist against this document.

Many thanks
Jon, JP and Julien

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

[Pce] 答复: [Teas] FlexE side meeting on Monday 17, at 18.30 - 20.00

[Fatai Zhang]

Hi Loa,

Thanks for your effort. 

I think you missed the leading actor: CCAMP WG, :-).

Forwarded to CCAMP as well. 




Thanks

Fatai


-邮件原件-
发件人: Teas [mailto:teas-boun...@ietf.org] 代表 Loa Andersson
发送时间: 2017年3月17日 9:17
收件人: draft-izh-ccamp-flexe-...@ietf.org; mpls-cha...@ietf.org; pce@ietf.org; 
TEAS WG; routing-discuss...@ietf.org
抄送: Ignas Bagdonas; ccamp-cha...@tools.ietf.org; Deborah A Brungard; Andrew G. 
Malis; n.leym...@telekom.de; draft-izh-ccamp-flexe-...@ietf.org; Stewart Bryant
主题: [Teas] FlexE side meeting on Monday 17, at 18.30 - 20.00

Folks,

On Monday March 27 in Zurich B , there will be a FlexE side meeting from 
18:30-20:00. The meeting will be chaired bt Daniele Ceccarelli and Nic Leyman. 
The initiative for this meeting were taken within the group that works on a 
FlexE Framework document (draft-izh-ccamp- flexe-fwk), and has been sponsored 
by Deborah Brungard and the ccamp working group co-chairs.

The intent is to bring people up to speed on the FlexE technology and try to 
understand what work will be appropriate to do in the IETF.

The agenda will be:

1. FlexE background and origins: Haomian Zheng
2. FlexE Technology Deep Dive:   Iftekhar Hussain
3. FlexE in the IETF:Mach Chen
4. Open Mic

Each presentation is panned to last 20 min, and the Open Mic 30 min.


/Daniele, Fatai and Loa
-- 


Loa Anderssonemail: l...@mail01.huawei.com
Senior MPLS Expert  l...@pi.nu
Huawei Technologies (consultant) phone: +46 739 81 21 64

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

[Pce] 答复: Poll for adoption: draft-dhodylee-pce-stateful-hpce

[Fatai Zhang]

Yes/support.




Thanks

Fatai

发件人: Pce [mailto:pce-boun...@ietf.org] 代表 Jonathan Hardwick
发送时间: 2017年6月1日 20:25
收件人: pce@ietf.org
抄送: draft-dhodylee-pce-stateful-h...@ietf.org; pce-cha...@ietf.org
主题: [Pce] Poll for adoption: draft-dhodylee-pce-stateful-hpce

All,

This is the start of a two week poll on making 
draft-dhodylee-pce-stateful-hpce-03 a PCE working group document.
https://datatracker.ietf.org/doc/draft-dhodylee-pce-stateful-hpce/


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 Thursday, June 15.



Many thanks,
Jon

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

[Pce] 答复: Building the PCE Agenda for IETF 103

[Fatai Zhang]

Hi Dhruv,

When I clicked the link you provided, it went to 
https://datatracker..ietf.org/meeting/103/materials/agenda-103-pce/, and it 
showed something wrong.

I think the correct link should be: 
https://datatracker.ietf.org/meeting/103/materials/agenda-103-pce/




Thanks

Fatai

发件人: Pce [mailto:pce-boun...@ietf.org] 代表 Dhruv Dhody
发送时间: 2018年10月25日 16:14
收件人: pce@ietf.org
抄送: pce-cha...@ietf.org
主题: Re: [Pce] Building the PCE Agenda for IETF 103

Hi WG,

The draft agenda is published - 
https://datatracker.ietf.org/meeting/103/materials/agenda-103-pce/

Please send the meeting slides to both your chairs and the secretery by Friday 
2nd November. Since we are scheduled for Monday it is important to upload the 
meeting material in advance.

Thanks!
Dhruv, (Jon & Julien)

On Wed, Oct 10, 2018 at 10:09 AM Dhruv Dhody 
mailto:dhruv.i...@gmail.com>> wrote:
Hi WG,

The PCE WG session in Bangkok is tentatively scheduled for Monday afternoon
[1]. If you need some face-to-face time to progress some work, please send
a slot request to the secretary and the chairs by Monday October 22nd
including:
- the draft(s) you want to discuss,
- the expected presenter name,
- the requested duration, including question time as part of the slot,
- the reason why you need face-to-face time as opposed to using the mailing
list (open 24/7).

Thank you,
Dhruv, Jon & Julien

[1] https://datatracker.ietf.org/meeting/103/agenda.html
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] 答复: Building the PCE Agenda for IETF 103

[Fatai Zhang]

OK, thanks.

It seems that it is mischievous only on my machine, ☺






Thanks

Fatai

发件人: Belotti, Sergio (Nokia - IT/Vimercate) [mailto:sergio.belo...@nokia.com]
发送时间: 2018年10月25日 17:45
收件人: Dhruv Dhody ; Fatai Zhang 
抄送: pce@ietf.org; pce-cha...@ietf.org
主题: RE: [Pce] Building the PCE Agenda for IETF 103

Hi Dhruv, Fatai,

Link is working properly also on my machine.

My 2 cents
Thanks
sergio

From: Pce mailto:pce-boun...@ietf.org>> On Behalf Of 
Dhruv Dhody
Sent: Thursday, October 25, 2018 11:39 AM
To: Fatai Zhang mailto:zhangfa...@huawei.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>; 
pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>
Subject: Re: [Pce] Building the PCE Agenda for IETF 103

Hi Fatai,

The link works on my machine(s) (i tried on all of them). I dont see the ".." 
in the email [1].
Maybe your local issue?

Thanks!
Dhruv
[1] https://www.ietf.org/mail-archive/web/pce/current/msg06061.html

On Thu, Oct 25, 2018 at 3:04 PM Fatai Zhang 
mailto:zhangfa...@huawei.com>> wrote:
Hi Dhruv,

When I clicked the link you provided, it went to 
https://datatracker..ietf.org/meeting/103/materials/agenda-103-pce/, and it 
showed something wrong.

I think the correct link should be: 
https://datatracker.ietf.org/meeting/103/materials/agenda-103-pce/




Thanks

Fatai

发件人: Pce [mailto:pce-boun...@ietf.org<mailto:pce-boun...@ietf.org>] 代表 Dhruv 
Dhody
发送时间: 2018年10月25日 16:14
收件人: p...@ietf..org<mailto:pce@ietf.org>
抄送: pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>
主题: Re: [Pce] Building the PCE Agenda for IETF 103

Hi WG,

The draft agenda is published - 
https://datatracker.ietf.org/meeting/103/materials/agenda-103-pce/<https://datatracker..ietf.org/meeting/103/materials/agenda-103-pce/>

Please send the meeting slides to both your chairs and the secretery by Friday 
2nd November. Since we are scheduled for Monday it is important to upload the 
meeting material in advance.

Thanks!
Dhruv, (Jon & Julien)

On Wed, Oct 10, 2018 at 10:09 AM Dhruv Dhody 
mailto:dhruv.i...@gmail.com>> wrote:
Hi WG,

The PCE WG session in Bangkok is tentatively scheduled for Monday afternoon
[1]. If you need some face-to-face time to progress some work, please send
a slot request to the secretary and the chairs by Monday October 22nd
including:
- the draft(s) you want to discuss,
- the expected presenter name,
- the requested duration, including question time as part of the slot,
- the reason why you need face-to-face time as opposed to using the mailing
list (open 24/7).

Thank you,
Dhruv, Jon & Julien

[1] https://datatracker.ietf.org/meeting/103/agenda.html
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[Fatai Zhang]

Hi,

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






Thanks

Fatai

-邮件原件-
发件人: Julien Meuric [mailto:julien.meu...@orange.com] 
发送时间: 2018年9月7日 0:01
收件人: draft-ietf-pce-hierarchy-extensi...@ietf.org
抄送: pce@ietf.org
主题: IPR Check on draft-ietf-pce-hierarchy-extensions

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] 答复: Replacing Jon as PCE Co-Chair

[Fatai Zhang]

Jon, Thanks for your great contribution to PCE WG!

Congratulations to Dhruv (and Adrian)!

I think PCE WG would be the most popular WG of RTG since it is the only one 
with three chairs and Adrian – one of the founders of PCE WG, ☺



Thanks

Fatai


From: Pce mailto:pce-boun...@ietf.org>> On Behalf Of 
BRUNGARD, DEBORAH A
Sent: 28 January 2019 16:13
To: pce@ietf.org
Cc: mailto:rtg-...@ietf.org>> 
(rtg-...@ietf.org) 
mailto:rtg-...@ietf.org>>; 
pce-cha...@ietf.org
Subject: [Pce] Replacing Jon as PCE Co-Chair

Hi PCEers,

As announced at IETF103, Jon Hardwick has requested to step down as PCE 
Co-Chair. We thank him for his many years of service and wish him all the best!

As Jon is very difficult to replace and to help Julien over these next several 
months, I’ve decided to replace Jon with two Co-Chairs: Dhruv Dhody and Adrian 
Farrel.

Dhruv is one of our top lead technical contributors in PCE and he is currently 
the PCE secretary. I am sure he will be fantastic in his new role as Co-Chair. 
The difficulty is that he is a co-author on a high proportion of the PCE drafts 
and that is not a good thing for a Chair as it will severely burden the other 
Co-Chair with managing those documents. Because of this difficulty, I’ve asked 
Dhruv to re-allocate authorship on a majority of his drafts as quickly as 
possible. Dhruv has agreed.

While Dhruv is learning the ropes of being a Chair and re-distributing his 
drafts, I’ve asked Adrian to help. Adrian, of course, is well known to all of 
us. No introduction needed

It is expected Adrian will only be needed for approximately 4 months.

Welcome to both Dhruv and Adrian!

Thanks!
Deborah

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