[Pce] PCE WG meeting minutes available

[Jonathan Hardwick <[e-mail]>]

The draft minutes for the PCE meeting at IETF 96 are now available.  Thanks to all our minute takers!  Please let me know if you have any comments or corrections.
https://www.ietf.org/proceedings/96/minutes/minutes-96-pce

Best regards
Jon

===============================================================================
PCE Working Group Meeting
IETF 96 (Berlin)

Working Group Chairs:
     Julien Meuric ([e-mail])
     JP Vasseur ([e-mail])
     Jonathan Hardwick ([e-mail])

Working Group Secretary:
     Daniel King ([e-mail])

Responsible AD:
     Deborah Brungard ([e-mail])

===============================================================================

-------------------------------------------------------------------------------
Session I

Time:
     July 21, 2016, 14:00-16:00 (2:00pm-4:00pm)

Location:
     Tiergarten, Intercontinental Berlin, Germany

-------------------------------------------------------------------------------

1. Introduction
---------------

1.1. Administrivia, Agenda Bashing (chairs, 5 min) (14:00-14:05)
1.2. WG Status (chairs, 15 min) (14:05-14:20)

<draft-ietf-pce-segment-routing>
Jeff: after fixing the semantics of MSD, we are ready to go

<pceps>
Dhruv: The authors dicussed the intended status and felt that due to the
       implementation maturity and number of them, we could change from
       "Experimental" to "Standards Track".

<stateful-sync>
Xian: Authors have addressed shepherd review comments.

<stateful-pce-gmpls>
<stateful-pce-remote-initiated-gmpls-lsp>
Xian: Basically ready, but would need WG to provide more feedback.


2. Work in Progress
-------------------

2.1 PCEP Hierarchy Extensions
https://datatracker.ietf.org/doc/draft-ietf-pce-hierarchy-extensions/
Dan King, 5 min (14:20-14:25)

No questions.

Julien: Regarding moving to standards track, No strong opinion, esp because of
        multiple implementation. Will take it to the list.


2.2 Inter-area and Inter-AS Applicability
https://datatracker.ietf.org/doc/draft-ietf-pce-inter-area-as-applicability/
Dan King, 5 min (14:25-14:30)

No questions.

Jon: Will move to LC, after the meeting.


2.3 PCEP Enhanced Errors
https://datatracker.ietf.org/doc/draft-ietf-pce-enhanced-errors/
Xian Zhang, 10 min (14:30-14:40)

Dhruv: When this work was presented (IETF 78) some of the procedures and
       corrosponding errors and notifications have evolved. The ways in which
       people are thinking of deploying PCEs are not necessarily the same.
       People think more now of deploying hierarchical PCE.  I am not sure this
       document is applicable any more. We will need to review this document
       again to ensure it reflects this.
Xian: I would like to discuss with Dhruv offline to review these issues.
Julien: [at mic, chair hat off] yes, ideas have moved on but this does not make
        the older ideas invalid.  We can update to include newer work.
Jeff: Yes, it would be good to have some guidelines for the new work, as we
      have new mechanisms that need to be reflected
Jon: Please see the action for someone to contribute text for the Security and
     Operational considerations section.


2.4 BGP-based PCE Discovery Mechanism
https://datatracker.ietf.org/doc/draft-dong-pce-discovery-proto-bgp/
Jie Dong, 10 min (14:40-14:50)

Poll
- Who has read this document? [About 12]
- Who would like to see this become a WG document? [Slightly fewer]


3. New Work
-----------

3.1 PCEP Experimental Code Points
https://datatracker.ietf.org/doc/draft-dhody-pce-pcep-exp-codepoints/
Dhruv Dhody, 10 min (14:50-15:00)

Adrian: Do this, but. Its not quite right yet. We will need to tweak the
        proposal. Experiments are good, and if the ranges are kept small they
        force developers to an early request for a code point or let go. If a
        code point is used for an experiment and the open source platform then
        release the version, it might mean the projct code point squats.

Dhruv: Could we assign for a specific time period, 1,3,5 years?

Adrian: Sounds like early allocation. I think we need to think about a third
        way.

Lou: Respond to Adrian's point, there is a allocation policy, maybe they want
     to use a code point for a 1-2 years. Its a "specification required".

Dhruv: When I read the allocation policy document, it was not clear that was
       possible.

Lou: You can also use a "Reserved" method. [See RFC5226?]

Adrian: This does not exist. It never did.

Lou: What you're describing is not "experimentation".  Experiments are isolated
     - you should not coordinate code points between experiments.  That is an
     IANA function.  Use IANA if that is what you want to do.

Lou: I am also concerned about informal allocation of code points across
     multiple protocols.

Dhruv: No, will exclude other/multiple protocols.

Julien: [Pesonal view] Thats why I like focusing on the essentials.  Just the
        message, object and TLV code point spaces.

Jon: I would like to see an experiment registry. Given the IANA sections of a
     number of I-Ds I have recently reviewed, I would also like to add
     experimental ranges for error-types and notfications.

Michael: We had a similar problem in TCPM, please look at RFC6994 as it might
         address some of the issues you highlight here.

Poll
- Who read the I-D? [A handful]
- WHo think this is a good base for the discussion? [Similar amount]


3.2 Applicability of PCEP to ACTN
https://datatracker.ietf.org/doc/draft-dhody-pce-applicability-actn/
Dhruv Dhody, 10 min (15:00-15:10)

Jon: Yes, it is my fault that you have had to write this I-D. Its helped me to
     understand the context of ACTN. The PNC <-> MSDC is hierachical PCE. The
     VN Association is not clear as to why the PNCs need to know the VN info,
     its seems the VN Association info would be used for the MSDC and above.
     Finally, is PCEP-LS integral to ACTN?

Dhruv: If you want to use other protocols with ACTN, thats fine. PCEP-LS is not
       mandated.

Jon: Good, so its not fundemental. Is PCECC something that needs to be in this
     applicability document?

Dhruv: The relationship with PCECC and ACTN is such that PCECC is just one PNC,
       and another PNC could be using SR or RSVP-TE. I will describe the
       relationship in the document as well.

Jeff: With PCEP-LS you are creating complexity and capability that already
      exists with things like BGP-LS.

Dhruv: It depends how you want to use it, if you use PCECC and you have PCEP
       already you can pull TE info via PCEP-LS and not have to use BGP-LS.
       There are extremes.

Jeff: You will still be missing link attributes.

Julien: You should focus on how PCEP-LS may be used for ACTN.

Pawel Brzozowski: Besides IGPs and BGP-LS we also have YANG.  We also have Ross
                  telling us not to create many ways to do a single thing.  We
                  don't need another mechanism.


3.3 Hierarchical PCE Discovery
https://datatracker.ietf.org/doc/draft-chen-pce-h-discovery/
Huaimo Chen, 10 min (15:10-15:20)

Julien: Does the Parent PCE really need to discover further information about
        the Child PCE, if I have already manually configured this info
        (capability and reachability).
Huaimo: We need to confirm the configration in the protocol.
Julien: It is not discovery, it is a configuration check.  Is this information
        dynamic?
Huaimo: There are security consideration, which is why configuration must be
        validated.


3.4 Connections and Accesses for Hierarchical PCE
https://datatracker.ietf.org/doc/draft-chen-pce-h-connect-access/
Huaimo Chen, 10 min (15:20-15:30)

Adrian: Your identified requirements mentioned H-PCE architecture (RFC6805),
        but I think there are methods available for discovery and dissemination
        of inter-domain links. These requirements might be solved by things
        like BGP-LS. Depending the deployment and configuration policy, you may
        find the operator will already know which links exist between domains.
Huaimo: Some times they dont, here we provide a easy way to provide that
        information.
Igor: What if there is no link between domains, how does the parent PCE compute
      a inter-domain path?
Huaimo: Bad luck.
Igor: If I report (parent PCE) I cannot compute a path, how do I handle this?
Anton Ivamnov: We have BGP-LS, this should be closed.
Julien: The usecase is the same, you are duplicating the work already done.


3.5 Native PCE TED
https://datatracker.ietf.org/doc/draft-chen-pce-pcc-ted/
Huaimo Chen, 10 min (15:30-15:40)

Adrian: The first slide is misleading, what you have is a partial diagram from
        RFC 4655.  You want to extend this to a node not running a routing
        protocol and using PCEP to learn TED.
Huaimo: Yes.


-------------------------------------------------------------------------------
Session II
Joint YANG session with MPLS & TEAS & PCE

Time:
     July 21, 2016, 16:20-18:20 (4:20pm-6:20pm)

Location:
     Charlottenburg II/III, Intercontinental Berlin, Germany

-------------------------------------------------------------------------------

Last meeting co-chaired by Ross. Set of pictures of Ross sitting between Pavan
and Jon taken by Lou and George.

1. Introduction
---------------

1.1. Welcome, Administrivia, Agenda Bashing (chairs, 10 min) (16:20-16:30)


2. YANG models discussion
-------------------------

2.1 YANG Data Model for TE Topologies
https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/
Xufeng Liu, 20 min (16:30-16:50)

Dhruv Dhody: Relationship with SR model?
XL: Types to be shared.
DD: Do we need RW on per-node attributes?
Tarek: There are cases where information is learned via IGP, but other cases
       where static may be supported, thus the need for RW
DD: What do we do on conflicts? TBD
Igor Bryskin: one of the clients (users?) wanted to do path computation based
              on TE information as well
Pavan: How many have read? Not so many. Please read and send comments to the
       list.


