Subject: Re: Re: VPN-IPv4 routes

From: "Rohit Gupta" <[email-masked]>
Date: Mon, 05 Apr 2004 12:13:07 +0530

Hi Rajesh,

Please find my comments inlined in RG&gt;&gt;

 If a MP_REACH_NLRI  route is advertised with a new set of Route  Targets, but the 
 same Route Distinguisher,  would not the old VPNv4 route be implicitly  removed from 
 all VRFs previously importing the (old) Route Targets. And a new vpnv4 route get created
 and imported into all the new VRFs, as per the new set of RTs.
 
RG&gt;&gt; Supose VRF A has an import RT of 100:100. It has previously imported a VPN route with this RT. Now accoding to you a remote PE now advertises the same VPN route with say an RT of 200:200. This is will not act as an implicit withdraw. Lets see why. When VRF A sees this new route it will not import this as the RTs carried in this route dont match with its import policy. It will thus ignore this route. Thus, what you wanted has not been achived. You wanted to have this route as an implicit withdraw. But this hasnt worked.
 
RG&gt;&gt; It can work as an implicit withdraw if the new route has the same RTs as before but different path attributes (ORIGIN, LP, MED, ASPATH, etc)
 
RG&gt;&gt; Hope I was clear.
 
 Would it be necessary to send a Withdraw for the old Route Target and an UPDATE
 for the new Route Target? 
 
RG&gt;&gt; Depends on what is different from new and the old route. If its the path attributes like LP, ASPATH, NEXT_HOP, etc. which differ then you can as well send an implicit withdraw. But if you want to send the route with new RTs then i guess, you need to withdraw this route.
 
Cheers,
Rohit
 
Also, does the ordering of MP_REACH_NLRI, MP_UNREACH_NLRI and Extended 
 Communities matter in an UPDATE. Implementations do send Extended
 community first (type code = 16), followed by MP_REACH_NLRI (14) and then
 MP_UNREACH_NLRI (15) 
 
 If the same route (RD + NLRI) is present in MP_REACH_NLRI and MP_UNREACH_NLRI, is the UPDATE done first or WithDraw done first?
Does it depend on the order in which the Path Attributes are present in the UPDATE?
 
Thanks,
Roger

Robert Raszuk &lt;[email-masked]&gt; wrote:
Hi Roger,

&gt; If they are present in the same UPDATE, and it also has a BGP Extended
&gt; Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be
&gt; interpreted as, for those VRFs which are importing those route
&gt; targets?

Nope. For unreachable information in any address family none of the 
attributes (incl BGP ext community attribute) are important and not 
considered. Remember that the NLRI format there still is RD:IPv4 so it 
uniquely identifies all by itself which remote destinations became 
unreachable.

In other words checking against RTs would be required on the withdraw 
only if any other PE would inject new set of RTs for previously 
advertised VPNv4 routes before withdrawing those apriori. That would be 
an illegal operation.

Cheers,
R.

&gt; Roger Pottier wrote:
&gt;
&gt; Hi! ,
&gt; 
&gt; RFC 2858 (Multiprotocol Extensions for BGP) specifies how MP_REACH_NLRI
&gt; and MP_UNREACH_NLRI is carried in a packet. Can a single BGP Update 
&gt; packet contain both MP_REACH_NLRI (Type code = 14) and MP_UNREACH_NLRI 
&gt; (Type code=15). I saw an implementation, sending both the path 
&gt; attributes in the same
&gt; UPDATE.
&gt; 
&gt; If they are present in the same UPDATE, and it also has a BGP Extended 
&gt; Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be interpreted 
&gt; as, for those VRFs which are importing those route targets?
&gt; 
&gt; Roger
&gt; 
&gt; ------------------------------------------------------------------------
&gt; Do you Yahoo!?
&gt; Yahoo! Small Business $15K Web Design Giveaway 
&gt; 
&gt; - Enter today

Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway - Enter todayIndiatimes Email now powered by APIC Advantage. Help! 
HelpClick on the image to chat with me

---

From: "Rohit Gupta" <[email-masked]>
Date: Mon, 05 Apr 2004 12:02:47 +0530

No Rajesh, there is nothing in the BGP spec which says that the path attributes should be processed in order of their absolute type codes.

There is thus nothing wrong with MP_UNREACH_NLRI coming before MP_REACH_NLRI 

~Rohit

"Rajesh Potti" wrote: 

Hi Robert, 

 Another issue on similiar lines: 
  When MP_REACH_NLRI and MP_UNREACH_NLRI are found in the same UPDATE, is there a particular order enforced? 
  MP_REACH_NLRI has type code 14, and MP_UNREACH_NLRI has type code 15, hence should it be 
  MP_REACH_NLRI followed by MP_UNREACH_NLRI in the same UPDATE. 

Rajesh 

Robert Raszuk wrote: 
Hi Roger, 

Cheers, 
R. 

&gt; Hi, 
&gt; &lt;http://us.rd.yahoo.com/evt=23609/*http://promotions.yahoo.com/design_giveaway/static/index2.html&gt; 
&gt; - Enter today-- 
Rajesh Potti.  Indiatimes Email now powered by APIC Advantage. Help!

---

From: "Rajesh Potti" <[email-masked]>
Date: Mon, 5 Apr 2004 11:17:54 -0400

Hi Rohit,

Comments below.

 If a MP_REACH_NLRI  route is advertised with a new set of Route  Targets,
but the 
 same Route Distinguisher,  would not the old VPNv4 route be implicitly
removed from 
 all VRFs previously importing the (old) Route Targets. And a new vpnv4
route get created
 and imported into all the new VRFs, as per the new set of RTs.

RG>> Supose VRF A has an import RT of 100:100. It has previously imported a
VPN route with this RT. Now accoding to you a remote PE now advertises the
same VPN route with say an RT of 200:200. This is will not act as an
implicit withdraw. Lets see why. When VRF A sees this new route it will not
import this as the RTs carried in this route dont match with its import
policy. It will thus ignore this route. Thus, what you wanted has not been
achived. You wanted to have this route as an implicit withdraw. But this
hasnt worked. 
 
Though the RT is different, the RD of the route is the same. Since RD
Uniquely identifies a route, the RD:IPV4 addresses are same as the old route
(with a different RT), should it be not treated as a replace 
route. The RFC does not clearly specify this, but says an RD Uniquely
identifies a route.
 
Thanks,
Rajesh

RG>> It can work as an implicit withdraw if the new route has the same RTs
as before but different path attributes (ORIGIN, LP, MED, ASPATH, etc)
 
RG>> Hope I was clear.
 
 Would it be necessary to send a Withdraw for the old Route Target and an
UPDATE
 for the new Route Target? 
 
RG>> Depends on what is different from new and the old route. If its the
path attributes like LP, ASPATH, NEXT_HOP, etc. which differ then you can as
well send an implicit withdraw. But if you want to send the route with new
RTs then i guess, you need to withdraw this route.
 
Cheers,
Rohit

 If the same route (RD + NLRI) is present in MP_REACH_NLRI and
MP_UNREACH_NLRI, is the UPDATE done first or WithDraw done first?
Does it depend on the order in which the Path Attributes are present in the
UPDATE?
 
Thanks,
Roger

Robert Raszuk <[email-masked]> wrote:

Hi Roger,

> If they are present in the same UPDATE, and it also has a BGP Extended
> Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be
> interpreted as, for those VRFs which are importing those route
> targets?

Cheers,
R.

> Roger Pottier wrote:
>
> Hi! ! ! ,
> 
> RFC 2858 (Multiprotocol Extensions for BGP) specifies how MP_REACH_NLRI
> and MP_UNREACH_NLRI is carried in a packet. Can a single BGP Update 
> packet contain both MP_REACH_NLRI (Type code = 14) and MP_UNREACH_NLRI 
> (Type code=15). I saw an implementation, sending both the path 
> attributes in the same
> UPDATE.
> 
> If they are present in the same UPDATE, and it also has a BGP Extended 
> Community attribute (Type code= 16) would the MP_UNREACH_NLRI also be
interpreted 
> as, for those VRFs which are importing those route targets?
> 
> Roger
> 
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Yahoo! Small Business $15K Web Design Giveaway 
> 
> - Enter today

  _____  

Do you Yahoo!?
Yahoo!
<http://us.rd.yahoo.com/evt=23609/*http://promotions.yahoo.com/design_giveaw
ay/static/index2.html> Small Business $15K Web Design Giveaway - Enter today

  _____  

Indiatimes Email now powered by APIC Advantage. Help!
<http://email.indiatimes.com/apic/>  

<http://imaround.indiatimes.com/IMaround/presencefr.mss?userid=rohitgupta416
> My Presence <http://email.indiatimes.com/apic/instachat.htm> Help
Click on the image to chat with me

---

From: "Vijayanand C - CTD, Chennai." <[email-masked]>
Date: Tue, 6 Apr 2004 12:10:45 +0530

Hi rohit,
Multiple RTs can be attached to a VPN-IPv4 route.( section 4.3.1 -
draft-ietf-ppvpn-rfc2547bis-04.txt  )  Assigning another RT to an existing
VPN-IPv4 route would'nt mean an implicit withdraw, but it would mean that
the route has one more RT attached to it now. This is an alternative to
generating multiple RDs for the same prefix, since this improves BGP
scaling. 
 
Regards,
Vijay

-----Original Message-----
From: Rajesh Potti [mailto:[email-masked]]
Sent: Monday, April 05, 2004 8:48 PM
To: 'Rohit Gupta'; Roger Pottier; [email-masked]
Cc: [email-masked]'
Subject: RE: Re: VPN-IPv4 routes

Hi Rohit,

Comments below.

 
 
Thanks,
Rajesh

RG>> Hope I was clear.

 
Cheers,
Rohit

 
Thanks,
Roger

Hi Roger,

Cheers,
R.

interpreted 

   _____  

Do you Yahoo!?
Yahoo!

   _____

---

From: "Rohit Gupta" <[email-masked]>
Date: Tue, 06 Apr 2004 14:08:23 +0530

Hi Rajesh,
. 

 
Though the RT is different, the RD of the route is the same. Since RD Uniquely identifies a route, the RD:IPV4 addresses are same as the old route (with a different RT), should it be not treated as a replace 
route. The RFC does not clearly specify this, but says an RD Uniquely identifies a route.
 
RG&gt;&gt; When a PE router receives VPN-IPV4 route it doesnt look at the RD before it decides whether it needs to import that route in its VRF or not. Thus even as you say that the RD:IPV4 route will be same, it doesnt matter. BGP will by only looking at the RTs decide whether it needs to import this route or not. Thus a route with a separate RT cannot be treated as an implicit withdraw.
 
Hope am clear.
 
RohitIndiatimes Email now powered by APIC Advantage. Help! 
HelpClick on the image to chat with me

---

From: "Rajesh Potti" <[email-masked]>
Date: Tue, 6 Apr 2004 10:17:44 -0400

Hi Vijay,
 
 Yes, multiple RTs can be attached to a VPNv4 route, and it increases
scalablility. But the multiple RTs should be
 present in the same UPDATE. The issue is whether a successive UPDATE (for a
vpnv4 route already advertised) would
 be treated as a Replace route, since it is the same RD:IPv4. If  we need a
Withdraw for a VPNv4 route followed by an
 UPDATE with new set of RTs, on RT Change, it might result in less
scalablity.
 
Rajesh

-----Original Message-----
From: Vijayanand C - CTD, Chennai. [mailto:[email-masked]] 
Sent: Tuesday, April 06, 2004 2:41 AM
To: Potti, Rajesh [BL60:SF40:EXCH]
Cc: [email-masked]'; 'Rohit Gupta'; Roger Pottier; [email-masked]
Subject: RE: Re: VPN-IPv4 routes

Hi rohit,
 
Regards,
Vijay

-----Original Message-----
From: Rajesh Potti [mailto:[email-masked]]
Sent: Monday, April 05, 2004 8:48 PM
To: 'Rohit Gupta'; Roger Pottier; [email-masked]
Cc: [email-masked]'
Subject: RE: Re: VPN-IPv4 routes

Hi Rohit,

Comments below.

 
 
Thanks,
Rajesh

RG>> Hope I was clear.

 
Cheers,
Rohit

 
Thanks,
Roger

Hi Roger,

Cheers,
R.

interpreted 

  _____  

Do you Yahoo!?
Yahoo!

  _____

---

From: "Rajesh Potti" <[email-masked]>
Date: Tue, 6 Apr 2004 10:36:37 -0400

Hi Rohit,
 
 The VPNv4 routes are inserted into VRFs based on RT, i agree. Your point
is, if the old (RD:IPv4) route was accepted into 
 a VRF due to RT Match, but the new vpnv4 route with RD and IPv4 route the
same, does not match the VRF's import
 Route Target. Almost like, the old route was accepted by route policy,
while new route gets rejected by the policy. In this
 case, new route should not be inserted and the old route should also be
removed. 
 
 This is similiar to the following scenario: 
 
 Consider Route 1.1.1.1 with community 2:2 was received from a peer. The
Route policy does not reject routes with 
 community 2:2, but does reject routes with community 3:3. Now, the peer
again sends an UPDATE for 1.1.1.1 with
 community 3:3. Since the route is rejected by new policy, the old route
1.1.1.1 with community 2:2 should also be 
removed.
 
 I think draft-ietf-l3vpn-rfc2547bis-01.txt (BGP/MPLS IP VPNs) should also
mention how Replace Route case is 
 handled for vpnv4 routes, and whether we need a withdraw for an RT change.
 
Thanks,
Rajesh

 

-----Original Message-----
From: Rohit Gupta [mailto:[email-masked]] 
Sent: Tuesday, April 06, 2004 4:38 AM
To: Potti, Rajesh [BL60:SF40:EXCH]; Rohit Gupta; Roger Pottier;
[email-masked]
Cc: [email-masked]
Subject: Re: RE: Re: VPN-IPv4 routes

Hi Rajesh,
.

 
RG>> When a PE router receives VPN-IPV4 route it doesnt look at the RD
before it decides whether it needs to import that route in its VRF or not.
Thus even as you say that the RD:IPV4 route will be same, it doesnt matter.
BGP will by only looking at the RTs decide whether it needs to import this
route or not. Thus a route with a separate RT cannot be treated as an
implicit withdraw. 

Hope am clear.
 
Rohit

  _____