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"
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
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
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
