Re: call for discussion on draft-heinanen-radius-pe-discovery-03.txt

>    If a PE wants for some reason to get from Radius an up-to-date list
>    of PEs in a particular VPN, it can at any time issue a new Access-
>    Request for any one of its CEs that belongs to the VPN.
>
> This seems like it is describing a re-authorization request. Is the intent
> for the CE to re-authenticate as part of this Access-Request?

I should also mention that RADIUS clients do not initiate
re-authentication or re-authorization requests "at any time". They only do
so under direction of the server.  For example, re-authentication can
occur after expiry of the time indicated in Session-Time, assuming that
Termination-Action=1 (RADIUS).  Alternatively, a server-initiated message
(CoA-Request) can result in the RADIUS client (PE) sending an
Access-Request.  So I'm curious as to whether these existing mechanisms
can be reused or whether something different is needed.

> In terms of the attributes necessary to implement this draft, I'd suggest
> reuse of the RFC 2868 Tunnel Attributes, if possible.

There is an RFC 2868bis effort underway, so it might make sense to contact
the authors and see if the needs described in the draft can be met:

http://www.watersprings.org/pub/id/draft-zorn-rfc2868bis-01.txt

For example, Section 5 of this draft says:

"If the RADIUS server returns attributes describing multiple tunnels then
the tunnels SHOULD be interpreted by the tunnel initiator as
alternatives and the server SHOULD include an instance of the Tunnel-
Preference Attribute in the set of Attributes pertaining to each
alternative tunnel.  Similarly, if the RADIUS client includes multiple
sets of tunnel Attributes in an Access-Request packet, all the
Attributes pertaining to a given tunnel SHOULD contain the same value in
their respective Tag fields and each set SHOULD include an appropriately
valued instance of the Tunnel-Preference Attribute."

So one question in my mind is under what conditions multiple tunnels will
not be interpreted by the tunnel initiator as alternatives, but rather as
distinct VPNs, which is what you want.

> Off the top of my
> head, I'd recommend the following:
>
> a. Definition of new Tunnel-Type values as appropriate.
> b. Reuse of existing Tunnel-Medium-Type values.
> c. Transmission of the VPNID in the Tunnel-Private-Group-Id Attribute.