[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Questions about draft-ietf-radext-filter-rules-00.txt
thanks for your response. Please find my comments inline:
Sanchez, Mauricio (ProCurve) wrote:
[mailto:email@example.com] On Behalf Of Hannes Tschofenig
Sent: Monday, June 05, 2006 3:02 AM
Subject: Questions about draft-ietf-radext-filter-rules-00.txt
I have two questions regarding the filter rules draft:
1) Is is possible to define the draft in such a way that the
actions can be extended? I would like to use the filter rule
format for QoS. For example, I would like to express
something like the following:
qos qparam1 in from 192.0.2.168 1234 to 2345
qparam1=some qos parameters
I'd be leery to go down this pass given that some already argue that the
syntax is already complex.
That's a standard argument.
The encoding is obviously not compact. There is plenty of room for
Moreover, IMHO allowing proprietary
extensions somewhat dilutes the customer value of having a standardized
attribute. Why not just define a VSA at this point?
You mix two functions into the filter language:
* Description of the data traffic (often referred as flow identifier)
* Action that is applied to the data traffic
Since you mesh the two aspects together you prevent it from being used
in a generic way.
There is also the desire to align this with Diameter, as you know. I
wonder how this would work.
Rather, I'd rather talk about what you need. It sounds like you want to
perform some sort of QoS reclassification based on L3-L4 information.
Layer 2, 3 and 4.
Can you describe more in depth what your requirements are and what you'd
like to accomplish? Given the syntax is not closed at this point, it's
still open to new extensions and modifications.
We might be aware of the QoS work in DIME. We need a description of the
data traffic and the respective QoS treatment. Alignment with the RADIUS
QoS work would be important.
We wrote a strawman proposal some time back, with
If possible, we should align it with the rest of the DIME QoS work and
potentially with the filter-rule work.
2) What happens if the IP address of the end host is not
known when the NAS-Traffic-Rule attribute is sent from the
RADIUS server to the RADIUS client in the Access-Accept? Is
there a field to indicate that the RADIUS client should
instantiate the rule when the end host gets the IP address assigned?
There already exists a technique to address this use case. The keyword
'assigned' can be assigned in the place of the source IP field.
'assigned' is defined as the IP associated with the terminal. What is
not described is the method by which the NAS determines the IP of a
I missed this aspect. Thanks for point me to it.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.