Hi Thanks for your discussion. Dhruv: I was under the impression that the format is fixed for each type. In the above draft , i see only delay variation can be 8 or 16 bits. Anywho, the current capability encoding with flag bit does not make sense. How would one link Type flag bit with the format flag bit? IMHO this format is not useful in the control plane, you might need this for data plane only. Maybe you want capability flag to indicate data plane capability? This needs some work. Li: As you said, Except the type of variation, each type has only one format, the format flag bit does not make much sense. But now the control plane need to keep align with the data plane to identify two kinds of variation. We will consider your comment in the next step.
Dhruv: My suggestion would be to think of a holistic solution from the start. Li: A good suggestion, we will propose a holistic solution in the next version of draft. Dhruv: What would be helpful would be an example or some text of how PCE uses this during path computation (it might be intuituve for detnet folks but helpful to be explicit for PCE folks). I don't see this in RFC 9016. Li: It is described in section 4 of Draft-ietf-detnet-bounded-latency-10<https://datatracker.ietf.org/doc/draft-ietf-detnet-bounded-latency/> that how to calculate the bounded latency from T-SPEC defined in RFC9016. And then the bounded latency calculated will be a constrain for the PCE’s path computation. Thanks! Li 发件人: Dhruv Dhody <[email protected]> 发送时间: 2022年7月25日 18:36 收件人: zhangli (CE) <[email protected]> 抄送: Dhruv Dhody <[email protected]>; [email protected]; [email protected] 主题: Re: [Pce] Reply for comments on draft-zhang-pce-enhanced-detnet-00 Hi, Thanks for your reply and discussion. On Mon, Jul 25, 2022 at 3:30 PM zhangli (CE) <[email protected]<mailto:[email protected]>> wrote: Dear Dhruv: Thanks for your comments, here is my reply: Q1: Where is the need for the format flag (uint32, uint16, uint8) coming from? A1: The need of format flag comes from section 4 of draft-yzz-detnet-enhanced-data-plane-00<https://datatracker.ietf.org/doc/draft-yzz-detnet-enhanced-data-plane/>. Since different types of bounded latency information could exist, the format of each type of BLI would be different. That's why we need the format flag in PCEP. Dhruv: I was under the impression that the format is fixed for each type. In the above draft , i see only delay variation can be 8 or 16 bits. Anywho, the current capability encoding with flag bit does not make sense. How would one link Type flag bit with the format flag bit? IMHO this format is not useful in the control plane, you might need this for data plane only. Maybe you want capability flag to indicate data plane capability? This needs some work. Q2: Is the BLI Type TLV meant for RP objects only? How does this work for stateful PCEP messages where there is no RP object? I assume multiple instances of the TLV with different BLI type is allowed. A2: Currently, it can only be used for RP objects, we will think about the extension for stateful PCEP later. Dhruv: My suggestion would be to think of a holistic solution from the start. Q3: How does PCE use the Traffic Model Object? Can there be multiple of them? Please clarify these with suitable references to DetNet documents. A3: The Traffic Model Object describes the traffic information model for DetNet that used for deterministic path computation, the content of it is referenced to RFC9016. There is only one Traffic Model Object in a DetNet path computation request. Dhruv: What would be helpful would be an example or some text of how PCE uses this during path computation (it might be intuituve for detnet folks but helpful to be explicit for PCE folks). I don't see this in RFC 9016. Q4: On one hand, we say BLI are of different formats but in the BLI List TLV and Shared BLI TLV, I see only 32 bits! A4: The format of BLI maybe 8bit, 16bit or 32bit, so we use the maximum of them as the uniform size. See my response to Q1. Thanks! Dhruv Thanks！ Li 发件人: Dhruv Dhody <[email protected]<mailto:[email protected]>> 发送时间: 2022年7月23日 2:30 收件人: [email protected]<mailto:[email protected]> 抄送: [email protected]<mailto:[email protected]> 主题: draft-zhang-pce-enhanced-detnet-00 Hi, Some quick comments... Where is the need for the format flag (uint32, uint16, uint8) coming from? Is the BLI Type TLV meant for RP objects only? How does this work for stateful PCEP messages where there is no RP object? I assume multiple instances of the TLV with different BLI type is allowed. How does PCE use the Traffic Model Object? Can there be multiple of them? Please clarify these with suitable references to DetNet documents. On one hand, we say BLI are of different formats but in the BLI List TLV and Shared BLI TLV, I see only 32 bits! Common comments to both DetNet drafts - - Perhaps it would be a good idea to first list out all the requirements for PCEP. We could then get a confirmation of those requirements from DetNet. I also note that both drafts have different terminology. - PCE WG can then decide the best strategy to encode this, where reusing the existing objects makes sense and where defining a new one would be a better strategy. - We should take the possible RSVP-TE signaling into consideration Hope this helps! Thanks! Dhruv _______________________________________________ Pce mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/pce
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
