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

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 31 Jul 2013 14:45:46 +0100

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).
 
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.
 
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.
 
Just my €0.02
 
Adrian
 
From: [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]
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]] 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,
 
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
 
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: Ramon Casellas <[email-masked]>
Date: Thu, 01 Aug 2013 04:51:15 +0200

Adrian, all

Please see inline.

> 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.
[Ramon] that is good to know, thanks; I have wondered about the 
rationale for that choice, which I humbly thought to be unfortunate; I 
would have guessed that algorithms  could use at least some token bucket 
or peak/mean rate parameters to compute paths in view of statistical 
multiplexing. Now, with contributions and standards work regarding 
metrics such as delay and packet loss rates imho it would make sense to 
characterize flows  / requests not only as a single floating point value 
/CBR.
However, also related to parts of your mail, the RFC5440 text in the 
bandwidth object description still puzzles me: "The notion of bandwidth 
is similar to the one used for RSVP signaling in [RFC2205], [RFC3209], 
and [RFC3473]" in which the term requested bandwidth is indeed used. I 
would think that the choice of bandwdith is clearly related to RSVP and 
"the sender-speec object for use if the PCC happens to be the ingress node"

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

[Ramon] Imho, 2 would be the use case I am most interested in, quite 
biased since most of the time in my scenarios pcc is part of an LSR (not 
necessarily ingress, but also in expansions). Much like I like that a 
PCC can pass the bits around regarding the ERO in a response, I would 
like to pass the tspec transparently, saying "expand the path I am 
establishing, this is the tspec I have in my sender descriptor". 
Otherwise, I am not sure what magic I have to implement to deduce a 
floating point bandwidth to convey in the object. Another use case (very 
particular to mu interests) is when I want to ask the PCE to perform 
routing and spectrum assignment. I want the PCE to compute a path of a 
given spectrum width, to pre-establish it. the width is given by the 
corresponding OTS / slot, and the actual client signal mapping is 
unknown, and will depend on the modulation format and FEC. I don't know 
what bandwdith I would convey in the message.
So in my case we are not always requesting bytes per second.

> 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.
>
[Ramon] In short, I would be ok if we agree that "this is not full 
related to bandwidth, leave the object as it is", but I would think that 
not being able to request/reply traffic parameters is a limitation of 
the PCEP extensions for GMPLS
>
> 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.
>
[Ramon] I think it should be possible

Thanks

Ramon