RE: [RPRWG] extendedFrame and floodingForm

[Anoop Ghanwani <anoop@xxxxxxxxxxxxxx>]

Bob, Mike,

That would argue only in favor of having floodingForm.
I don't see any value in having the extendedFrame passed
as a parameter.

Also, as far as floodingForm goes, why does x.msr
need to be able to control it?   Is there a
scenario where allowing the client to set floodingForm 
would be useful?

-Anoop

-----Original Message-----
From: Castellano, Robert [mailto:RCastellano@xxxxxxxxx]
Sent: Friday, April 18, 2003 9:07 AM
To: 'Mike Takefman'; Anoop Ghanwani
Cc: 'stds-802-17@xxxxxxxx'
Subject: RE: [RPRWG] extendedFrame and floodingForm


Hi, 
Any entity sitting above the MAC that is going to be doing ringlet
selection, 
needs to be able to set the floodingIndication (Now FI).  This would 
also include an Enhanced bridging client (shim layer mentioned 
by .1). 
        robert 
> -----Original Message----- 
> From: Mike Takefman [mailto:tak@xxxxxxxxx] 
> Sent: Friday, April 18, 2003 11:05 AM 
> To: Anoop Ghanwani 
> Cc: 'stds-802-17@xxxxxxxx' 
> Subject: Re: [RPRWG] extendedFrame and floodingForm 
> 
> Anoop, 
> 
> My memory is slightly hazy but I do recall Dr. Yu 
> expressing interest in having X.msr being able to 
> control the flooding form. 
> 
> mike 
> 
> Anoop Ghanwani wrote: 
> > 
> > Why are the extendedFrame and floodingForm parameters 
> > part of the MA_DATA.request primitive?  These should 
> > be determined completely within the MAC based on the 
> > destinationAddress presented by the client. 
> > 
> > -Anoop 
> 
> -- 
> Michael Takefman              tak@xxxxxxxxx 
> Manager of Engineering,       Cisco Systems 
> Chair IEEE 802.17 Stds WG 
> 2000 Innovation Dr, Ottawa, Canada, K2K 3E8 
> voice: 613-254-3399       cell:613-220-6991 
>