Done. Thanks. Adrian > -----Original Message----- > From: Jonathan Hardwick [mailto:[email protected]] > Sent: 03 January 2017 17:53 > To: [email protected] > Cc: [email protected]; [email protected]; > [email protected] > Subject: RE: [Pce] Shepherd's review of draft-ietf-pce-inter-layer-ext-11 > > Hi Adrian > > I think your proposed new text is good. Many thanks. > Please submit the update and I will do the shepherd's report. > > Cheers > Jon > > > -----Original Message----- > From: Adrian Farrel [mailto:[email protected]] > Sent: 29 December 2016 18:52 > To: Jonathan Hardwick <[email protected]> > Cc: [email protected]; [email protected]; > [email protected] > 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 am going round and round on this :-( > > I, M, and T grrrrrrrr! > > Our case is I=1, M=0, T=0 meaning: > - The PCE may perform inter-layer path computation and return an inter-layer > path > - A mono-layer path is requested > - Triggered signaling is not allowed > > I read this to mean that the computation may look at more than one layer, but > that the returned path must be in only one layer. Therefore, the path cannot dip > into another layer, but could use a virtual link that spans that layer. However, that > virtual link must already exist and cannot be set up on demand. > > So far, so good. > > Now, if the virtual link has been pre-established it will (presumably?) already > appear in the TED for the upper layer, so I think you are right. > > OLD > 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. > In addition, loose hops that span the lower-layer network must not > be specified. Therefore, this is equivalent to the I flag being > clear (zero). > NEW > 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 that have not been pre-signaled MUST NOT > be used in path computation. In addition, loose hops that span the > lower-layer network MUST NOT be specified. Therefore, this is > equivalent to the I flag being clear (zero). > END > > > > 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. > > Done? > > Cheers, > Adrian
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
