Skip to main content

Minutes IETF99: pce
minutes-99-pce-00

Meeting Minutes Path Computation Element (pce) WG
Date and time 2017-07-18 13:50
Title Minutes IETF99: pce
State Active
Other versions plain text
Last updated 2017-07-20

minutes-99-pce-00
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, end
             of next week.
Jonathan Hardwick: For draft-ietf-pce-path-setup-type, Check with implementers
                   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
               not.
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]
draft-ietf-pce-association-group

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 (0.0.0.0). But note that association id, type and source together
       act as key. In case of multi-head, the association source IP address is
       either PCE or value such as 0.0.0.0. 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 association
       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 associations
               and we would want to use the full association identifier space.

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 resources
     separately?
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 delay
           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]
draft-lee-pce-flexible-grid

Julien: Regarding Frequency Slot Restriction - Why not reuse the existing
        label set encoding defined in GMPLS for frequency slot? Rather than
        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 field),
       we proposed using only one mechanism - bit map encoding similarly to
       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 adoption.


3.4. PCEP Extensions for Stitching with H-PCE (Young Lee, 10 min) [75/120]
draft-lee-pce-lsp-stitching-hpce

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) [85/120]
draft-li-pce-pcep-flowspec

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)
[95/120]
draft-zhao-pce-pcep-extension-for-pce-controller
draft-zhao-pce-pcep-extension-pce-controller-sr
draft-palle-pce-controller-labeldb-sync

Jon: Can you justify, why we need a new message, why not use one-hop LSP using
     PCInitiate?
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 making
     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
        node.

4.3. PCEP for Distribution of Link State and TE (Young Lee, 10 min) [105/120]
draft-dhodylee-pce-pcep-ls

Bin Young Yun: PoC with PCEP-LS, We implemented three recovery schemes and are
               interested in the restoration times. We think these extensions
               are useful. For time critical recovery, this is quite useful.
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 proposal.
       This proposal is not another solution, but an improvement to existing
       IGP-TE. Proven via experiments.
Julien: You can improve IGP. Use Yang. BGP-LS exist. Also PCEP is not deployed
        everywhere.
Young: In a centralized world, use of PCEP is better and Yang is text based
       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 we
           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 model.
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
      networks.
Adrian: Think of what harm can this do? rather than the benefit. Julien says
        competing mechanism. But it does not damage anything, market could
        decide.
Julien: Operators worry about too many mechanism, leading to interoperability
        issues.

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
       perspective?
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>>