Subject: [Pce] WG Last Call: draft-ietf-pce-inter-layer-req-12

From: Julien Meuric <[email-masked]>
Date: Thu, 09 Sep 2010 18:37:44 +0200

Hi PCE WG.

The I-D draft-ietf-pce-inter-layer-req-12 has been stable for a while 
(except from number and expiration date...). This message starts a 
2-week WG Last Call which will end on Friday 24th October at 12 GMT.

Please send you comments to the PCE mailing list.

Thanks,

JP & Julien

---

From: Julien Meuric <[email-masked]>
Date: Thu, 09 Sep 2010 18:45:08 +0200

My mistake! This 2-week WG Last Call on 
"draft-ietf-pce-inter-layer-req-12" will end on Friday 24th September at 
12 GMT.

Good night...

Julien

Le 09/09/2010 18:37, Julien Meuric a écrit :
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: Meral Shirazipour <[email-masked]>
Date: Thu, 09 Sep 2010 15:08:41 -0400

Hi,
   I have a few small comments on this draft. Please see below.

1)

SECTION 1

"A network may comprise multiple layers. These layers may represent
   separations of technologies (e.g., packet switch capable (PSC), time
   division multiplex (TDM), lambda switch capable (LSC)) [RFC3945],
   separation of data plane switching granularity levels (e.g., PSC-1
   and PSC-2, or VC4 and VC12) [RFC5212], or a distinction between
   client and server networking roles (e.g., commercial or
   administrative separation of client and server networks). "

The "separation of technologies" is the GMPLS Region, and the "data plane
granularity levels" is the GMPLS Layer.
It would clarify the draft if this is mentioned along the fact that the rest of
the draft uses the term multi-layer for both terms (or mainly for
inter-region), as explained in RFC5212.

2)

Section 3.1.3
   "Furthermore, it may be desirable to constrain the number of layer
   boundaries crossed (i.e., the number of adaptations performed on the
   end-to-end path), so PCEP SHOULD include a constraint or objective
   function to minimize or cap the number of adaptations on a path, and
   a mechanism to report that number when a path is supplied."

PCEP SHOULD also include a constraint on the "types" of adaptations used on the
path (and a cap for each adaptation type)

3)

typo: SECTION 3.2
"be able to advise the following"

advise = advertise ?

4)

SECTION 4.3
"PCE Communication Protocol (PCECP)" was a term used before 2009 (i.e., before
PCEP, RFC5440).
I would use PCEP instead of PCECP.

5)
SECTION 4.3
"inter-PCE-PCE": is it inter-PCE ?

6)

SECTION4.5
"Whatever means is used to collect the information to build the
   topology graph MUST include the requisite information."

I donnot understand this sentence. Please clarify it.

7)

4.6. Impact on Network Operation

"The use of a PCE to compute inter-layer paths is not expected to have
   significant impact on network operations."

I disagree with this.I think that the inter-layer PCE discovery and any
inter-layer path computation scheme needs to consider the impact of creating
new lower layer (++BW) links, on the higher layer links/connections, and the TE
mechanisms that may be in place on the higher layers.

Inter-layer PCE discovery insinuates that more than one PCEs may be available.
If this is the case, each PCE may have visibility on different parts of the
lower layer network, which may lead to different paths, etc. Therefore any
inter-layer PCE discovery and any inter-layer path computation scheme should
consider its impact on network operations.

Regards,
Meral

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 9 Sep 2010 21:42:46 +0100

Hi Meral,

Thanks for reading!

> inter-region), as explained in RFC5212.

I think I see your point although I don't completely agree with the stark 
distinction you draw.

Would you like to suggest a revision to this paragraph to address your 
concerns?

> path (and a cap for each adaptation type)

Hmm. You are asking for a different requirement from the one described in 
this paragraph. This paragraph describes the constraint on the *number* of 
adaptations performed.

You are asking for two additional constraints:

1. Control on which adaptations are allowed.

I believe this is at least partially covered in the previous paragraph:

   A request from a PCC to a PCE MUST support the inclusion of
   constraints for a multi-layer path. This includes control over which
   network layers may, must, or must not be included in the computed
   path. Such control may be expressed in terms of the switching types
   of the layer networks.

But you may be asking for a more complicated constraint. Instead of 
controlling the layers that can be traversed, you are talking about 
controlling the adaptations performed (which is a more subtle distinction).

While I have no particular reason to be opposed to this, I wonder whether 
you have a specific reason for wanting it.

2. Control on the number of each adaptation

This could certainly be added. Is it over-engineering? Do you have a 
specific reason for wanting it?

> "be able to advise the following"

I think the word was chosen carefully to cover both the case where the 
capabilities are advertised in the discovery protocol (i.e. the IGP) and the 
case where the capabilities are learned when the session is set up (i.e. in 
the PCEP Open).

Can change this to "advertise" if you feel strongly and if no-one objects.

> I would use PCEP instead of PCECP.

Good catch.

> "inter-PCE-PCE": is it inter-PCE ?

Yes, or "PCE-PCE"

> I donnot understand this sentence. Please clarify it.

Over-zealous edit :-)

The whole sentence is a bit obvious really, but it should read...

NEW
Whatever means is used to collect the information to build the
topology graph, the graph MUST include the requisite information.

> consider its impact on network operations.

I don't understand the points you are making about multiple PCEs in the same 
lower layer having different views of the same lower layer (or the use of 
the word "insinuates").

Again, if you could suggest the text change you would like to see, this 
would help us focus our discussion.

Thanks,
Adrian

---

From: Meral Shirazipour <[email-masked]>
Date: Thu, 09 Sep 2010 20:46:56 -0400

Hi Adrian,

> Thanks for reading!
always my pleasure:)

> Would you like to suggest a revision to this paragraph to address your

Based on the definition of GMPLS Region/Layer given in RFC5212(and other RFCs),
the text between the ++ signs would clarify more (If you agree):

"A network may comprise multiple layers. These layers may represent ++GMPLS
Regions which are++ separation of technologies (e.g., packet switch capable
(PSC), time division multiplex (TDM), lambda switch capable (LSC)) [RFC3945],
++GMPLS Layers which are++ separation of data plane switching granularity
levels (e.g., PSC-1 and PSC-2, or VC4 and VC12) [RFC5212],..."

Just a general comment (not related directly to this draft):

The above would mean that going from a VC12 to VC4 triggers inter-layer PCE path
computation! I am neutral about this even though I see inter-layer PCE path
computation (with PCE coorperation ...) being useful mostly in the inter-Region
case - and I would have a mono-Layer PCE handle the VC12 to VC4 case. Another
way to say this is that any mono-Layer PCE should be able to handle the GMPLS
Layers within the Switching Region it supports.

> specific reason for wanting it?

I hope I will not open pandora's box by asking this:) But what is exactly an
"adaptation" (today)?
Based on RFC5212 and RFC4397 (and a few other refs) it can be nesting/unnesting
on/from an H-LSP, or it can be 'conversion' which is demanding for the node and
may be sub-optimal by wasting a high percentage of the bandwidth in the server
layer.

Given this definition, I would like to limit the number of 'conversion'
adaptation (cap = 0) and allow 'nesting' adaptation (e.g. with cap = 2).

> Can change this to "advertise" if you feel strongly and if no-one objects.

As long as it is not a typo "advise" is good, and it also could mean that a PCE
may decide not to advertise all of its capabilities etc., as described in
Section 4.1.

> topology graph, the graph MUST include the requisite information.

It is clear now, thanks.

> lower layer having different views of the same lower layer (or the use of

That was just an unnecessary example on what could cause disruption in the
higher layers...

> would help us focus our discussion.

RFC5212 "Section 5.4. Stability" and "Section 5.5.  Disruption Minimization",
warn about the impact of inter-layer path computation. I think this should be
mentioned in this draft as well.  Between the ++ is what I propose, (If you
agree):

   "The use of a PCE to compute inter-layer paths is not expected to have
   significant impact on network operations ++if the upper layer Traffic
   Engineering practices are aware of the frequent changes that might
   occur in the VNT [RFC5212]++. ++It should also++ be noted that
   the introduction of ..."

Best Regards,
Meral

---

From: Julien Meuric <[email-masked]>
Date: Tue, 28 Sep 2010 15:53:25 +0200

Hi authors of inter-layer requirements.

Here are my comments on the I-D. I have tried to avoid duplication with 
comments already raised during last call.

----------
"PCC-PCE communication protocol" or "PCE communication protocol" are 
used many times in the document. While it is not wrong, early versions 
were written before RFC 5440 and I think most of those phrases could be 
replaced by the acronym "PCEP" (except from the abstract maybe).
----------
Page 1
-----
s/Generalized MPLS (GMPLS) networks/Generalized MPLS (GMPLS)-controlled 
networks/
----------
Page 3
-----
s/PCE protocol (PCEP)/PCE communication Protocol (PCEP)/
s/Label Switching Router/Label Switch Router/
----------
Page 4
-----
In definition of PCC, the word "application" is used while it is defined 
as a subcase of an "entity" in the following definition of PCE. I would 
suggest to replace "client application" by "client entity" and move the 
brackets "(component, application or network node)" from the definiton 
of PCE to the definition of PCC (which comes 1st).
-----
"higher layer might not have information", "hence might not": I believe 
this use case is likely to happen and I would upgrade the probability by 
replacing "might" with "may". Nevertheless, I do not want to change the 
author's original intend, so it is up to you.
-----
s/computation, consists of/computation consists of/
-----
s/GMPLS optical network/GMPLS-controlled optical network/
----------
Page 5
-----
s/only TE-links/only TE links/ (no strong opinion on the dash, but 
should be consistent along the document)
----------
Page 6
-----
s/the PCEP MUST/PCEP MUST/
----------
Page 7
-----
"When each layer is controlled by a PCE": not sure about this use of the 
word "control"; I would suggest something like "When each layer is in 
the scope of a different PCE".
-----
s/inter-Layer paths/inter-layer paths/
----------
Page 8
-----
Back to the comment on "advise". I am completely fine with it, but in 
case future readers think it is a typo, one might consider "able to 
provide the following information about inter-layer-..."
-----
s/GMPLS networks/GMPLS-controlled networks/
----------
Page 9
-----
s/Whatever means is/Whatever means are/
-----

Cheers,

Julien

---

From: Julien Meuric <[email-masked]>
Date: Tue, 28 Sep 2010 15:51:18 +0200

Hi all.

This last call has ended. My review will follow in a separate e-mail. 
Authors, please move forward by addressing legitimate comments.

Regards,

Julien

Le 09/09/2010 18:45, Julien Meuric a écrit :
> "draft-ietf-pce-inter-layer-req-12" will end on Friday 24th September 
> at 12 GMT.
>
> Good night...
>
> Julien
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 29 Sep 2010 09:01:51 +0100

Thanks Julien,

> s/Label Switching Router/Label Switch Router/

Nope. LSR = Label Switching Router (RFC 3031 section 2.1)

> author's original intend, so it is up to you.

No change.
In the probability stakes, "might" and "may" have the same value, IMHO.
However, there are proscriptive implications to "may not" that the authors 
wish to avoid.

Cheers,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 29 Sep 2010 09:25:21 +0100

Hi Meral,

Just making these changes to the draft.

>> > It would clarify the draft if this is mentioned along the fact that the
>> > rest of the draft uses the term multi-layer for both terms (or mainly 
>> > for
> ++GMPLS

OK. I did this, but moved the new text to be next to the citations.

> Layers within the Switching Region it supports.

I don't think that there is any requirement explicit or implicit that says 
that a network has to use PCE, and certainly no requirement that sub-layers 
must be operated as separate layers.

>> > PCEP SHOULD also include a constraint on the "types" of adaptations 
>> > used
>> > on the path (and a cap for each adaptation type)
>>

Well, I for one am frightened of what may be in that box, and I prefer to 
refer you to our friends in the ITU-T.

> may be sub-optimal by wasting a high percentage of the bandwidth in the 

I don't know whether you can describe something unavoidable as suboptimal.
An adaptation is the "munging" (technical term) that must be done to data to 
go from one layer to another. Depending on the layers it can be as little as 
nothing, as simple as plain encapsulation, or considerbaly complex.

> adaptation (cap = 0) and allow 'nesting' adaptation (e.g. with cap = 2).

I don't think life is as simple as you imply.
By "nesting" I assume you mean encapsulation within the same technology.
This is not always smooth (and sometimes not possible :-)
Even in the packet case nesting implies inserting a new label. This may 
cause the layer 2 MTU to be exceeded requiring fragmentation and resulting 
in significant changes to efficiency.

I am disinclined to open this up further at this late stage. It would, IMHO, 
be better to task PCE with achieving end-to-end efficiency, than it would be 
to try to guess how to impose this by controlling the adaptations.

> may decide not to advertise all of its capabilities etc., as described in

Since Julien also raised this, I have changed to "advertise"

>> > SECTION 4.3
>> > "PCE Communication Protocol (PCECP)" was a term used before 2009 (i.e.,
>> > before PCEP, RFC5440).
>> > inter-layer path computation scheme needs to consider the impact of
>> > creating new lower layer (++BW) links, on the higher layer links/
>> > connections, and the TE mechanisms that may be in place on the
>> > higher layers.
>> >
>> > If this is the case, each PCE may have visibility on different parts of
>> > the lower layer network, which may lead to different paths, etc.
>> > Therefore any inter-layer PCE discovery and any inter-layer path
>> > computation scheme should consider its impact on network operations.
>>

Thanks.

Cheers,
Adrian

---

From: Julien Meuric <[email-masked]>
Date: Wed, 29 Sep 2010 10:39:26 +0200

Hi Adrian.

Let me quote myself: "Back to the comment on "advise". I am completely 
fine with it". I realize that my sentence was not clear at all: I am 
completely fine with the word "advise" which is, as you answered, far 
better than "advertise" (discovery through PCEP is not really 
advertisement). In other words, here is my priority order:
1- advise (best)
2- some phrase like "provide the following information about" (compromise)
3- advertise (downgraded wording, worst).

Up to you,

Thanks

Julien

---

From: Meral Shirazipour <[email-masked]>
Date: Wed, 29 Sep 2010 09:39:49 -0400

Hi Adrian,
   Thanks for considering the comments.
> Since Julien also raised this, I have changed to "advertise"
I think Julien re-confirmed, it would be best to keep it "advise" and 
not change it to "advertise". (it makes sense because a PCE may decide 
not to advertise all of its capabilities, as described in Section 4.1).

> I am disinclined to open this up further at this late stage.
I agree. If the need comes later it can always be looked at by the WG.

Best Regards,
Meral

>>> > The "separation of technologies" is the GMPLS Region, and the 
>>> "data > plane
>>> > rest of the draft uses the term multi-layer for both terms (or 
>>> mainly > for
> I don't think that there is any requirement explicit or implicit that 
> says that a network has to use PCE, and certainly no requirement that 
> sub-layers must be operated as separate layers.
>
>>> > Section 3.1.3
>>> > PCEP SHOULD also include a constraint on the "types" of 
>>> adaptations > used
> Well, I for one am frightened of what may be in that box, and I 
> prefer to refer you to our friends in the ITU-T.
>
> An adaptation is the "munging" (technical term) that must be done to 
> data to go from one layer to another. Depending on the layers it can 
> be as little as nothing, as simple as plain encapsulation, or 
> considerbaly complex.
>
> Even in the packet case nesting implies inserting a new label. This 
> may cause the layer 2 MTU to be exceeded requiring fragmentation and 
> resulting in significant changes to efficiency.
>
> I am disinclined to open this up further at this late stage. It 
> would, IMHO, be better to task PCE with achieving end-to-end 
> efficiency, than it would be to try to guess how to impose this by 
> controlling the adaptations.
>
>>> > typo: SECTION 3.2

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 29 Sep 2010 16:16:03 +0100

OK, I reverted it.

Chairs: I think we are done with all the LC comment.

Thanks,
Adrian
----- Original Message ----- 
From: "Meral Shirazipour" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 29, 2010 2:39 PM
Subject: Re: [Pce] WG Last Call: draft-ietf-pce-inter-layer-req-12

> I think Julien re-confirmed, it would be best to keep it "advise" and not 
> change it to "advertise". (it makes sense because a PCE may decide not to 
> advertise all of its capabilities, as described in Section 4.1).
>
>
>> An adaptation is the "munging" (technical term) that must be done to data 
>> to go from one layer to another. Depending on the layers it can be as 
>> little as nothing, as simple as plain encapsulation, or considerbaly 
>> complex.
>>
>> cause the layer 2 MTU to be exceeded requiring fragmentation and 
>> I am disinclined to open this up further at this late stage. It would, 
>> IMHO, be better to task PCE with achieving end-to-end efficiency, than it 
>> would be to try to guess how to impose this by controlling the 
>> adaptations.
>>
>>>> > typo: SECTION 3.2