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

 > That's fine. A RADIUS "Call Check" assumes that the user is 
 > authenticated
 > by another means (e.g. OSPF MD5), so there are no authentication
 > attributes in the Access-Request. But it *does* require that 
 > the CE be
 > identified in some way. That typically is via an L2 address, but it
 > could be something else. I'm just asking what uniquely 
 > identifies the CE
 > in this case. Given that there is no authentication exchange 
 > occurring,
 > it is probably not appropriate for the PE to "forge" an
 > authentication as through the CE really did authenticate when
 > in fact it didn't.  Since RADIUS doesn't require 
 > authentication (that's
 > what "Call Check" and "Authorize Only" Service-Type values are for)
 > there's no need to forge an authentication just to be 
 > compliant with the
 > protocol.
 
RS> I think it is important to recognise that the sole purpose of a PPVPN
discovery mechanism is to discover VPN endpoints. There have been other
suggestions that the discovery mechanism may distribute QoS and perhaps
topology information, but these requirements have not been properly defined
(and could also be distributed using a signalling mechanism).

As the protocol being used for discovery in Juha's draft is RADIUS, it has
the added bonus of being able to authenticate CEs. However, there is no
requirement for a discovery mechanism to authenticate or to distribute/store
any information whatsoever about CEs routers.

To join a VPN, a PE just needs to know that it is connected to at least one
CE that is a member of a particular VPN. This is a local matter, information
about that particular CE does not need to be distributed. Once a PE knows it
has at least one CE in a particular VPN it can request information about
other PEs in the same VPN, or filter out the relevant information if the
discovery mechanism is receiver based (i.e. BGP).

However, having said that in Juha's draft the PEs do send CE information to
the RADIUS server (for authentication), which is a very valuable feature. In
the draft, currently CEs are identified by a name, rather than MAC address
or port number, which is configured on the customer interface. As CE
authentication is not a requirement, how CEs should be identified (i.e.
port, Mac address, name) has not been discussed. Although the CE identifier
issue is something that needs to be resolved, CE authentication is an extra
feature and should not hold up the draft becoming a WG document.

 > Tunnel-Assignment-ID is used to allow multiple connections 
 > to be carried
 > over the same tunnel. That is not quite the same thing as 
 > having multiple
 > tunnels between two endpoints.

RS> This is OK for MPLS as each LSP can be described as being a separate
tunnel. However, in L2TP does the Tunnel-Private-Group-Id refer to the L2TP
tunnel or to an individual session? In L2TP each tunnel can have multiple
sessions, with each session corresponding to a different VPN.