* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Pce Status Pages

Path Computation Element (Active WG)
Rtg Area: Alvaro Retana, Alia Atlas, Deborah Brungard | 2005-Jan-12 —  

IETF-99 pce minutes

Session 2017-07-18 1550-1750: Congress Hall III - Audio stream - pce chatroom


minutes-99-pce-00 minutes

          PCE Working Group Meeting - Tuesday, July 18, 2017; 3:50-5:50 PM
          Slides:    https://datatracker.ietf.org/meeting/99/session/pce
          Meetecho:  http://www.meetecho.com/ietf99/pce
          1. Introduction
          1.1. Administrivia, Agenda Bashing (chairs, 5 min)
          1.2. WG Status (chairs, 20 min) [25/120]
          - Note Well is updated, please check RFC8179
          - Working Group has a new Secretary, welcome to Dhruv Dhody
          - Thanks Daniel King for his service
          Daniel King: For draft-ietf-pce-inter-area-as-applicability, New update,
                       of next week.
          Jonathan Hardwick: For draft-ietf-pce-path-setup-type, Check with
                             and make a final decision on RSVP-TE path setup type.
          Julien Meuric: For draft-ietf-pce-pcep-yang, Open Issues - it's an
                         issue beyond PCEP, Whether to keep notification in the
                         model or
          Dhruv Dhody: We are checking with yang doctors, we asked if we should
          rely on
                       yang push or keep notifications in the model.
          Daniel King: For draft-ietf-pce-hierarchy-extensions, to be updated -
          end of
                       next week.
          2. WG I-Ds
          2.1. PCEP Extensions for Association Groups (Dhruv Dhody, 10 min) [35/120]
          Jon: If you have a dynamic association group ID, does the ID get used
          from the
               head-end (PCC address space)? What happens for multi-head LSP?
          Dhruv: Yes and in case of multi-head, association id is from PCE or
          a generic
                 value ( But note that association id, type and source
                 act as key. In case of multi-head, the association source IP
                 address is
                 either PCE or value such as In case of dynamic
                 association, we
                 want to make sure that the association identifier is does not clash
                 with association id that would be configured by operator .
          Jon: Why did not make the ID range explicit, and assigned/managed by IANA?
          Dhruv: The original proposal had explicit allocations but this was removed
                 after feedback from other authors/contributors. Since some
                 could be only dynamic or operator-configured, the wastage of some
                 association identifier space should be avoided.
          Rakesh Gandhi: For bi-directional, we have multi-head LSP in same
                         and we would want to use the full association identifier
          3. New I-Ds
          3.1. PCEP Extensions for Residual Bandwidth (Daniele Ceccarelli, 10 min)
          [45/120] draft-lazzeri-pce-residual-bw
          Jon: Clarification question for Daniele - Is this applicable for only one
               source requesting the LSP, so that reporting residual BW can be used?
               What happens if multiple PCCs are setting up LSPs and consuming
          Daniele Ceccarelli: We had considered single source (a single H-PCE),
          and in
                              case of multiple, some synchronization between
                              them. Scope
                              was a single source.
          Dhruv: Even if only single source node, the proposed mechanism will
          only work
                     if there is no other path computation requests asking for
                     the same
                     resource. It is possible there should be a timing issue,
                     i.e., the
                     residual resource should only be valid for a duration of time.
                     Shouldn't this be similar to delay metric, the delay at the
                     time of
                     path computation in a stateless PCRep message and receiving
                     later via telemetry.
          Daniele: In the worst case, you cannot get any advantage, but it
          improves if
                   you are lucky.
          Dhruv: Agree.
          3.2. PCEP Extensions for Flexible Grid (Young Lee, 10 min) [55/120]
          Julien: Regarding Frequency Slot Restriction - Why not reuse the existing
                  label set encoding defined in GMPLS for frequency slot? Rather
                  request a new Spectrum Allocation TLV?
          Young: We actually do reuse label set encoding, but we have "m" and
          "n" slot
                 width identifiers fields. Out of label set mechanism (action
                 we proposed using only one mechanism - bit map encoding similarly
                 the YANG efforts for WSON/Flexi-grid.
          Julien: More cleanup of text is needed
          3.3. PCEP Extensions for Multilayer LSP Association (Fangwei Hu, 10 min)
          [65/120] draft-xiong-pce-multilayer-lsp-association
          Jon: Who has read this draft?  [3 hands raised]
          Jon: Need more engagement from working group before we can poll for
          3.4. PCEP Extensions for Stitching with H-PCE (Young Lee, 10 min) [75/120]
          Julien: Would you consider merging BRPC and this draft into one?
          Young: We are open to that.
          Jeff Tantsura: The label should be binding-sid.
          Julien: we are also considering having a single solution for binding,
                  stitching, etc. We should limit number of documents in parallel.
          Young: We can discuss with authors of three drafts off-line.
          Sergio Belotti: The intention and example is clear, but the draft
          lacks the
                          explanation on the procedure and intention.
          Young: We can do that.
          Jeff: Consider MSD, you may run out of labels, we can talk off-line.
          4. Previously Discussed Topics
          4.1. PCEP Extension for Flow Specification (Adrian Farrel, 10 min)
          Jon: I think it is in scope. Corollary to PCE initiate.
          Adrian Farrel: It is surprising that we don't have this, and this has been
                         solved via multiple approaches such as BGP, netconf, CLI...
          Jeff: In scope, very much needed. Not sure about RD.
          Daniele: Agree with Jeff, how often would this binding occur.
          Adrian: It may depend on how frequent the LSP arrival rate is, which is an
                  unknown parameter.
          Jeff: Currently this might be done via nexthop resolution, that would
          be the
                only way to do this granularly.
          4.2. PCE as Central Controller (Dhruv Dhody/Satish Karunanithi, 10 min)
          Jon: Can you justify, why we need a new message, why not use one-hop
          LSP using
          Dhruv: We considered this, but for SR, it was a bit tricky and to
          retrofit it
                 there was not clean. It was an implementation choice. We are open
                 to WG
                 feedback on that.
          Adrian: I am in the same camp as Jon, and we should try our best to use
                  existing message.
          Jon: It is important, if the IGP is bypassed. We need to justify before
               a decision.
          Dhruv: We should turn to the architectures and use cases drafts, and
                 investigate on whether PCEP has any advantages in case PCE is also
                 managing the label space.
          <<Dog barking>>
          Adrian: If PCE is SDN controller, we don't use RSVP-TE, it is PCE
          that touch
                  the nodes. In case of SR, we don't use IGP, it is PCE that
                  touch the
          4.3. PCEP for Distribution of Link State and TE (Young Lee, 10 min)
          Bin Young Yun: PoC with PCEP-LS, We implemented three recovery schemes
          and are
                         interested in the restoration times. We think these
                         are useful. For time critical recovery, this is quite
          Julien: We already have multiple solutions ISIS-TE, OSPF-TE, BGP-LS, Yang
                  model et al., why do we need another one?
          Young: OSPF-TE and ISIS-TE has a slower convergence time than this
                 This proposal is not another solution, but an improvement to
                 IGP-TE. Proven via experiments.
          Julien: You can improve IGP. Use Yang. BGP-LS exist. Also PCEP is not
          Young: In a centralized world, use of PCEP is better and Yang is text
                 and doesn't give the same performance as a binary based
                 protocol. No
                 one support incremental update on attribute change.
          Jeff: Convergence is not an issue. Not convinced this is required
          for packet,
                agree it is useful for optical environments, no other alternatives
                exist. If you have customer asking for packet, we should do this.
          Young: We can all agree on optical (Flexgrid, GMPLS).
          Haomian Zheng: We have conducted performance study with this proposal with
                         text-based proposal such as YANG. We see two-three
                         times faster
                         than the text-based model. Optical/Microwave demand a PCEP
                         based solution. We need a base PCEP-LS, over which these
                         extensions can be built.
          Julien: All optical n/w have IGP (at least for management), not all
          have PCEP.
          Michael Scharf: XML/Json can be parsed fast, parser implementation issue.
          Haomian Zheng: PCEP-LS co-exist with other solution, rather than compete.
          Julien: IETF develops standards, or catalog?
          Young: Can we ask WG what do they think?
          Jon: We are using PCEP to do what is done via IGP, I need to refer this
               discussion to the AD to see if we can take this work on given it
               may be
               out of scope of our charter.
          Young: I would like to ask how the WG thinks of this proposal. We need
          to make
                 a decision based on that.
          Lou Berger (as TEAS co-chair): ACTN is basically SDN for TE networks. If
                     have PCE/PCEP as a mechanism to go down to the device in
                     ACTN. We
                     have been working on a assumption that PCE as SDN controller,
                     it is
                     easy to see this work falls into the TEAS ACTN architecture.
          Poll initiated by Jon
          1. Who wants to see this work adopted? [9 hands]
          2. Who does not want this work adopted? [3 hands]
          Lou: To Julien, is PCEP is appropriate for SDN? Or only for distributed
          Julien: Avoid duplication, this feature is covered by other mechanism.
          Jeff: PCEP might not be build for this much amount of information, we need
                more semantics/focus on optical/microwave, and not on dynamic packet
          Adrian: Think of what harm can this do? rather than the benefit. Julien
                  competing mechanism. But it does not damage anything, market could
          Julien: Operators worry about too many mechanism, leading to
          Young: PCE is doing much more than path computation. If PCE is Central
                 Controller (PCE-CC), why would this work be not in scope from that
          Jon: Strong support as well as strong issues, so no clear consensus. Next
               step is talk to AD and discuss on the list.
          <<Meeting Adjourned, See you at IETF 100>>

Generated from PyHt script /wg/pce/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -