Re: [Pce] Shepherd's review of draft-ietf-pce-inter-layer-ext-11

["Adrian Farrel" <[e-mail]>]

Done. Thanks.
Adrian

> -----Original Message-----
> From: Jonathan Hardwick [mailto:[e-mail]]
> Sent: 03 January 2017 17:53
> To: [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]
> 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:[e-mail]]
> Sent: 29 December 2016 18:52
> To: Jonathan Hardwick <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]
> 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