* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Pce Status Pages

Path Computation Element (Active WG)
Rtg Area: Alvaro Retana, Deborah Brungard, Martin Vigoureux | 2005-Jan-12 —  

IETF-108 pce minutes

Session 2020-07-28 1410-1550: Room 4 - Audio stream - pce chatroom


IETF 108 PCE WG Meeting Minutes

PCE Working Group Meeting – Tuesday, July 28, 2020 14:10-15:50 UTC Session III

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

1. Introduction

  • 1.1 Administrivia, Agenda Bashing (chairs, 5 min)

  • 1.2 WG Status (chairs, 10 min) [15/100]

  • 1.3 State of WG I-Ds and next steps (chairs, 10 min) [25/100]

    • 11 RFCs since IETF 106

2. Segment Routing

2.1 SR Birdirectional (Rakesh, 10 min) [35/100]


  • Tarek Saad: Does this Bi-Dir support multiple segment lists? What would happen if there are multiple segment lists in the SR path?
  • Rakesh Gandhi: In this I-D we say SR-Path (and not SR-Policy, Candidate Path, Segment List). PCEP has the capability via association group.
  • Tarek: Are you disallowing multiple segment list? or an SR CP being instantiated with multiple segment list for BirDir ?
  • Rakesh: we are not disallowing it. Not clear what would be the use case. But, if there is use-case and requirement we can discuss and put the required text in the draft.
  • Dhruv: We have to mention SR Policy somewhere in this document and what is the relation between this work and the SR policy work. We cant leave that open for interpretation it will be good if you could handle that.
  • Rakesh: Definitely, yes.
  • Dhruv: I remember there were other comments as well, I want to make sure those were handled in this new version. Something that got missed was adding PLSP-ID in the figure to make that part easier to understand. Other people who commented during the adoption please recheck if your comments were handled or not.
  • Rakesh: yes, I remember that comment we will add that the figure.
  • Dhruv: Is the RSVP-TE document ready to ship or is there any dependency between this work and RSVP-TE work? Shall we ship RSVP-TE?
  • Rakesh: I think so, there was a small change that we made in March when we updated this SR Path. Since then for 4 months its been pretty stable and there is nothing outstanding. I don’t see any intersection at this point.

2.2 Multipath ERO (Mike Koldychev, 10 min) [45/100]


  • Dhruv: There was discussion on the list about the use of sub-objects. I want to make sure within the WG we have consenses that we will be using a new object and not use the sub-object technique. If anybody have any concerns on that we have time. But it would be a good idea to close on that. Feel free to join the queue if you have any thoughts on that.
  • Dhruv: In the text we still have mention of SERO, and there is a thought of using this in P2MP as well, my suggestion would be to leave that out for now, we have the other document SR replication P2MP. May be its better to do it there keep this on P2P case.
  • Mike Koldychev: Point taken. We did plan to use it for the Tree SID to program multiple outgoing paths. We will consider how to move some of the Tree SID specifics into Tree SID drafts, so that this one is targeted more towards a simpler use-case.
  • Dhruv: Thanks Mike. Any other questions ?
  • Andrew Stone: Feedback for the object v/s sub-object (also provided on list) - I think the way that it is structured in the draft is the cleanest way. So I agree that we can keep it as is.
  • Mike: I agree. The problem with putting something new on the ERO object is that its meant to be kind of carrying stuff from RSVP-TE. Andrew’s reply on the list summarized it very well.
  • Quan Xiong: A Path segment is used to define SR path and in your draft has defined a Path-ID and I think it is similar. What is the difference between path segment and path ID?
  • Mike: Path segment is a label that is programmed on the tail-end. Path ID is not a label, it is juat numeric value, unique only within the context of the tunnel. It would typically have a value like zero, one, etc. So there is no similarity between them they are kind of very different things. May be we can discuss this on the list.
  • Quan: Thank you.
  • Dhruv: I was just going through the document, IANA section needs some work because we have some flag fields that we are defining so make sure IANA section is handled. Apart from that document I think the document is in a good condition. Thanks for working on it.
  • Mike: I will look at the IANA section for sure.

2.3 Entropy (Quan Xion, 10 min) [55/100]


  • Zhenbin Li: Is ELI/EL calculated for a SR-Path or a specific traffic low ?
  • Quan: We used PCE to compute the ELI/EL position not the value of the EL/ELIs. The value of the ELI/EL is calculated at the ingress. We propose the PCE to decide the placement. Because RFC 8662 proposes the criteria to determine the best EL/ELI placement. So we think the placement is important and it can be computed in the PCE. So PCE computes the placement and the ELI/EL value is computed in the ingress.
  • Zhenbin: I understand this. So for the ingress we have two entities. One entity is the SR Path and another is user traffic flow. When PCE calculates the ELI/EL position, is it calculation for the SR path or the traffic flow identified by the five tuple?
  • Quan: I am not sure. SR path is also computed for the traffic flow.
  • Zhenbin: I think its a different granularity. We can have more discussion in the mailing list.
  • Dhruv: My understanding of reading the draft was that is is being put as part of SR Path. So you can continue to have this discussion on the list and clarify.
  • Quan: OK. Thank you Dhruv.
  • Dhruv: I also sent an email regarding last IETF’s discussion with Stephane. We want to make sure we close on that discussion if anybody has any thoughts on that? Just a single bit is used by PCC to say it has capability to add multiple ELI/EL pairs. We had this discussion in the last meeting whether something more is needed. So I would like for us to have a conclusion on this so we can continue to do that in the mailing list.
  • Quan: Yes, welcome to discuss in the mailing list.
  • Dhruv: One more question, You have another presentation where we are talking about the LSP object flag fields. We have run out of flags so I would suggest you to change this document and use the flags from the extended LSP flag TLV.
  • Quan: OK. Thank You.

2.4 SRv6-Yang (Luc-Fabrice/Shuping, 10 mins) [65/100]


  • Dhruv: Not a question directly related to this document, but something missing is to link the SID list with the SR Policy YANG as well. This is missing for both SRv6 as well SR-MPLS, so it would be worth exploring if we could put a reference to the SR Policy YANG as well and not just the SID List.
  • Luc-Fabrice: Noted.

2.5 IFIT (Giuseppe Fioccola, 5 mins) [70/100]


  • Tarek: Question about Flow-ID. Is it coming from PCE, is it a global or is it scoped within head-end?
  • Giuseppe Fioccola: Do you mean the FlowID in this draft ?
  • Tarek: Yes.
  • Giuseppe: This is coming from the draft in 6man of the alternate making extension for IPv6 where we define the option header.
  • Tarek: OK, in that draft there is information about is it Global or scoped within the head-end.
  • Giuseppe: Yes.
  • Tarek: I will take a look.
  • Loa Andersson: I have question on flags in the TLVs. 16 bit, 8 bit, 4 bit flags. We are running out of flag space. Will we run out of flag space in a year or two ? If we do we have to add another flag field.
  • Giuseppe: Yes, this is a good point. We should also evaluate some possible extensibility. I understand your point.
  • Dhruv: Are these flags coming from data plane documents? So if this point actually makes sense even in the data plane case and they are not defined in PCEP extension but we are reusing these flags form other documents. Is that correct?
  • Giuseppe: Yes. Correct, that its coming from other documents.
  • Dhruv: This is something IOAM folks need to consider.
  • Zhenbin: I don’t think flow-id is global. Its a domain-wide flow id.
  • Giuseppe: Agree, its global in the network domain.
  • Zhenbin: Agree.

3. Stateful PCE

3.1 Local Protection Enforcement (Andrew Stone, 10 mins) [80/100]


  • Dhruv: Anybody has any thoughts on updating RFC 5440? Please feel free to speak up.
  • Andrew: As next step, request to chairs for adoption poll.
  • Dhruv: You have to bear with us. There is a bit of queue here, so we will get to it.
  • Dhruv: Update the implementation section in the document.
  • Andrew: Sure.

