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

From: "Margaria, Cyril (Coriant - DE/Munich)" <[email-masked]>
Date: Mon, 14 Oct 2013 10:39:01 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Margaria, Cyril (Coriant - DE/Munich)
Sent: Thursday, August 01, 2013 9:24 AM
To: [email-masked]; 'Fatai Zhang'; 'Ramon Casellas'; 'Jonathan Hardwick'; [email-masked]
Subject: Re: [Pce] Bandwidth: Comments on draft-ietf-pce-gmpls-pcep-extensions-08

Adrian, all
Please see inline
From: Adrian Farrel [mailto:[email-masked]]
Sent: Wednesday, July 31, 2013 3:46 PM
To: Margaria, Cyril (Coriant - DE/Munich); 'Fatai Zhang'; 'Ramon Casellas'; 'Jonathan Hardwick'; [email-masked]<mailto:[email-masked]>
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: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Margaria, Cyril (Coriant - DE/Munich)
Sent: 30 July 2013 17:33
To: Fatai Zhang; Ramon Casellas; Jonathan Hardwick; [email-masked]<mailto:[email-masked]>
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: [email-masked]<mailto:[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]<mailto:[email-masked]>
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

发件人: [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

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: Qin Wu <[email-masked]>
Date: Tue, 15 Oct 2013 02:26:24 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Margaria, Cyril (Coriant - DE/Munich)
Sent: Monday, October 14, 2013 6:39 PM
To: Margaria, Cyril (Coriant - DE/Munich); [email-masked]; Fatai Zhang; 'Ramon Casellas'; 'Jonathan Hardwick'; [email-masked]
Subject: Re: [Pce] Bandwidth: Comments on draft-ietf-pce-gmpls-pcep-extensions-08

Hi,

Adrian, all
Please see inline

Hi Cyril,

Just my €0.02
Adrian

Hi PCE WG,

Hi all,

Thanks

Fatai

---

Jon, Cyril, all

Ramon

--

---

From: "He, Peng" <[email-masked]>
Date: Mon, 14 Oct 2013 22:41:54 -0400

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

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

Hi,

To: [email-masked]<mailto:[email-masked]>; 'Fatai Zhang'; 'Ramon Casellas'; 'Jonathan Hardwick'; [email-masked]<mailto:[email-masked]>

Adrian, all
Please see inline

Hi Cyril,

Just my €0.02
Adrian

Hi PCE WG,

Hi all,

Thanks

Fatai

---

Jon, Cyril, all

Ramon

--

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 15 Oct 2013 02:53:20 +0000

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:[email-masked]]
Sent: Tuesday, October 15, 2013 10:42 AM
To: Qin Wu; Margaria, Cyril (Coriant - DE/Munich); [email-masked]; Fatai Zhang; 'Ramon Casellas'; 'Jonathan Hardwick'; [email-masked]
Subject: RE: [Pce] Bandwidth: Comments on draft-ietf-pce-gmpls-pcep-extensions-08

Regards,
Peng

Regards!
-Qin

Hi,

Adrian, all
Please see inline

Hi Cyril,

Just my €0.02
Adrian

Hi PCE WG,

Hi all,

Thanks

Fatai

---

Jon, Cyril, all

Ramon

--

---

From: Qin Wu <[email-masked]>
Date: Tue, 15 Oct 2013 03:07:25 +0000

I am thinking is this related to lifetime of LSP?

Regards!
-Qin

Regards,
Peng

Regards!
-Qin

Hi,

Adrian, all
Please see inline

Hi Cyril,

Just my €0.02
Adrian

Hi PCE WG,

Hi all,

Thanks

Fatai

---

Jon, Cyril, all

Ramon

--

---

From: "He, Peng" <[email-masked]>
Date: Mon, 14 Oct 2013 23:12:25 -0400

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:[email-masked]]
Sent: Monday, October 14, 2013 10:53 PM
To: He, Peng; Qin Wu; Margaria, Cyril (Coriant - DE/Munich); [email-masked]; 'Ramon Casellas'; 'Jonathan Hardwick'; [email-masked]
Subject: RE: [Pce] Bandwidth: Comments on draft-ietf-pce-gmpls-pcep-extensions-08

Peng,

Best Regards

Fatai

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

Regards,
Peng

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

Regards!
-Qin

Hi,

Adrian, all
Please see inline

Hi Cyril,

Just my €0.02
Adrian

Hi PCE WG,

Hi all,

Thanks

Fatai

---

Jon, Cyril, all

Ramon

--

---

From: "Margaria, Cyril (Coriant - DE/Munich)" <[email-masked]>
Date: Tue, 15 Oct 2013 06:57:00 +0000

Hi,

I think the hold-off time could impact the path computation, I think this as valid policy, also for stateless PCE. From this Bandwidth Scheduling extension
Should consider also the stateless PCE case, in which case the values apply for policy only.

So it seems you say that we should have a point c) regarding the lifetime of the pipe, and it should be in another object, correct?
This is aligned with our proposal.

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

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.

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

Regards,
Peng

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

Peng,

Best Regards

Fatai

Regards,
Peng

Regards!
-Qin

Hi,

Adrian, all
Please see inline

Hi Cyril,

Just my €0.02
Adrian

Hi PCE WG,

Hi all,

Thanks

