[Pce] Bandwidth Utilization Encoding in PCEP (was RE: Bandwidth: Comments on draft-ietf-pce-gmpls-pcep-extensions-08)

[Dhruv Dhody <[e-mail]>]

Hi All,

(snip)

Now considering draft-wu-pce-pcep-link-bw-utilization-00, I did not check the related IGP draft, but my understanding is that the BU object constrain the PCE to leave a given percentage free on each link. The first point I see is that the BANDWIDTH /size of the pipe is not related to this information, correct?.

[Qin]: closely. My understanding it is more related to how much bandwidth is utilized on each link rather than how much bandwidth  is reserved per link.
[DD] The BU object constrain the PCE to ’not select a link in the path’ if the current utilization of the link is above a certain X%. So yes in a way it lets PCE leave  at least a given percentage free on each link in the path.
And yes this information is not related to BANDWIDTH /size.

The second point is : can this be solved by a new metric? The BU LRBU would be metric bound path computation, this would align well with the OF you propose.

[Qin]: Good question. Dhruv and I discussed PCEP encoding for BU before. It seems BU object is only applied to per link rather than all path, if we define it as a new Metric object,
We need some kind of disclaimer to say that BU is applied to per-link.
Then we think about another way, i.e., define it as a new Object rather than a Metric, in this case, we don’t need such disclaimer.
To be honest, which way is better?
[DD] So far all METRIC types in PCEP are applied to the  end to end path and not per link basis.
IMHO the handling of BU object is similar to BANDWIDTH object which is a constraint applied on each link of the path.
And for optimization criteria OF codes are described to select the most underutilized links.

We would welcome WG feedback on the preferred encoding option.

Mit freundlichen Grüßen / Best Regards
Cyril Margaria
From: He, Peng [mailto:[e-mail]]
Sent: Tuesday, October 15, 2013 5:12 AM
To: Fatai Zhang; Qin Wu; Margaria, Cyril (Coriant - DE/Munich); [e-mail]<mailto:[e-mail]>; 'Ramon Casellas'; 'Jonathan Hardwick'; [e-mail]<mailto:[e-mail]>
Subject: RE: [Pce] Bandwidth: Comments on draft-ietf-pce-gmpls-pcep-extensions-08

Thanks Fatai .. I was originally thinking the various holding-time of flows could impact the path computation result to each individual flow (e.g., partially similar to long-lived elephant flow vs. short-lived mice flow, there were some research work there a while ago). Bandwidth scheduling actually covers it, say you can schedule a bandwidth/pipe either for later on usage, or now ☺


Regards,
Peng


From: Fatai Zhang [mailto:[e-mail]]
Sent: Monday, October 14, 2013 10:53 PM
To: He, Peng; Qin Wu; Margaria, Cyril (Coriant - DE/Munich); [e-mail]<mailto:[e-mail]>; 'Ramon Casellas'; 'Jonathan Hardwick'; [e-mail]<mailto:[e-mail]>
Subject: RE: [Pce] Bandwidth: Comments on draft-ietf-pce-gmpls-pcep-extensions-08

Peng,

A good question.  I think ‘Yes’ to your question and ‘not covered by the current PCEP protocol’.

What you said has been mentioned as "Bandwidth Scheduling" in [draft-ietf-pce-stateful-pce-app], which also includes starting-time besides holing-time.

PCEP extensions will come soon. Hope to get more thoughts from you on this point.



Best Regards

Fatai

From: He, Peng [mailto:[e-mail]]
Sent: Tuesday, October 15, 2013 10:42 AM
To: Qin Wu; Margaria, Cyril (Coriant - DE/Munich); [e-mail]<mailto:[e-mail]>; Fatai Zhang; 'Ramon Casellas'; 'Jonathan Hardwick'; [e-mail]<mailto:[e-mail]>
Subject: RE: [Pce] Bandwidth: Comments on draft-ietf-pce-gmpls-pcep-extensions-08

Just a side question, do we also need to consider how long this pipe will be used? i.e., the holding-time;  or it is already covered by other object?


Regards,
Peng


From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Qin Wu
Sent: Monday, October 14, 2013 10:26 PM
To: Margaria, Cyril (Coriant - DE/Munich); [e-mail]<mailto:[e-mail]>; Fatai Zhang; 'Ramon Casellas'; 'Jonathan Hardwick'; [e-mail]<mailto:[e-mail]>
Subject: Re: [Pce] Bandwidth: Comments on draft-ietf-pce-gmpls-pcep-extensions-08

What additional optional information could be in this pipe?
Could additional optional information be link bandwidth utilization information defined in draft-wu-pce-pcep-link-bw-utilization-00?

Is the pipe you are describing applied to all path or per link?

Regards!
-Qin
From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Margaria, Cyril (Coriant - DE/Munich)
Sent: Monday, October 14, 2013 6:39 PM
To: Margaria, Cyril (Coriant - DE/Munich); [e-mail]<mailto:[e-mail]>; Fatai Zhang; 'Ramon Casellas'; 'Jonathan Hardwick'; [e-mail]<mailto:[e-mail]>
Subject: Re: [Pce] Bandwidth: Comments on draft-ietf-pce-gmpls-pcep-extensions-08

Hi,

