Subject: Route Target in BGP/MPLS IP VPN

From: "Fabien Verhaeghe" <[email-masked]>
Date: Wed, 26 Jan 2005 13:03:27 +0100

Hi,

I've got a question about the use of "Route Target" in BGP/MPLS IP VPN
Section 4.3.5 of  draft-ietf-l3vpn-rfc2547bis-03.txt states:

"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
Route Target values, one meaning "Hub" and one meaning "Spoke". At
the VRFs attached to the hub sites, "Hub" is the Export Target and
"Spoke" is the Import Target. At the VRFs attached to the spoke
site, "Hub" is the Import Target and "Spoke" is the Export Target."

If I have 3 sites A,B,C. one CE/PE pair for each site and one VRF per CE/PE.
Site A is the hub
Site B,C are spoke

In A VRF I would have the routes to both sites B and C
In B,C VRF I would only have routes to A since with BGP routes learned from IBGP are not
advertised to BGP peer in the same AS (RFC 1771 9.2.1).

So how can systems in site B communicate with systems in site C?

I guess I misunderstood something, and PE connected to site A will actually advertised routes received from site C
to site B. But it seems inconsistent with RFC 1771 9.2.1.

Can someone explain to me please?

Thanks
Fabien

---

From: "Kulmala, Marko" <[email-masked]>
Date: Wed, 26 Jan 2005 16:10:26 +0200

Hi,
 
It seems that many times people mean different thing when they talk
about hub and spoke VPN.
This is my opinion:
- When spokes have connectivity through hub site then it is real hub and
spoke VPN.
- If spokes have no connectivity at all between each other then they do
not belong to same VPN from IP connectivity point of view.
The topology that Taras described (no connectivity between spokes) is in
my mind collection of overlapping VPNs.
Hub site and each spoke site form separate VPN. So, there are so many
VPNs as there are spokes and hub site belongs to all those VPNs.
 
Marko

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
	Sent: 26. tammikuuta 2005 15:43
	To: [email-masked]; [email-masked]
	Subject: RE: Route Target in BGP/MPLS IP VPN

	Fabien: "What I understood is that Spoke can not communicate
DIRECTLY with each other. They have
	to go through the Hub."
	Taras:
	No, spokes can not communicate with each other even through hub.
That is idea of hub&spoke VPN - it is VPN with PARTIAL connectivity.
	Suppose, you have a large data center and some clients of data
center. Clients want to reach data center, but they don't want have ANY
connectivity with other clients due security reasons, for example.
	 
	As to BGP routing, I may say, that PE router on site B (spoke
Site) may receive all routes, including routes from site C. But it does
not install routes to site C in its VRF routing table. Route Target of
route from site C do not mach VRF "import" set of route target
attributes.
	 
	Taras

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Fabien Verhaeghe
	Sent: Wednesday, January 26, 2005 4:15 PM
	To: [email-masked]
	Subject: Re: Route Target in BGP/MPLS IP VPN

	Thanks for your answer Taras ,
	 
	What I understood is that Spoke can not communicate DIRECTLY
with each other. They have
	to go through the Hub. 
	 
	But if a packet is received at PE C (from the CE) for a
destination address which is in site B he won't
	have any route that says to go through the Hub.
	 
	I'm talking about the routing between PEs when I make a
reference to RFC1771 9.2.1. Not between CE and PE.
	 
	Fabien
	 
	----- Original Message ----- 
	From: [email-masked] 
	To: [email-masked] ; [email-masked] 
	Sent: Wednesday, January 26, 2005 1:29 PM
	Subject: RE: Route Target in BGP/MPLS IP VPN

	Hi,

	The main idea of Hub&spoke is the following: spokes may
communicate with hub, but spokes can NOT communicate with each other.

	So, everything seems to be ok. Site A can communicate with site
B & C, and sites B & C can't communicate with each other.

	As I can understand we may use: RIPv2, OSPF and EBGP to make
routing between PE and CE. So RFC1771 9.2.1 it's not our case.

	Cheers.

	Taras

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Fabien Verhaeghe
	Sent: Wednesday, January 26, 2005 3:03 PM
	To: [email-masked]
	Subject: Route Target in BGP/MPLS IP VPN

	Hi,
	 
	I've got a question about the use of "Route Target" in BGP/MPLS
IP VPN
	Section 4.3.5 of  draft-ietf-l3vpn-rfc2547bis-03.txt states:
	 
	"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
	Route Target values, one meaning "Hub" and one meaning "Spoke".
At
	
	the VRFs attached to the hub sites, "Hub" is the Export Target
and
	"Spoke" is the Import Target. At the VRFs attached to the spoke
	
	site, "Hub" is the Import Target and "Spoke" is the Export
Target."
	 
	If I have 3 sites A,B,C. one CE/PE pair for each site and one
VRF per CE/PE.
	Site A is the hub
	Site B,C are spoke
	 
	In A VRF I would have the routes to both sites B and C
	In B,C VRF I would only have routes to A since with BGP routes
learned from IBGP are not
	advertised to BGP peer in the same AS (RFC 1771 9.2.1).

	I guess I misunderstood something, and PE connected to site A
will actually advertised routes received from site C
	to site B. But it seems inconsistent with RFC 1771 9.2.1.

	Thanks
	Fabien

	 

============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================

---

From: [email-masked]
Date: Wed, 26 Jan 2005 19:10:38 +0300

I agree with you!
Btw, in RFC 2547 hub&spoke VPN was described not so deep.
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.
 
Who knows, may be authors of draft-ietf-l3vpn-rfc2547bis-03.txt will describe h&s VPN more deeply.
 
Taras

From: Fabien Verhaeghe [mailto:[email-masked]] 
Sent: Wednesday, January 26, 2005 6:48 PM
To: Юшков Тарас; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: Route Target in BGP/MPLS IP VPN

Seems clear to me now.
 
Maybe in draft-ietf-l3vpn-rfc2547bis-03.txt it should explicitly be said that the spoke and hub here does not offer connectivity 
between the spoke.
 
Thanks all
Fabien
 
----- Original Message ----- 
From: [email-masked] 
To: [email-masked] ; [email-masked] 
Cc: [email-masked] 
Sent: Wednesday, January 26, 2005 3:34 PM
Subject: RE: Route Target in BGP/MPLS IP VPN

Jim,
Fabien asked us about example in draft-ietf-l3vpn-rfc2547bis-03.txt (4.3.5). In this examples authors show us how to build hub&spoke VPN without any connectivity between spokes.
Btw, I agree with you. There is another kind of VPN called hub&spoke, where traffic between spokes goes through hub. But it is not the case of 4.3.5.
 
Marko,
As I can understand if you want to build hub&spoke VPN with connectivity between spokes through hub, you have to organize one VPN per spoke. Each VPN must be "point-to-point" (including one spoke site and separate (sub)interface on hub site). Than you must organize routing between these VPN on CE on hub Site.
So, we have as many different VPNs as spoke sites, you want to connect to hub.
 
Cheers
Taras

From: jguichar [mailto:[email-masked]] 
Sent: Wednesday, January 26, 2005 5:11 PM
To: Юшков Тарас; [email-masked]; [email-masked]
Subject: RE: Route Target in BGP/MPLS IP VPN

Not exactly. It is actually both of these things and connectivity between spokes is driven by configuration. In one model spokes cannot communicate, in another they can (preferably via a firewall at the hub). 

Jim Guichard CCIE# 2069
System Architect - MPLS Technologies

ITD Boxborough
DD: 978-936-1586
Cell: 978-302-0481 

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: Wednesday, January 26, 2005 8:43 AM
	To: [email-masked]; [email-masked]
	Subject: RE: Route Target in BGP/MPLS IP VPN

	Fabien: "What I understood is that Spoke can not communicate DIRECTLY with each other. They have
	to go through the Hub."
	Taras:
	No, spokes can not communicate with each other even through hub. That is idea of hub&spoke VPN - it is VPN with PARTIAL connectivity.
	Suppose, you have a large data center and some clients of data center. Clients want to reach data center, but they don't want have ANY connectivity with other clients due security reasons, for example.
	 
	As to BGP routing, I may say, that PE router on site B (spoke Site) may receive all routes, including routes from site C. But it does not install routes to site C in its VRF routing table. Route Target of route from site C do not mach VRF "import" set of route target attributes.
	 
	Taras

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Fabien Verhaeghe
	Sent: Wednesday, January 26, 2005 4:15 PM
	To: [email-masked]
	Subject: Re: Route Target in BGP/MPLS IP VPN

	What I understood is that Spoke can not communicate DIRECTLY with each other. They have
	to go through the Hub. 
	 
	But if a packet is received at PE C (from the CE) for a destination address which is in site B he won't
	have any route that says to go through the Hub.
	 
	I'm talking about the routing between PEs when I make a reference to RFC1771 9.2.1. Not between CE and PE.
	 
	Fabien
	 
	----- Original Message ----- 
	From: [email-masked] 
	To: [email-masked] ; [email-masked] 
	Sent: Wednesday, January 26, 2005 1:29 PM
	Subject: RE: Route Target in BGP/MPLS IP VPN

	Hi,

	The main idea of Hub&spoke is the following: spokes may communicate with hub, but spokes can NOT communicate with each other.

	So, everything seems to be ok. Site A can communicate with site B & C, and sites B & C can't communicate with each other.

	As I can understand we may use: RIPv2, OSPF and EBGP to make routing between PE and CE. So RFC1771 9.2.1 it's not our case.

	Cheers.

	Taras

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Fabien Verhaeghe
	Sent: Wednesday, January 26, 2005 3:03 PM
	To: [email-masked]
	Subject: Route Target in BGP/MPLS IP VPN

	Hi,

	

	 

	 
	 
	Thanks
	Fabien

---

From: "Schliesser, Benson" <[email-masked]>
Date: Wed, 26 Jan 2005 10:14:21 -0600

If the Hub advertises an aggregate prefix (0/0, 10/8, etc.) then it should support spoke-spoke traffic, per the draft. (section 5 refers back to 4.3.2, which explains this)

Cheers,
-Benson

		From: [email-masked] [mailto:[email-masked]] On Behalf Of Fabien Verhaeghe
		Sent: Wednesday, January 26, 2005 3:48 PM
		To: [email-masked]; [email-masked]; [email-masked]
		Cc: [email-masked]
		Subject: Re: Route Target in BGP/MPLS IP VPN

		Seems clear to me now.

				Thanks all
				Fabien
		 
		----- Original Message ----- 
		From: [email-masked] 
		To: [email-masked] ; [email-masked] 
		Cc: [email-masked] 
		Sent: Wednesday, January 26, 2005 3:34 PM
		Subject: RE: Route Target in BGP/MPLS IP VPN

		Jim,
		 
		Marko,
		 
		Cheers
		Taras

		Jim Guichard CCIE# 2069
		
		ITD Boxborough
		DD: 978-936-1586
		Cell: 978-302-0481 

			 
			 
			Taras

			 

			 
			Fabien
			 
			----- Original Message ----- 
			From: [email-masked] 
			To: [email-masked] ; [email-masked] 
			Sent: Wednesday, January 26, 2005 1:29 PM
			Subject: RE: Route Target in BGP/MPLS IP VPN

			Hi,

			Cheers.

			Taras

						Hi,

			 

			 

			Thanks
			Fabien

---

From: "Kulmala, Marko" <[email-masked]>
Date: Thu, 27 Jan 2005 08:25:04 +0200

Benson,

Yes, it does support spoke-spoke traffic in that way but spoke-spoke traffic does not go through customer hub site instead it would only through hub PE.
This is because VRF (import RT=hub, export RT=spoke) in hub PE has also those more specific routes to the spokes.
Thus, from customer point of view, this is full mesh VPN.

To make the spoke-spoke traffic go through customer hub site a bit more complex implementation is needed. 

Marko

> -----Original Message-----
> From: Schliesser, Benson [mailto:[email-masked]] 
> Sent: 26. tammikuuta 2005 18:14
> To: Fabien Verhaeghe; [email-masked]; 
> [email-masked]; Kulmala, Marko
> Cc: [email-masked]
> If the Hub advertises an aggregate prefix (0/0, 10/8, etc.) 
> then it should support spoke-spoke traffic, per the draft. 
> (section 5 refers back to 4.3.2, which explains this)
> 
> Cheers,
> -Benson
> 	 
> 	
> 	
> 
> 		From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Fabien Verhaeghe
> 		Maybe in draft-ietf-l3vpn-rfc2547bis-03.txt it 
> should explicitly be said that the spoke and hub here does 
> not offer connectivity 
> 		between the spoke.
> 		 
> 				Thanks all
> 				Fabien
> 		 
> 		Fabien asked us about example in 
> draft-ietf-l3vpn-rfc2547bis-03.txt (4.3.5). In this examples 
> authors show us how to build hub&spoke VPN without any 
> connectivity between spokes.
> 		Btw, I agree with you. There is another kind of 
> VPN called hub&spoke, where traffic between spokes goes 
> through hub. But it is not the case of 4.3.5.
> 		 
> 		Marko,
> 		As I can understand if you want to build 
> hub&spoke VPN with connectivity between spokes through hub, 
> you have to organize one VPN per spoke. Each VPN must be 
> "point-to-point" (including one spoke site and separate 
> (sub)interface on hub site). Than you must organize routing 
> between these VPN on CE on hub Site.
> 		To: Юшков Тарас; 
> [email-masked]; [email-masked]
> 		Not exactly. It is actually both of these 
> things and connectivity between spokes is driven by 
> configuration. In one model spokes cannot communicate, in 
> another they can (preferably via a firewall at the hub). 
> 		 
> 
> 		Jim Guichard CCIE# 2069
> 			From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> 						Fabien: "What I 
> understood is that Spoke can not communicate DIRECTLY with 
> each other. They have
> 			to go through the Hub."
> 			Taras:
> 						No, spokes can 
> not communicate with each other even through hub. That is 
> idea of hub&spoke VPN - it is VPN with PARTIAL connectivity.
> 			Suppose, you have a large data center 
> and some clients of data center. Clients want to reach data 
> center, but they don't want have ANY connectivity with other 
> clients due security reasons, for example.
> 			 
> 			As to BGP routing, I may say, that PE 
> router on site B (spoke Site) may receive all routes, 
> including routes from site C. But it does not install routes 
> to site C in its VRF routing table. Route Target of route 
> from site C do not mach VRF "import" set of route target attributes.
> 			 
> 			Taras
> 
> 			From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Fabien Verhaeghe
> 			What I understood is that Spoke can not 
> communicate DIRECTLY with each other. They have
> 			to go through the Hub. 
> 			 
> 			But if a packet is received at PE C 
> (from the CE) for a destination address which is in site B he won't
> 			I'm talking about the routing between 
> PEs when I make a reference to RFC1771 9.2.1. Not between CE and PE.
> 			 
> 			Fabien
> 			 
> 			The main idea of Hub&spoke is the 
> following: spokes may communicate with hub, but spokes can 
> NOT communicate with each other.
> 
> 			So, everything seems to be ok. Site A 
> can communicate with site B & C, and sites B & C can't 
> communicate with each other.
> 
> 			As I can understand we may use: RIPv2, 
> OSPF and EBGP to make routing between PE and CE. So RFC1771 
> 9.2.1 it's not our case.
> 
> 			 
> 
> 			Cheers.
> 
> 			Taras
> 
> 			
> 			From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Fabien Verhaeghe
> 			Section 4.3.5 of  
> draft-ietf-l3vpn-rfc2547bis-03.txt states:
> 			 
> 						the VRFs 
> attached to the hub sites, "Hub" is the Export Target and
> 						site, "Hub" is 
> the Import Target and "Spoke" is the Export Target."
> 			 
> 			In B,C VRF I would only have routes to 
> A since with BGP routes learned from IBGP are not
> 			I guess I misunderstood something, and 
> PE connected to site A will actually advertised routes 
> received from site C

---

From: [email-masked]
Date: Thu, 27 Jan 2005 12:59:02 +0100

You could do this using two VRFs. 

I don't think it is required though (but this could be implementation
dependent). As far as I understand this, a PE never passes on VPN
traffic received from one PE to another PE (i.e. PE has no transit
function). Thus even though the VRF on PE A has more specific entries
for let's say site C in the example below, these would not be valid for
traffic received from another PE -e.g. PE B (because the next-hop is a
PE as well) and the PE would/should only consider 'CE' next-hops as
valid.

cheers,
	Eduard

> From: Bala Venkata [mailto:[email-masked]] 
> Sent: donderdag 27 januari 2005 10:06
> To: Metz, E.T.
> Cc: [email-masked]; [email-masked]
> Eduard-
> When you say
> "This will result in traffic from CE-B to CE-C to go like 
> this CE-B -> 
> PE-B -> PE-A -> CE-A -> PE-A -> PE-C -> CE-C."
> 
> are you assuming that PE-A has two VRF's ? One to import the routes
> from the spokes and the other two export its (CE-A's) routes to them ?
> Just wanted to be clear on your "PE-A -> CE-A -> PE-A" portion.
> 
> (btw, it is confusing to call everything "hub and spoke" - I vaguely
> remember coming across the phrase "Central Services" must be in 
> Guichard's book...?)
> 
> 
> Thanks !
> 
> 
> [email-masked] wrote:
> >  
> > In a hub-and-spoke VPN, spoke-sites (assuming these do not 
> share a VRF
> > when connected to the same PE) cannot communicate with eachother
> > directly, i.e. spoke-PE to spoke-PE. If spoke-sites need to 
> communicate
> > with eachother the communication path indeed goes (must go) 
> through the
> > hub-CE, the underlying requirement could e.g. be that 
> traffic between B
> > and C needs to pass a firewall at A. Note that the hub-PE 
> never acts as
> > a 'transit' node in this case. To achieve spoke-spoke 
> communication you
> > either need to advertise an aggregate (covering the spoke-subnets or
> > entire VPN) or a default from the hub-site (CE), and ensure that the
> > hub-CE has specific routes to the spoke-CEs pointing to the 
> hub-PE. This
> > will result in traffic from CE-B to CE-C to go like this 
> CE-B -> PE-B ->
> > PE-A -> CE-A -> PE-A -> PE-C -> CE-C.
> > 
> > Hope this helps.
> > 
> > cheers,
> >     Eduard
> > 
> >     Sent: woensdag 26 januari 2005 14:15
> >     To: [email-masked]

---

From: "Schliesser, Benson" <[email-masked]>
Date: Thu, 27 Jan 2005 07:10:17 -0600

Marko-

Yes, from a customer perspective there is complete reachability between all sites in the VPN. Though, complete reachability and full-mesh connectivity are different things.

The rationale I had in mind, from a SP perspective, for creating a sub-full-mesh topology while maintaining complete reachability in the VPN, is so that the Hub PE node could be used to provide some layered services, that might be unique to it amongst PEs. (Firewall, IDS, content caching or filtering, QOS policy, etc.)

I agree though, that making spoke-spoke traffic traverse a "Hub" CE is a bit more difficult. A customer who wants this sort of topology is just as well off with CE-CE tunnels (i.e. GRE) or a pt-pt L2 network (i.e. FR PW/PVC).

Cheers,
-Benson

> From: Kulmala, Marko [mailto:[email-masked]] 
> Sent: Thursday, January 27, 2005 6:25 AM
> To: Schliesser, Benson; Fabien Verhaeghe; 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Yes, it does support spoke-spoke traffic in that way but 
> spoke-spoke traffic does not go through customer hub site 
> instead it would only through hub PE.
> This is because VRF (import RT=hub, export RT=spoke) in hub 
> PE has also those more specific routes to the spokes.
> To make the spoke-spoke traffic go through customer hub site 
> a bit more complex implementation is needed. 
> 
> Marko
> 
> > To: Fabien Verhaeghe; [email-masked]; [email-masked]; 
> > Kulmala, Marko
> > Cc: [email-masked]
> > If the Hub advertises an aggregate prefix (0/0, 10/8, etc.) then it 
> > should support spoke-spoke traffic, per the draft.
> should explicitly be 
> > said that the spoke and hub here does not offer connectivity
> > 		between the spoke.
> > 		 
> > 				Thanks all
> > 				Fabien
> > 		 
> > draft-ietf-l3vpn-rfc2547bis-03.txt (4.3.5). In this 
> examples authors 
> > show us how to build hub&spoke VPN without any connectivity between 
> > spokes.
> VPN called 
> > hub&spoke, where traffic between spokes goes through hub. But it is 
> > not the case of 4.3.5.
> > 		 
> > 		Marko,
> hub&spoke VPN with 
> > connectivity between spokes through hub, you have to 
> organize one VPN 
> > per spoke. Each VPN must be "point-to-point" (including one 
> spoke site 
> > and separate (sub)interface on hub site). Than you must organize 
> > routing between these VPN on CE on hub Site.
> > 		So, we have as many different VPNs as spoke 
> sites, you want to 
> > connect to hub.
> > 		 
> > 		Cheers
> > 		Taras
> > 
> things and connectivity 
> > between spokes is driven by configuration. In one model 
> spokes cannot 
> > communicate, in another they can (preferably via a firewall at the 
> > hub).
> > 		 
> > 
> > 		Jim Guichard CCIE# 2069
> each other. 
> > They have
> > not communicate with each other even through hub. That is idea of 
> > hub&spoke VPN - it is VPN with PARTIAL connectivity.
> and some clients of data 
> > center. Clients want to reach data center, but they don't want have 
> > ANY connectivity with other clients due security reasons, 
> for example.
> > 			 
> router on site B (spoke Site) 
> > may receive all routes, including routes from site C. But 
> it does not 
> > install routes to site C in its VRF routing table. Route Target of 
> > following: spokes may communicate with hub, but spokes can NOT 
> can communicate with site B & 
> > C, and sites B & C can't communicate with each other.
> > 
> > 			I've got a question about the use of 
> "Route Target" in BGP/MPLS IP 
> > VPN
> > 			Section 4.3.5 of
> > 			"Alternatively, suppose one desired, 
> for whatever reason, to create 
> > a
> > 			If I have 3 sites A,B,C. one CE/PE pair 
> for each site and one VRF 
> > per CE/PE.
> > 			Site A is the hub
> > 			Site B,C are spoke
> > 			 
> PE connected to site A will 
> > actually advertised routes received from site C
> intended recipient, you are hereby notified that any 
> reproduction, dissemination or distribution of this 
> communication is strictly prohibited. If you have received 
> this communication in error, please notify us immediately by 
> replying to the message and deleting it from your computer. 
> Thank you. Tellabs

---

From: "Schliesser, Benson" <[email-masked]>
Date: Thu, 27 Jan 2005 07:31:22 -0600

[email-masked]:
> As far as I understand this, a PE never passes on VPN
> traffic received from one PE to another PE (i.e. PE has
> no transit function). 
> [...]
> (because the next-hop is a PE as well) and the PE
> would/should only consider 'CE' next-hops as valid.

While this is true for certain types of L2 VPNs, it's not forbidden in
2547bis. Per section 5 and 4.3.2, there are times when a VRF lookup is
performed on traffic incoming from a PE-PE link. Presumably, that
traffic could then be forwarded via a different PE-PE link.

I'll grant that it might be an implementation specific behavior. Perhaps
the I-D could be more specific.

Cheers,
-Benson

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of [email-masked]
> Sent: Thursday, January 27, 2005 11:59 AM
> To: [email-masked]
> Cc: [email-masked]
> I don't think it is required though (but this could be 
> implementation dependent). As far as I understand this, a PE 
> never passes on VPN traffic received from one PE to another 
> PE (i.e. PE has no transit function). Thus even though the 
> VRF on PE A has more specific entries for let's say site C in 
> the example below, these would not be valid for traffic 
> received from another PE -e.g. PE B (because the next-hop is 
> a PE as well) and the PE would/should only consider 'CE' 
> next-hops as valid.
> 
> cheers,
> 	Eduard
>