Subject: VPN-IPv4 routes

From: Roger Pottier <[email-masked]>
Date: Fri, 2 Apr 2004 13:10:40 -0800 (PST)

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

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 02 Apr 2004 14:36:18 -0800

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?

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.

 > Roger Pottier wrote:
>  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 
> <http://us.rd.yahoo.com/evt=23609/*http://promotions.yahoo.com/design_giveaway/static/index2.html> 
> - Enter today

---

From: Rajesh Potti <[email-masked]>
Date: Fri, 02 Apr 2004 18:38:32 -0500

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

--
Rajesh Potti.

---

From: Roger Pottier <[email-masked]>
Date: Sat, 3 Apr 2004 18:10:58 -0800 (PST)

Hi Robert,
 
 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.
 
 Would it be necessary to send a Withdraw for the old Route Target and an UPDATE
 for the new Route Target? 
 
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 <[email-masked]> wrote:
Hi Roger,

Cheers,
R.