IETF 109 PCE WG Meeting Minutes
PCE Working Group Meeting - Thursday, November 19, 2020 12:00-14:00 UTC Session I
- Chairs: Dhruv Dhody, Julien Meuric
- Secretery: Hari (Hariharan Ananthakrishnan)
1.1 Administrivia, Agenda Bashing (chairs, 5 min)
1.2 WG Status (chairs, 10 min) [15/120]
1.3 State of WG I-Ds and next steps (chairs, 15 min) [30/120]
- Rakesh Gandhi: draft-ietf-pce-association-bidir-08 - Next week the doc will be updated.
- Aijun Wang: draft-ietf-pce-pcep-extension-native-ip - After the draft is stable, will reach out to IDR WG with BGP Consdirations for their opinion.
- Andrew Stone: draft-ietf-pce-path-protection-enforcement - Draft name seems to be incorrect. It was originally named as path protection and then its renamed to local protection. Dhruv will check the draft name.
2. Segment Routing
2.1 Binding SID (Mike Koldychev, 10 min) [40/120]
- Tarek Saad: Question on Binding SID new type, currently you can download one binding SID for one tunnel. Is my assumption correct?
- Mike: We changed that and updated the document. We allow for multiple binding SIDs now. We allow it for MPLS & SRv6
- Huaimo Chen: For Binding SID, why do you use two values 0 & 1 for one type ?
- Mike: 0 & 1 is to differentiate other bits in the MPLS 32-bit label such as the EXP bits. BT=1 means you control the EXP bits in the MPLS Label. BT=0 means you only want to specify the 20-bit MPLS and dont care about the EXP Bits.
- Huaimo: Please provide more details in the doc if not available.
- Mike: Its there in the document.
- Dhruv: 20 bit label value v/s 32 bit stack label entry is the right way to put it.
- Boris Khasanov: In recent SR Policy draft we added the Composite Path has been introduced, does this draft need to reflect this somehow?
- Mike: Its not going to be in this draft. Its going to be in PCEP multipath path. This draft is about carrying binding Label and its unaffected by the composite policy addtion.
- Dhruv: Even the SR Policy association might be something that might change as well, not just the multi-path document?
- Mike: No, I dont think so. You just need to carry color instead of ERO to support the composite policy. Candidate path instead of having segment list of labels it will have the color thats required to signalling the composite policy.
- Pavan Beeram: There might be some changes in the SR Policy. There are multiple ways of addressing it.We will discuss on the list
- Dhruv: The document is making good progress. Is the doc ready for LC?
- Mike: We can wait until the next one to decide that.
- Cheng Li: I agree with Mike. We can wait for one more meeting to decide on the LC.
2.2 PCEP for SRv6 (Cheng Li, 10 min) [50/120]
- Dhruv: The next draft will describe about Algorithm. We can decide if we need A-flag in that discussion.
- Dhruv: Between the Binding SID and PCEP SRv6 document, please align the SID structure. It should be same format atleast in the PCEP.
- Cheng: OK.
- Dhruv: Another question that is not directly related to SRv6, this V-flag introduced here for SRv6 but we dont have it for SR MPLS. If we are adding it to SRv6 ERO, we might have to update the SR MPLS as well with V-flag.
2.3 Algorithm in SID (Mike Koldychev, 10 min) [60/120]
- Jie Dong: This is a useful extension. L-Bit: its not clear whether different prefix SIDs with different algorithms can be put in the same ERO for one path?
- Mike: If you specify the Loose flag, then its allowed to insert another algorithm.
- Jie: Using different alogirthm in one path might cause a loop if it is allowed.
- Mike: Do you mean if we can use algorithm 128 and 129 or you algorithm 129 if you can but you cant fall back to some other algorithm ?
- Jie: My point is for Prefix SID in one path, we might have to restrict it to use one consistent algorithm, if they fallback to one, then they should not use different algorithm.
- Mike: You think that might cause a loop ?
- Jie: yes, different algorithms used in one path may cause a loop.
- Jie: In PCEP, SR Segment type is described in different way (SID+NAI) vs SR Policy in SPRING and IDR WG. NAI should be aligned with Segment types.
- Mike: In PCEP we used NAI encoding, in BGP we use different types of SIDS ABCD upto K. Its too late to unify them. We should go through them and make sure they have equivalent format.
- Dhruv: We could use this opportunity to fix misalignment between the docs. For example the v-flag that we were discussing in the previous document can we use this document to also add the v flag for SR MPLS. Just as an example.
- Mike: Sure.
- Dhruv: LSPA part is not very clear. We are not sure if this algorithm has to be use as end-to-end path algorithm or while picking Prefix SIDs you prefer SIDs that uses this algorithm. As you know we have an Objective Function which is suppose to do minimum delay path that is an end-to-end objective function. Is this algorithm going to replace that or adding to that? Please do take care of that part as well when describing LSPA.
- Mike: OK, Point taken.
- Tarek: If we are crossing multiple domains, we might have to specify 128 in domain-A and 129 in domain-B. There is an implicit assumption that an algorithm is end-to-end. You might want to open up the possibility of an algorithm per domain. We can talk the details of it.
- Mike: Not sure how to specify domain specific algorithm.
- Tarek: I will reach out offline.
- Loa Anderson: Question on number of things that could be done with one algorithm. Is there a practical limit to how many things you can do?
- Mike: You might be able to specify FLex algo computation constraint and you need to be able to specify that a given computed ERO hop is of a particular FLEX aglorithm.
- Loa: Are those the only things that we can do ?
- Mike: I guess, yes.
- Loa: Is it possible to extend the current format ?
- Mike: this is for specific purpose to carry Flex algo constraint or result.
- Loa: Lets say you have more than one type of constrain and you have a minimum bandwidth and the jitter. Can you put both of them in there ?
- Mike: You may be able to mix Flex algo constraint with another constraint. Its possible to combine different constraints.
- Loa: I will reread the draft and take it to the list.
- Loa: Could we exclude nodes?
- Mike: Yes it should be possible. Its possible to have more than two constraints.
- Loa: So there is no pratical limit to how many constraints you could have ?
- Mike: Yes, for sure not. It doesnt mean that other constraints are not allowed to be used with this one.
- Huaimo: In one domain for that path, could we have multiple algorithms? One may be for delay and one may be for bandwidth.
- Mike: Not necessarily. If you request a path optimizing latency, the PCE may return a flex algo that optimizes latency.
- Huaimo: should we group algos per domain ?
- Mike: I dont think there should be any issues in using different algorithms within or outside domains.
- Mike: Its upto the PCE controller to take care that there isnt any loop.
- Huaimo: Should there be any check about using different algorithms for consistency ?
- Mike: Why not ? We can discuss that.
- Dhruv: Its best for the mailing list.
- Pavan: There is definetly value in having the ability to specify different constraint/objectives for a inter-domain path. In RSVP we have the notion of Hop attributes, where we can provide set of attributes to a given path. We dont have that in PCEP. If we could bring in that construct, it will be useful. We can discuss about that in the list.
- Jeff Tantsura: Concatenation of algorithms would be logical in single domain.
- Mike: There could be counter examples where this could be bad.
- Jeff: From document perspective we need to provide scenarios where its safe to do so. We need to protect consumer of this information from breaking things.
- Mike: Thats more of vendor implementation of algorithm.
- Jeff: Its our job to remove any ambiguity.
- Dhruv: Please take the remaining questions to the list.
2.4 P2MP SR Policy (Hooman Bidgoli, 10 min) [70/120]
- Huaimo: This looks like a PCE Controller where PCE needs to send instructiosn to each node along the P2MP Path ?
- Hooman: You are correct, the nodes that are involved in replication needs to have this information.
- Huaimo: In that case for each P2MP path there is state in the network? This is not consistent with the philosophy of SR routing. For Segment Routing that idea is there is no state in the network.
- Hooman: Good point. That battle was already fought in the SPRING WG. A segment in P2MP creates a replication segment, without that we dont know the outgoing interfaces.
- Dhruv: W.r.t PCE extension, we have a concept called PCE as Central Controller. The PCECC technique and use of CCI object would have become a better extension to PCEP protocol than what is currently being described in the document. We have discussed this in the past as well when you last presented this in the PCE working group and that concern still exists.
- Hooman: The ERO object that we are using is fit for this idea.
- Dhruv: Lets have the discussion in the list. Its not just the ERO object, the whole framework that I am worried about.
- Hooman: Sure we can discuss in the mailing list.
3. Stateful PCE & PCECC
3.1 PCECC Drafts (Shuping Peng, 10 mins) [80/120]
- Aijun: The draft name could be confused with PCE for SR Policy. Can we think of a way to distinguish them?
- Dhruv: Are you suggesting draft name change or title change?
- Aijun: Yes.
- Dhruv: OK. We can take that into consideration.
- Shuping: Sure, we can discuss about it.
3.2 IFIT (Giuseppe Fioccola, 10 min) [90/120]
- Mike: Whether there are use-cases where we could have different tracing options per segment-list of the SR Policy candidate path? The SR Policy candidate path have multiple segment list.
- Giuseppe: This is something we can consider.
- Mike: Same thing has to be done for BGP related draft as well.
3.3 Path MTU (Luc-Fabrice Ndifor, 10 mins) [100/120]
- Mike: Its a good and useful draft. The SR policy candidate path can have multiple segment lists, each segment list may have different PMTU. I noticed that your PMTU is per candidate path, in that case one has to report lowest of those segment list. It might useful to also report each segment list separately as well, in case the headend is able to send different sized packet to different Segment List.
- Fabrice: Noted.
- Jeff: How useful is this in SR use-cases ? The real constraint is the amount of SIDs that we can impose. MTU is implicit to that. I believe MSD provides enough information to compute constraints.
- Cheng Li: To answer Mike’s question, we have similar solution in BGP Path MTU policy.
- Cheng Li: We could discuss in the list regarding Jeff’s comment about MSD.
3.4 Updates to Stateful PCE drafts (Cheng Li, 15 mins) [115/120]
- Dhruv: From the chairs perspective, the documents have been stable since IETF-105. Now is the time to for the WG to speak up.
- Dhruv: See you at gather.town.