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

Hi Robert,

Based on your reply, I don't think I explained myself very clearly. To use
an example, lets say that PE1 belongs to VPNs A, B, C, and D, and that PE2
belongs to VPNs C, D, E, and F. Now if I understand correctly (which I may
not as I am not a BGP expert by any stretch of the imagination!) using ORF:

- PE1 and PE2 establish a BGP session and exchange capabilities
- PE1 sends ORF entries to PE2 saying "Only send me updates for VPNs A, B,
C, and D."
- PE2 sends ORF entries to PE1 saying "Only send me updates for VPNs C, D,
E, and F."

This happens before the actual BGP discovery process takes place, i.e.
before the PE's exchange NLRIs.

Now, by implication, PE1 knows that PE2 belongs to VPNs C, D, E, and F, and
PE2 knows that PE1 belongs to VPNs A, B, C, and D. However, PE1 didn't need
to receive any information about VPN E or F as it is not a member of these
VPNs, and likewise PE2 in the case of VPNs A and B. The PEs do not use this
information in the VPN discovery context, but they do receive it.

Regards,

Richard

 > -----Original Message-----
 > From: Robert Raszuk [mailto:[email protected]]
 > Sent: 20 May 2003 20:18
 > 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
 > 
 > 
 > 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.
 > >  > >  >
 > >  > >
 > >  > >
 > >  >
 >