Hi Bala,
MY QUOTE:
>> IMHO Saying sites are in more than one VPN builds the wrong mental
>> picture unless they are physically connected as above.
Here I am referring to the example in the document where there are
actually three VPN's not two. Semantics maybe!
Lets look at the draft to make sure I use the correct terminology for
the technology:
Consider a set of "sites" which are attached to a common network
which we may call the "backbone". Let's apply some policy to create a
number of subsets of that set, and let's impose the following rule:
two sites may have IP interconnectivity over that backbone only if at
least one of these subsets contains them both.
The subsets we have created are "Virtual Private Networks" (VPN's).
Two sites have IP connectivity over the common backbone only if there
is some VPN which contains them both. Two sites which have no VPN in
common have no connectivity over that backbone.
If all the sites in a VPN are owned by the same enterprise, the VPN
is a corporate "intranet". If the various sites in a VPN are owned
by different enterprises, the VPN is an "extranet". A site can be in
more than one VPN; e.g., in an intranet and in several extranets. In
general, when we use the term VPN we will not be distinguishing
between intranets and extranets.
This is the definitions for this specific implementation,
draft-ietf-ppvpn-rfc2547bis-00.txt (so I guess I should stick to this in
future:)
Sticking to the draft definitions which uses set theory:
In the implementation the policy is defined by VRFs and Route targets.
If two sites have access to each other i.e. two sites have the routes
enabling them to communicate over the shared backbone, then they are in
the same VPN.
>So can I then say :
>
>1. A Site being a member of more than one VPN
>2. Extranet
>
>are two distinct things ?
I would say yes they are two distinct things. By the above definition
an extranet is at least 2 sites in 1 VPN, each site owned by a
different enterprise.
In general the tradition view is that a site in two VPN's is in an
Extranet. However, a site could be connected to more than 1 VPN and all
of the VPN's could be Intranets owned by the same enterprise.
For example: A single enterprise having various departments separates
them into VPNS. Some sites from one VPN can communicate with some sites
in other VPN's e.g. all probably need to communicate with accounts.
This is one example, (call it an Intranet-Extranet if you like).
> If so, is it common that case 1 happens in Intranet scenarios ?
I wouldn't like to say how common this is, however, I have seen this
type of implementation in large corporations or holding companies with
many subsidiaries/holdings.
With L3VPNs technology this type of implementation is simplified.
>Also I assume that case 1 can be implemented using JunOS even
>if the Site has only ONE CE Router, is that right ?
Yes, As long as the correct policy is in place to export and import
routes between sites/CEs then this is correct.
This is the important thing - no matter the semantics or terminology or
point of view, the Juniper solution can provided all of the
functionality described:)
Gary
>-----Original Message-----
>From: Bala Subrahmanyam Venkata [mailto:bsubrahm@doradosoftware.com]
>Sent: 17 October 2001 18:34
>To: Gary Tate
>Cc: juniper-nsp@puck.nether.net
>Subject: RE: [j-nsp] Extranet in MPLS VPNs
>
>
>Gary, you mentioned in your last email that:
>
>> IMHO Saying sites are in more than one VPN builds the wrong mental
>> picture unless they are physicall connected as above.
>>So can I then say :
>
>1. A Site being a member of more than one VPN
>2. Extranet
>
>are two distinct things ? If so, is it common that case 1 happens in
>Intranet scenarios ?
>
>Also I assume that case 1 can be implemented using JunOS even
>if the Site
>has only ONE CE Router, is that right ?
>
>TIA for your time ! EOM.
>
>
>/bala
>
>
>
>
>
>
>> >>Thanx for the response Gary. I have some questions along the
>> >>same lines.
>> >>
>> >>Does Juniper's implementation then mandates that for every
>> >>site that needs
>> >>to be in more than one VPN it must have its routes in a
>> >>separate VRF routing
>> >>instance ?
>> >
>> >No this is not the case.
>>
>> I meant to explain:) -
>>
>> For a Site to belong to VPN at least one of the CE's of this
>Site, must
>> be connected to at least one PE-VRF that is associated with that VPN.
>>
>> (Note CEs from the same site do not have to be connected to
>the Same PE,
>> and can be connected physically to different VPN's on the same PE or
>> different PE's).
>>
>> Valid Physical configurations:
>>
>> SITE 1
>>
>> CE1---- VRF VPNA (PE1)
>> |
>> CE2---- VRF VPNA (PE2)
>>
>> SITE 1
>>
>> CE1---- VRF VPNA (PE1)
>> `---- VRF VPNA (PE2)
>>
>> SITE 1
>>
>> CE1---- VRF VPNA (PE1)
>> |
>> CE2---- VRF VPNB (PE2)
>>
>> SITE 1
>>
>> CE1---- VRF VPNA (PE1)
>> `---- VRF VPNB (PE1)
>>
>>
>> IMHO Saying sites are in more than one VPN builds the wrong mental
>> picture unless they are physicall connected as above.
>>
>> For extranets (IMHO) It is better to state a case like Sites
>from VPN-A
>> need access to Sites in VPN-B and VPN-C. Sites in VPN-B and VPN-C do
>> not need to have access to each other.
>>
>> in this example Route targets would be used to import routes
>into VRFs
>> for sites on different PEs e.g.
>>
>> VRF for VPN A would import routes from sites in VPN-A (Target:VPN:A),
>> from Sites in VPN-B (Target:VPN:B) and Sites in VPN-C (Target:VPN:C)
>> which are connected to other PE's.
>>
>> VRF for VPN B Would import routes from Sites in VPN-B
>(Target:VPN:B) and
>> from Sites in VPN-A (Target:VPN:A), which are connected to
>other PE's.
>>
>> VRF for VPN C Would import routes from Sites in VPN-C
>(Target:VPN:C) and
>> from Sites in VPN-A (Target:VPN:A), which are connected to
>other PE's.
>>
>> So A and B can communicate
>> A and C can communicate
>> B and C cannot
>>
>> The RIB-groups perform the same functionality as Route Targets for
>> importing routes *between* Sites of different VPN's (VRFs),
>connected to
>> the *same* PE, which need to communicate with each other.
>>
>> I hope this is clear.
>>
>> >
>> >>For eg., if
>> >>
>> >>VPN A has sites Site1, Site2 and Site3
>> >>VPN B has Site1 and Site2
>> >>
>> >>(assumption: Site1, Site2 & Site3 are attached to the same PE
>> >>router. Each has its own CE Router in its site pointing to the PE.)
>> >>
>> >>then, it means Site1 & Site2 routes will be in a VRF
>routing instance
>> >>("S1-S2") and Site3 routes will be in another VRF routing
>> >>instance ("S3").
>> >
>> >Yes this is correct.
>> >
>> >>If Site1 again, becomes a part of some other VPN C, then a
>VRF routing
>> >>instance is created for Site1 ("S1"). Also "S1-S2" routing
>instance is
>> >>edited such that it contains only routes from Site2. VRF
>> >>routing instance "S3" will still contain routes from Site3.
>> >
>> >Yes this is esentially correct, if a site moves from one VPN
>> >to another
>> >then its configuration must be moved to the correct VRF.
>> >
>> >>And if there is a Site4 also having memberships to VPN A and
>> >>VPN B, then its
>> >>routes are in "S1-S2" VRF routing instance ??
>> >
>> >Correct.
>> >
>> >>> >P.S. A comment on the doc. Calling the sites as "VPNA", "VPNB"
>> >>> >and "VPNAB"
>> >>> >is confusing. Perhaps you can choose a better name that
>> >>describes the
>> >>> >scenario ?
>> >>>
>> >>> I will send this on the appropriate people internally. Do
>> >>you have any
>> >>> suggestions for names?
>> >>
>> >>Just call them Site A, Site B and Site AB. (BTW, I assume your
>> >>"VPNAB" is a
>> >>whole another site and does not mean that either Site A or
>> >>Site B CE Router
>> >>has an additional interface now on the PE...is that right ?)
>> >
>> >This is correct and now I see the confusion. I will pass this
>> >on to the
>> >author.
>> >
>> >>
>> >>EOM.
>> >>
>> >>/bala
>
>
This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:37 EDT