Re: Questions about draft-ietf-radext-filter-rules-00.txt

[Hannes Tschofenig <Hannes.Tschofenig@gmx.net>]

Hi Mauricio,

thanks for your response. Please find my comments inline:

Sanchez, Mauricio (ProCurve) wrote:

> > -----Original Message-----
> > From: owner-radiusext@ops.ietf.org 
> > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Hannes Tschofenig
> > Sent: Monday, June 05, 2006 3:02 AM
> > To: radiusext@ops.ietf.org
> > Subject: Questions about draft-ietf-radext-filter-rules-00.txt
> >
> > Hi all,
> >
> > 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 
improvement...

  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 
http://www.tschofenig.com/drafts/draft-tschofenig-radext-qos-02.txt
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
> terminal.

I missed this aspect. Thanks for point me to it.


Ciao
Hannes


> MS


--
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/>