[Pce] PCE WG meeting minutes available

[Jonathan Hardwick <[e-mail]>]

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


Best regards

Jon


===============================================================================
PCE Working Group Meeting
IETF 97 (Seoul)

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:
     November 16, 2016, 13:30-15:00 (1:30pm-3:00pm)

Location:
     Park Ballroom 1, Conrad Seoul, Republic of Korea

With thanks to our scribes:
     - Dhruv Dhody
     - Yuji Tochio (remote)
     - Haomian Zheng
     - Daniel King

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

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

1.1. Administrivia, Agenda Bashing (chairs, 5 min) (13:30-13:35) [5/90]

-  The session is being co-chaired by Jon Hardwick and Daniel King.
  Unfortunately, Julien and JP were unable to travel to the IETF this time.
-  Agenda bashing: no agenda changes.


1.2. WG Status (chairs, 15 min) (13:35-13:50) [20/90]

Adrian Farrel: Can you clarify "No renewal" on the "Early code point
               allocations" on slide: Documents beyond the WG
Jon Hardwick: After requesting early code point allocation, only one renewal is
              permitted.
Adrian Farrel: The AD can give special dispensation to renew a second time.
Deborah Brungard: Yes, you can ask the IESG to do it.
Jon Hardwick: I know that is an avenue we can take, but I very much don't want
              to take it.  I want to finish this work instead.
Adrian Farrel: I would very much like to see these documents published as RFC.
Jon Hardwick: The stateful PCE authors have comitted to move within one week.

Dhruv Dhody: The [stateful-pce-inter-domain-lsp] I-D is not adopted, it was
             submitted using a WG doc name by mistake.

Himanshu Shah: There is the auto-bandwidth draft we are interested in.  We have
               asked for WG adoption a few times.
Jon Hardwick: Does anyone want to support (at the mic) the auto-bandwidth I-D,
              or object to it?
              <nobody except authors showed support>
Jon Hardwick: The problem was that JP had a significant concern about this
              draft and emailed the list.  Was this resolved?
Dhruv Dhody: We replied to JP's comments and thought we addressed the
             questions. We would like to discuss how to move the I-D forward
             and request adoption.
Jon Hardwick: If JP's concerns have been addressed then we can call for
              adoption.


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

2.1. PCEP Extension for associating Policies and LSPs
https://datatracker.ietf.org/doc/draft-dhody-pce-association-policy/
Dhruv Dhody, 5 min (13:50-13:55) [25/90]
Dhruy Dhody: We would like to associate a user-defined policy to a group of
             LSPs.

Adrian Farrel: How does this relate to the signaled policy that RSVP might use?
               Also, is there a vendor independent mode capability?
Dhruv Dhody: We would like to work with you on this.


2.2. PCEP Extension for LSP Diversity
https://datatracker.ietf.org/doc/draft-litkowski-pce-association-diversity/
Stephane Litkowski, 10 min (13:55-14:05) [35/90]

Haomian Zheng: This is useful. The resource sharing draft is related to this
               work. Let's work together.
Stephane Litkowski: Yes.

Loa Andersson: Regarding the shortest path flag (P), is that strict (lowest hop
               count)?

George Swallow: If your shortest path won't allow totally disjoint, what will
                you get?
Stephane Litkowski: Then the PCE can relax the requirement to be totally
                    disjoint, but only if the PCC has indicated that this is
                    acceptable by leaving the "strict disjointedness" flag (S)
                    unset.

Daniele Ceccarelli: If you set both P and S flags, and you cannot meet both
                    requiements, can you relax/prioritise one?
Stephane Litkowski: It's strict currently, but we can discuss.

Adrian Farrel: Please take care to distinguish between this disjointedness
               constraint and an objective function. We will have an offline
               discussion.

Lou Berger: Have you looked at lsp-diversity draft in CCAMP and now in TEAS?
Stephane Litkowski: No. Can you send me the pointer?

Jon Hardwick: This is good, missing function. I have two comments.
              1) Please don't suggest code points in your draft.  Before we can
                 poll for adoption, please remove these code points and submit
                 a new version of the draft.  Once adopted, we can proceed to
                 an IANA early allocation, which is a fast process.
              2) If the PCE relaxes the diversity criteria for some of the
                 LSPs, you need a way to tell the PCC which LSPs got relaxed.
                 If the PCC gets less than it asked for, then it needs to know.
Stephane: OK.

Himanshu Shah: I particularly agree with Jon's second point.


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

3.1. Association-aware Computation
https://datatracker.ietf.org/doc/draft-litkowski-pce-state-sync/
Stephane Litkowski, 10 min (14:05-14:15) [45/90]

Danielle Ceccarelli: This is a good solution for a problem that doesn't exist.
                     What you need is a PCE server with a good internal
                     reliability mechanism.  SDN controllers are already
                     offering this.
Stephane Litkowski: We have the problem. We are doing this for resilency,
                    scalability, and to avoid a computation loop.  We have an
                    SDN-like availability solution, which can be issued.
