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

["Margaria, Cyril (Coriant - DE/Munich)" <[e-mail]>]

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]
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]