Subject: RE: draft-ietf-l2tpext-ds-01.txt

From: Klausberger Walter <[email-masked]>
Date: Mon, 11 Dec 2000 17:57:58 +0100

Hi folks,

I like the idea of negotiating QoS parameters during tunnel/session
establishment, but I asked myself all the time, where the DS parameters will
be configured for a special session.

There are parameters planned in the L2TP MIB, but in LAC case the parameters
often come frome an AAA server like RADIUS. Shouldn't there be an extension
in the tunneling parameters?

Another thing is the Tequila group. They want to provide SLA negotiation for
RAS user via PPP IPCP extension. This should also be mapped onto tunnel
sessions (if granted). To grant such features again new AAA attributes could
be used.

Is anyone already thinking about that, or is someone willing to discuss
these matters in more detail?

see you at the IETF
with best regards
Walter

---

From: Evan Caves <[email-masked]>
Date: Mon, 11 Dec 2000 13:55:05 -0800

> Klausberger Walter wrote:
> 
> Hi folks,
> 
> establishment, but I asked myself all the time, where the DS
> parameters will be configured for a special session.

They will most likely be returned by a AAA server.

> 
> There are parameters planned in the L2TP MIB,

Remind me again about these parameters :-).

> but in LAC case the
> parameters often come frome an AAA server like RADIUS. Shouldn't there
> be an extension in the tunneling parameters?

Yup.

> 
> Another thing is the Tequila group. 

The what group?

> They want to provide SLA
> negotiation for RAS user via PPP IPCP extension. 

Uggghhh.

> This should also be
> mapped onto tunnel sessions (if granted). To grant such features again
> new AAA attributes could be used.
> 
> Is anyone already thinking about that, or is someone willing to
> discuss these matters in more detail?
> 
> see you at the IETF
> with best regards
> Walter

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 12 Dec 2000 15:46:48 -0800

> > negotiation for RAS user via PPP IPCP extension.

I'll second that.

> > new AAA attributes could be used.

As part of the process of revising RFC 2868 we have considered adding a
diffserv-related attribute.