3.2 Extended LSP Flag (Quan, 10 min) [90/100]


  • Dhruv: Julien and I think this document is useful and we were considering fast tracking this document. So if folks have any comments please respond to the list or ask questions here. There is still some tightening up of text that is needed in the document. So I will work with authors and provide my comments on the list.

3.3 Path MTU (Shuping Peng, 10 mins) [100/100]


  • Tarek Saad: The MTU that you are going to signal from PCE is that MPLS MTU, IP MTU or Layer 2 MTU? which MTU is it?
  • Shuping Peng: That depends on the data plane, its not limited.
  • Tarek: Is it tied up to LSP? Is that what you are trying to say?
  • Shuping: Yes, it could also be LSP, but this is for SR network.
  • Tarek: Yes, if this is SRv6 are you going to signal the IP MTU?
  • Shuping: For the IP MTU? What do you mean?
  • Tarke: Excluding the L2 header.
  • Zhenbin Li: This is path MTU for the SR Policy. For SRv6 its IP MTU. It depends on the calculation options.
  • Tarek: Its good to clarify, if its not already in the draft. I agree Robin.
  • Cheng Li: It is associated with the data plane. If we are calculating path MTU for SRv6 path then its an IP layer MTU if we are calculating an SR MPLS path then its the MPLS Layer MTU.
  • Vishnu Pavan Beeram: So the Path MTU determination does it take into account say its a MPLS Path, does it take into account the number of labels in the stack at each hop or in the case of SRV6 path does it take the header, incoming header size at each hop of the path or is it something that is out of the scope of this document?
  • Shuping: For SR MPLS it considers the label stacks. For SRv6 its SID list.
  • Pavan: If you have five hops using adjacency SIDs; are you just going to discount this label stack size for five labels or is it taking into account? What would be the incoming label stack size at each hop? Typically if you are calculating the Path MTU, you do discount for the label stack size or the header size and then determine. I haven’t read through the draft, but looking at the slides you just seem to be saying that is just the minimum of the link MTU.
  • Dhruv: Document describes the minimum of link MTU. But I will let Cheng and Shuping answer.
  • Cheng: We first need to collect the minimal value of the link MTU along the path, based on this we need to make minor adjustments like TI-LFA overhead. The PMTU is the value of the minimum link MTU minus other overhead, like overhead of FRR. In this way, the ingress node can use the path-MTU directly.
  • Pavan: I think it will result in conservative estimate. I will send it to the list.
  • Jananbabu Rajamanickam: Are we going to consider the repair path MTU or just the primary path ?
  • Shuping: It is not in the current draft, we could look into it in future.

4. If time permits

4.1 SR Path Ingress Protection (Huaimo Chen, 10 mins) [110/100]


  • Zhenbin: Can you clarify if the ingress protection is local protection or end-to-end protection?
  • Huaimo Chen: Good question. This is end-to-end protection. We require the controller such as PCE to compute end-to-end path and end-to-end protection path.
  • Zhenbin: Its not clear. If the failure of P1 happens, there is PCE to synchronize this backup information. CE1 also can directly consider the traffic to the back up of the SR Path. I am not sure why the information should be synchronized between the two PEs.
  • Huaimo: In order to implement the protection, we need some kind of behavior in the CE. One kind of behavior is that CE1 can multi-cast the traffic to both ingress nodes and backup node. Thats one behavior. Another behavior is that CE1 can detect the failure of the PE1 only after detecting the failure of PE1 and then PE1 to CE1. CE1 can send traffic to both PEs and controller has to let the backup PE to drop the traffic. We need control information to be delivered to the PEs.


  • Dhurv: Julien, Deborah any last thoughts before we end the session?
  • Dhurv: Thanks everyone. Thanks for attending PCE session. Enjoy your rest of the week and hope to see you in person sometime soon. Stay safe. Thank You.

Generated from PyHt script /wg/pce/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -