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 protected]; 'Ramon Casellas'; 'Jonathan Hardwick';
[email protected]
*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.
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
