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

Hi Richard,

> discovery process in its own right, in which peering PEs will receive VPN
> membership information for VPNs that they do not belong to.

Not necessarily ;) 

Once BGP session comes up and all capabilities are exchanged and matched
one could easily implement filtering based on default being "Don't send
anything unless explicitly asked for it" ... see
draft-marques-ppvpn-rt-constrain-00.txt section 6 paragraph 1 where in
the lack of explicit request no information is propagated to the peer at
all.

R.



> [email protected] wrote:
> 
> Yakov
> 
> I stand corrected regarding my session establishment observation, again.
> However, one could still consider the exchange of ORF entries to be a
> discovery process in its own right, in which peering PEs will receive VPN
> membership information for VPNs that they do not belong to. Obviously PE's
> do not use this VPN membership information in the context of VPN discovery,
> but they receive the information nonetheless. Again, I'm not saying this is
> an issue, just an observation.
> 
> Richard
> 
>  > -----Original Message-----
>  > From: Yakov Rekhter [mailto:[email protected]]
>  > Sent: 20 May 2003 18:35
>  > To: Spencer,R,Richard,XGH5 R
>  > Cc: [email protected]; [email protected]; [email protected]
>  > Subject: Re: call for discussion on
>  > draft-heinanen-radius-pe-discovery-03. txt
>  >
>  >
>  > Richard,
>  >
>  > > Yakov
>  > >
>  > > I stand corrected, yes ORF could be used to filter outbound VPN
>  > > advertisements and therefore limit the distribution of VPN
>  > information.
>  > > However, what happens when BGP peers first establish
>  > sessions with each
>  > > other, won't they exchange NLRIs containing VPN discovery
>  > information before
>  > > they receive route-refresh messages containing ORF
>  > entries? In which case
>  > > the VPN information will already have been received,
>  > although once sessions
>  > > are established and route-refresh messages received, ORF
>  > can be used to
>  > > filter future VPN advertisements.
>  >
>  > You are incorrect again. Please read section 8 of ORF spec
>  > (draft-ietf-idr-route-filter-08.txt).
>  >
>  > Yakov.
>  >
>  > > Also, the actual exchange of ORF entries
>  > > between peers could be considered to be a VPN discovery
>  > process in itself.
>  > > After all, the remote PE is effectively saying 'Here is a
>  > list of VPNs that
>  > > I belong to, only send me updates for these VPNs'.I'm not
>  > saying these are
>  > > issues, just observations.
>  > >
>  > > The point I was trying to make is that the PEs in the
>  > RADIUS discovery draft
>  > > only ever receive information about the PEs that belong to
>  > a particular VPN,
>  > > and do not have to perform any filtering. Again, I'm not
>  > saying that this is
>  > > an issue, merely an observation.
>  > >
>  > > Richard
>  > >
>  > >  > -----Original Message-----
>  > >  > From: Yakov Rekhter [mailto:[email protected]]
>  > >  > Sent: 20 May 2003 16:37
>  > >  > To: Spencer,R,Richard,XGH5 R
>  > >  > Cc: [email protected]; [email protected]; [email protected];
>  > >  > [email protected]
>  > >  > Subject: Re: call for discussion on
>  > >  > draft-heinanen-radius-pe-discovery-03. txt
>  > >  >
>  > >  >
>  > >  > Richard,
>  > >  >
>  > >  > [clipped...]
>  > >  >
>  > >  > >  > 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.
>  > >  >
>  > >  > This is incorrect. Please read section 7 of
>  > >  > draft-ietf-ppvpn-bgpvpn-auto-05.txt.
>  > >  >
>  > >  > Yakov.
>  > >  >
>  > >
>  > >
>  >