Subject: RE: Reflecting new-MAM/SAM definition in diff-te drafts

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 16 May 2003 15:26:11 +0100

Hello Dimitry,

>> -----Original Message-----
>> From: Dimitry Haskin [mailto:[email-masked]] 
>> Sent: 25 April 2003 22:28
>> To: 'Ash, Gerald R (Jerry), ALABS'; Francois Le Faucheur (flefauch)
>> Cc: [email-masked]
>> Subject: RE: Reflecting new-MAM/SAM definition in diff-te drafts
>> 
>> 
>> Gerald,
>> 
>> > 3. The 'maximum link bandwidth' parameter is a physical 
>> > constraint and serves to limit the assignable sum of link 
>> > bandwidth across class types.  In the recent discussion, this 
>> > constraint has sometimes been referred to as an 'implicit max 
>> > link BW constraint'.  However there is nothing 'implicit' 
>> > about this constraint/parameter, it is an existing link 
>> > parameter and a physical constraint on assignable link bandwidth.
>> > 4. Given comment #3, we don't need to use the 'max reservable 
>> > link bandwidth' parameter instead of the 'maximum link 
>> > bandwidth' parameter, as you have proposed.
>> 
>> The 'maximum link bandwidth' as defined is the actual link 
>> capacity and not
>> meant to be used as a reservation constraint. The 'max 
>> reservable link
>> bandwidth' was originally defined for this purpose. The 
>> amount of confusion
>> around these definitions puzzles me.
>>

After some investigation, here's my understanding:

1) At the time where "Max Link Bandwidth" was specified, (at least some
of) the folks involved were intending it as a constraint on the single
size of an LSP. Now, this didn't actually quite make it in the text of
the OSPF/ISIS specs, yet arguably the text doesn't either completely
exclude this interpretation. I suspect this may be (part of) the
explanation for the confusion around this. But that doesn't matter too
much...I guess.

2) Anyway, today, it seems that using "Max Link Bandwidth" to limit the
size of an individual LSP is not supported by all implementations, and
where supported, is not commonly used by SPs.
Based on this, I propose to follow Dimitry's suggestion and remove the
2nd check in the CAC formulas.
ie remove the following check:
"> >>        B <= Max Link Bandwidth "
(for memory, B is the size of the LSP being admitted)

Cheers

Francois

>> Dimitry
>> 
>> P.S. Excerpts from draft-katz-yeung-ospf-traffic-09.txt:
>> 
>> 
>>  2.5.6. Maximum Bandwidth
>> 
>>    The Maximum Bandwidth sub-TLV specifies the maximum bandwidth that
>>    can be used on this link in this direction (from the system
>>    originating the LSA to its neighbor), in IEEE floating 
>> point format.
>>    This is the true link capacity.  The units are bytes per second.
>> 
>>    The Maximum Bandwidth sub-TLV is TLV type 6, and is four octets in
>>    length.
>> 
>>  2.5.7. Maximum Reservable Bandwidth
>> 
>>    The Maximum Reservable Bandwidth sub-TLV specifies the maximum
>>    bandwidth that may be reserved on this link in this direction, in
>>    IEEE floating point format.  Note that this may be 
>> greater than the
>>    maximum bandwidth (in which case the link may be oversubscribed).
>>    This SHOULD be user-configurable; the default value should be the
>>    Maximum Bandwidth.  The units are bytes per second.
>> 
>>    The Maximum Reservable Bandwidth sub-TLV is TLV type 7, 
>> and is four
>>    octets in length.
>>

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 16 May 2003 15:40:31 +0100

Hello Jerry,

>> around these definitions puzzles me.

Do you agree with Dimitry's point that it is the "Max Reservable
Bandwidth" that should be used for constraining reservations (across
Class-Types) - not the "Max Link Bw"- ?  

If yes, would you agree that the following rules would apply for the
"new MAM" definition:
	o for each value of b in the range 0 <= b <= 7: 
		Reserved (CTb) <= BCb, 
	o SUM (Reserved (CTc)) <= Max Reservable Bandwidth, 
		for all "c" in the range 0 <= c <= (MaxCT-1)

Thanks

Francois

---

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Mon, 19 May 2003 16:27:08 -0500

Hi Francois,

Welcome back, I notice you've been off the list for a while.  

> Class-Types) - not the "Max Link Bw"- ?

