Subject: [Pce] Comments on draft-ietf-pce-gmpls-pcep-extensions-08

From: Jonathan Hardwick <[email-masked]>
Date: Tue, 23 Jul 2013 14:22:25 +0000

Hello

I have reviewed this draft and have the following comments and questions.

Best regards
Jon

Section 2 RBNF
The RBNF implies that BANDWITH and GENERALIZED-BANDWIDTH can be mixed on a single request & response.  That looks wrong to me, I think that either one or the other should be supplied but not both.  If both really can be used, please could you add text explaining why?
Same comment for LOAD-BALANCING and GENERALIZED-LOAD-BALANCING.

Section 2.1 RP object
The bits used for the RG flag are not defined until section 5.4.  Please at least xref from 2.1 to 5.4 for the definition.  Better still, define them in section 2.1.

"The RG flag is backward-compatible with

[RFC5440<http://tools.ietf.org/html/rfc5440>]: the value sent by an implementation (PCC or PCE) not

   supporting it will indicate a node granularity."

Pre-existing implementations may calculate at node or link granularity so I don't think you can assume that a back-level implementation will always return node-level granularity.  So, backwards-compatibility does not work as you expect.

My suggestion is to make 0 the reserved value for the RG flags (not 3).  Then the backwards compatibility problem is resolved, since the value RG==0 implies that the sender is a back-level node and so is ignoring the RG field.

"If a PCE honored the the requested routing granularity for a request,

it SHOULD indicate the selected routing granularity in the RP object

included in the response"

Suggest changing the above excerpt to:

"The PCE MUST indicate the selected routing granularity in the RP object

included in the response"

Justification: I think you mean MUST, not SHOULD.  Otherwise the PCC can't rely on the RG flag, rendering it useless.  Also, why should the PCE do this only if it honoured the RG?  I think the PCE should be free to use policy to choose to route at a different RG than that given in the request, and whatever RG is chooses to do the routing at, it should return that RG in the response.  Along the same lines:

"The PCE MAY return

finer granularity on the route based on its policy.  The PCC can

decide if the ERO is acceptable based on its content."

Suggest changing the above excerpt to

"The PCE MAY return

any granularity it likes on the route based on its policy.  The PCC can

decide if the ERO is acceptable based on its content."

Comment on the following statement:

"The PCE MAY try to follow this granularity and MAY return a NO-PATH

if the requested granularity cannot be provided."

If the PCE cannot supply a path at the given granularity then it is either a problem with the PCE's capabilities or a policy issue.  As such, NO-PATH is not appropriate; the PCE should respond with PCErr with a suitable error code.

Section 2.2 and 2.3 GENERALIZED-BANDWIDTH and GENERALIZED-LOAD-BALANCING
I think it is better to specify a format for the GENERALIZED-BANDWIDTH and GENERALIZED-LOAD-BALANCING objects that allows a single instance of the object to specify both forwards and reverse bandwidth.  By having two objects you complicate matters because you then need to specify (and write extra code for!) all the consistency rules between the objects (e.g. you don't say what happens if the max-LSPs field differs between the forwards and reverse direction GEN-LB object).  This in turn will make implementation more fiddly and potentially less interoperable.  How about including the reverse-direction TSPEC in the same object as the forwards-direction TSPEC if the R bit is set?

You state that multiple objects with the same TSPEC type are dealt with by ignoring all but the first.  Why do you allow multiple objects with a different TSPEC type?  And what is the PCE to so with a request containing different types of TSPEC?  I think that all TSPECs need to have the same type.

Section 2.4.1 Generalized-Endpoint object type
To aid clarity, suggest rewording this:

"A PCE not supporting those
   TLVs but not being able to fulfill the label restriction MUST respond
   with a response with NO-PATH with the bit "No endpoint label
   resource" or "No endpoint label resource in range" in the NO-PATH-
   VECTOR TLV, the response SHOULD include the ENDPOINT object in the
   response with only the TLV where it could not met the constraint."

to this:

"A PCE supporting those
   TLVs but not being able to fulfil the label restriction MUST send
   a response with a NO-PATH object which has the bit "No endpoint label
   resource" or "No endpoint label resource in range" set in the NO-PATH-
   VECTOR TLV.  The response SHOULD include an ENDPOINT object
   containing only the TLV where the PCE could not meet the constraint."

Section 2.4.2.5 Labels TLV
Suggest changing

"This Bit SHOULD be set to 0 in a SUGGESTED-LABEL-SET
      TLV Set."

to

"This Bit SHOULD be set to 0 in a SUGGESTED-LABEL-SET
      TLV Set and ignored on receipt."

Delete orphaned text which says "Table 5" - no table present in this section.

Section 2.5
Stipulate that IP address subobject MUST be a link subobject.
Clarify that >1 label subobject may follow each link-address or unnumbered-link subobject.

Section 2.6 XRO
Better to just define the X bit than refer to RFC 5521.  The definition is simple enough.

You say the C-Type is "copied from the label object" - what label object?  Isn't this just a number which identifies the type of the labels?

Does the label field specify a single label or an array of labels?  (Suppose single label but it is not quite clear.)

Section 2.7 PROTECTION-ATTRIBUTE TLV
I am not sure that re-using the format from RFC 4872/4873 is the right way to go.  It leaves us with a format containing many elements that are superfluous (or at least, not obviously applicable) to path computation.  It would help if you could add some text explaining why each field is applicable to path computation.

For example, on the PROTECTION-ATTRIBUTE TLV flags:

*         S bit: since the PCE server does not assign resources, it seems that this bit will not be used in PCEP, correct?

*         N bit: I think this is irrelevant to PCEP.

*         O bit: ditto.

*         I bit: ditto.

*         R bit: ditto.

Unless I have misunderstood, I think It would be better not to define these bits in the object format.  If you must have them then I think you should at least stipulate that they are ignored on receipt.

You say "LSP Flags can be considered for routing policy based on the protection type."  I think you must mean the Link Flags, since these specify the link attributes that the path requires.  I am not sure what use the LSP flags are to the PCE; please could you explain?  Same comment applies to segment recovery flags.

Where you say "The other attributes are only meaningful for a stateful PCE", please could you say why a stateful PCE might make use of them, or point me at a draft where this is discussed?

---

From: "Margaria, Cyril (Coriant - DE/Munich)" <[email-masked]>
Date: Thu, 25 Jul 2013 14:41:30 +0000

Hi Jonathan,

Thanks for the review, please see inline .

Mit freundlichen Grüßen / Best Regards
Cyril Margaria
From: Jonathan Hardwick [mailto:[email-masked]]
Sent: Tuesday, July 23, 2013 4:22 PM
To: [email-masked]
Cc: [email-masked]
Subject: Comments on draft-ietf-pce-gmpls-pcep-extensions-08

Hello

Best regards
Jon

Section 2 RBNF

[[Margaria.C]] This is for backward-compatibility : for instance for reoptimization request the BANDWIDTH MUST be provided. We did not want to change existing  logic but to enhance the information. The GENERALIZED-BANDWIDTH is present as a detailed expression of the BANDWIDTH.

Section 2.1 RP object

[[Margaria.C]] OK

[[Margaria.C]] In that case the ERO contains nodes, the intent is more to ask for a more detailed route rather than to force a less detailed route. The values should be read as node (or better) , not node-only ERO (Wording can be added).  Do you see a use case for node-only ERO (or link-only ERO) ?

Justification: I think you mean MUST, not SHOULD.  Otherwise the PCC can't rely on the RG flag, rendering it useless.
[[Margaria.C]] In the absence of flag the PCC should check. The SHOULD is here to allow PCEs supporting the other object but not filling this bit, but in any case they can put 0 (PCC has to check then), so a MUST can be added.
Also, why should the PCE do this only if it honoured the RG?  I think the PCE should be free to use policy to choose to route at a different RG than that given in the request, and whatever RG is chooses to do the routing at, it should return that RG in the response.
[[Margaria.C]] OK

  Along the same lines:

"The PCE MAY return

"The PCE MAY return

[[Margaria.C]] OK

If the PCE cannot supply a path at the given granularity then it is either a problem with the PCE's capabilities or a policy issue.  As such, NO-PATH is not appropriate; the PCE should respond with PCErr with a suitable error code.
[[Margaria.C]] The PCE may also miss TE information (loose routing over a domain or missing label information) , so a NO-PATH is valid in that case (if policy dictate it should not return a lower granularity).
I will add the PCErr for the case you mentioned.

Section 2.2 and 2.3 GENERALIZED-BANDWIDTH and GENERALIZED-LOAD-BALANCING
I think it is better to specify a format for the GENERALIZED-BANDWIDTH and GENERALIZED-LOAD-BALANCING objects that allows a single instance of the object to specify both forwards and reverse bandwidth.  By having two objects you complicate matters because you then need to specify (and write extra code for!) all the consistency rules between the objects (e.g. you don't say what happens if the max-LSPs field differs between the forwards and reverse direction GEN-LB object).  This in turn will make implementation more fiddly and potentially less interoperable.  How about including the reverse-direction TSPEC in the same object as the forwards-direction TSPEC if the R bit is set?
[[Margaria.C]] Its a good point, I will consider it.

You state that multiple objects with the same TSPEC type are dealt with by ignoring all but the first.  Why do you allow multiple objects with a different TSPEC type?
[[Margaria.C]] To be permissive, this is done in other protocols
 And what is the PCE to so with a request containing different types of TSPEC?  I think that all TSPECs need to have the same type.
[[Margaria.C]] This is to address draft-ietf-pce-inter-layer-ext, I do not think we should disallow requesting an Ethernet LSP using a SDH or OTN layer (and specifying if we do prefer ODU 0 or ODUFLex)

to this:

"A PCE supporting those

[[Margaria.C]] OK

to

[[Margaria.C]] OK
[[Margaria.C]] OK

Section 2.5

[[Margaria.C]] OK
Section 2.6 XRO
Better to just define the X bit than refer to RFC 5521.  The definition is simple enough.
[[Margaria.C]] I would do both.
You say the C-Type is "copied from the label object" - what label object?  Isn't this just a number which identifies the type of the labels?
[[Margaria.C]] Yes, I will correct.
Does the label field specify a single label or an array of labels?  (Suppose single label but it is not quite clear.)
[[Margaria.C]] A single label, for multiple label this should be repeated

Section 2.7 PROTECTION-ATTRIBUTE TLV
I am not sure that re-using the format from RFC 4872/4873 is the right way to go.  It leaves us with a format containing many elements that are superfluous (or at least, not obviously applicable) to path computation.  It would help if you could add some text explaining why each field is applicable to path computation.
[[Margaria.C]] --> keeping the same format is done for simplicity of the definition, and this object is used as policy input.
For example, on the PROTECTION-ATTRIBUTE TLV flags:

·         S bit: since the PCE server does not assign resources, it seems that this bit will not be used in PCEP, correct?

·         N bit: I think this is irrelevant to PCEP.

·         O bit: ditto.

·         I bit: ditto.

·         R bit: ditto.

[[Margaria.C]] So it woud be better to state "contains the value of the PROTECTION object defined by RFC4872" and its used for policy input.

Where you say "The other attributes are only meaningful for a stateful PCE", please could you say why a stateful PCE might make use of them, or point me at a draft where this is discussed?
Some semantic are covered in draft-tanaka-pce-stateful-pce-mbb-01 ,  draft-crabbe-pce-stateful-pce-protection-00 and they also were present in draft-ietf-pce-stateful-pce .

---

From: Jonathan Hardwick <[email-masked]>
Date: Tue, 30 Jul 2013 09:08:46 +0000

Cyril and I had an offline conversation about these comments.  This email is to document the discussion for the benefit of the mailing list.  See [JEH-MC] comments below.

We have one question for the WG, as follows.  If anyone has an opinion on this, please could you provide it to the mailing list?

---
[JEH-MC] Jon believes that this draft should relax the restriction of RFC 5440 that the BANDWIDTH object is mandatory, in the case where a GENERALIZED-BANDWIDTH is supplied instead.  This would mean changing existing procedures, the initial mechanism was not to change RFC5440 object presence rule.  Cyril is fine with the proposal from Jonathan, but we would like to get WG and implementers feedback.
---

Regards
Jon & Cyril

From: Margaria, Cyril (Coriant - DE/Munich) [mailto:[email-masked]]
Sent: 25 July 2013 16:42
To: Jonathan Hardwick; [email-masked]
Cc: [email-masked]
Subject: RE: Comments on draft-ietf-pce-gmpls-pcep-extensions-08

Hi Jonathan,

Mit freundlichen Grüßen / Best Regards
Cyril Margaria
From: Jonathan Hardwick [mailto:[email-masked]]
Sent: Tuesday, July 23, 2013 4:22 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Comments on draft-ietf-pce-gmpls-pcep-extensions-08

Hello

Best regards
Jon

Section 2 RBNF

[JEH-MC] Jon believes that this draft should relax the restriction of RFC 5440 that the BANDWIDTH object is mandatory, in the case where a GENERALIZED-BANDWIDTH is supplied instead.  This would mean changing existing procedures, the initial mechanism was not to change RFC5440 object presence rule.  Cyril is fine with the proposal from Jonathan, but we would like to get WG and implementers feedback.

Section 2.1 RP object

[[Margaria.C]] OK

[JEH-MC] We agreed that it would make the PCC's life easier if it could tell just by looking at the RG flag in the response whether the PCE understands and uses the RG flag.  This suggests that RG=0 sent by the PCE should not convey any information about granularity, meaning that the PCC has to check the ERO's granularity by hand.  If the PCE supplies a non-zero RG flag then the semantic is that the returned ERO's granularity is "at least" the granularity conveyed by the RG (so that if any part of the ERO is at node granularity then "RG=node granularity" is used).

  Along the same lines:

"The PCE MAY return

"The PCE MAY return

[[Margaria.C]] OK

[JEH-MC] This is with Cyril to think about.  He will provide an explanation back to the list if he decides not to do this.

[JEH-MC] A paragraph will be added on the usage of multiple TSPEC types in the Inter-layer scenario.  This will be done in consultation with the inter-layer draft authors.

to this:

"A PCE supporting those

[[Margaria.C]] OK

to

Section 2.5

[[Margaria.C]] OK
Section 2.6 XRO

·         O bit: ditto.

·         I bit: ditto.

·         R bit: ditto.

[JEH-MC] Since the intent of providing this attribute is largely to allow for policy on the stateful PCE, we agreed that it is best to keep the existing format.

[[Margaria.C]] In fact this can be both. The link flags can be used as-is, the LSP flags (LSP (protection) flags, from RFC4872) will indicate the TE-LSP protection type, this protection type is a good example of routing policy input. I can modify the text as follows :
"For example LSP (protection) Flags or Link flags fields can be used by implementation for routing policy input."
A more concrete example could be added "A PCE could prefer specific link for a given protection type, for instance path with short delays for 1+1 protected path if they correspond to a different SLA class". But this may be too much.

---

From: Ramon Casellas <[email-masked]>
Date: Tue, 30 Jul 2013 11:32:20 +0200

On 07/30/2013 11:08 AM, Jonathan Hardwick wrote:
>
> Cyril and I had an offline conversation about these comments.  This 
> email is to document the discussion for the benefit of the mailing 
> list.  See *[JEH-MC]* comments below.
>
> We have one question for the WG, as follows.  If anyone has an opinion 
> on this, please could you provide it to the mailing list?
>
> ---
>
> *[JEH-MC]*Jon believes that this draft should relax the restriction of 
> RFC 5440 that the BANDWIDTH object is mandatory, in the case where a 
> GENERALIZED-BANDWIDTH is supplied instead.  This would mean changing 
> existing procedures, the initial mechanism was not to change RFC5440 
> object presence rule.  Cyril is fine with the proposal from Jonathan, 
> but we would like to get WG and implementers feedback.
>
>

Jon, Cyril, all

In this case, I would go back to one of my initial suggestions: do not 
add GENERALIZED_BANDWIDTH and add a TLV to the BW objects, which can be 
ignored.

In other words, the creation of GEN_BW was justified due to:  a) do not 
touch rfc5440 b) if RFC5440 does not state that BW object can have TLVs, 
then they can't and it is fixed length.

My personal preference always was to add a TLV or a new object type for 
BW.  If we allow ourselves a liberal interpretation of rfc5440 then 
let's assume we can add a tlv...

Just my opinion, of course, and not a particularly strong one

Ramon

-- 
Ramon Casellas, Ph.D. -- Senior Research Associate -- Networks Division
Optical Networks and Systems Department -- http://wikiona.cttc.es
CTTC - Centre Tecnològic de Telecomunicacions de Catalunya
Parc Mediterrani de la Tecnologia (PMT) - Edifici B4
Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain
Tel.: +34 93 645 29 00 ext 2168-- Fax. +34 93 645 29 01

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 30 Jul 2013 12:41:28 +0000

Hi all,

I think a new object type could be better and simple.

Thanks

Fatai

发件人: [email-masked] [mailto:[email-masked]] 代表 Ramon Casellas
发送时间: 2013年7月30日 17:32
收件人: Jonathan Hardwick; [email-masked]
主题: Re: [Pce] Comments on draft-ietf-pce-gmpls-pcep-extensions-08

---

Jon, Cyril, all

In this case, I would go back to one of my initial suggestions: do not add GENERALIZED_BANDWIDTH and add a TLV to the BW objects, which can be ignored.

In other words, the creation of GEN_BW was justified due to:  a) do not touch rfc5440 b) if RFC5440 does not state that BW object can have TLVs, then they can't and it is fixed length.

My personal preference always was to add a TLV or a new object type for BW.  If we allow ourselves a liberal interpretation of rfc5440 then let's assume we can add a tlv...

Ramon

--

---

From: "Margaria, Cyril (Coriant - DE/Munich)" <[email-masked]>
Date: Tue, 30 Jul 2013 16:33:08 +0000

Hi PCE WG,

The Problem we had with the BANDWIDTH (and LOAD-BALANCING BTW) object is that RFC5440 section 7.7 defines
“The BANDWIDTH object body has a fixed length of 4 bytes.”

RFC5440 defines two OT : 1 and 2. The text can be interpreted as all OT (current and future) should have length = 4, this is not future friendly.

Now several options can be considered :

1)      GMPLS-pcep extensions : new object, keep existing implementation untouched, at the expense of the gmpls ones (more complex rules)

2)      Allow TLV in the BANDWIDTH

3)      Treat this as an errata to RFC5440 ““The BANDWIDTH of OT 1 and OT 2  object body have a fixed length of 4 bytes.”, and define new OT for GMPLS

The Cons of 1 is discussed below.
The cons of the TLV would be to change existing object definition and make the protocol definition rather awkward : different Object format depending on OPEN (for example) negotiation and would not help for new CTypes

With 3) the existing implementation for existing CType will see no change, it may be a problem for new CTypes (anyhow not supported), but an implementation may return an Unknow object, unknown object type OR treated as invalid object. This can be solved by negotiating the use of OT>2 for BANDWIDTH (and LOAD-BALANCING)

For the sake of discussion I attach a slideset if by any chance there is some time left during the session,

Mit freundlichen Grüßen / Best Regards
Cyril Margaria
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fatai Zhang
Sent: Tuesday, July 30, 2013 2:41 PM
To: Ramon Casellas; Jonathan Hardwick; [email-masked]
Subject: [Pce] 答复: Comments on draft-ietf-pce-gmpls-pcep-extensions-08

Hi all,

Thanks

Fatai

发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] 代表 Ramon Casellas
发送时间: 2013年7月30日 17:32
收件人: Jonathan Hardwick; [email-masked]<mailto:[email-masked]>
主题: Re: [Pce] Comments on draft-ietf-pce-gmpls-pcep-extensions-08

---

Jon, Cyril, all

Ramon

--

---

From: Ramon Casellas <[email-masked]>
Date: Tue, 30 Jul 2013 21:37:56 +0200

El 30/07/2013 18:33, Margaria, Cyril (Coriant - DE/Munich) escribió:
>
> Hi PCE WG,
>
> 3)Treat this as an errata to RFC5440 ““The BANDWIDTH *of OT 1 and OT 
> 2*  object body have a fixed length of 4 bytes.”, and define new OT 
> for GMPLS
>
PCErs, all

Rather than "Errata" :) consider it a liberal interpretation, but I 
guess this approach is a nice trade-off.
Maybe a solution could be to define Ctypes 3 and 4 which are like 1 and 
2 but allowing TLVs (generically), then define a TLV to encode GMPLS 
traffic parameters. The BW objects can have a 32 bit IEEE floating point 
encoding of the nominal rate. Current implementations support 1 and 2 
with fixed size. New Ctypes can be addressed with "unknown object 
ctype", hopefully without strictly checking the object length.

Just my view, of course
R.

---

From: [email-masked]
Date: Wed, 31 Jul 2013 10:56:05 +0800

Hi, Ramon, Cyril & all,

I second this solution.

Defining new C-type can also keep the current protocol and implementation 
untouched. But we need to loose the restriction of bandwidth object in 
RFC5440 first.

Besides, IMHO, the solution allowing TLVs can better help the path 
computation process. There is no need to retrieve homogenous parameters 
from two different objects for PCE when computing the path.

Just my view too.

Thanks
Qilei Wang

Ramon Casellas <[email-masked]> 
发件人:  [email-masked]
2013-07-31 03:37

收件人
"Margaria, Cyril (Coriant - DE/Munich)" <[email-masked]>, 
抄送
"[email-masked]" <[email-masked]>
主题
Re: [Pce] 答复:  Comments on draft-ietf-pce-gmpls-pcep-extensions-08

3)      Treat this as an errata to RFC5440 ““The BANDWIDTH of OT 1 and 
OT 2  object body have a fixed length of 4 bytes.”, and define new OT for 
GMPLS
 
PCErs, all

Rather than "Errata" :) consider it a liberal interpretation, but I guess 
this approach is a nice trade-off. 
Maybe a solution could be to define Ctypes 3 and 4 which are like 1 and 2 
but allowing TLVs (generically), then define a TLV to encode GMPLS traffic 
parameters. The BW objects can have a 32 bit IEEE floating point encoding 
of the nominal rate. Current implementations support 1 and 2 with fixed 
size. New Ctypes can be addressed with "unknown object ctype", hopefully 
without strictly checking the object length. 

Just my view, of course
R.
_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce