IETF 111 PCE WG Meeting Minutes

PCE Working Group Meeting - 1

Monday, July 26, 2021 14:30-15:30 PST (21:30-22:30 UTC)

• Chairs: Dhruv Dhody, Julien Meuric
• Secretary: Hari (Hariharan Ananthakrishnan)
• Slides
• Video

Introduction

1.1 Administrivia, Agenda Bashing (chairs, 5 min)
1.2 WG Status (chairs, 10 min) [15/60]
1.3 State of WG I-Ds and next steps (chairs, 10 min) [25/60]

• [Susan Hares] IDR will hold an interim for Flowspec V2. Anticipate moving V2 Flowspec quickly (6 - 9 months). Flowspec V2 is handling problems with TLVs.
• [Haomian Zheng] Flexible-Grid is mostly stable. We could move forward.
• [Haomian Zheng] VN association is stable. Not sure if there is any dependency on ACTN-VN.
• [Dhruv] There is no dependency. I think we can progress.

Stateful

2.1 Native IP (Aijun, 10 min) [35/60]
draft-ietf-pce-pcep-extension-native-ip-14

• [Mike Koldychev] Is it correct that route (PPA) injected is going to be flooded to every node in the domain ?
• [Dhruv] As far as I understand that is not happening. It only uses PCEP to program only required information.
• [Mike] How will mid point know ? We can take this to the list.
• [Mike] How will you support Equal cost multi-path or weighted multi-path ?
• [Susan Hares] Are R1 and R7 route reflector clients ? Its unclear in the draft
• [Aijun] R3 is a RR client.
• [Susan Hares] What type of BGP peer is R1 and R7 ? Are they RR clients or RR themself?
• [Aijun] R7 and R1 are RR clients.
• [Susan Hares] R5 and R6 simply forwarding routers ?
• [Dhruv] We can take the discussion to the list.

2.2 IFIT (Giuseppe, 5 min) [40/60]
draft-chen-pce-pcep-ifit-04

• [Dhruv] Open question from the previous meeting: Whether we need to create a registry for the flags ? Similar discussion happening in LSR group as well. In PCE WG, all our flags have a registry.
• [Giuseppe] We can be aligned and we can update the draft accordingly.

2.3 New TE Constraints (Quan, 5 min) [45/60]
draft-peng-pce-te-constraints-06

• [Andrew] General question about color extension. There is a draft presentation after this one that discusses color in the steering context. This doc context is about constraint. Is there a collision between association policy and color as a constraint? Isn't there an overlap in usage with association policy?
• [Quan] The color TLV can be used in many scenarios.
• [Andrew] These are two different purposes as one is steering and the other is path constraints.
• [Dhruv] The association policy is already an RFC. We need to have a stronger justification on why we need new TLVs ?
• [Jie] Scope of the document ? Is this about generic constraint extension for PCE or specific to network slicing ?
• [Quan] It is generic.
• [Jie] Text in the draft about network slicing could be cleaned up. There is no Slice ID defined in the TEAS network slice definition draft. There is on-going discussion about Slice ID/terminology in TEAS WG.
• [Quan] Do you have suggestion on the format for slice ID TLV ?
• [Jie] If its generic document, suggest removing the slice-id TLV.
• [Tarek] There are cases where a path is crossing multiple topologies. The constraints can be a union or intersection and can be more eloborate on these. We are in discussion about a draft for constraints filter. Topology filters draft in TEAS is at: https://datatracker.ietf.org/doc/html/draft-bestbar-teas-yang-topology-filter-00 .
• [Tarek] Its not enough to have a Flex-ID. Because multiple IGPs can have the same number to mean different definitions. We need more information there.
• [Mike] The color TLV is very useful. There is another color TLV in another draft. We need to merge.

New I-Ds

3.1 RSVP Color (Balaji/Pavan, 5 min) [50/60]
draft-rajagopalan-pcep-rsvp-color-01

• [Mike] Classful transport as one of the applications. BGP-Color Aware Routing as another application.
• [Andrew] If there is LSP path in primary/secondary. Is that intended to say that it will update only the active ?
• [Paven] We dont have scenarios where we only have secondary and no primary.
• [Andrew] In PCEP we dont have primary/secondary, but there is association protection document.
• [Paven] I thought there is a way to mention primary/secondary.
• [Susan Hares] If this takes auto-configuration ? If not please include that in the draft.
• [Pavan] Yes, we will need.

3.2 VLAN-based Native IP (Yue Wang, 5 min) [55/60]
draft-wang-pce-vlan-based-traffic-forwarding-00
*
* [Dhruv] Out of time. We will do in the Thursday session.

PCE Working Group Meeting Session II

Thursday, July 29, 2021 12:00-13:00 PST (19:00-20:00 UTC)

• Slides
• Video

Segment Routing (SR)

4.1 Algorithm in SID (Samuel, 10 min)
draft-tokar-pce-sid-algo-04

