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 (julien.meu...@orange.com)
JP Vasseur (j...@cisco.com)
Jonathan Hardwick (jonathan.hardw...@metaswitch.com)
Working Group Secretary:
Daniel King (dan...@olddog.co.uk)
Responsible AD:
Deborah Brungard (db3...@att.com)
===============================================================================
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.
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
