[j-nsp] Usage of Route distinguisher in VPLS

Guy Davies aguydavies at gmail.com
Wed Jun 27 05:58:17 EDT 2007


Hi Monika,

I haven't played around much with VPLS but a quick read of RFC 4761
reveals the following...

Section 3.5 of RFC 4761 appears to be the key.  It refers to
multihoming mechanisms for VPLS and states the following...

   In the case where the PEs connected to the same site are assigned the
   same VE ID, a loop-free topology is constructed by routing
   mechanisms, in particular, by BGP path selection.  When a BGP speaker
   receives two equivalent NLRIs (see below for the definition), it
   applies standard path selection criteria such as Local Preference and
   AS Path Length to determine which NLRI to choose; it MUST pick only
   one.  If the chosen NLRI is subsequently withdrawn, the BGP speaker
   applies path selection to the remaining equivalent VPLS NLRIs to pick
   another; if none remain, the forwarding information associated with
   that NLRI is removed.

   Two VPLS NLRIs are considered equivalent from a path selection point
   of view if the Route Distinguisher, the VE ID, and the VE Block
   Offset are the same.  If two PEs are assigned the same VE ID in a
   given VPLS, they MUST use the same Route Distinguisher, and they
   SHOULD announce the same VE Block Size for a given VE Offset.

In section 3.3, it states (paraphrasing) that you MAY configure an RD
on a PE for each VPLS.  If you choose not to configure one manually
then one will be automatically created for each VPLS.

So, (taking 3.3 and 3.5 together) if you want to do multihoming, you
MUST manually configure the same RD for the same VPLS on all the PE to
which multihomed sites in that VPLS are connected (so it makes sense
to configure the same RD on all PE for that VPLS).

Rgds,

Guy

On 27/06/07, Monika M <monika.vpls at gmail.com> wrote:
> Thanks for your replies
> I think there was a confusion in my query.
> My question was to understand why Route distinguisher is proposed in VPLS
> NLRI? What is the use of sending RD in the NLRI?
>
> With MP-BGP, there are two extensions for VPN application.
> 1 - L3VPN (RFC 4364) and L2 VPN (RFC 4761) both of them have Route
> distinguisher in the NLRI.
>
> The purpose of using Route distinguisher in L3 VPN is clear.  But in 4761,
> the purpose RD servers is not clear.
>
> Monika
>
>
>
>
> On 6/26/07, xinyu zeng <xinyu.zeng at gmail.com> wrote:
> >
> > Hi Monika,
> >
> > You can check with RFC 4761. Generally, NLRI for VPLS format is as
> > following:
> >
> >       +------------------------------------+
> >       |  Length (2 octets)            |
> >       +------------------------------------+
> >       |  Route Distinguisher  (8 octets)|
> >       +------------------------------------+
> >       |  VE ID (2 octets)             |
> >       +------------------------------------+
> >       |  VE Block Offset (2 octets)|
> >       +------------------------------------+
> >       |  VE Block Size (2 octets)|
> >       +------------------------------------+
> >       |  Label Base (3 octets)     |
> >       +------------------------------------+
> >
> > MAC address is not in the NLRI as L3VPN. So your can't expect to carry mac
> > tables in NLRI. MAC learning is by flooding in L2VPN, not by carried in
> > MPBGP as L3VPN.
> >
> >  On 6/26/07, Monika M <monika.vpls at gmail.com> wrote:
> >
> > > Hi,
> > >           In L3VPN, The purpose of the Route Distinguisher is solely to
> > > allow one to create distinct routes to a common IPv4  address prefix.
> > >
> > > But why do we need Route distinguisher for VPLS?
> > >
> > > Was this added to VPLS to be consistent with L3VPN?
> > >
> > >
> > > -Monika
> > > _______________________________________________
> > > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/juniper-nsp
> > >
> >
> >
> >
> > --
> > Best Regards,
> > Yours Xinyu.Zeng
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>


More information about the juniper-nsp mailing list