Hi Adrian Thanks for the replies - see [Jon] below on the remaining discussion points.
Cheers Jon -----Original Message----- From: Adrian Farrel [mailto:adr...@olddog.co.uk] Sent: 02 December 2016 19:57 To: Jonathan Hardwick <jonathan.hardw...@metaswitch.com> Cc: pce@ietf.org; draft-ietf-pce-inter-layer-...@ietf.org; tomonori.tak...@ntt.com Subject: RE: [Pce] Shepherd's review of draft-ietf-pce-inter-layer-ext-11 > Section 3.1 > This text: > > o However, when the I flag is set (one), the M flag is clear >(zero), > and the T flag is clear (zero), since triggered signaling is not > allowed, virtual TE links must not be used in path computation. > > I don't think I agree with this interpretation. The virtual TE links > have been set up ahead of time, and are already in the link state > database for the client layer, I believe? If so, using them for a > client layer path should not require any additional triggered > signalling within the server layer. My understanding of this > combination of bits is that the computed path may use virtual TE links > in the client layer, but may not use loose hops across the server > layer, or specify nodes/links in the server layer as explicit hops. Please > tell me if I am misunderstanding this. I think a virtual link may or may not already be set up in the underlying network. That is, the link appears in the TED, but may be ready for use of may require triggered signalling before it can be used. In the PCReq the PCC can say "You must supply a path that can only be used if it is pre-established" (T=0) or "You can supply a path that can be left unestablished requires triggered signalling if you like" (T=1). Given that interpretation, does your understanding change? [Jon] Thanks for the clarification. I agree that the virtual link may or may not already be set up. But I don't think it follows that "virtual TE links must not be used in path computation" if T=0. If the PCE happens to know that a virtual TE link is pre-established (as it may from the stateful PCE extensions), then I think the PCE should be allowed to use it. Would it make sense to say "virtual TE links MUST NOT be used in path computation unless the PCE knows that they are already established"? > I think we should strengthen the requirements of the following text: > > Reserved bits of the INTER-LAYER object SHOULD be transmitted as zero > and SHOULD be ignored on receipt. A PCE that forwards a path > computation request to other PCEs SHOULD preserve the settings of > reserved bits in the PCReq messages it sends and in the PCRep messages > it forwards to PCCs. > > as follows: > > Reserved bits of the INTER-LAYER object sent between a PCC and > PCE in the same domain MUST be transmitted as zero and SHOULD be >ignored on receipt. A PCE that forwards a path computation request to >other PCEs MUST preserve the settings of reserved bits in the PCReq >messages it sends and in the PCRep messages it forwards to PCCs. > > Otherwise, an implementation that chooses to ignore the SHOULDs could > break any new features that want to use the reserved bits. I can go with your changed wording. But beware the people who say that, as a result of the "MUST" you can't build any protocol extensions :-) [Jon] Thanks. I think the usage of "MUST" in such cases is normal and is consistent with RFC 5440. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
