Internal BGP as PE-CE Protocol Pedro Marques Robert Raszuk Dan Tappan Luca Martini

Problem  When BGP is used as PE-CE protocol, it uses External BGP rules: as-path perpending, etc.  Accept looped routes in CE-1  Rewrite customer AS# with provider AS# CE-1PE-1PE-2CE-2 Provider AS AS Route Advertisement as-path as-path

Continued  When CE connections are not isolated islands and exchange BGP routes with any other party, it just gets messier.  Customer island peers with the service provider (for Internet service, for instance).  Customer islands exchange routes with outside world: Provider AS# appears in the path.  Never ending requests for as-path rewrite hacks.

Rent-a-core  Traditional network design:  Core distributes routing information to sites.  Reflectors participate in top level iBGP mesh.  Pop/Site routers receive routing information from their respective RRs.  IGP may be stub area if there are no backdoor links.  These are often managed independently. CE-1RR-1RR-2CE-2 Core

Proposed model  PE routers are route reflectors to each CE site location.  Customer network attributes are pushed into an “attribute stack” at ingress.  This deals with interference on local- preference, communities, MEDs, etc.  At egress “attribute stack” is poped. cluster is perpended when advertising to CE side.  cluster-list performs loop avoidance.

IGP interaction  Shouldn’t require a single IGP between distinct sites.  Even if an IGP is running between all sites it may not be able to compare inter-site metrics (Provider assigned) and intra-site.  Perform implicit “next-hop self” on the PE/RR  when advertising to CE.  when advertising to other PEs.  PE/RR makes decisions by taking inter-cluster metrics always higher than intra-cluster.

Deployment  Mix and match of eBGP and iBGP in the same VPN.  Proposed attribute (ATTR_SET) consists of customer AS# plus attributes in original path.  This allows a PE to know what to advertise to a given CE. iBGPeBGP internalif same as# use internal rules pop and apply external rules externaladvertise as-isexisting rules peer origin

Summary  Using iBGP between PE and CE requires a few extra considerations:  non-interference of customer attributes in provider network.  IGP/next-hop dependencies.  apply external rules when crossing as boundaries.  iBGP interaction can provide transparency to customer network.  as-path manipulation hacks only get you so far.

Thank You For more details see: draft-marques-ppvpn-ibgp-00.txt