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

From: Jonathan Hardwick <[email-masked]>
Date: Fri, 2 Dec 2016 16:50:20 +0000

Dear authors / PCE WG

I have reviewed this document as its shepherd and have the following comments.  Overall, I found this a very well written document, and most of the comments are minor.  My apologies for delivering these after the working group last call has concluded.

Please let me know what you think.

Best regards
Jon

Section 1
"network layering can be support" -> "network layering can be supported"

Section 2
"a hybrid nodes" -> "a hybrid node"
"In this case, PCE needs to be" -> "In this case, a PCE needs to be"

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 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.

A few typos in 3.1:
"and also in PCRpt, PCUpd, and PCInitiate message" -> "and also in PCRpt, PCUpd, and PCInitiate messages"
"When M flag is set (zero)" -> "When M flag is clear (zero)"
"or stitched (xref target="RFC5150" /> LSPs" : stray text "xref target" - bugged XML?

Section 3.3
"without INTER-LAYER Object" -> "without an INTER-LAYER Object"

Section 3.5
This text:

   Optional TLVs: Optional TLVs may be included within the object to
   specify more specific server layer path information (e.g., traffic
   parameters).

I think it would be better to say

   Optional TLVs: Optional TLVs MAY be included within the object to
   specify more specific server layer path information (e.g., traffic
   parameters).  Such TLVs will be defined by other documents.

Section 4.1
Please expand the acronym VNTM on first use.
Please include reference to RFC 5541 when discussing the OF object.

Section 4.2
"PCE MAY specify" -> "The PCE MAY specify"
"the requested PCE replies a PCRep message" -> "the requested PCE sends a PCRep message"

Section 4.3
"message objects define in this" -> "message objects defined in this"

Section 5
Minor typo in the RBNF:
      <PCReq Message>::= <Common Header>
                         [<SVEC-list>]
                         <request-list>
That should be [<svec-list>].

Section 7.2
The description of the T bit should probably be "Triggered Signalling Allowed" to be consistent with the other two (which are named according to their role on the PCReq).

---

From: Adrian Farrel <[email-masked]>
Date: Fri, 2 Dec 2016 17:13:32 +0000

That's no problem, Jon.

We'll attend to your comments fifthwith.

A

From: Jonathan Hardwick [mailto:[email-masked]]
Sent: 02 December 2016 16:50
To: [email-masked]; [email-masked]
Subject: Shepherd's review of draft-ietf-pce-inter-layer-ext-11

Dear authors / PCE WG

Best regards
Jon

Section 1

Section 2

Section 3.1
This text:

as follows:

A few typos in 3.1:

Section 3.3

Section 3.5
This text:

Section 4.1

Section 4.2

Section 4.3

Section 5
Minor typo in the RBNF:

Section 7.2

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 2 Dec 2016 19:56:55 -0000

> Please let me know what you think.

Tomonori's address updated.

> Section 1
> “network layering can be support” -> “network layering can be supported”

Ack

> Section 2
> “a hybrid nodes” -> “a hybrid node”
> “In this case, PCE needs to be” -> “In this case, a PCE needs to be”

Ack

> 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?

> 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 :-)

> A few typos in 3.1:
> “and also in PCRpt, PCUpd, and PCInitiate message” -> “and also in PCRpt,
PCUpd, and PCInitiate messages”
> “When M flag is set (zero)” -> “When M flag is clear (zero)”
> “or stitched (xref target="RFC5150" /> LSPs” : stray text “xref target” –
bugged XML?

Ack

> Section 3.3
> “without INTER-LAYER Object” -> “without an INTER-LAYER Object”

Ack

> parameters).  Such TLVs will be defined by other documents.

Sure

> Please expand the acronym VNTM on first use.

Ack in the last para of section 2.

> Please include reference to RFC 5541 when discussing the OF object.

Ack

> Section 4.2
> “PCE MAY specify” -> “The PCE MAY specify”
> “the requested PCE replies a PCRep message” -> “the requested PCE sends a
PCRep message”

I used "replies with a PCRep message"

> Section 4.3
> “message objects define in this” -> “message objects defined in this”

Ack

> That should be [<svec-list>].

Ack

> Section 7.2
> The description of the T bit should probably be “Triggered
> Signalling Allowed” to be consistent with the other two
> (which are named according to their role on the PCReq).

Yes

I'll wait for your response on the one discussion point before I post.

Thanks,
Adrian
--
Buy somone you love a book for Christmas
Tales from the Wood - Eighteen new fairy tales.
More Tales from the Wood - Eighteen MORE new fairy tales.
https://www.feedaread.com/profiles/8604/
http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924
Or buy from me direct.

---

From: Jonathan Hardwick <[email-masked]>
Date: Wed, 7 Dec 2016 14:37:36 +0000

Hi Adrian

Thanks for the replies - see [Jon] below on the remaining discussion points.

Cheers
Jon

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: 02 December 2016 19:57
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

> 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).

[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"?

> reserved bits in the PCReq messages it sends and in the PCRep messages 
> it forwards to PCCs.
>
> as follows:
>
> 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.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 29 Dec 2016 18:52:21 -0000

> > 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.
> >
> > layer, or specify nodes/links in the server layer as explicit hops.  Please
tell me if
> > I am misunderstanding this.
> 
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).
> [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

> [Jon] Thanks. I think the usage of "MUST" in such cases is normal and is
consistent
> with RFC 5440.

Done?

Cheers,
Adrian