2.2 A YANG Data Model for Traffic Engineering Tunnels and Interfaces
https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te/
Tarek Saad, 20 min (16:50-17:10)

Lou Berger: Send that [option request] to Netmod.
Xian Zhang: No strong preference among options, but, do these options on tunnel
            model also apply to TE topology?
TS: I think you are actually asking about somthing that is derrived from
    routing config, which is also using  option #2 (schema mount).
LB: Routing config is using it, although the another wildcard form. logical
    element and network instance in the RTGWG are also using this form. This
    would be the 1st use of mounting a specific schema.
Loa Anderson: Issues to be fixed on valid ranges of label values.
TS: Ack
LA: Ambiguous names to be fixed on H-LSP part.
LB: What about Extension Labels (RFC7274)
TA: will need to consider.
DD: Be careful on artifical segmentation around PCC/PCE...
DD: The lsp-key is 5 tuple and it should support extensions towards other
    technologies, e.g., SR.
TA: Will have split P2P and P2MP LSPs so will have index within each (sub)
    trees
LA: ietf-te-yang inherits from 2 models; do we need to ensure special review
    for these cases?


2.3 A YANG Data Model for MPLS Static LSPs
https://datatracker.ietf.org/doc/draft-ietf-mpls-static-yang/
Tarek Saad, 20 min (17:10-17:30)

Iftekar (Infinera): Who's taking care of switch over?
TS: Static configuration. Pre-programmed backups are possible. Behaviors widely
    depend on DP capabilities.
LB: What about OpenConfig's "applied state" discussion?
TS: No IETF consensus about its usage so far.
LB: Indeed, reco is not to jump to fast, too much error-prone.
TS: General consistency matters.
LB: From routing area discussion: use to be limited. View as author?
Pavan: Agreed on consistency, but eithier way is fine.
LB: Simplifying our models might be nice. Maybe we should ask the room.
Kamran Raza (Cisco): Should be consistent with MPLS document, some fallback
                     already happened.
XL: Not so much work. Structure to be simplified.
LA: Would it work if both simplified and more complicated module were pushed?
LB: Would work, but more implementation load.  2 different ways for every
    information element; Having just one way to access the information implies
    less code.
LB (chair hat on):
    How many care? <A decent number, but "not as many as expected">
    How many for simplified? <Almost the same>
    How many for OpenConfig approach with augmentation? <A small number>
    How many for OpenConfig as is? <One>


2.4 TEAS Transport Service Model
https://datatracker.ietf.org/doc/draft-zhang-teas-transport-service-model/
Xian Zhang, 15 min (17:30-17:45)

Tarek S: I don't understand what's missing from other modules for "step 1".
XZ: SB relies on PCEP, this is a service model.
Daniele Ceccareli: Is technology-specific only on tunnels or also at service
                   level?
XZ: A couple of attributes are relevant for services.
DC: OK, so both tunnels and service include technology-specific.
Anurag Sharma (Infinera): Commonalty with tunnel: required work?
XZ: Many things from tunnels turn optional/unnecessary.
Himanshu Shah: Would end up creating something covered by other service models.
George Swallow: There seem to be confusion. Service layer may be different from
                transport layer (e.g., Ethernet and OTN).
Jon: This document is about transport as a service, not end user service
HS: Need another document to connect all the dots
DC: We can have higher layer services on top of pipe as well as service filling
    in pipes. We don't have a common service model, like an umbrella.
XZ: We are looking at it differently, where we can have the ethernet or OTN
    service
DC: Any plans in mind to solve non-te services?
XZ: Plans only for transport/TE.
Igor Bryskin: There is no difference between transport or service so lets just
              use (existing) tunnel model
XZ: Indeed, difference is not clear.


2.5 PCEP YANG
https://datatracker.ietf.org/doc/draft-pkd-pce-pcep-yang/
Dhruv Dhody, 15 min (17:45-18:00)

Jeff Tantsura: Key-chain is close to LC.

Julien: Who has read document? <Some>

    Who thinks it should be a WG document? <more!>

    Who thinks it shouldn't be a WG document? <none>

    Clear consensus in the room. Decision will be confirmed by a poll on the
    PCE list.


2.6 YANG Data Model for MPLS LDP and mLDP
https://datatracker.ietf.org/doc/draft-raza-mpls-ldp-mldp-yang/
Kamran Raza, 15 min (18:00-18:15)

No question


2.7 LSP-PING-YANG
https://tools.ietf.org/html/draft-zheng-mpls-lsp-ping-yang-cfg-03
Greg Mirsky (remaining time; started at 6:07)

Italo Busi: Are you including MEG, MEP, MIP, etc?
GM: LSP ping doesn't need those. No intention to introduce them there.
Zheng? (Huawei, co-author): Confirmed

<6:12 - Meeting adjourned>