Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [RPRWG] extendedFrame and floodingForm




Anoop,

I'm in complete agreement, and I've already made notes to file comments along these lines. I see no need for extendedFrame since this should be entirely determined by the presence and value of sourceAddress.

And I see no reason to allow the client to set floodingForm on a per frame basis.

jl

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




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 
>