RE: Reflecting new-MAM/SAM definition in diff-te drafts [[email protected] in Pass-Through List] ['from' in Pass-Through List] [[email protected] in Pass-Through List] ['from' in Pass-Through List]
"Francois Le Faucheur (flefauch)" <[email protected]>
| Newsgroups | gmane.ietf.tewg |
|---|---|
| Message-ID | <[email protected]> |
Hello Sanjaya, >> -----Original Message----- >> From: Choudhury, Sanjaya [mailto:[email protected]] >> Sent: 22 May 2003 15:30 >> To: [email protected] >> Subject: RE: Reflecting new-MAM/SAM definition in diff-te >> drafts [[email protected] in Pass-Through List] >> ['from' in Pass-Through List] [[email protected] in >> Pass-Through List] ['from' in Pass-Through List] >> >> >> > >> > Again, assuming we define LSOM as the "Link Size Overbooking >> > Multiplier" >> > (as opposed to the "LSP/Link Size Overbooking Multiplier"), >> > then I agree >> > with your relationship. >> > >> > Thanks for helping get all this clarified. >> > >> > Francois >> >> Hi! I am not sure it is necessary to introduce the concept >> of a new multiplier ("LSOM") in DSTE-PROTO. >> Oh. I couldn't agree more. This is what I tried to indicate also in my earlier message: [FLF] For DS-TE, like for TE, I think we don't need to explicitely [FLF] define in [FLF] the drafts the concepts of LSP/Link Size overbooking [FLF] Multipliers (LSOMs) [FLF] nor formulas using them because we operate directly/exclusively on [FLF] "normalised" values. We only defined LSOM fo the purpose of the email discussion to facilitate the discussions and confirmed we were all in synch in terms of overbooking model. But I don't propose to add the LSOM concept/formulas into the drafts. >> Only change that should probably goto the draft is to replace >> "Max Link Bw" in formulas by "Max reservable Bw", when user >> overrides the maxLinkBw (with a max reservable bw). >> Right. "Max Reservable Bw" will be the value used as the aggregate constraint on all CTs. >> Here is how I understand the types of overbookings:- >> 1. Link size overbooking >> -user overrides the 'max link bw' (dictated by >> the hardware), with a larger/smaller bandwidth >> reservable on the link, be by configuring a >> 'max reservable bw'. Yes. Minor detail. I am not sure what you meant exactly by "override". The way I would put it is that we always use the Max Reservable bw (which may be set by default to the actual Link Bandwidth or may be configured by operator to some larger/smaller value). I think we agree. >> -no additional multipliers are needed Yep. >> 2. LSP size overbooking >> -user reserves more/less amount of BW for the LSP >> compared to the actual amount of traffic the LSP >> is expected to carry. >> -No additional 'multipliers' are needed. The LSP >> BW follows the normal BCs based on the CTs Yep. >> 3. per CT overbooking >> -user specifies the LOM on a per CT per interface >> basis. LSP BW adheres to BCs dictated by the CT it >> is associated with Yes. Factoring in the LOM, of course. Good summary of overbooking methods. Thanks. >> -when user has overridden the 'max link bw' by >> configuring a explicit 'max reservable bw', the >> user specified value should be used as the upper >> limit for the link. >> >> Reserved(CTx) vs Normalized(CTx): >> If no LOM is being used, we can assume the LOM to be >> 1 (100% no over/underbooking). This will allows us >> to use Normalized(CTx) in all the formulas (instead >> of two sets -one with Reserved and the other with >> Normalized). >> The drafts already state that when LOM are not used it means they are set to 1. I had put the two sets of formulas with/without LOM because LOM is purely an optional mechanism [ and frankly I don't expect it to be used that often considering how much you can achieve with Link overbooking and LSP overbooking] so I thought it would be useful to state the formulas without LOM . Note that while the CAC formulas are pretty much the same with/without LOM (with simple substitution of "reserved" by "normalised") the formulas for computing Unreserved BW do get less intuitive with LOM than without. Thanks for your comments and analysis. Francois >> Thanks, >> sanjay >> >> >> >> >>