Subject: RE: [Pce] Draft PCE WG Minutes - IETF-63

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Fri, 26 Aug 2005 12:05:07 +0200

Hi JP, all

A few minor edits in the minutes

> JL: I have a major concern on scalability with the draft's 
> approach, one major bottleneck is on the PCE-PCE signaling,

on the PCC-PCE signaling
 
> we should minimize the signaling, the objective is to have 
> distribution to reduce this, whereas this draft re-introduces 
> this overhead for synchronization.  

> You are redefining the concept of cluster. Why not use the PCE 
>engine?

Why not rather use a single PCE and clusterize the PCE engine?

> One major bottleneck on the PCE architecture is the pcc-pce 
> signalling. To ensure path computation, reduce the number of 
> path computation requirements received by a pce.

the number of path computation requests

Regards,

JL

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de JP Vasseur
> Envoyé : samedi 13 août 2005 16:21
> À : [email-masked]
> Objet : [Pce] Draft PCE WG Minutes - IETF-63
> 
> (Please comment by August 27th)
> 
> ----------------------------------
> PCE Working Group meeting minutes
> ----------------------------------
> 
> IETF-63 - Paris, France - Tuesday, August 2, 2005.
> 
> (Thanks to Jaudelice and Deborah for having taken the minutes)
> 
> ------------------
> 1. Agenda (Adrian)
> ------------------
> 1) Agenda/Admin (10mn)
> 2) Progress against milestones (5mn)
> 3) Drafts (55mn)
>      - draft-ietf-pce-architecture-01.txt (Farrel - 10mn)
>      - draft-ietf-pce-discovery-reqs-01.txt (Le Roux 'Äì 10mn)
>      - draft-ietf-pce-comm-protocol-gen-reqs-01.txt (Ash - 10mn)
>      - draft-zhang-pce-comm-app-model-01.txt (Zhang - 5mn)
>      - draft-vasseur-pce-pcep-01.txt (Vasseur - 10mn)
>      - draft-choi-pce-metric-protocol-02.txt (Choi - 10mn)
> 4) Working Group next steps (20mn)
> 
> -----------------------------------
> 2. Progress against Milestones (JP)
> -----------------------------------
> 
> 1. Submit first draft of PCE architecture document: done 2. 
> Submit first draft of PCE discovery requirements and protocol 
> extensions documents
>     (half-done: PCE discovery requirements ID is done) 3. 
> Submit first draft of the PCE communication protocol requirements
> (done)
> 4. Definition of the objective metrics (to be done later - 
> more progress required on other IDs first) 5. PCE 
> communication protocol specification (decision to be made by 
> the WG soon)
> 
> -----------------------------------------------------------------
> PCE Architecture ID: draft-ietf-pce-architecture-01.txt (Adrian)
> -----------------------------------------------------------------
> 
> Adrian thanked everyone that contributed to help get this 
> version out Mainly editorial revisions resulting from 
> Minneapolis meeting have been done (Clarifications, but 
> nothing major) More a framework, and an architecture overview 
> and deployment scenarios.
> Describes the architectural overview and building blocks Many 
> mailing list comments and private comments Not any major 
> substantial changes Plan to add discussion of policy, will 
> separate exchange of policy info in the PCE communication and 
> the use of policy within the architecture
> 
> Question (?): present a functional view as well as component view?
> 
> Adrian: currently view point is third dimension
> 
> Arthi: policy - how will it be addressed in the document?
> 
> Adrian: the current doc will only have something high level - 
> Lou will provide draft text
> 
> Igor: when I issue a path request, can I disallow paths 
> requiring distributed computation,
> 
> Adrian: that's something for the computation
> 
> Dimitri: is this the only document for policy or we will do 
> something else ?
> 
> JP: we need requirements and solution detailed in a separate ID.
> 
> Lou: we had discussion, as Adrian said, we will have later a 
> standalone document with more details after we have more 
> discussion in the WG
> 
> Dimitri: in other WG, are discussing policy for interdomain, 
> need that for this group
> 
> Adrian - agree
> 
> Plans: architecture is believed to be stable but needs 
> discussions resulting from emails on the list.
> 
> --------------------------------------------------------------
> ----------
> ----------
> Requirements for PCE Discovery: draft-ietf-pce-discovery-reqs-01.txt
> (Jean-Louis)
> --------------------------------------------------------------
> ----------
> ----------
> 
> Set of requiretments for automatic pce discovery
> 
> comments and discussions on the list have been addressed in 
> the new version -01
> * multi-area example
> * application scenario
> * reorganized PCE info to be disclosed (mandatory versus optional)
> 
> It must be noted that this is optional in the pce discovery 
> mechanism, not necessarily optional for pce architecture,
> * extensibility section
> * security requirements
> * PCE capabilities definition is out of the scope (should be 
> in a separate document)
> 
> Open issues:
> - two stage discovery ? should limit to basic or include more 
> detailed - all as part of this document
> - security trust model- need to detail requirements
> - need feedback on discovery of pce power and congestion 
> status - should be part of this discovery mechanism or as 
> part of a more detailed requirements phase?
> 
> Next steps:
> 
> * address open issues
> 
> Discussion
> 
> Dimitri: the question on one or two stage, for me it's the 
> question how many pces will we have - if only a small group, 
> then number of sessions, with more detailed information, can 
> be supported. Tradeoffs if small set, and all receive 
> information, or if a lot of PCEs, may want only the subset 
> that needs to know.
> 
> JP: could use a flooding based mechanism
> 
> Dimitri: but what is expected then on the use of this information ?
> 
> Arthi: It is premature to talk about solution. Do we have a 
> sense of what direction we might be taking? On the section on 
> scalability:  
> number of pce pccs are factors but also should consider the 
> load on a pce.
> The details that you have might not be relevant to a PCE.
> 
> Dimitri: should say if the info is of interest to all the pces or not
> 
> Arthi: I'm less concerned with the PCE if the PCE is itself a PCC
> 
> Igor: Flooding is good, but it has problems: scalability and 
> security. You still want to know the capabilities of pce so 
> you may need to establish a session.
> 
> JP: we may now be discussing solutions on how to do basic 
> capabilities and additional capabilities
> 
> Igor: we will need this discussion though
> 
> JP:  I don't see this as pce discovery, this is a 
> capabilities exchange
> 
> JL: Do you have an idea of a communication protocol
> 
> Igor: It should not be flooding.
> 
> JL: For general discovery we should use flooding.
> 
> JL: You must be able to control to which pcc you will be 
> disclosing the information: all pccs in an area, etc.
> 
> Adrian: the draft though today does include some capabilities
> 
> Dimitri: can you provide requirements on more the dynamics 
> needed for these capabilities
> 
> JP: A limited number of capabilities such as the congestion 
> parameter is likely to be dynamic
> 
> Richard: propose discuss possible solutions over email 
> exchange, even though it's not to be included in the 
> requirements, the discussion helps to understand
> 
> Arthi: agree should discuss to an extend some of the solutions
> 
> JP: thanks to quickly resolve the set of open issues. The 
> draft should then be ready for Working Group LC.
> 
> ------------------------------------------------
> PCE Communication Protocol
>  Generic Requirements
> draft-ietf-pce-comm-protocol-gen-reqs-01.txt
> (Jerry)
> -----------------------------------------------
> 
> Generic requirements applicable to all PCEs
> 
> application-specific requirements to be addressed in separate 
> requirements documents
> 
> A table with a summary is included.
> 
> Open Issues
> 
> * requirements for less constrained path requests/response
> * requirements for responsiveness & session maintenance
> * detailed requirements on throttling messages under overload
> * specify 'boundary' numbers on scalability
> * clearly state supported policy models & corresponding 
> requirements/ implications
> * avoid feature creep
> * need to progress application-specific requirements
> * PCE  protocol proposal needs to identify how generic & 
> application- specific requirements are met
> 
> Discussion:
> 
> JP: Detailed scalability issues are related to implementation.
> 
> Adrian: we need a range as don't want protocol to provide the limit
> 
> JP: on the less-constrained path computation topic, we don't 
> have a consensus yet, we should have a separate document
> 
> Arthi: we had a discussion in the pwe group that there may be 
> requirements for pce
> 
> Adrian: by us splitting the document between generic and 
> extended reqs (more application specific) we could handle this better
> 
> Arthi: also though may not be in scope
> 
> Adrian: yes we should say if it's out of scope
> 
> Arthi: Some new requirements may come up for PCE, we need to 
> have a plan on how to address that.
> 
> Adrian: The document is extensible.
> 
> Arthi: We might see other consumers of PCE
> 
> JP: Sure and the protocol should be designed to handle 
> extensions so as to meet new requirements but we may need to recharter
> 
> ---------------------------------------------
> PCE Communication Protocol Application Model 
> draft-zhang-pce-comm-app-model-01.txt
> (Zhang)
> --------------------------------------------
> 
> * how to avoid contention with TE link fails
> * how to load balance among PCEs
> * how to update the PCEs about resource allocation
> 
> JP asked who has read the draft: good show of hands
> 
> Adrian: rather than saying this is the way forward, would 
> prefer emphasis on what are the requirements
> 
> (coauthor of the draft ??): this draft addresses a way to ...
> 
> Adrian: yes, this draft has requirements on an 
> implementation, would like first to see top level 
> requirements and architecture
> 
> Igor: one of the requirements for the protocol is getting 
> updates, etc,
> 
> Adrian: first need requirements
> 
> Igor: my view this is not a signaling protocol, not rsvp, we 
> shouldn't go thru the process of using a signaling protocol
> 
> JL: I have a major concern on scalability with the draft's 
> approach, one major bottleneck is on the PCE-PCE signaling, 
> we should minimize the signaling, the objective is to have 
> distribution to reduce this, whereas this draft re-introduces 
> this overhead for synchronization.  
> You are redefining the concept of cluster. Why not use the PCE engine?
> One major bottleneck on the PCE architecture is the pcc-pce 
> signalling. To ensure path computation, reduce the number of 
> path computation requirements received by a pce.
> 
> Author: it does not consume much bandwidth.
> 
> JL: It is not a problem of bandwidth but communication overhead.
> 
> JP: I have similar concerns. Have you tried to evaluate what 
> would be the overhead in term of extra signaling due to this 
> mechanism? One way to roughly evaluate would be by using simulations.
> 
> Adrian: best for us to discuss over email to provide adequate 
> time for the discussion.
> 
> -------------------------------------------------------------
> Path Computation Element (PCE) communication Protocol (PCEP)
> 
> draft-vasseur-pce-pcep-01.txt
> (JP)
> --------------------------------------------------------------
> 
> PCC-PCE and between PCEs communication
> 
> There were two proposals in the past which were discontinued 
> and a completely new protocol has been designed (PCEP) highly 
> driven by the PCE WG requirement document. Chief objective 
> was to make it extensible to cope with future requirements.
> 
> Major changes from 00 to 01:
> * rewritten for clarity
> * few sections removed
> * new section on protocol model
> * added security consideration
> * very rough manageability consideration section added (to be fleshed
> out)
> * two new objects defined
> 
> Unique communication protocol for PCC-PCE and PCE-PCE.
> 
> Summary - pcep meets most of the requirements.
> 
> Open issues (need inputs from the working group)
> 
> * Objective functions needs to be defined (next revision)
> * Protocol recovery: requires more detailed requirements
> * Policy: requires more discussion
> 
> Discussion
> 
> Bijan Jabbari: What was the reason for TCP?
> 
> JP: reliability and flow control. TCP was a very good 
> candidate for that.
> 
> Bijan: Question of scalability of TCP.
> 
> JP (vendor hat): We do not see any scalability issue with TCP.  
> Current TCP implementations can support a very high number of 
> TCP sessions.
> 
> Question (?). You are creating a new protocol. Did you do an 
> analisys on existing protocols and reaons for not using them?
> 
> Adrian: yes we did , but here formal requirement for the WG 
> to take reqs to other groups to ask if have anything, so this 
> draft progressing depends on answer.
> 
> Lou: Many protocols have been worked on. Instead of 
> reinventing the weel, why not use one already existing. What 
> we are doing here in path computation is a new application, 
> but session application (keep alive, discovery) have been 
> resolved before and it would be great to concentrate on what 
> is related to pce.
> 
> Adrian: great if we can learn lessons
> 
> Lou: and reuse
> 
> Adrian: agree
> 
> Dimitri: agree as Lou said
> 
> Lou: session management, keep alives, etc have been done already
> 
> JP: the question is, is there anything specifics to PCE that 
> we need a new protocol
> 
> Dimitri: With a new solution we will have to pass all the 
> stages the others have passed to achieve a robust solution.
> 
> JP: That's why we have the question here.
> 
> Adrian: yes, this protocol in this draft has not been selected
> 
> Bijan: If this is IP only, was DNS discussed?
> 
> Adrian: this is IP only
> 
> Bijan: have we looked at DNS ?
> 
> Adrian: bring it to the list to suggest
> 
> Lou: Comment on need to go back and use an existing mechanism 
> whenever you can.
> 
> JP: yes, whenever you can.
> 
> Loa: if we have TCP, then we have a basis, to do more, we 
> need justification,
> JP: agree
> 
> Jerry: can you include what is met and not met on 
> requirements into the draft ?
> 
> JP: ok, will do.
> 
> Jerry: if we do not have a list of requirements, how can we proceed?
> 
> Yakov: Comment on the need for protocol specific keep-alive: 
> we need a PCE specific keep-alive protocol since TCP will not 
> take care of it.
> 
> JP: fully agree.
> 
> Lou: You need keep-alive (TCP-based solutions already have 
> keep- alives). Find out what's the requirement, then lift the 
> existing solution.
> 
> Lou: my comment is to look at experience - e.g. if need 
> keepalives, it's a mistake to look at this again without 
> considering previous work, and do all the requirements all 
> over again, should look at existing protocols, transaction semantics
> 
> Adrian: yes, persistency should be addressed in the requirements
> 
> Sue: keepalives in a protocol is needed in addition to tcp, 
> need to pay careful attention to the state machine 
> interaction between the two - pcc-pce. Need to ensure handle 
> failure scenarios, noticed missing here some of what protocol 
> has to solve, should feed back into requirements
> 
> JP: Sometimes you do not want a permanent session, and 
> sometimes you do. Do we need two modes?
> 
> Adrian: question should be asked to the requirements team.
> 
> JL: we should be more flexible and support both request and 
> permanent as it will depend on the request, and number of 
> pces to maintain, may have a full mesh and may not want to 
> maintain a permanent
> 
> JP: this is what we heard - may only need on request, other 
> times will need permanent, so may want both modes, and 
> negotiate upon session establishment.
> 
> Adrian: when doing the solutions and have a question, should 
> take back to the requirements folks
> 
> JP: Less-constrained path computation aspects will be removed 
> from this draft and be worked out in a separate ID.
> 
> ------------------------------------------------
> Path Computation Element Metric Protocol (PCEMP)
> 
> draft-choi-pce-metric-protocol-02.txt
> (Dipnarayan Guha)
> ------------------------------------------------
> 
> PCE metric protocol (PCEMP): generic routing and path 
> computation protocol targeted towards inter-domain pce peers.
> 
> Reviewed slides
> 
> JP: we encourage you to provide simulation results to the 
> mailing list it will help
> 
> No discussion
> 
> ------------------------------
> working group next steps (JP)
> ------------------------------
> 
> - new revision of the PCE architecture ID to be published 
> soon (WG last call soon after this ietf)
> - new revision of the generic pce communication requirement 
> ID (WG last call soon after this ietf)
> - submit a new ID for pce discovery protocol extensions 
> (minor protocol work only)
> 
> Start application-specific requirements IDs for PCE based computation
> 
> *Inter-area: Jean-Louis
> *Inter-As: Raymond, Nabil
> 
> JP: note that such ID must be PCE-specific (take into account 
> RFC4105 and inter-as requirements ID produced by the TE WG).
> 
> Adrian: WG to decide on which pce communication protocol 
> solution to pursue
> - two proposals presented
> - selection of one solution as a basis now does not imply 
> rejecting good points of other solution nor accepting bad 
> points of selected solutions.
> If pick one, that does not prevent us from taking the best of 
> other one also, and also other ietf protocols. email will be 
> sent to the application ADs to ask their input.
> 
> - New ID on the less contrained path problem comprising the 
> requirement + solution
> 
> - Need to verify the solution model for inter-domain pce with 
> CCAMP, MPLS working groups
> 
> Adrian - other application specific requirements IDs (interlayer,
> p2mp) should continue their work, just realize other work 
> needs to be done first:
>      inter-layer: Eiji, Kenji
>      P2MP: Seisho (currently out of scope of PCE WG charter)
> 
> Thanks.
> 
> JP.
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pce
> 

_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: JP Vasseur <[email-masked]>
Date: Tue, 30 Aug 2005 11:14:16 -0400

Hi Jean-Louis,

Thanks for the modifications, they will be incorporated.

JP.