No, I think more clarifications are needed, see below.
 
> 	o for each value of b in the range 0 <= b <= 7: 

This definition is OK, wherein the formula can be applied to either 'normalized' (by the overbooking factor) or 'unnormalized' bandwidth.

> 		for all "c" in the range 0 <= c <= (MaxCT-1)

I agree with Wai Sum that this formula is incorrect for DS-TE, since the above formula only reflects the Max Reservable Bandwidth for the entire link, and does not reflect the per-CT overbooking factor.

Since there is a per-CT overbooking factor, this must be reflected in a summation of reserved bandwidth.  As such, use of the following formula would appear to more correct:

  SUM (Reserved (CTc)/overbooking(CTc)) <= Max Link Bandwidth
    for all "c" in the range 0 <= c <= (MaxCT-1)

Thanks,
Jerry

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 20 May 2003 10:56:04 +0100

Jerry, Waisum and all,

>> This definition is OK, wherein the formula can be applied to 
>> either 'normalized' (by the overbooking factor) or 
>> 'unnormalized' bandwidth.
>> 

Yes, absolutely, in case the per-CT Local Overbooking Multipliers (LOM)
are used, then the formulas need to be applied to the normalised
bandwidth (I was only trying to get some agreement first on the
definition in the simpler case where per-CT overbooking is not used,
sorry I didn't make that explicit).

Anyway, this part of the formula would not change from current version
of MAM draft:

1)when per-CT LOMs are not used:
"o	for each value of b in the range 0 <= b <= (MaxCT - 1):
            		Reserved (CTb) <= BCb,"

1)when per-CT LOMs are  used:
"-	for each value of b in the range 0 <= b <= (MaxCT - 1):
            		Normalised(CTb) <= BCb,"

So I think we all agree with that part of the formula, right?

>> I agree with Wai Sum that this formula is incorrect for 
>> DS-TE, since the above formula only reflects the Max 
>> Reservable Bandwidth for the entire link, and does not 
>> reflect the per-CT overbooking factor.
>> 
>> Since there is a per-CT overbooking factor, this must be 
>> reflected in a summation of reserved bandwidth.  As such, 
>> use of the following formula would appear to more correct:
>> 

Again, here I agree that the formula needs to be applied to Normalised
bandwidth when per-CT LOMs are used. 

Also, I think we are in agreement that we should include an explicit
condition in the MAM definition which constraints "SUM (Normalised
(CTc))" (ie to make explicit the formally "implicit" constraint). Am I
right that we agree on that?

So, the only divergence seems to be that when doing the check on SUM
(Normalised (CTc)):
	- you propose to use "Max Link Bandwidth"
	- I propose to use "Max Reservable Bandwidth"

Again this seems to be coming from different interpretations of these
two IGP parameters. 
Like Dimitry pointed out, to me the parameter which is meant to be used
for reservations is "Max Reservable Bandwidth". This what I read in the
IGP extension text. Also, as mentioned earlier, the TE implementations
that I am familiar with are currently all using "Max Reservable
Bandwidth" for aggregate admission control decisions and not "Max Link
Bandwdith".

Cheers

Francois

---

From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
Date: Tue, 20 May 2003 14:45:29 +0200

Francois, Waisum and all

IMHO "max reservable bandwidth" should be used rather than
max-link-bandwidth to control the aggregate bandwidth in MAM.
Indeed max-link-bandwidth should be rather used to limit bandwidth of
one LSP.
Overbooking allows to take into account the fact that statiscally, not
all LSPs are simultaneously loaded, but we should also limit the
bandwidth of one LSP

So I agree with Francois regarding the use of max-reservalbe-bandwidth,
and I suggest to add a third rule that is 

An LSP of bandwidth B can be accepted if 
	B < max-link-bandwidth 

Note that this rule also applies to RDM

Regards 

JL

-----Message d'origine-----
De : Francois Le Faucheur (flefauch) [mailto:[email-masked]]
Envoye : mardi 20 mai 2003 11:56
A : Ash, Gerald R (Jerry), ALABS; Lai, Wai S (Waisum), ALABS; Dimitry
Haskin
Cc : [email-masked]
Objet : RE: Reflecting new-MAM/SAM definition in diff-te drafts

Jerry, Waisum and all,

Cheers

Francois

---

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Tue, 20 May 2003 09:19:28 -0500

Francois, All,

> So I think we all agree with that part of the formula, right?

Yes, I think we agree on this.

> bandwidth when per-CT LOMs are used.

Right.  So we need to specify what that formula is.  We have suggested this formula:

    SUM (Reserved(CTc)/LOM(CTc)) <= Max Link Bandwidth
     for all "c" in the range 0 <= c <= (MaxCT-1)

or, equivalently:

   SUM (Normalized(CTc)) <= Max Link Bandwidth
     for all "c" in the range 0 <= c <= (MaxCT-1)

> right that we agree on that?

Yes, we need a formula to make explicit the 'implicit' constraint (and for all the BC models, not just MAM).

> Like Dimitry pointed out, to me the parameter which is meant 
> to be used for reservations is "Max Reservable Bandwidth". This what 
> I read in the IGP extension text. Also, as mentioned earlier, the TE 
> implementations that I am familiar with are currently all using "Max 
> Reservable Bandwidth" for aggregate admission control decisions and 
> not "Max Link Bandwidth".

Use of "Max Reservable Bandwidth" appears to be OK without per-CT Local Overbooking Multipliers (LOMs).  That is, when there is only *one* LOM for the entire link, then the formula you give appears to be correct:

However, this formula is incorrect for DS-TE when per-CT LOM's are used, since the above formula only reflects the Max Reservable Bandwidth for the entire link, and does not reflect the per-CT local overbooking factors.  So what formula do you suggest when per-CT LOM's are used?

The formula we suggested appears to be correct when per-CT LOM's are used:

    SUM (Reserved(CTc)/LOM(CTc)) <= Max Link Bandwidth
     for all "c" in the range 0 <= c <= (MaxCT-1)

or, equivalently:

   SUM (Normalized(CTc)) <= Max Link Bandwidth
     for all "c" in the range 0 <= c <= (MaxCT-1)

Please suggest what formula you propose for when per-CT LOM's are used, and which also reflects Max Reservable Bandwidth instead of Max Link Bandwidth.

Thanks,
Jerry

---

From: Dimitry Haskin <[email-masked]>
Date: Tue, 20 May 2003 10:57:50 -0400

> 
> Use of "Max Reservable Bandwidth" appears to be OK without 
> per-CT Local Overbooking Multipliers (LOMs).  That is, when 
> there is only *one* LOM for the entire link, then the formula 
> you give appears to be correct:
> 
> However, this formula is incorrect for DS-TE when per-CT 
> LOM's are used, since the above formula only reflects the Max 
> reflect the per-CT local overbooking factors.  So what 
> formula do you suggest when per-CT LOM's are used?
>

Wouldn't 'Reserved (CTc)' it the above formula already accounts for the
overbooking multiplier at CTc?  I don't see how this formula precludes
per-CT LOM's to be used. Please explain.

Regards,
  Dimitry

---

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Tue, 20 May 2003 10:35:16 -0500

Dimitry, Francois,

> per-CT LOM's to be used. Please explain.

Are you then proposing these formulas:

1. When per-CT LOMs are not used:

     o SUM (Reserved(CTc)) <= Max Reservable Bandwidth, 
         for all "c" in the range 0 <= c <= (MaxCT-1)

2. When per-CT LOMs are used:

     o SUM (Normalized(CTc)) <= Max Reservable Bandwidth, 
         for all "c" in the range 0 <= c <= (MaxCT-1)

Is that correct?  Please confirm, and/or give the formulas you propose.

Thanks,
Jerry

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 20 May 2003 16:38:51 +0100

Hello Dimitry, Jerry, Waisum,

>> Sent: 20 May 2003 16:58
>> Cc: [email-masked]; Lai, Wai S (Waisum), ALABS; Dimitry Haskin

I've been using "Reserved" and "Normalised" as per their definitions in
the proto draft, the RDM draft and the MAM draft.

Quoting from these drafts:

==================================
- "Reserved (CTc)": For a given Class-Type CTc ( 0 <= c <= MaxCT ) ,let
us define "Reserved(CTc)" as the sum of the bandwidth reserved by all
established LSPs which belong to CTc. 
- Normalised(CTc) : let us define "Normalised(CTc)" as
"Reserved(CTc)/LOM(c)", where LOM (c) is the Local Overbooking
Multiplier for CTc defined in [DSTE-PROTO].
=====================================

What that means is that "Reserved(CTc)" does factor in the overbooking
method which is refered to as "LSP/link size overbooking" method and is
the overbooking method commonly used in TE networks. However, it does
NOT factor in the optional "Local Overbooking Multiplier" method.

"Normalised (CTc)"  factors-in both the "LSP/link size overbooking" and
the optional "Local Overbooking Multiplier" method.

Definitions of the "LSP/link size overbooking" method and "Local
overbooking Multiplier" method can be found in section "4.1.2. per-CT
Local Overbooking Multipliers (LOMs) of the dste-proto draft.

Based on this, my proposal is to include the following condition to
reflect the aggregate constraint when both overbooking methods are used
(ie "LSP/link size overbooking" method and "Local overbooking
Multiplier" method):

    o SUM (Normalised (CTc)) <= Max Reservable Bandwidth, 
        for all "c" in the range 0 <= c <= (MaxCT-1)

where "Normalised (CTc) is equal to "Reserved(CTc)/LOM(c)" as currently
defined in RDM and MAM drafts.

Thanks

Francois

---

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Tue, 20 May 2003 16:57:46 -0500

Francois, All,

> - "Reserved(CTc)": For a given Class-Type CTc ( 0 <= c <= MaxCT ) ,let
> method which is referred to as "LSP/link size overbooking" method and is
> "Normalised(CTc)"  factors-in both the "LSP/link size overbooking" and

Thank you for reviewing this.  

I had not appreciated that 'Reserved(CTc)' is actually a normalized quantity, normalized by the 'LSP/link size overbooking multiplier' (LSOM).

Just to further clarify, in terms of the actual bandwidth requested, I suppose this relationship must hold:

Reserved(CTc) = Bandwidth-Requested(CTc)/LSOM

where

Bandwidth-Requested(CTc): For a given Class-Type CTc ( 0 <= c <= MaxCT ), define "Bandwidth-Requested(CTc)" as the sum of the bandwidth requested by all established LSPs which belong to CTc. 

Is that correct?  If so, then 'Reserved(CTc)' is also a 'normalized' quantity, but this time it is normalized by the LSOM, right?

Thanks for the clarifications,
Jerry

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 21 May 2003 10:04:36 +0100

Hello Jerry,

>> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
>> Sent: 20 May 2003 23:58
>> To: Francois Le Faucheur (flefauch)
>> Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]; Lai, 
>> Wai S (Waisum), ALABS; Dimitry Haskin
>> I had not appreciated that 'Reserved(CTc)' is actually a 
>> normalized quantity, normalized by the 'LSP/link size 
>> overbooking multiplier' (LSOM).
>> 
>> Just to further clarify, in terms of the actual bandwidth 
>> requested, I suppose this relationship must hold:
>> 
>> Bandwidth-Requested(CTc): For a given Class-Type CTc ( 0 <= 
>> c <= MaxCT ), define "Bandwidth-Requested(CTc)" as the sum 
>> of the bandwidth requested by all established LSPs which 
>> belong to CTc. 
>> 
>> Is that correct?  If so, then 'Reserved(CTc)' is also a 
>> 'normalized' quantity, but this time it is normalized by the 
>> LSOM, right?
>>

Yes, I do agree with your statement that "Reserved(CTc)" is also
normalised in the sense that it reflects the LSP/link size overbooking.

This is analogous to what happens today with regular TE. The bandwidth
that is configured as the LSP size may reflect some over/underbooking
factor. Similarly the Max Reservable bandwidth may reflect some
over/underbooking ratio.
The good thing is that from TE's perspective, the only thing we have to
worry about are these "normalised" bandwidth (reflecting LSP/link size
Overbooking).
If an LSP bandwidth is configured/signaled as 100, it is irrelevant (for
TE) whether the SP expects a peak load of 200 on that LSP and applied an
LSP overbooking of 2, or whether the SP actually expects a peak load of
100 and applied no overbooking.
Similarly, the relevant constraint is the Max Reservable Bandwidth
(which can be configured smaller or larger than real link capacity). For
TE, what matters is that the Max Reservable Bw is set to, say, 1000. It
doesn't really matter whether the link is actually indeed of 1000 or
whether it is actually a link of 500 with an link overbooking of 2.
Basically, TE will establish 10 LSPs of configured bandwidth 100 on that
link of 1000. That's it.
This is why, in regular TE, only the LSP bandwidth is the one considered
(and is indeed a normalised bandwidth factoring LSP Size Overbooking)
and only Max Reservable is considered (which is also a normalised value
factoring in the link size overbooking). 
One interesting point is that TE does not explicitely need the concept
of LSP size Overbooking *Multiplier" and the Link Size Overbooking
*Multiplier". They are effectively transparent to TE which works only on
normalised bandwidth. 

