IETF 112 PCE WG Agenda
PCE Working Group Meeting – Session I
Wednesday, November 10, 2021 14:30-15:30 UTC
Introduction
1.1. Administrivia, Agenda Bashing (Chairs, 5 min) [5/60]
1.2. WG Status (Chairs, 10 min) [15/60]
1.3. State of WG I-Ds and next steps (Chairs, 10 min) [25/60]
- [Dhruv] draft-ietf-pce-binding-label-sid authors have updated the draft and waiting for AD.
- [John Scudder] I acknowledge that they are waiting on me. I will get that soon. Thank you.
- [Andrew Stone] draft-ietf-local-protection-enforcement is in a steady state. There are two implementations. So whenever the WG feels that it's ready we are good to proceed further.
Segment Routing
2.1. Multipath ERO (Mike Koldychev, 10 mins) [35/60]
draft-ietf-pce-multipath-03
- [Cheng Li] We have a draft on bidirectional-sr-path where we can associate forward and reverse paths. I would like the difference between that and your solution.
- [Mike] This solution lets you support multiple segment lists. It still uses the bidirectional association. It still sends the bi-directional association A1 for candidate path one on H1 and the same bidirectional association A1 on candidate path 1 on E1, so that two candidate-paths are associated. But it is also necessary to link each segment list together with another segment list or with a set of other segment lits so that association works at the level of the candidate path. But if you have a candidate path with multiple segment lists then it doesn't seem to work that well. We can take the discussion offline.
- [Dhruv] One comment with Chair hat ON would be this is a pretty big change, so do discuss this on the working group list like what is the requirement for this change. Get Working Group's feedback on this. I think it's ok to update a working group document and ask for the slot, but keep the mailing list engaged as well. So bring up this change on the mailing list specifically and ask for feedback from the working group.
- [Dhruv] Adding to what Cheng was saying, we need to have a section that clearly describes the relationship with SR bidirectional and have clarity on how that extension gets used in which cases and in case there is a multi-path how the two things will work with each other. Of course, you can imagine there could be error cases and others where you put some information in association and a little bit different information in your TLV. So how that thing will work together so a little bit more tightening is needed and I see I think some authors of SR bidirectional is also there so I am hoping that they will keep track of this work as well.
- [Boris Khasanov] It will be very helpful if implementation status is added in the next version.
- [Mike] We don't have an implementation status, we will add it ASAP. That's why IANA code point will be very useful.
- [Rakesh Gandhi] In SR-BiDir association draft we have a new section that talks about the relationship with this draft that Mike is presenting. As well there is an explanation in the draft that Mike is presenting with some examples that also point back to the bidirectional on how it would work. Please review the text and let us know your feedback.
- [Cheng] When it's finished, I just want to get feedback from the working group, and let's discuss further here.
- [Dhruv] Some of the points that Ketan brought up in IDR working group where he was mentioning that some of these changes need to be discussed in SPRING as well. He brought up the issue related to the backup segment list, where that is not part of the SR policy architecture, and it's something that is missing so we need to keep track of that as well. I wanted to make sure that it's captured in our minutes so that we can track it.
- [Mike] That's a good point, I will sync up with Ketan.
- [Loa Andersson] I haven't carefully read Cheng's draft and Mike's draft together. But it seems like there is an opportunity to merge drafts here. Would that fly with the authors?
- [Mike] The SR bi-dir draft is more like associating different candidate paths, but this draft is working within each candidate path to further associate segment lists.
- [Loa] I think it's fine, if that's the case you should get some text about that in your draft and some in their draft.
- [Mike] Point taken. That is missing, some linkage between them.
- [Rakesh] I don't see a need to merge them. They are different use-cases, so they solve different problems. There is a text for that in the bidirectional draft. Please review and let us know.
- [Mike] We keep this multi-path draft agnostic to any SR technology, so it's kind of generic PCEP extension that can be applied to other data planes.
2.2. SR Policy (Mike Koldychev, 10 min) [45/60]
draft-ietf-pce-segment-routing-policy-cp-06
- [Boris] One question and suggestion also. Question if we will have to look at 7.4 item in the draft PC initiated SR Policy with multiple candidate paths. Item 1 is quite confusing because there is no clear differentiation like should PCE send one PCInitiate message or multiple. May be worth adding more clearly like MAY send or SHOULD send.
- [Mike] I believe each PCIntiate message could contain multiple LSPs or it could or they could arrive in different PCInitiate messages. The unit of signaling in PCEP is PLSP-ID. So you could have multiple PLSP-IDs in the same message, but that doesn't give you anything except for saving 4 bytes of a message header. Or you could send multiple PCInitiate messages with each message containing only one PLSP-ID.
- [Boris] Regarding implementation status, we recently did some testing with our controller prototype. Since Cisco and Juniper currently support it in the production version of the software, it's not proof of concept anymore.
- [Mike] We use vendor TLV, that's what we mean by proof-of-concept.
- [Dhruv] Get WG feedback on the generic mechanism. Right now all these mechanisms to make it generic are not part of the association object, they are carried outside it but the main use cases for these is still SR Policy. So now the issue comes in that the name of the document is SR Policy and we are keeping some generic mechanism, it's ok to do it. There are no hard and fast rules but we want to make sure that we are doing the right thing and the working group is thinking about it. One option could be to highlight that these are needed for SR policy and introduced in the SR policy architecture. The encoding is such that they are outside the association object. We can add a paragraph that they can be used for other non-SR policy cases as well. I wanted to get the Working Group feedback also.
- [Mike] Point taken. SR Policy architecture was the first to standardize this behavior, so that's the reasoning of why I put them in the draft, but I am definitely open to whatever people decide.
2.3. Path MTU (Luc-Fabrice Ndifor, 5 mins) [50/60]
draft-li-pce-pcep-pmtu-05
- [Dhruv] Thanks your keeping the document up to date and thanks for the comments. Chairs will discuss and we will look out for the wiki where we will update our adoption queue.
2.4. IFIT (Giuseppe Fioccola, 5 mins) [55/60]
draft-chen-pce-pcep-ifit-04
- [Dhruv] Looking at the last minutes there is one comment regarding the registry for flags. Did we take an action on it or did we decide not to do it? Could you update on that?
- [Giuseppe] I forgot. That's something we can consider.
2.5. Ingress Protection (Huaimo Chen, 5 mins) [60/60]
draft-chen-pce-sr-ingress-protection-06
- [Dhruv] Thanks for merging the two documents. What happens to RSVP-TE ? Is this not useful for RSVP-TE?
- [Huaimo] As I mentioned this can provide two types of protection, SR-Path and BIER-TE path. So if want to extend this one to provide protections for TE path, I think it's easy we just add one flag and may include those TLVs for the TE Path.
- [Dhruv] I am not able to understand why we need to differentiate so much? We have path setup type which will tell us if it's SRv6 or BIER or whatever. The mechanisms would be anyway the same irrespective of what is the path setup type. So I know from capability it makes sense that I want to have a separate flag for each of them so that I can identify the capability but for the rest of the procedure what is the main point to have different sections or different handling for each path setup type. I was thinking that this could be a common generic draft and we don't have to talk too much about what happens for SR, BIER-TE or RSVP-TE For most of the procedures why should we handle different path setup types?
- [Huaimo] You are correct. This is for backup paths, we can use backup path types when we initiate the path. Here we have explicitly indicated that this type is just to emphasize. For the ingress sub protection TLV, We can remove the path-type indicator.
- [Zheng] If this draft has been discussed in BIER WG?
- [Huaimo] No, since this is an extension for PCE.
- [Zheng] In my opinion, this use-case should be discussed in SPRING and BIER WG at first.
- [Mike] Just to confirm, this requires a connection to CE device.
- [Huaimo] Not exactly
- [Mike] It's good to elaborate on this in the draft. It is also good to mention different service overlay types this applies to.
- [Huaimo] In the draft we mentioned that in some cases we need communication with CE.
- [Dhruv] There are some older comments as well. Please handle all the comments that you have received.
PCE Working Group Meeting – Session II
Friday, November 12, 2021 16:00-17:00 UTC
Update to PCEP
3.1. Relax Object Ordering (Dhruv Dhody, 10 mins) [10/60]
draft-dhody-pce-pcep-object-order-00
- [Julien] Chairs would be happy to hear feedback from people of the working group, especially existing implementations that may have concerns about the proposal.
- [Andrew] Past implementation that follows strict writing in RFC 5440 to do the ordering. In terms of backward compatibility, the end result is essentially well tough luck you guys cant drop. That is difficult for me to digest at the same time I don't have an alternative wordsmith. It's something that I am gonna have to think about how can we allow future miss ordering while still allowing those past implementations to succeed. I am concerned about the backward compatibility and the interop that we have been essentially hardening over the last couple of years that may lead to less interop even though the goal is more interop in long run.
- [Julien] Thanks. We want to collect as much feedback as possible and make sure that we will do a clever decision at the end of the process. This is just the first proposal.
- [Aijun Wang] I want to ask if the receiver can ignore the ordering of the object, then what is the usage for the sender to order in object? I think it's impossible to define the rule for ordering so many types of PCEP objects.
- [Dhruv] If I understand your comment, I think this is the usual philosophy in standards that we have followed. That while sending you to use MUST but while receiving you should use SHOULD, so that we allow a liberal process and unnecessarily we don't cross error conditions. If you look at RSVP which Adrian pointed they do not have the strict ordering rule and they follow the same RBNF and similar objects like in PCEP.
- [Oscar Gonzalez de Dios] In the past we had several problems in the interop. I think regardless you allow some flexibility in some places, the grammar needs to be revisited on the whole. Either be strict put all the order in place or if we want to relax, we have to say where to relax. In general, if we say that a protocol that is designed to be in an order you suddenly say that it is not an order that does not work.
- [Boris] I support this approach. It would be good to signal this relaxing capability as additional PCEP capability to align with the old implementation.
- [Julien] That's an interesting idea to share.
- [Mike] Being liberal in what we accept is always a good thing. It's assumed that the implementations will follow it. I think it's a good idea. We can specify the ordering may be relative between two objects. For example, path attribute object has to go right before the ERO object. For global ordering, this might not be necessary.
3.2. Topology Filter (Quan Xiong, 10 mins) [20/60]
draft-xpbs-pce-topology-filter-01
- [Jie Dong] I see you mentioned the new draft NRP-ID. This is related to network-slicing. We submitted a draft on the PCEP extension for VTN which will be presented next. Follow the discussion in TEAS WG about the relationship between this one. There is a topology filter YANG model, I see there is some difference between these two drafts in the content like TE topology is not covering this one, te-topology-identifier is not covered. I am not sure if you want a consistent definition of the topology filter.
- [Quan] We proposed it two years ago, as we all know the TEAS WG didn't reach an agreement about their term of the identifier of this network slice. The te-topology-identifier is not included in the current version. We will consider it in the later version under the topology.
- [Jie] Need to clarify the relationship between the topology filter in the YANG model and this draft. It is not clear from the current draft.
- [Zhenbin Li (Robin)] This is one draft divided into four drafts. Maybe more drafts will be proposed. There can be different constraints, but I doubt if there is a requirement or not.
- [Dhruv] We will be looking out for guidance from TEAS WG/Chair on how to process and we are requesting authors to keep alignment with the TEAS document and this document. There are other comments which I will send to the list.
3.3. VTN in PCEP (Minxue Wang, 10 mins) [30/60]
draft-dong-pce-pcep-vtn-00
- [Tarek Saad] As you know TEAS WG agreed on network resources to call the underlay resources associated with slice network resource partition and we can pass NRP-ID in the PCEP message. I am not sure if you want to standardize to passing two IDs a VTN-ID and NRP-ID. May be authors of this draft should collaborate with the authors of the draft that Quan had mentioned earlier. I would like to hear the Working Group chair's opinion on that as well.
- [Dhruv] Are you sure that we have this resolved in TEAS already? Atleast that's not my reading and I would welcome the TEAS chair to correct me if I am saying that wrong.
- [Tarek] I did see the term Network Resource Partition in the slice definitions draft that Adrian and editors are driving.
- [Dhruv] But this is coming from enhanced VPN, right? They have applicability outside of Network slicing.
- [Tarek] Any generic protocol extension has to reference a generic term which is network resource partition. Otherwise, we will end up duplicating protocol extensions and that was the whole point of coming up with a generic term.
- [Dhruv] We are looking for TEAS guidance on this.
- [Jie] We have sent an email to discuss the relationship between enhanced VPN and network slicing on TEAS mailing list. I suggest people provide their feedback and opinions to that based on that we can see whether they have the different scope or not.
- [Pavan] There was an open item after the last interim meeting. There was a thread that Adrian started. Few names floated around. From the chair's point of view, we would like the authors of the document to pick what is appropriate.
- [Adrian Farrel] I am the editor for the TEAS framework. There is no consensus being called on what the text in the framework says. The intention is to provide a common base reference and definitions and allow other documents to either use that terminology or to say what we are doing in this document maps to the base terminology as follows. We are not attempting to force people to rewrite or change their documents or change their solutions merely to explain how their solutions map to the framework.
- [Dhruv] We will continue the discussion on the mailing list.
3.4. PCEP-LS (Gyan Mishra, 10 mins) [40/60]
draft-dhodylee-pce-pcep-ls-22
- [Cheng] I want to work on this. We have BGP-LS already. If we want to make the PCEP protocol perfect, then we need to finish this work.
- [Zhenbin] PCEP-LS is definitely useful in other scenarios.
- [Aijun] We prefer the usage of the PCEP-LS over BGP-LS. I think this certainly simplify the implementation of the controller and the router.
Multicast
4.1. BIER (Huanan Li, 10 mins) [50/60]
draft-li-pce-based-bier-02
- [Dhruv] This was presented in BIER WG as well. We need to get a clear set of requirements from BIER WG and overall architecture that we can check against in the PCE. There are a lot of BIER and non-BIER in the same document which is confusing. We need to look at this whole work holistically.
- [Tony Przygienda] The best is to get an interim meeting from the PCE side and BIER side. I suggest getting together with Greg, set up and start rolling interim and work kind of the charter of the interim or work items during the interim.
- [Aijun] I think the people in BIER WG are interested in a multicast solution for PCE. I think we can discuss this later in the interim.
- [Dhruv] The document is called PCE-based BIER, so it shouldn't have non-BIER things in the document. We need to have clarity of what is applicable for any multicast overlay. We have RSVP, SR P2MP policy as well. So we want things that are generic to not be a part of the BIER specific extension to PCEP.
- [Gyan] This document should focus on BIER and not non-BIER related. There is already RFC 6006 which talks about Point-To-Multipoint PCEP extension, so there is already existing work that deals with non-BIER specific multicast.
Others
5.1. Color in PCEP (Balaji Rajagopalan, 5 mins) [55/60]
draft-rajagopalan-pce-pcep-color-00
- [Dhruv] I could not find where this TLV is going to be carried. Which PCEP object?
- [Pavan] It is in LSPA. It depends on the use-case. In multi-path draft it would sit under the path-attribute.
- [Dhruv] But you do have the RSVP use-case as well right, so at least for RSVP use-case you need to specify where this TLV is carried.
- [Pavan] We will look into it.
5.2. VLAN-based Native IP (Yue Wang, 5 mins) [60/60]
draft-wang-pce-vlan-based-traffic-forwarding-01
- [Aijun] More explanation. The usage of VLAN-Based forward is similar with MPLS forwarding, but can be used in Native IP environment. We are trying to align with the PCECC procedures.
End
Last updated on 16 Nov 2021, 1221 UTC