[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Comments/questions about bandwidth draft



Hi Gilles,
Thanks for reading the draft and your comments.  Please see my responses
inline.
BR,
Farid

> -----Original Message-----
> From: BOURDON Gilles RD-CORE-ISS 
> [mailto:gilles.bourdon@francetelecom.com] 
> Sent: Thursday, July 22, 2004 2:43 AM
> To: Adrangi, Farid
> Cc: radiusext@ops.ietf.org
> Subject: Comments/questions about bandwidth draft
> 
> 
> I have some comments and questions about the bandwidth draft:
> 
> 1) As far as I understand, the NAS behaves differently when receiving
> invalid selection of bandwidth parameter: in push mode, a COA NAK is
> sent but nothing happens to the session, and in pull mode the user
> session is terminated. 

Your observation is correct, but I don't think there is an inconsistency
here.  In pull mode, when the NAS advertises its bandwidth capabilities,
the AAA server is expected to do the selection within the boundary of
the advertised bandwidth parameters.  In the absence of the
advertisement, the NAS does not drop the session if it cannot honor the
"Selection" specified by the AAA server.

> I think it would be better to adopt the same
> behaviour in both cases. In the same idea, no specific behaviour is
> defined in pull mode in case the NAS cannot comply with the request
> ("resources unavailable" error cause is sent in push mode).
> 
That would be nice - but how can we do that in the pull model after
receiving an Access-Accept?  


> 2) Maybe the four bandwidth parameters could be aggregated in a unique
> attribute, since all are required in a message ? Or the rule can be
> loosen a little bit in allowing transmission of a composed set of
> attribute... Non present attributes could be interpreted as 
> "default" or
> "unchanged". But maybe there is a specific explanation to 
> this choice ?
> 
As you are aware, we had a long discussion on this topic -- I think the
consenus was to use individual attributes but we are okay with using a
single attribute here as well.  How do you suggest we should close on
this subjet?

> 3) About the "Don't care" value, I think it requires more precision.
> Should we understand "don't care" as a infinite (line-rate) 
> bandwidth ?
> Or a default bandwidth already set in the NAS ?
> 
Ok.  It refers to the default bandwidth already set in the NAS -- you
are right the draft is not specific about it; will fix it.  Thanks.

> 4) In section 4, shouldn't Note 1 include Access-Accept messages, not
> only COA ?
> 

You are right -- it should apply to both!

Again, thank you for comments and your help.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>