Before starting to update the document on that topic, I would be interested to hear your and the WG opinion on that topic,
Basically we are re-discussing what is the  BANDWIDTH object in PCEP, how GMPLS nodes can express its BW constraints.

We had a talk in Berlin and our conclusion is that :
 There is two thing that we can express:

a)      the size of the pipe you want in your network

b)      An additional optional information is what you put in this pipe

We think that a) is represented by the BANDWIDTH object and b) should be represented by something else.
Furthermore how to encode BANDWIDTH  depends on the switching technology, so we think that new object Type for BANDWIDTH can be made to include the generalized BW definition, as the size restriction can be interpreted of OT 1 and 2.

This would simplify the different documents and implementations.

Your feedback will be greatly appreciated.

Mit freundlichen Grüßen / Best Regards
Cyril Margaria
From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Margaria, Cyril (Coriant - DE/Munich)
Sent: Thursday, August 01, 2013 9:24 AM
To: [e-mail]<mailto:[e-mail]>; 'Fatai Zhang'; 'Ramon Casellas'; 'Jonathan Hardwick'; [e-mail]<mailto:[e-mail]>
Subject: Re: [Pce] Bandwidth: Comments on draft-ietf-pce-gmpls-pcep-extensions-08

Adrian, all
Please see inline
From: Adrian Farrel [mailto:[e-mail]]
Sent: Wednesday, July 31, 2013 3:46 PM
To: Margaria, Cyril (Coriant - DE/Munich); 'Fatai Zhang'; 'Ramon Casellas'; 'Jonathan Hardwick'; [e-mail]<mailto:[e-mail]>
Subject: Bandwidth: Comments on draft-ietf-pce-gmpls-pcep-extensions-08

Hi Cyril,

Thanks for raising the question.

Before getting on to discuss how to make the change, we need to dig more into "why to make the change".

I went straight to this draft trying to find the reasoning.
In 1.3 I found...
     [RFC5440] does not include the ability to
      convey a (Intserv) TSPEC object.
I probably made the mistake of stopping when I reached this text.
The text is completely true!
However, 5440 was wilful in its choice to not support Intserv on the understanding (which might not be true anymore, but probably is) that no-one uses Intserv TSpec in their MPLS-TE or GMPLS implementations.

*If* Intserv is the only reason for the discussion of changing the Bandwidth object, we should drop the discussion, IMHO.

I then went to draft-ietf-pce-gmpls-aps-req and searched for "bandwidth" and the only discussion I found was with respect to the asymmetrical requirements.


At the mic, Cyril and Fatai helped me to understand that the requirement is not specific to bandwidth, but is related to Traffic Parameters that will be signaled. This breaks the problem out into three different use cases:

1. The PCC wishes to request *bandwidth*. It does not mind it gets a fat pipe or VCAT, a lambda or OTN.
2. The PCC wants bandwidth, but *does* care about how this supplied in the network. This makes the request:
   i. layer-specific
   ii. sub-layer-specific
   iii. label-specific
3. The PCE wants to convey information to the PCC about what details it needs to place in signaling.

My view is that the Bandwidth object is not called the "Sender-TSpec object for use if the PCC just happens to be the ingress node of a GMPLS LSP" object! My view is that the bandwidth object describes the bandwidth that has been requested, and the bandwidth that the supplied path will actually be able to supply (may be >, =, or < requested b/w).

[[Margaria.C]] I have the same understanding on the semantic, but not on the encoding. For some PCC (corresponding to 2-i) having a floating point only will make him translate that in its layer bandwidth, which may be sometime the right translation.
I understand the current encoding as bandwidth for some packet-packet based technology, but it is not adequate for all technologies-

Thus, IMHO, if we want to constrain the request to return paths that use a limited set of the available network resources, we need to add this through other objects.

[[Margaria.C]] That would work, but I think that having a new CType to convey different encoding of the bandwidth would be better. This would allow to request to request a VC4 and get a pwe bandwidth (use case 1). The constraining to layers is addressed in the inter-layer draft.

And if we want to give information to the PCC that it can map to specific details in the signaling protocol, then we should provide that detail in objects specifically intended to carry that information.  This information is clearly related to bandwidth, but it is not the same as bandwidth
[[Margaria.C]] Its not specific to the signalling protocol per se (although we are using one protocol encoding), it is specific to the layer used, and this is addressed in CCAMP draft-zhang-ccamp-gmpls-h-lsp-mln (and is currently addressed in another way in the inter-layer for that matter).

Just my €0.02
Adrian

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Margaria, Cyril (Coriant - DE/Munich)
Sent: 30 July 2013 17:33
To: Fatai Zhang; Ramon Casellas; Jonathan Hardwick; [e-mail]<mailto:[e-mail]>
Subject: Re: [Pce] 答复: Comments on draft-ietf-pce-gmpls-pcep-extensions-08

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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Fatai Zhang
Sent: Tuesday, July 30, 2013 2:41 PM
To: Ramon Casellas; Jonathan Hardwick; [e-mail]<mailto:[e-mail]>
Subject: [Pce] 答复: Comments on draft-ietf-pce-gmpls-pcep-extensions-08

Hi all,

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

Thanks

Fatai


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

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.: [phone] ext 2168-- Fax. [phone]