Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pce-inter-layer-req-15

From: Adrian Farrel <[email-masked]>
Date: Sun, 08 May 2011 15:15:44 +0100

Several years passed; the snow settled into great drifts and all life vanished
from the courtyard of the great palace...

in line...

> - General comment/question: In reading the document I found a number of
> places where the text seemed to imply that the PCC was always the
> layer/region boundary, which is inconsistent with RFC5623.  Is this
> intentional?
> 
> Examples from the document include:
> 257 An ingress LSR for the higher-layer LSP, or a PCC, needs to
> 258 know whether triggered signaling is required or not.
> 
> While this is true for the boundary LSR, I'm not sure how it fits into
> this document.  Isn't such determination made by the boundary LSR per
> RFCs 4206 and 6001?  If so, the sentence is out of scope of this
> document.  If you do keep it, I suggest replacing " An ingress LSR for
> the higher-layer LSP, or a PCC," with something along the lines of "A
> layer boundary LSR".

I think you misread this one.
The ingress LSR for the higher-layer LSP is unlikely to be the boundary LSR.
That would more likely be the ingress LSR for the lower-layer LSP.
But the case where it is, is caught by your next comment.

> 275   Also note that an ingress LSR may be present in multiple layers.
> 
> Is "ingress LSR" mean "a layer boundary LSR", or "the PCC LSR"?

Hmm, yes, both, or either.
Clarifying text.

> 299  3.1.4. Adaptation Capability
> 
> 301  It MUST be possible for the path computation request to indicate the
> 302  desired adaptation function at the end points of the lower-layer LSP
> 303  that is being computed. This will be particularly important where the
> 304  ingress and egress LSR participate in more than one layer network but
> 305  may not be capable of all associated adaptations.
> 
> This section cases me concern a number of levels.  The first is that
> "adaptation function" is not defined in this document, nor is it used in
> the other MRN documents.  Furthermore, is it reasonable to have
> adaptation  indicated by a PCC when the layer/region boundary is at an
> intermediate LSR?  Perhaps this paragraph is only intended to apply to a
> multi-layer PCC/LSR?  In either case, the scope and intent of this
> paragraph really needs to be clarified.

Yup, this applies to the ingress/egress of the lower layer LSP (it is clearly
important to build an LSP that can be used by the higher layer!

We mean it in the sense that "adapt" is used in RFC 5212. I'll add a
clarification.

> 126 [RFC4657] and [RFC4674].
> 
> Suggest adding ", and the framework provided in [RFC5623]."

OK

> 271   virtual TE links from regular TE links, it MUST be understood that a
> 
> Who MUST understand this? If this is the reader/implementer/user then
> this should be "must".  If there are protocol implications, they should
> be made more explicit, i.e., they're not clear.

Good catch of passive voice.

> 276  Thus, when a mono-layer path is requested or supplied, PCEP MUST be
> 277  able to indicate the required/provided path layer.
> 
> Doesn't this requirement also apply to multi-layer paths? (Consider case
> where ingress/PCC is present in multiple layers.)

Yes. This should read "even when" since that is case we wanted to highlight.

> 330 purpose, the PCE discovery mechanism MAY support the disclosure of
> 
> As this applies to the mechanism and not a particular implementation,
> shouldn't this be a "MUST"?

Disagree. There are other options to Discovery including capabilities exchange
and configuration. So this really is only a "MAY".
 
> 333	   path-computation-related PCE capabilities:
> 
> Should supported layers be included in the advertised capability list?

Yes. In fact, the supported layers are no use without the adaptation functions,
and the adaptation functions would not be any use without the layers. So the
adaptation is sufficient.
 
> 350	4.1. Control of Function and Policy
> 
> Do you want to add a reference to 5394?

Yup.

Many thanks for the careful review.

Adrian

---

From: Lou Berger <[email-masked]>
Date: Mon, 09 May 2011 09:53:13 -0400

Hi Adrian,

> from the courtyard of the great palace...

Humm, means I have to remember this draft.  I'll try!

> in line...

responses too...

> But the case where it is, is caught by your next comment.

I guess I just don't understand the point being made in the text. We
agree that the higher-layer LSP is unlikely to be the boundary LSR. So
why does "An ingress LSR for the *higher-layer* LSP, or a PCC, needs to
know whether triggered signaling is required or not."?

> important to build an LSP that can be used by the higher layer!

I think I read this paragraph from the standpoint of the earlier
sentence which was referring to the path computation request of the
"ingress LSR for the higher-layer LSP".  If the PCC is the ingress of
the lower layer LSP, this section makes perfect sense. Perhaps you can
rephrase text to clarify?

> [...]

> and configuration. So this really is only a "MAY".

Okay, I buy configuration as an alternative that doesn't require the
such advertisements.  I certainly defer to the WG/authors on this, but
it seems to me "MAY" is quite weak guidance given the value of the
advertisements.

> adaptation is sufficient.

I've always considered "adaptation" path-computation logically separable
from "layer-specific" path-computation, but can accept that the latter
isn't expected without the former.  You may want to make this
implication explicit.

> Many thanks for the careful review.

You're welcome.  Hope you found it useful.
Lou