comments on draft-ietf-ccamp-ospf-gmpls-extensions-09.txt

["Jorge Pinto" <Jorge.Pinto@siemens.com>]

Hello OSPF for GMPLS fans,

I have some comments regarding Bandwidth advertisments as intended on draft-ietf-ccamp-ospf-gmpls-extensions-09.txt.

Although there are many different issues that i would like to comment on this document, i will refrain myself to a discussion only on the "unreserved LSP bandwidth" advertisment... (yes, i'm testing the open-mindness of this list).

In technologies that do not allow over-booking (SDH/SONET is my prime concern), the Max LSP bandwidth, the reserved LSP bandwidth at each priority 'p' and the external (i'll explain what "external" means... later on) bandwidth are the true descriptors of allocated Bandwidth resources for a link.
The unreserved LSP bandwidth at priority 'p' is a definition dependent on the pre-emption of lower-priority LSPs, and does not account for "external" (not exactly legacy) resource usage. If you take the following example you'll see what i'm getting at (i'm sorry if your mailer is not using a constant-width font):
Max LSP BW=100 (as in "GMPLS manages it all")

LSP Prio|LSP Res BW|LSP UnRes BW
  0     |     0    |    100 (it can pre-empt all of the other lower prios!)         
  1     |     2    |    98
  2     |     0    |    98  (it takes into account only 'p' priorities < 2)
  3     |    10    |    88
  4     |     0    |    88
  5     |     0    |    88
  6     |     0    |    88
  7     |    10    |    78  (which is the "no-preemption" available BW)

Now, consider that it would be VERY nice to have GMPLS as an add-on to many already depployed Network Managment Systems, and even if GMPLS is used in a large extent, there will be a considerenly large number of resources that GMPLS will NOT manage (but will have to account for, for inter-operability with non-GMPLS managment). This is what i'm considering the external BW allocated (note that the numeric values may not even match at both ends of a link).
Evindentely, by cross-matching of Network-Element and GMPLS MIBs one can compute the external bandwidth allocated per interface and the LSP BWs... i'm still waiting for this "external BW" metric to be included on the TE LSAs (since it may reduce the Available GMPLS BW, regardless of how large the Max LSP BW is set to).

However, i agree that the LSP unreserved BW is an easy method to account for GMPLS resource usage... but it is incomplete.
IMHO, it should be evident that there will always be the requirement of some operators to have "sacro-saint" paths that GMPLS respects and cannot manage, and the Max LSP bandwidth allowed is basically a initial configuration value (not a rule).
The other reason why the Unreserved BW is not sufficient is that it works under the priciple of pre-emption (as demonstrated on the example). However, we should accomodate the possibility (tested by us) of alternative routing strategies that only resort to pre-emption of lower priorities resources, iff "everything else fails". I should also say that this strategy is already demonstrated and proofed, and it could well fall on the definition of a "proprietary CSPF-TE", something that ccamp actually advises.
On the conceptual point of view, i think it is best to advertise what BW the Interface actually has allocated (LSP reserved BW at each prio, Max LSP Bw and externally allocated BW) than the estimate of how much BW could an LSP at priority 'p' WOULD be able to reserve, on the absense of non-GMPLS management entities.

To keep the mail short, but still open to a broader discussion,

Best regards,

Jorge Pinto
Siemens IC R&D ON
mail: jorge.pinto@siemens.com
phone: (+351) 21 417 8147
I-want-you-to-think-I'm-very-smart-quote "If NT is the answer, you did not understand the question..."