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

From: Jonathan Hardwick <[email-masked]>
Date: Tue, 3 Jan 2017 17:52:32 +0000

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-masked]] 
Sent: 29 December 2016 18:52
To: Jonathan Hardwick <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
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

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 3 Jan 2017 18:40:25 -0000

Done. Thanks.
Adrian

> From: Jonathan Hardwick [mailto:[email-masked]]
> Sent: 03 January 2017 17:53
> To: [email-masked]
> 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