The DS-TE approach is the same with respect to LSP/link Size Overbooking
ie the only "bandwidth" we are concerned about is the actual LSP size,
which factors in the LSP Size Overbooking (ie which is normalised , as
you stated) and the BCs [+ Max Reservable Bw (as proposed)].
For DS-TE, like for TE, I think we don't need to explicitely define in
the drafts the concepts of LSP/Link Size overbooking Multipliers (LSOMs)
nor formulas using them because we operate directly/exclusively on
"normalised" values. But I think we  agree in spirit in what those would
be anyway, based on our discussion.

Thanks

Francois

PS: of course, as mentioned earlier, "Reserved(CTc)" factors LSOMs but
does not factor the LOMs. "Normalised(CTc)" does factor both.

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 21 May 2003 10:21:19 +0100

Hello Sandy,

>> From: sanford goldfless [mailto:[email-masked]] 
>> Sent: 20 May 2003 20:55
>> To: [email-masked]
>> Francois,
>> At this time, could you please clear up one point regarding 
>> overbooking
>> with RDM?
>> 
>> Max Reservable is now back as the  choice for the parameter 
>> indicating
>> the aggregate overbooking factor.  

Yes, but note that this was the asumption already in current RDM draft.

>>You also show nicely that it can
>> indeed be used in a CAC rule together with per-CT LOMs, by 
>> normalizing
>> the per-CT reservations and then comparing to Max 
>> Reservable.  A setting
>> of Max Reservable could be used to enforce a lower aggregate 
>> reservation
>> amount than the sum of the normalized per-TE-Class advertisements of
>> Unreserved would. 
>> 
>> So, therefore, doesn't the semantic of this parameter and that of BCO
>> now need to be kept distinct?  I say this because it was my
>> understanding that the advertised  bw constraints would not 
>> be adjusted
>> for link overbooking.  

Actually, again here, we need to distinguish the overbooking related to
LSP/Link Size Overbooking and realted to the per-CT Link Overbooking
Multipliers.

Advertised BCs are not adjusted to reflect the Local Overbooking
Multipliers, nor is Max Reservable Bw.
But advertised BCs do inherently reflect the LSP/Link Size overbooking
factors (as discussed in previous message to Jerry, BCs are "normalised"
bandwidth which factor in the Link Size Overbooking, just like Max
Reservable Bandwidth).

Refering to section "6.3 Example Usage of LOM" of diff-te-russian-01:
	 -the advertised BCs are BC0=200 and BC1=100 (regardless of the
LOM values).
	- However, it may very well be that the actual link bandwidth is
in reality only of 100 and that BC0=Max-Res-Bw effectively=200 already
factors in an overbooking factor of 2.

So I think BC0 does coincide with Max Reservable Bw (in the case of RDM
only of course).

Thanks

Francois

>>Or is this not right, and the BCs 
>> themselves in
>> RDM must somehow be adjusted for overbooking?
>> 
>> Thanks,
>> Sandy Goldfless  
>> 
>> Sanford Goldfless
>> 192 Fuller St
>> Brookline MA 02446
>> 617-738-1754
>> [email-masked]
>> 
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Francois Le Faucheur (flefauch)
>> Sent: Tuesday, May 20, 2003 12:32 PM
>> To: Ash, Gerald R (Jerry), ALABS
>> Cc: [email-masked]
>> Jerry,
>> >> Yes, we need a formula to make explicit the 'implicit' 
>> >> constraint (and for all the BC models, not just MAM).
>> >> 
>> 
>> That's a good point.
>> 
>> With RDM, the proposed formula of:
>> already applies, since we have:
>> 	- SUM (Normalised(CTc)) <= BC0, and
>> 	- BC0=Max Reservable Bw
>> 
>> It would be nice to have exact same formula also apply to MAM.
>> 
>> Cheers
>> 
>> Francois
>> 
>> 
>> 
>> 
>>

