Subject: RE: Re: Advertising Routes to a PE

From: [email-masked]
Date: Wed, 30 Jul 2003 15:46:51 +0300

I think that below configuration works even if route 2:2::10.0.0.0/8 is 
not advertised since export RTs in the VRF A and B are the same.

But what if VRF B has different export RTs than VRF A ? 
Then I think it is necessary to advertise route 2:2::10.0.0.0/8 as well.

Conceptually I think that both routes should be advertised. 
What is reason not to do so ?

Best Regards,
Marko Kulmala

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 30. heinäkuuta 2003 12:35
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Advertising Routes to a PE
> 
> 
> 
> Yes this is correct :). Advertising of locally imported routes should
> not be allowed.
> 
> R.
> 
> > John Smith wrote:
> > 
> > Hi,
> > 
> > I have a conceptual doubt.
> > 
> > I have two VRFs A and B defined on a PE router. Both of 
> them have overlapping Route
> > Targets.
> > 
> > My basic config goes something like this.
> > 
> > !
> > ip vrf A
> >  rd 1:1
> >  route-target both 100:100
> > !
> > ip vrf B
> >  rd 2:2
> >  route-target both 100:100
> > !
> > 
> > Now i learn a route (say 10.0.0.0/8) from VRF A. I 
> redistribute it into VRF B too as they
> > have overlapping RTs.
> > 
> > Now when this PE router peers up with another PE peer it 
> will announce 1:1::10.0.0.0/8
> > along with the associated Route Targets. Should it also 
> advertise 2:2::10.0.0.0/8 to the
> > remote PE router?
> > 
> > I have a router from one major vendor which is not doing 
> this. I see it only advertising
> > 1:1::10.0.0.0/8
> > 
> > Is this correct?
> > 
> > Regards,
> > Smith
> > 
> > 
> ______________________________________________________________
> __________
> > Want to chat instantly with your online friends?  Get the 
> FREE Yahoo!
> > Messenger http://uk.messenger.yahoo.com/
> 
> 

============================================================
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: Dan Tappan <[email-masked]>
Date: Wed, 30 Jul 2003 09:35:56 -0400

>But what if VRF B has different export RTs than VRF A ?

In the scenario you've described the route in VRF B is not exported, so 
export RTs do not apply.

In this context 'exported' means "redistributed from a VRF RIB into BGP, 
for purposes of producing a vpnv4 route for advertisement to other PEs". 
So, as you can see, the route in VRF B is _imported_ (installed into the 
proper RIB by BGP based on the RTs associated with the route) but there is 
no reason to export it.

At an architectural level, the BGP advertisement needs to be based on which 
vpnv4 routes are produced on a given PE, which is a separate issue from 
what VRF RIB a route is installed into. The vpnv4 route is based on the RIB 
entry which exported the route.  (the fact that some implementations 
internally generate a vpnv4 route for VRF B, for purposes of book-keeping, 
is separate from the 2547 architecture).

If you have a need to control the RT set which is associated with a vpnv4 
route, then there are other mechanisms to do so.

If one followed your suggested model consistently then every route received 
by PE and imported into multiple VRFs would result in the re-advertisement 
of multiple vpnv4 routes. This would both be a violation of iBGP 
procedures, and would result in an explosion of routing information.

---

From: Enke Chen <[email-masked]>
Date: Wed, 30 Jul 2003 09:56:50 -0700

Hi, Dan:

> Message-Id: <[email-masked]>
> Date: Wed, 30 Jul 2003 09:35:56 -0400
> To: [email-masked]
> From: Dan Tappan <[email-masked]>
> Subject: RE: Re: Advertising Routes to a PE
> Cc: [email-masked], [email-masked], [email-masked]
> In-Reply-To: <H000037a03938ef1.1059569210.maile01.tellabs.fi@MHS>
> 
> In the scenario you've described the route in VRF B is not exported, so=20
> export RTs do not apply.
> 
> In this context 'exported' means "redistributed from a VRF RIB into BGP,=20
> for purposes of producing a vpnv4 route for advertisement to other PEs".=20
> So, as you can see, the route in VRF B is _imported_ (installed into the=20
> proper RIB by BGP based on the RTs associated with the route) but there is=
> no reason to export it.
> 
> At an architectural level, the BGP advertisement needs to be based on which=
> vpnv4 routes are produced on a given PE, which is a separate issue from=20
> what VRF RIB a route is installed into. The vpnv4 route is based on the RIB=
> entry which exported the route.  (the fact that some implementations=20
> internally generate a vpnv4 route for VRF B, for purposes of book-keeping,=
> If you have a need to control the RT set which is associated with a vpnv4=20
> If one followed your suggested model consistently then every route received=
> by PE and imported into multiple VRFs would result in the re-advertisement=

In this particular case, the imported route is locally sourced (and is not
from iBGP). The normal BGP procedure would not disallow its advertisement,
would it?

To answer the question (raised by Marko?):

It seems to me that certain intended VPN associations would not be achieved
without advertsing the locally imported (and locally sourced) route.

-- Enke

> > > Sent: 30. hein=E4kuuta 2003 12:35
> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> 
>

---

From: Dan Tappan <[email-masked]>
Date: Wed, 30 Jul 2003 16:00:50 -0400

>without advertsing the locally imported (and locally sourced) route.

Hi Enke,

Look at it another way. Let's say the configuration is you hypothesize, 
maybe as below:
  ip vrf A
   rd 1:1
   route-target both 100:100
  !
  ip vrf B
   rd 2:2
   route-target both 100:100
   route-target export 100:200
!

The question is: with the above configuration, at the 2547 architectural 
level, how many copies of the route _need_ to be advertised? I claim that 
you get identical results advertising a single route as advertising both 
the original and the sourced route. That is, if the two routes are 
identical (which they will be by definition if the route in VRF A is 
imported into VRF B), and given the definition of RT in section 4.3.1 of 
draft-ietf-l3vpn-rfc2547bis-00, then advertising

1:1:x/x,  Label=L1, RT={ 100:100}
2:2:x/x, Label=L1, RT={100:100, 100:200}

will produce exactly the same effect on a remote PE as advertising

1:1:x/x, Label=L1, RT={100:100, 100:200}

So, architecturally only the latter is necessary. Now, if the only way for 
a particular  implementation to produce route with all desired RT sets was 
to advertise two routes, then I suppose there's nothing which forbids it to 
do so; but IMO it would be inferior to an implementation that can advertise 
only a single route. In at least one implementation there are ways to 
achieve this.

---

From: Enke Chen <[email-masked]>
Date: Wed, 30 Jul 2003 13:55:32 -0700

Hi, Dan:

> Message-Id: <[email-masked]>
> Date: Wed, 30 Jul 2003 16:00:50 -0400
> To: Enke Chen <[email-masked]>
> Cc: [email-masked], [email-masked],
> 	[email-masked], [email-masked]
> In-Reply-To: <[email-masked]>
> References: <Message from Dan Tappan <[email-masked]>
>  <[email-masked]>
> 

It seems to me that there is a difference if there exists a customer on the
remote PE with the following attributes:

        vrf C:  rd 3:3,  import 100:200, export 100:200

(In that case vrf B probably should have import: 100:100 100:200.)

> only a single route. In at least one implementation there are ways to 

When the export attributes are the same for the original route and the
locally imported route, I agree that it is a nice optimization to suppress
the advertisement of the imported route. When they are different, however,
the optimization does lead to constrains on vpn association, which IMO
does not seem to be necessary or correct.

Regards,  -- Enke

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 30 Jul 2003 23:30:10 +0200

Hey Enke,

I must say that today operational examples tell me that there is enough
of struggle for providers to fully grasp the concept of the original's
basic export as well as per route export from the original vrf. Adding
to this a proposed - well maybe too strong word but described by you -
chained redistribution of any route when it is imported may IMHO
generate huge does of problems. Or maybe we should distinguish two cases
where export of imported route is feasible:

A) When the route is comming from CE
B) When the route is comming from PE with different RD

Cheers,
R.

> Enke Chen wrote:

---

From: Dan Tappan <[email-masked]>
Date: Wed, 30 Jul 2003 17:31:06 -0400

>         vrf C:  rd 3:3,  import 100:200, export 100:200

I don't see it. In that case C will end up importing the same route (i.e. 
the packet will end up in the same place) either way.

>does not seem to be necessary or correct.

I don't think you've demonstrated a case where the behavior ends up being 
different.

(yet) another way to look at the problem. This started out with the VRF B 
on the same PE as VRF A. What if VRF B were on a different PE?

1. Should the system behave differently in that case? (principle of least 
surprise says 'no')
2. should that PE re-export the route which was imported into VRF B?

---

From: Enke Chen <[email-masked]>
Date: Wed, 30 Jul 2003 14:43:52 -0700

Dan,

> Message-Id: <[email-masked]>
> Date: Wed, 30 Jul 2003 17:31:06 -0400
> 	[email-masked], [email-masked], [email-masked]
> In-Reply-To: <[email-masked]>
>  <[email-masked]>
> 

    > 1:1:x/x, Label=L1, RT={100:100, 100:200}

You magically combined the RT of both 1:1:x/x and 2:2:x/x :-)

That is one way of doing it, and advertising the both is another way.
The result is equivalent on the remote PE.

> 2. should that PE re-export the route which was imported into VRF B?

My answer is "no" in general (with the exeception of "local importing" that
we have been discussing"). Recursive importing adds too much complexity
with little gain.

-- Enke

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 30 Jul 2003 23:53:59 +0200

Enke,

> we have been discussing"). Recursive importing adds too much complexity

Did you mean to say "recursive export" ? Or are we switching topics now
to talk about "recursive importing" :) ?

R.

---

From: Enke Chen <[email-masked]>
Date: Wed, 30 Jul 2003 14:56:39 -0700

Hi, Robert:

> Message-ID: <[email-masked]>
> Date: Wed, 30 Jul 2003 23:53:59 +0200
> From: Robert Raszuk <[email-masked]>
> Cc: Dan Tappan <[email-masked]>, [email-masked],
> 	[email-masked], [email-masked]
> References: <[email-masked]>
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> Enke,
> 

You got me, I meant "recursive export". Thanks for pointing this out.

-- Enke

---

From: Dan Tappan <[email-masked]>
Date: Wed, 30 Jul 2003 18:00:47 -0400

>Dan,

...

>You magically combined the RT of both 1:1:x/x and 2:2:x/x :-)

It wasn't magic. My point was that there are ways to achieve the desired RT 
set w/o re-exporting a second route. That was what I meant by:

>>Now, if the only way for a particular  implementation to produce route 
>>with all desired RT sets was to advertise two routes, then I suppose 
>>there's nothing which forbids it to do so; but IMO it would be inferior 
>>to an implementation that can advertise only a single route.

I haven't yet seen a case where re-exporting is the most straightforward 
way to achieve a desired import policy, particularly when you take into 
account PE-connection-independence. And I can think of cases where it would 
produce the wrong result if applied in general.