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

From: [email-masked]
Date: Tue, 20 May 2003 16:13:24 +0100

Eric

 > Richard> The  RADIUS  discovery draft  is  the  only  one 
 > that  includes  CE
 > Richard> authentication
 > 
 > I'm not sure that having the  CE authenticated by the SP is 
 > that interesting
 > in this  context, as such  authentication could be  done by 
 > the PE.   If the
 > authentication  could  be proxied  to  a  radius  server 
 > controlled  by  the
 > customer,  that might  be more  interesting,  as it  would 
 > be  immune to  SP
 > misconfigurations. 

RS> What is not considered to be interesting to some parties, may well be
interesting to others. I do consider the idea of VPN site authentication
being an integral part of a VPN site discovery mechanism to be an
interesting feature.

 > Richard> and  meets all  the  discovery requirements  
 > identified within  the
 > Richard> PPVPN WG so far including "Limits VPN information 
 > to only those PEs
 > Richard> involved  in  that  VPN",  "Extendible to  provide  
 > information  in
 > Richard> additional to VPN endpoint IP address" and 
 > "Supports inter-provider
 > Richard> VPNs". 
 > 
 > The BGP-based discovery procedure meets these requirements. 

RS> I think how well the BGP discovery mechanism is perceived to meet the
above requirements depends on how the requirements are interpreted. 

In the case of limiting VPN information to only those PEs involved in the
VPN, in the BGP discovery process PEs broadcast VPN membership information
for all the VPNs that they are members of, to all the other PEs in the
network. This is done regardless of whether the other PEs in the network are
members of the VPN or not and is a receiver based filtering process in which
receiving PEs have to filter out the relevant information for the VPNs that
they belong to. Information for VPNs that a receiving PE is not a member of
can be discarded (or retained for future use). The point being that the
*distribution* of VPN information is not limited to those PEs involved in a
particular VPN, although the storing of this information can be.

In the 'Extendible to provide information in addition to VPN endpoint IP
address' case, in BGP the L2 information TLV includes information about the
encapsulation type and the L2 Maximum Transmission Unit (MTU) and could be
extended (or new TLVs defined) to provide further information. However,
distribution of p2p information is not supported as all VPN information must
be broadcast to all PEs. This issue has been discussed already on the
mailing list but I do not believe any vital pieces of information that must
be distributed on a p2p basis were identified. I would just like to point
out that this is something that perhaps should be taken into consideration
when selecting a discovery mechanism.

Richard

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 20 May 2003 08:37:26 -0700

Richard,

[clipped...]
 
> particular VPN, although the storing of this information can be.

This is incorrect. Please read section 7 of draft-ietf-ppvpn-bgpvpn-auto-05.txt.
  
Yakov.