The MPLS-OPS Archive

Cell Relay Retreat>MPLS-OPS Archive>month:2002-Mar> msg00126



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Re: VRFs on ASBRs with inter-AS VPNs[sic]

  • From: Robert Raszuk <raszuk@cisco.com>
  • Date: Mon, 18 Mar 2002 14:16:25 +0100
  • CC: "Mpls-Ops (E-mail)" <mpls-ops@mplsrc.com>
  • Organization: Signature: http://www.employees.org/~raszuk/sig/
  • Resent-Date: Mon, 18 Mar 2002 09:27:22 -0500
  • To: Krzysztof Szarkowicz <kszarkowicz@freemail.hu>

Hej Krzysiek,

> Why 128 bytes? Should it rather be variable size, depending on which optional attributes are attached to the prefix?

No - neither paths nor attributes are copied physically. We point from
the copied b_net to the original paths & attributes therefor the size of
the b_net is constant.

> > > > > A) Have a special single bgp community for exportable to inter-as peer
> > > > > vpnv4 routes - you set the filter once on ASBR and done.
> > > > >
> 
> If I have vpnv4 peering with different AS-es and each of my neigboring AS would need different set of vpnv4 prefixes, it would mean that I need to create so many special communities as many vpnv4 inter-as peerings I have. Is it not better to base the inbound filter on ASBR on RTs, instead of this special community?

True, but only in the case when existing RT assinment is sufficient. All
I am saying that when I would have a choice to add a new set of
communities (my existing ones do not provider enough granularity) I
would prefer to use regular communities rather then extended to save my
RAM in all PEs & RRs passing or using those routes.

R.

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml