Subject: RE: RD in 2547 bis

From: "Sylvia Sugar" <[email-masked]>
Date: Thu, 17 Apr 2003 19:15:31 +0000

Hello Mr. Jim,

Thank you so much Mr Jim.

I believe I have made my point clear and you have given me the necessary 
answers.

only 2 remain:

>not necessarily - you can rewrite the RT values at the ASBR routers or you
>can carry them unchanged between AS's - this is a deployment choice.

1st let me put on my glasses:

@_@

1.

From 2457bis:
4.3.1. The Route Target Attribute

   Every VRF is associated with one or more "Route Target" attributes.

   When a VPN-IPv4 route is created (from an IPv4 route which the PE has
   learned from a CE) by a PE router, it is associated with one or more
   "Route Target" attributes.  These are carried in BGP as attributes of
   the route.

   Any route associated with Route Target T must be distributed to every
   PE router that has a VRF associated with Route Target T.  When such a
   route is received by a PE router, it is eligible to be installed
   those of the PE's VRFs which are associated with Route Target T.
   *(Whether it actually gets installed depends upon the outcome of the
   BGP decision process, and upon the outcome of the decision process of
   the PE-CE IGP.)*

Is this mean that even if one "overwrites" the route target, the route 
target still identifies the VRF "across the globe" where the routes get 
distributed?

So if even one was to modify the routes, it would not be a problem as the 
defination of Route Target would remain the same throughout across all 
Service Providers?

Also, does this mean that the BGP decision process now works after filtering 
on Route Target?

also from RFC 2547:

4.2.4. Building VPNs using Target and Origin Attributes

   By setting up the Target VPN and VPN of Origin attributes properly,
   one can construct different kinds of VPNs.

   Suppose it is desired to create a Closed User Group (CUG) which
   contains a particular set of sites. This can be done by creating a
   particular Target VPN attribute value to represent the CUG. This
   value then needs to be associated with the per-site forwarding tables
   for each site in the CUG, and it needs to be associated with every
   route learned from a site in the CUG.  Any route which has this
   Target VPN attribute will need to be redistributed so that it reaches
   every PE router attached to one of the sites in the CUG.

   Alternatively, suppose one desired, for whatever reason, to create a
   "hub and spoke" kind of VPN.  This could be done by the use of two
   Target Attribute values, one meaning "Hub" and one meaning "Spoke".
   Then routes from the spokes could be distributed to the hub, without
   causing routes from the hub to be distributed to the spokes.

   Suppose one has a number of sites which are in an intranet and an
   extranet, as well as a number of sites which are in the intranet
   only.  Then there may be both intranet and extranet routes which have
   a Target VPN identifying the entire set of sites.  The sites which
   are to have intranet routes only can filter out all routes with the
   "wrong" *VPN of Origin*. (@_@)

   These two attributes allow great flexibility in allowing one to
   control the distribution of routing information among various sets of
   sites, which in turn provides great flexibility in constructing VPNs.

There doesnt seem to be any mention of Route Distinguisher here :-((

oooooohhhhhh! this is all so confusing now :-(( Could you please clarify?

2.
>the RD is 64 bits = 8 bytes
from 2547bis:

The RDs are structured so that every service provider can administer
   its own "numbering space" (i.e., can make its own assignments of
   RDs), without conflicting with the RD assignments made by any other
   service provider.

so Mr. Jim, incase one goes across service providers, RD may overlap? ohh 
now its all so confusing again :-((

The RT seems to be longer than RD too :-((

Thank you so much for your help and patience.

I am sure now I can confidently look into MPBGP based on 2547 and 2547bis 
and hence give a good solution to my customers.

Thanks all,

-SylviaXO

>From: "Jim Guichard" <[email-masked]>
>To: "Sylvia Sugar" <[email-masked]>,   
><[email-masked]>
>Subject: RE: RD in 2547 bis
>Date: Thu, 17 Apr 2003 11:36:24 -0400
>
>Hi Sylvia,
>
> > >-----Original Message-----
> > >From: Sylvia Sugar [mailto:[email-masked]]
> > >Sent: Thursday, April 17, 2003 3:54 AM
> > >To: [email-masked]; [email-masked]
> > >Subject: RE: RD in 2547 bis
> > >
> > >
> > >Hello Mr. Jim,
> > >
> > >I must thank you for taking time to mail back on my query. It
> > >really feels
> > >nice to have the author of a book on MPLS, answer me my queries.
> > >I am really
> > >thankful to you for your time and patience.
> > >
> > >
> > >I still have a few more things to clarify.
> > >
> > >
> > >> > >>
> > >> > >> > > > >RD is local to the router /used to distinguish VPNv4 
>routes
> > >> > >>locally, is my
> > >> > >> > >understanding.
> > >> > >> > > RD becomes crucial with the presence of RRs.
> > >> > >>
> > >> > >>How come? Can you please give me some pointers as to how RD 
>becomes
> > >> > >>"crucial" in presence
> > >> > >>of RRs.
> > >>
> > >>the RD is not really local to the router in the sense that it can 
>affect
> > >>route selection at the RRs. If you use the same RD on say PE1
> > >and PE2 (lets
> > >>call it RD 100:2) and then export route 1.1.1.1 from both PEs,
> > >the RR will
> > >>see two identical routes e.g. 100:2:1.1.1.1. It will select one as 
>best
> > >>path
> > >>and therefore one of the routes is lost from downstream PEs.
> > >
> > >
> > >But Mr Jim, how could one use different Route Distiguisher for the same
> > >prefix? In the book it seems to say its unique to the customer.
>
>this can happen if you export the same route from two different PEs - note
>that this will happen if you have a dual-attached site advertising the same
>set of prefixes.
>
> > >
> > >On the other had, when one passes routes across VPNs, it seems
> > >to say that
> > >the Route Target is used to identify the "VRF" of customer. There is
> > >something about multiple service providers, who each would have
> > >control of
> > >RD which would be local to them, but Route Target would be unique to a
> > >customer across all service providers.
>
>not necessarily - you can rewrite the RT values at the ASBR routers or you
>can carry them unchanged between AS's - this is a deployment choice.
>
> > >
> > >The reason cited for the same is the size of the Route
> > >Distinguisher is very
> > >small.
>
>the RD is 64 bits = 8 bytes
>
> > >
> > >This is my understanding from 2547 and 2547bis.
> > >
> > >I am not too sure where this was mentioned in your book.
> > >
> > >However, it seems to make Route Distinguisher redundant.
> > >One could simply replace Route Distinguisher with Route Target
> > >and it seems
> > >to achieve the same functionality
>
>no, it does not. The RT is used for import/export policy. The RD is used to
>make the IPv4 address unique. An update can carry multiple RT values but a
>single RD for each NLRI within the update. Jim
>
> > >
> > >Please correct me if I am wrong. This is all sooo confusing. :-((
> > >
> > >-SylviaXO
> > >
> > >_________________________________________________________________
> > >MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.
> > >http://join.msn.com/?page=features/virus
>
>
>

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

---

From: "Jim Guichard" <[email-masked]>
Date: Thu, 17 Apr 2003 15:55:06 -0400

Hi Sylvia,

> >Sent: Thursday, April 17, 2003 3:16 PM
> >To: [email-masked]

a PE may import any route that contains an RT value that has been configured
as eligible for import locally. So, if PE1 has VRF1 that has an import
statement saying "import any routes with RT value 1" then, if an update
arrives with route X and RT value 1, it will import it. This particular
route X might have been exported from PE2 in another AS using RT value 2 but
at the ASBR a rewrite occurred where RT value 2 got changed to RT value 1.
This is perfectly valid.

> >Also, does this mean that the BGP decision process now works

not exactly. I cannot speak for other implementations but in the Cisco case,
BGP best path is run against all routes within the BGP table and then a
further best path selection occurs during the import processing. So, if you
had RD1:1.1.1.1, and RD2:1.1.1.1 in the BGP table, they would be considered
as unique routes and therefore not comparable. However, if they both had RT
value 1 and VRF1 imports RT value 1, they will be compared during the import
and only 1 will be chosen as the best path.

> >There doesnt seem to be any mention of Route Distinguisher here :-((

and neither should there be 8^) the RT is what controls import/export - RD
has nothing to do with it.

> >now its all so confusing again :-((

no, it is actually the opposite. Because the normal structure of the RD is
ASN:value it should be unique between providers as they have their own ASN#.
They have to be unique otherwise you could get conflicting VPNv4 prefixes
e.g if SPa uses RD1:100 and so does SPb then how can they both export route
1.1.1.1 ? it would be exported as 1:100:1.1.1.1 within both AS's.

Jim