Fatai

---

Jon, Cyril, all

Ramon

--

---

From: Qin Wu <[email-masked]>
Date: Tue, 15 Oct 2013 07:41:45 +0000

From: Margaria, Cyril (Coriant - DE/Munich) [mailto:[email-masked]]
Sent: Tuesday, October 15, 2013 2:57 PM
To: He, Peng; Fatai Zhang; Qin Wu; [email-masked]; 'Ramon Casellas'; 'Jonathan Hardwick'; [email-masked]
Subject: RE: [Pce] Bandwidth: Comments on draft-ietf-pce-gmpls-pcep-extensions-08

Hi,

[Qin]:This seems my interpretation to what Peng suggested.

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

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

Regards,
Peng

Peng,

Best Regards

Fatai

Regards,
Peng

Regards!
-Qin

Hi,

Adrian, all
Please see inline

Hi Cyril,

Just my €0.02
Adrian

Hi PCE WG,

Hi all,

Thanks

Fatai

---

Jon, Cyril, all

Ramon

--

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 15 Oct 2013 07:58:52 +0000

Hi All,

(snip)

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

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

To: Fatai Zhang; Qin Wu; Margaria, Cyril (Coriant - DE/Munich); [email-masked]<mailto:[email-masked]>; 'Ramon Casellas'; 'Jonathan Hardwick'; [email-masked]<mailto:[email-masked]>

Regards,
Peng

Peng,

Best Regards

Fatai

Regards,
Peng

Regards!
-Qin

Hi,

Adrian, all
Please see inline

Hi Cyril,

Just my €0.02
Adrian

Hi PCE WG,

Hi all,

Thanks

Fatai

---

Jon, Cyril, all

Ramon

--

---

From: Qin Wu <[email-masked]>
Date: Tue, 15 Oct 2013 08:06:18 +0000

From: Dhruv Dhody
Sent: Tuesday, October 15, 2013 3:59 PM
To: Qin Wu; Margaria, Cyril (Coriant - DE/Munich); He, Peng; Fatai Zhang; [email-masked]; 'Ramon Casellas'; 'Jonathan Hardwick'; [email-masked]
Subject: Bandwidth Utilization Encoding in PCEP (was RE: [Pce] Bandwidth: Comments on draft-ietf-pce-gmpls-pcep-extensions-08)

Hi All,

(snip)

[Qin]: Exactly. Also thanks for answering the 1st point described above. I fully agree.

---

From: Ramon Casellas <[email-masked]>
Date: Tue, 15 Oct 2013 10:35:26 +0200

El 15/10/2013 10:06, Qin Wu escribió:
>
> *From:*Dhruv Dhody
> *Sent:* Tuesday, October 15, 2013 3:59 PM
> *To:* Qin Wu; Margaria, Cyril (Coriant - DE/Munich); He, Peng; Fatai 
> Zhang; [email-masked]; 'Ramon Casellas'; 'Jonathan Hardwick'; 
> [email-masked]
> *Subject:* Bandwidth Utilization Encoding in PCEP (was RE: [Pce] 
> Bandwidth: Comments on draft-ietf-pce-gmpls-pcep-extensions-08)
>
> 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. /*
>
> [Qin]: Exactly. Also thanks for answering the 1^st point described 
> above. I fully agree.
>

Dear all,

I would guess that to some extent, we are mixing things:

a) How to address the fact that RFC5440 BANDWIDTH object does not seem 
to be enough to cover GMPLS extensions. This is IMHO, the priority, 
given the state of draft-ietf-pce-gmpls-pcep extensions, along with 
relationship with / the need for GENERALIZED_BANDWIDTH and related 
objects (load sharing) and whether we can work around the strict 
limitation of 4 bytes as per RFC5440

b) Whether we need to convey, in a request, the characterization of the 
channel that we are requesting computation for (the "pipe") as well as 
the client signal to be transported over that channel.

c) The addition of other bandwidth-related constraints and path 
attributes to PCEP, and how to deal with Additive / Convex path metrics. 
Like in unreserved or residual bandwidth or OSNR, it is possible to 
deduce path metrics that are not the "sum" of link metrics.

d) The subsequent discussions about bandwidth scheduling, statefulness, 
etc.. (right now, just for the purposes of path computation, a stateless 
PCE needs not to be aware of the concept of "holding time". imho)

I would like to move forward a) taking into account that for e.g., WSON 
and SSON the "pipe" cannot even be expressed in bytes/second. My basic 
question would be: does the WG consider the addition of object types 
e.g. 3 and 4 that are not restricted by IEEE floating point format a 
reasonable choice?.

In particular, Adrian's mail 
http://www.ietf.org/mail-archive/web/pce/current/msg03297.html is what 
needs to be addressed to move this draft to LC, specially points 1, 2 
and 3. (also quoting "My view is that the bandwidth object describes the 
bandwidth that has been requested" makes me think what "request 
bandwidth" means in optical networks. We discussed off line in Berlin 
about the TSPEC, the reasons behind the current choice, etc. and I don't 
think that Intserv is the reason behind changing the BANDWIDTH object, 
but what Adrian mentions in his 2), which renders this more complex 
given the direct link between gmpls and inter-layer extensions.

Personally, I would like to nail down this before moving to other, more 
advanced, issues.

thanks
R.