---

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Wed, 21 May 2003 08:23:51 -0500

Hi Francois,

>> I suppose this relationship must hold:
>>
>> LSOM: 'LSP/link size overbooking multiplier'
>>
 
> One interesting point is that TE does not explicitly need the concept
> For DS-TE, like for TE, I think we don't need to explicitly define in

Thank you for the good and clear explanation.

Then, to clarify further, the following relationship would seem to hold:

LSOM = Max Reservable Bandwidth/Max Link Bandwidth

Is that correct?

If so, then another way to write your proposed formula for the sum of reserved bandwidth would be:

  o SUM (Normalized(CTc)) <= Max Link Bandwidth X LSOM
      for all "c" in the range 0 <= c <= (MaxCT-1)

Is that right?

Thanks,
Jerry

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 21 May 2003 14:47:55 +0100

Jerry,

See very far below: 

>> Sent: 21 May 2003 15:24

In the "LSP/Link Size Overbooking" method one can apply overbooking by
tweaking the LSP size (lets' call this the "LSP Size Overbooking")
and/or by tweaking the Max Reservable Bw (lets' call this the "Link Size
Overbooking").

Assuming we define LSOM as the "Link Size Overbooking Multiplier" (as
opposed to the "LSP/Link Size Overbooking Multiplier"), then I agree
with the above relationship.

Just to be clear, what I am trying to say is that the above relationship
you stated relates to the overbooking applied on the Link (but that the
overbooking applied on the LSP size is transparent to that because it is
already factored in the LSP size configured/signaled).

>>       for all "c" in the range 0 <= c <= (MaxCT-1)

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

---

From: "Lai, Wai S (Waisum), ALABS" <[email-masked]>
Date: Sun, 25 May 2003 14:24:45 -0500

Jim,
  I think we still need some more discussion.  Please see
http://ops.ietf.org/lists/te-wg/te-wg.2003/msg00290.html
as a result of the complexity of the overbooking options.
Thanks, Wai Sum

-----Original Message-----
From: Jim Boyle [mailto:[email-masked]]
Sent: Friday, May 23, 2003 8:31 PM
To: Francois Le Faucheur (flefauch)
Cc: [email-masked]; Lai, Wai S (Waisum), ALABS
Subject: RE: Reflecting new-MAM/SAM definition in diff-te drafts 

So is there agreement now?

If so, what's the fallout?

I don't want to pull the reqt's out of IESG, and as stated in the list,
it 
isnt the place MAM is defined (sorry SAM, I think we have enough
bandwidth 
models).

Francois, can you re-propose changes for proto, RDM and MAM?

thanks,

Jim

btw... I also think LOMs are lots of complexity for little gain :)

On Tue, 20 May 2003, Francois Le Faucheur (flefauch) wrote:

> >> Sent: 20 May 2003 17:35
> >> To: Dimitry Haskin; Francois Le Faucheur (flefauch)
> >> Wai S (Waisum), ALABS
> Yes, this is exactly what I propose.
> I think this is similar to what you were proposing, only using "Max
Res
> Bw" instead of "Max Link Bw". 
> 
> Sorry I didn't make that very clear before.
> 
> Cheers
> 
> FRancois
> 
> >> 
> >> Thanks,
> >> Jerry
> >> 
> 
> 
> 
>

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 26 May 2003 14:04:32 +0100

Hi Jim,

>> Sent: 24 May 2003 02:31
>> Cc: [email-masked]; Lai, Wai S , ALABS

Working on it. Almost there (I think).

>> I don't want to pull the reqt's out of IESG, and as stated 
>> in the list, it 
>> isnt the place MAM is defined (sorry SAM, I think we have 
>> enough bandwidth 
>> models).

Alright. It seems the potential inconsistency I was worrying about
between the current MAM definition in -rqts and the upcoming MAM spec
isn't such a worry for most people, so let's take the easiest path:
	- leave -reqts as it is
	- keep the MAM name for the MAM spec and update the definition
in there.

>> Francois, can you re-propose changes for proto, RDM and MAM?

Will try do as soon as we have closed on the overbooking discussion (and
perhaps also on the removal/keeping of LOM).

Thanks

Francois
 
>> > I think this is similar to what you were proposing, only 
>> using "Max Res