Subject: Re:

From: "alok" <[email-masked]>
Date: Tue, 15 Apr 2003 19:10:19 +0530

then what does "VPN of origin attribute" indicate?

----- Original Message -----
From: <[email-masked]>
Sent: Tuesday, April 15, 2003 7:42 PM

> Microsoft Mail Internet Headers Version 2.0
> X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
> content-class: urn:content-classes:message
> MIME-Version: 1.0
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> Subject: RE:
> Date: Tue, 15 Apr 2003 14:36:04 +0100
> Message-ID:
<[email-masked]>
> X-MS-Has-Attach:
> X-MS-TNEF-Correlator:
> Thread-Index: AcMDUO31DVnmqpEkTb+89O6PCkAKYAAAH1Jg
> From: <[email-masked]>
> To: <[email-masked]>
> Return-Path: [email-masked]
> X-OriginalArrivalTime: 15 Apr 2003 13:36:05.0242 (UTC)
FILETIME=[F6B03DA0:01C30353]
>
> Alok,
>
> The IPv4 address + RD =3D VPNv4 address and is carried in MP-BGP as a =
> 96-bit route prefix.=20
>
> The RT is not appended to the IPv4 address, instead it is carried in an =
> extended BGP community with a value of 2 for the high-order 16 bits =
> meaning MPLS VPN RT.
>
> For the VPN mechanism to work:
>
> 1. The customer address must be made globally unique (to support =
> overlapping addresses) so must have a 64-bit value (lets call it "Value =
> X") prepended to it.
>
> 2. There must be a way of identifying which VPN a route belongs to.=20
>
> Now, there is nothing stopping someone writing an implementation which =
> uses Value-X for filtering to determine which VPN the route belongs to =
> instead of using an extended BGP community. However, because there is a =
> 1:1 mapping between the route and the VPN, the route could only be =
> imported into one VPN and therefore each customer could only be a =
> member of one VPN.
>
> Regards,
>
> Richard
>
>
>
>
> -----Original Message-----
> From: alok [mailto:[email-masked]]
> Sent: 15 April 2003 14:17
> To: Spencer,R,Richard,XGH5 R
> Subject: Re:=20
>
>
> i want to know why not..
> im not questioning what was made...im asking about what is "being =
> made"...
>
> -rgds
> Alok
> ----- Original Message -----
> From: <[email-masked]>
> Sent: Tuesday, April 15, 2003 7:05 PM
>
>
> > Microsoft Mail Internet Headers Version 2.0
> > X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
> > content-class: urn:content-classes:message
> > MIME-Version: 1.0
> > Content-Type: text/plain;
> > charset=3D"iso-8859-1"
> > Content-Transfer-Encoding: quoted-printable
> > Subject: RE: RD in 2547 bis
> > Date: Tue, 15 Apr 2003 13:59:07 +0100
> > Message-ID:
> <[email-masked]>
> > X-MS-Has-Attach:
> > X-MS-TNEF-Correlator:
> > Thread-Topic: RD in 2547 bis
> > Thread-Index: AcMDSI6WQTL6q5dkQtaxcNV/MIBniwAAZgpA
> > From: <[email-masked]>
> > To: <[email-masked]>,
> > <[email-masked]>
> > Return-Path: [email-masked]
> > X-OriginalArrivalTime: 15 Apr 2003 12:59:08.0312 (UTC)
> FILETIME=3D[CD4B9180:01C3034E]
> >
> > Alok
> >
> > 1. The ONLY purpose of the RD is to transform non-unique 32-bit =3D
> > customer IPv4 addresses into unique 96-bit VPNv4 addresses. The RD =
> =3D
> > COULD be used to filter (i.e. be used as a VPN identifier) but this =
> =3D
> > would not allow support for customers belonging to multiple VPNs.
> >
> > The ONLY purpose of the RT is to indicate which VPN a customer =
> address =3D
> > belongs to. Any number of RT's can be attached to a single VPNv4 =
> route =3D
> > to identify multiple VPN memberships but ONLY 1 RD can be attached to =
> a =3D
> > customer route.
> >
> > 2. A VPNv4 route DOES NOT =3D3D IPv4 + RT. A VPNv4 route =3D3D IPv4 + =
> RD.
> >
> > If you are still confused the mechanisms described in 2547 are well =
> =3D
> > documented within the IETF pages and elsewhere on the net.
> >
> > Richard
> >
> > -----Original Message-----
> > From: alok [mailto:[email-masked]]
> > Sent: 15 April 2003 13:00
> > To: [email-masked]
> > Subject: Re: RD in 2547 bis
> >
> >
> > hi,
> >
> > am still confused....
> >
> > I would like to know
> > 1. can RD be used to filter ...if not why....
> > 2. i say a VPNv4 route =3D3D IPv4+RT ... why not?
> >
> > -rgds
> > Alok
> > ----- Original Message -----
> > From: Apcar, Jeff <[email-masked]>
> > To: alok <[email-masked]>; <[email-masked]>
> > Sent: Tuesday, April 15, 2003 5:01 PM
> > Subject: RE: RD in 2547 bis
> >
> >
> > > In 2547bis the mechansim to pass VPN addresses with between PE =3D
> > routers is
> > > MultiProtocol-BGP. MP-BGP's job is to exchange the VPN routes, but =
> it =3D
> > is
> > not
> > > interested  in what VPN these addresses belong to. YOu need the RD =
> to =3D
> > make
> > > the VPN addresses unique to MP-BGP, and consequently to the SP =3D
> > domain. For
> > > example, suppose you had VPN RED and VPN GREEN on different =3D
> > PE-routers and
> > > they both originated an address from RFC1918, like 10.2.1.0/24, =
> then =3D
> > if
> > they
> > > were not uniquely identified by an RD, when the two 10.2.1.0/24 =3D
> > addresses
> > > arrived at the same remote PE-router, BGP would simply do its best =
> =3D
> > path
> > > selection algorithm on the two addresses and only pick one. Hence =
> you
> > would
> > > lose the other. If they are both unique with an RD then it is =
> called =3D
> > a
> > VPNv4
> > > address. BGP will see them as unique and the MP-BGP peer on the =3D
> > remote
> > > PE-router would accept both. Then to decide which VPN to place the
> > received
> > > address in we use the RT, which is an extended community attribute.
> > >
> > > You need the RD to make the VPN addresses to unique MP-BGP you need =
> =3D
> > the RT
> > > to select which VPN to include the address (the RT allows you to =
> =3D
> > create
> > > Intranets, Extranets etc...)
> > >
> > > > -----Original Message-----
> > > > From: alok [mailto:[email-masked]]
> > > > Sent: Tuesday, 15 April 2003 9:08 PM
> > > > To: [email-masked]
> > > > Subject: Re: RD in 2547 bis
> > > >
> > > >
> > > > lets assume there was no RT
> > > >
> > > > could we filter on RD?
> > > >
> > > > if we can do that, then why not vice versa?
> > > >
> > > > ----- Original Message -----
> > > > From: <[email-masked]>
> > > > To: <[email-masked]>; <[email-masked]>
> > > > Sent: Tuesday, April 15, 2003 4:31 PM
> > > > Subject: RE: RD in 2547 bis
> > > >
> > > >
> > > > > Hi,
> > > > >
> > > > > The overlapping address problem is that different VPNs that
> > > > is provided
> > > > > by one operator can have the same private address space.
> > > > For instance,
> > > > > two VPNs may have several identical addresses.  The RD
> > > > makes VPN routes
> > > > > unique for each VPN.
> > > > >
> > > > > The RT is used to determine how to import and export the
> > > > VPN routes into
> > > > > the relevant VRFs.
> > > > >
> > > > > There are many in mailing list who can answer better and
> > > > more pedogical
> > > > > then me.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Nhat Thanh
> > > > >
> > > > > -----Original Message-----
> > > > > From: alok [mailto:[email-masked]]
> > > > > Sent: den 15 april 2003 12:55
> > > > > To: [email-masked]
> > > > > Subject: Re: RD in 2547 bis
> > > > >
> > > > >
> > > > > what is the "overlapping address problem"?
> > > > >
> > > > > why isnt RT sufficient to identify the ipv4 prefix uniquely?
> > > > >
> > > > > why "both"?
> > > > >
> > > > > ----- Original Message -----
> > > > > From: <[email-masked]>
> > > > > To: <[email-masked]>; <[email-masked]>
> > > > > Sent: Tuesday, April 15, 2003 4:20 PM
> > > > > Subject: RE: RD in 2547 bis
> > > > >
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > The purpose of RD is simply resolve the overlapping
> > > > address problem
> > > > > > in VPN context.
> > > > > >
> > > > > > regards,
> > > > > >
> > > > > > /Nhat Thanh
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: alok [mailto:[email-masked]]
> > > > > > Sent: den 15 april 2003 12:37
> > > > > > To: [email-masked]
> > > > > > Subject: RD in 2547 bis
> > > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I know this has been asked time and again, but its still
> > > > confusing me
> > > > > >
> > > > > > what is the purpose of RD ?
> > > > > >
> > > > > > -rgds
> > > > > > Alok
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
> >
> >
> >
>
>