• [Dhruv] Clarification on the word deprecated, is it about moving away from NAI types and changing SR-ERO and SRv6-ERO objects or about IANA?
• [Samuel] That is correct. Code points are not yet allocated, so we just replaced the NAI types which were introduced in the draft.
• [Loa] A procedural question. Some WG requires new IPR statement if there new members joining midway. Will PCE require IPR statements for new co-authors ?
• [Dhruv] This is still an individual draft. Our requirement is any author or contributor who is aware of IPR should disclose it ASAP. I will discuss this with co-chair and AD and other WG chairs. Maybe it would be good have a common policy in the Routing Area.
• [Boris] Any plans for test implementation ?
• [Samuel] Because of recent change, I assume there are no other implementations yet. When other implementations are ready, we can test interoperability.

4.2 Entropy Label Position (Quan, 10 min) [20/60]
draft-peng-pce-entropy-label-position-06

• [Dhruv] Can you explain minimum-ERLD TLV ? I am not sure of the usage.
• [Quan] this is the new update from the last version. Egress cannot compute minimum-ERLD or cant guess the minimum-ERLD along the path. Hence this option to let PCE communicate the computed minimum-ERLD to PCC. There are two options. Option 1: Get the path minimum-ERLD and it can determine the position and calculated value itself. Option 2 is, PCE directly computes the position for egress and ingress just calculate the value of the entropy label and insert their positions which the PCE calculated.
• [Dhruv] Maybe worth adding more details in the draft.
• [Jeff] PCEP is peer-to-peer protocol so information about path capabilities can only be derived from underlying IGP. More text regarding how these pieces work together will be very good.
• [Cheng] Is path minimal-ERLD similar to MSD ?
• [Dhruv] Please add the description in the document and mailing-list.

Multicast

5.1 SR P2MP Policy (Hooman, 10 min) [30/60]
draft-hsd-pce-sr-p2mp-policy-03

• [Dhruv] The document is moving in a good direction. I request more people to review the work and give feedback.
• [Andrew] Should we send a formal request to the list for adoption queue ?
• [Dhruv] Go ahead and send the request.

5.2 BIER-TE (Ran, 5 min) [35/60]
draft-chen-pce-bier-09

• [Dhruv] Thanks for working together and merging documents.
• [Cheng] Do we have the requirements of BIER-TE standards?
• [Tony P] BIER-TE has been adopted quite a long while ago and its moving forward. Its in the AD review. Once you adopt this work, please forward the request to BIER WG for cross WG review.
• [Dhruv] Please add more description about the use-case where this new objective function would be needed. One more comment is, you should reference RFC8623 which is the stateful P2MP extension. I would assume the PCRpt and PCUpd messages will be based on this RFC. It is surprising that RFC8623 is not referenced at all.
• [Ran] We will add the reference in our doc.
• [Tony P] More of an observation that applies to this draft and the next draft. BIER architecture has been prepared to deal with signaling or IGP or controller-based operation from day one. A PCE or controller could be used in many different models, the BIER-TE capabilities are not wide enough. Suggest the authors to add these in the general consideration section and how PCE can be used and give these flags some more meaningful names, so that when we have other models / PCE extensions we can differentiate between those things.

5.3 PCE based BIER (Huanan, 10 min) [45/60]
draft-li-pce-based-bier-01

• [Tony P] Flag is not generic enough. The message format here is very dense. I would suggest breaking it down more in case you want to extend the whole messaging for this PCE extension.
• [Dhruv] We have not included mulitcast source and group information in PCEP messages. If we agree that if this is useful for PCEP to do why do we tightly couple to BIER ? Can this be done in a generic way, were BIER specific things could be sub-TLVs. This kind of information can be used for non-BIER multicast uses as well.
• [Huanan] We can discuss this in detail in the mailing list later.
• [Loa] We have been working on egress/ingress protection for more than a decade now. Should we do some generalization in this area to capture what we learned over time ?
• [Dhruv] Good to discuss this after the next presentation.

5.4 BIER-TE Ingress Protection (Huaimo, 10 min) [55/60]
draft-chen-pce-bier-te-ingress-protect-00

• [Pavan] It seems to be similar to one of the procedures discussed in RFC 8424. It is an experimental RFC. Is this also targetted as experimental work ?
• [Huaimo] It is similar to that one. We need extensions for PCE.
• [Dhruv] There was a proposal from you also about SR Ingress protection which had a very similar set of procedures. It might be a good idea to have a common way of doing this, rather than having very specific extensions for each.
• [Huaimo] Sure. We will consider.

From Session 1

6.1 VLAN-based Native IP (Yue Wang, 5 min) [60/60]
draft-wang-pce-vlan-based-traffic-forwarding-00

• [Aijun] The procedure is newly introduced, so we want to discuss the mechanism on the list later.
• [Dhurv] Let us continue the discussion on the list.

Updated on 31 July 2021 2145 UTC