Danielle Ceccarelli: You may also have IGP, BGP database issue.

Haomian Zheng: Is the role master/slave permanent? Or per LSP?
Stephane Litkowski:  You can decide it flexibly.
Haomian Zheng: If everything is configured manually, it may be controversial.
Stephane Litkowski: We never say it's the best.
Adrian Farrel: In the real world, i.e. non-Unicorn networks, this is good
               solution for a real problem.
Dhruv Dhody: The solution should be applicable to multiple deployment options:
             H-PCE, stateful, et al.


3.2. Ability for a stateful PCE to request and obtain control of a LSP
https://datatracker.ietf.org/doc/draft-raghu-pce-lsp-control-request/
Dhruv Dhody, 5 min (14:15-14:20) [50/90]

Jon Hardwick: (Chair hat off) This seems like useful function to have.
Haomian Zheng: How does this work with pce-initiate?
Dhruv Dhody: It's applicable if the LSP is orphaned, this is not for creating a
             new LSP.


3.3. P2MP Updates (RFC 6006bis)
https://datatracker.ietf.org/doc/draft-palleti-pce-rfc6006bis/
Dhruv Dhody, 5 min (14:20-14:25) [55/90]

Jon Hardwick: Should we spin a new RFC or simply submit an errata?
George Swallow: Coders are more likely to look at the RBNF than to read the
                text. They may not notice an errata. I say spin a new RFC.
Adrian Farrel: Do both, the WG can publish a bis quickly.
Jon Hardwick: Action for Dhruv to enter this in the errata system.


3.4. PCE for Native IP
https://datatracker.ietf.org/doc/draft-wang-teas-pce-native-ip/
https://datatracker.ietf.org/doc/draft-wang-pce-extension-native-ip/
Aijun Wang, 10 min (14:30-14:40) [65/90]

Jescia Chen: I have not read this carefully, but I am confused. How do you
             modify forwarding behavior? There is bgp-flowspec and
             pce-flowspec.
George Swallow: Are you assuming every node in the slides is running BGP?
Jon Hardwick: There ia an architecture and solution dicussion to be had first.
              There is already a TEAS document covering this, so I suggest you
              continue to discuss the architecture and use case in TEAS, then
              we can continue the dicussion on solution (PCEP) work if there is
              consensus in TEAS around this idea.
George Swallow: Suggest you also include the IDR WG in the dicussion.


3.5. Connections and Accesses for Hierarchical PCE
https://datatracker.ietf.org/doc/draft-chen-pce-h-connect-access/
Huaimo Chen, 10 min (14:40-14:50) [75/90]

Jon Hardwick: Are you implementing this?
Huaimo Chen: Not yet, but we are thinking about it.
Dhruv Dhody: We have function in PCEP-LS that solves some of the function
             required.
Jon Hardwick: Please continue this dicussion on the list.


3.6. Optical Link-State Distribution in PCEP
https://datatracker.ietf.org/doc/draft-lee-pce-pcep-ls-optical/
Young Lee, 10 min (14:50-14:55) [85/90]

Jon Hardwick: This work assumes that we have already accepted PCEP-LS. PCEP-LS
              has been discussed before, but it's not clear what the support is
              from the WG, beyond the existing document authors. We have had
              negative comments that this work re-invents the function already
              in BGP-LS.  A question I have is what support do we have in the
              PCE WG for PCEP-LS generally (not just this draft)?  Anyone like
              to voice support in the room? Or anyone not agreeing that we
              should adopt it?
              <Nobody spoke on either side.>
Young Lee: I would remind eveyone that BGP-LS is for packet and we need optical
           support.
Jon Hardwick: Are you saying that BGP-LS lacks TLVs to describe the optical
              domain, or that the devices you have deployed in the optical
              domain do not have a BGP stack running on them?
Young Lee: It is both.
Jon Hardwick: You can fix the lack of optical TLVs in BGP.  However, it is
              harder to see how you can fix the lack of deployment of BGP in
              those networks.
Haomian Zheng: We need to make clear what PCEP-LS is competing with.  If
               BGP-LS, unfortunately optical networks don't have BGP and we
               will fail on IP+Optical without optical PCEP-LS.  If competing
               with other protocols, we need a gap analysis. Currently PCEP-LS
               is the only solution for optical.
Adrian Farrel: Putting in new TLVs in any protocol is doable; if optical TLVs
               do not exist in BGP-LS then they can always be added.  So this
               is not a lever for creating PCEP-LS.  The real reason is the
               lack of BGP in optical deployments.  However, if we are looking
               at mechanisms then maybe we also need to consider netconf.
Jon Hardwick: We need further dicussion, I'll start a thread on thread in the
              PCE list.


3.7. PCEP Link-State extensions for Segment Routing
https://datatracker.ietf.org/doc/draft-li-pce-pcep-ls-sr-extension/
Jiajia Fan, 5 min (14:55-14:60) [90/90]

- No comments.


End of session 14:59.