RE: Example of LOM usage
"Francois Le Faucheur (flefauch)" <[email protected]>
| Newsgroups | gmane.ietf.tewg |
|---|---|
| Message-ID | <[email protected]> |
Dimitry, >> I understand that a provider may want different per CT >> overbooking ratios on >> different links. However I still fail to understand why LOM would be >> required to provide a good service in such a configuration. >> Can you clarify? >> I believe we have already discuss when LOM is required or not and concluded on that. Quoting from your message: >> Francois, >> >> Thanks for your clear explanation. What has escaped me >> before is that LOM is >> useful only for those cases where both of the following must be true: >> >> 1) CTs of the same link have different overbooking ratios. >> 2) The amount of reservations in one CT must precisely >> effect reservable >> bandwidths in other CTs of the same link. >> >> If I am correct, then it is quite possible to support >> different overbooking >> ratios per CT per link without LOM, provided that 2) is not >> required (or at >> least not with the same level of precision that LOM can provide). >> >> Thanks, >> Dimitry To put the same thing in a different way: - if you don't need per-CT-per-link ratios, you do NOT need LOM - if you need per-CT-per-Link ratios and can tolerate some inaccuracy in how a CT affects the global constraints (which I think you also refer to as allowing some degradation on some CTs in your discussion with Sanjaya), then you do NOT need LOM. - if you need per-CT-per-Link ratios and want accuracy in how a CT affects the global constraints, then you do need LOM. So the points I think you're getting at are that: 1) needing per-CT-per-Link ratios does not always mean you need LOM 2) from your experience: - most SPs won't need per-CT-per-link ratios - the few SPs who may need per-CT-per-link ratios are likely to tolerate some inaccuracy in bookeeping over the aggregate constraint, Therefore the case for LOM is very slim. Right? Cheers Francois