Dear WG,
Please find attached the PCE WG minutes - IETF-66. If you have any
comment, please let us know by Sep 1.
Thanks.
JP and Adrian.
Draft PCE WG Minutes IETF-66 Montreal July-66
Many Thanks to Sherif Awad and Zafar Ali for having taken the minutes.
2) Working Group progress (Chairs - 10mn): see slides
Comment from Jean Louis Le Roux (JL) : PCE Inter-area requirements ID is quite
stable and last call is coming up. The policy section has been updated and the
ID is ready for WG last call.
3) Update on Manageability Considerations (Adrian - 5mn)
Adrian> After last IETF we talked about making a requirement for the IDs to
have a Manageability considerations section. We received good feedback. Some
resistance, as it makes process too heavy. We are talking to ADs about it in
OPS. We have supports from them for this but we need to nail down the "what and
how". Next step is to write an ID. Still needs to be discussed since might be
to processes heavy.
Adrian asked if some one thinks this is a bad idea. No objection raised.
4) Inter-AS Requirements for the Path Computation Element Communication
Protocol (PCECP) - draft-bitar-zhang-interas-pcecp-reqs-01.txt
(Nabil - 10mn)
Nabil requested for draft to be a WG draft and for WG feedback.
JP> This a major rework since the previous revision had several sections that
had to be reworded or removed (out of the scope). Now the draft is much better
scoped. Show of hand on who read the doc. Very good. Who in favor; Good
support. Anyone in opposition? No one opposed. Good support, we will confirm
on the list.
5) Update on Path Computation Element (PCE) Communication Protocol (PCEP)
draft-ietf-pce-pcep-02.txt (JL Le Roux - 10mn)
Major update to this version is addition of the FSM. JL described the FSM.
JL Asked for WG feedback especially on the recent updates.
JP> We had some discussion on scoping of this document and the goal here is to
freeze PCEP document changes at this stage to consolidate the basics before
adding further extensions. There are 3-4 on going implementation. We would like
to get interops results hopefully before LC.
Adrian> The protocol spec is reaching a level of stability, on going
implementations may find some holes.
Dimitri asked for clarification on usage of P/ I flag.
JL> this is clearly stated in the document.
JP asked for more discussions on the Mailing List.
Richard Rabat asked for some explanation on potential race condition on Two TCP
connection requests at the same time. Explanation was provided.
Adrian/JP suggested extensive WG review on the next revision.
6) Update on PCE Discovery protocol - draft-ietf-pce-disco-proto-igp-02.txt
(Jean-Louis Le Roux - 10mn)
JL> Requirement ID is stable and in final stage.
JP: There is an implementation.
JL requested WG LC.
JP asked Ross (AD) for feedback on splitting the document into two: one for
ISIS and one for OSPF.
Ross> What are the possible deltas; if this doc is 40 pages, will we end up
with two doc of 35 pages, each?
JP> Delta is small, e.g., semantics are common. We expect two doc of approx. 25
pages each.
Lou> There has to be two documents; when we claim implementations for the
RFC-es, implementing for one protocol cannot claim implementation for other
protocols.
Ross> This is a good reason for the split. Makes more sense to Split.
JL> Shall we make changes and do the split at the end? Or shall we split now.
JP> Splitting at the very end makes more sense.
Adrian> Split also makes it easier to do cross WG review easier.
Emile Stefan> Split will impact the MIB document and lead to some duplicate
work.
Adrian> We have done similar split for the GMPLS Signaling Document in the
past.
Emile still showed concerns.
Adrian asked to talk more off-line.
7) Definitions of Managed Objects for Path Computation Element Discovery
Protocol (PCEDP) inside a Path Computation Client (PCC)
draft-stephan-pce-pcedp-pcc-mib-00
JL> Congestion seems to be for PCE and not PCC MIB modules.
Adrian> We should not flood the notification process.
Adrian suggested moving textual conventions to a separate document and MIB
module so they can be re-used. Emile brought up the point that have a new MIB
module RFC for two textual convention might be a bit strange but Adrian pointed
out this was fine and more textual conventions are still coming.
Adrian asked that since the PCE might discover other PCE's in the same domain
why not run the MIB module on the PCE. Emile commented that this scenario was
possible and not excluded by his ID.
JL commented that a PCC can run the MIB module.
Adrian> Have you considered how this should or should not hook in to the IGP
MIBs?
Emile commented that not really although he was following the IGP MIBS closely
and his MIBS are neutral with respect to the IGP protocol.
Not requested to become a WG document.
JL> splitting in two document should be started out pretty soon.
Emile thinks MIB should be mandatory for protocol specifications. Its better
done by protocol owner since they know exactly what to watch.
JP> You did not ask the WG to take this as a WG doc. It will be a nice target
to have protocol document and the MIB document together. No one objected.
8) Update on "A Backward Recursive PCE-based Computation (BRPC) procedure to
compute shortest inter-domain Traffic Engineering Label Switched Paths" -
draft-vasseur-pce-brpc-01.txt (JP Vasseur - 5mn)
JP> This ID has a long history (presented and discussed many times).
Implementation already exists; so only expect the editorial changes.
Next steps is to add more details such as path diversity, GMPLS support and
manageability.
JP requested to adopt the ID as a WG document.
Adrian> We will poll the WG (on the list).
9) Update on Inter-Layer Traffic Engineering (Eiji Oki - 10mn)
- drat-ietf-pce-inter-layer-frwk-01.txt
- draft-ietf-pce-inter-layer-req-02.txt
10) Definition of Virtual Network Topology Manager (VNTM) for PCE-based
Inter-Layer MPLS and GMPLS Traffic Engineering - draft-oki-pce-vntm-def-00.txt
(Eiji Oki - 5mn)
Eiji Requested for WG feedback/ Q&A.
No Q&A.
JP> There was NOT much discussion on Multilayer on the mailing list. Please
review the documents and provide your feedback.
Eiji requested for feedback on these ID-es.
Adrian> Are there any open issues with the draft or you only need review
comments?
Eiji> No open issues, just looking for comments.
Dimitri> re: VNT This is not in the context of this WG. This group does not
define PCE-VNT communication. PCE WG is only scoped to define PCE-PCC
Communiction.
JP Agreed. Anything related to VNT manager specification is out of the scope of
the WG
Dimitri> My comment also applies to VNT definition. Before considering it, we
need to discuss the associated tradeoff. E.g., an LSR may communicate directly
to VNT and NOT via PCE, which is not in scope of PCE WG. It's not good to have
multiple architectures.
Adrian> Clearly work to mange inter-layer management is done in CCAMP work. The
scope here is to see how VNT fits in the context of PCE.
Dimitri> If there is an interaction between VNT and PCE, we never scoped it.
Eiji> VNT Manager description is in the context of PCE.
Dimitri> On slide 6, what do you mean by lower layer setup?
Eiji> PCE judges if lower layer path is needed. Same element is needed to setup
a lower layer LSP.
Dimitri> It's a policy decision; VNT can be triggered by signaling.
Eiji> Framework document describes two triggered methods- Triggered signaling
and non-triggered signaling. None-triggered signaling is VNT manager.
Dimitri> Need to clearify if/ why VNT Manager should be open IF.
Adrian> We are not clear if there is a requirement for a protocol. This is an
exploration phase.
Dimitri> If only exploration, why is this work not in CCAMP?
Adrian> Generic exploration is welcomed in CCAMP, but I cannot force anyone to
write an ID.
Dimitri> MLN requirements also take into account VNT.
JP> Full agreement that this is a exploration phase. There may not be any work
needed in PCE.
11) Preserving Topology Confidentiality in Inter-Domain Path
Computation and Signaling - draft-bradford-pce-path-key-00.txt (Adrian Farrel -
10mn)
Adrian> Rich is the editor.
Dimitri> On ERO extension, this work is to be done in CCAMP.
Adrian> Yes, we need an ERO subobject, which should be in CCAMP.
Lou> Your slide still show encryption as an option.
Adrian> This is a typo. This option has been dropped.
JL> Push model is to improve LSP setup time, but there is a price to pay as we
need to push information to all ASBRs.
Adrian> Yes, there is an associated tradeoff.
Show of hand who thinks this is a good idea. Any objection to work?
Some people thinks it's a good idea. No one objected.
Adrian> We take it further to the list.
Question (?): How do you identify which PCE generated which path key.
Adrian> You encode the originating PCE in the path key.
12) Discussion on Policy-Enabled Path Computation Framework
policy-enabled-path-comp - (Igor Bryskin, Lou Berger, Dimitri Papadimitrioui (TB
C) - 10mn)
Lou asked this doc to be accepted as a WG ID.
Adrian asked the room, ~5 hands.
Adrian asked for any objection/ if someone thinks it's a bad idea.
No one objected.
Adrian> We will take it to the list.
13) Framework for the Policy-Based Recovery Mechanism in GMPLS Network -
draft-lee-ccamp-pce-policy-recovery-framework-00.txt (Young Lee - 10mn)
Dimitri> Did you ask yourself why we worked for four years and did not go into
usability of the tools? It's because usability is complex and up to the
operator. Why should we do it now? No operator needs it and they told us they
have their own tools. All these capabilities are already there and provided
within the tools. This is outside the scope.
Lee> This recovery policy is in the context of PCE and for communication
between PCE and PCC.
Lou> What is presented here does not modify the framework of policy within PCE.
What is being talked about is a possible application of this framework. Whether
it's a good one or now these guys disagree.
JL> PCE computes path, it does not allocate bandwidth so why would the PCE need
this information?
Lee> PCE needs to update DB to mark that bandwidth has been assigned.
PCE does not know if the signalling request has gone through. PCE needs
accurate link information but agreed that some policy might not be applicable
to PCE.
Dimitri> Would we also need a provisioning policy. We were focusing the work on
path computation and path computation polices. Are we entering into application
that will make use the PCE. Second point is the policies were just an agreement
within a given recovery domain. It's up to the operator to select the recovery
policy for the domain.
Igor> We are not taking about recovery policies but rather polices that effect
path computation calculations. No updating PCE DB.
Dimitri> We are assuming some sequences to be assumed from work on CCAMP.
JL> This is a good start for discussion on the mailing list.
Lou> We should ask service providers who would like to see this as a WG
document.
Adrian> Ask for room feed-back: 5 liked to see this as a WG document.
Issue will be taken to the mailing list.
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
