[Idr] VPN black holing because of non-checking next-hop

[Antonio Huete <[e-mail]>]

Dear all,


I write this e-mail for you because I knew you were working in draft http://datatracker.ietf.org/doc/draft-ietf-idr-bgp-bestpath-selection-criteria/ and the technology group I work in is very interested in these kinds of features as we consider them an important improvement when selecting next-hops that will become eligible, removing those that do not meet needed rules to become a best path.



Let me explain some historical data about our network:



-          Since 2001, the main vendor deployed in our network has been Juniper (close to 95% of routers) and the another 5% were Cisco 7600 acting as PE routers. But from last year, Cisco CRS-3 (in the core) and ASR9000 (in the edge) are being deployed, allowing this vendor to increase its presence in our network at the expense of Juniper.



-          Historically,  Juniper routers have developed mechanisms to check if next-hops are valid, and if so they become as "eligible" as a previous step to become the "best". If they are not valid they become "Unusable", but never it will be selected as a best path, in which case it could provoke a traffic blackholing.



-          Let me put a real example to illustrate how we take advantage of features like this:



o   Our company offers MPLS VPN service to our clients

o   LDP is used as transport mechanism

o   If for any reason a label is not available for this next-hop (FEC) we find out 2 different behaviors:



§  If it is a Juniper PE, it checks this next-hop is not valid and it declares it as "Unusable", using the next  option it has available  as "best" path.

§  If it is a Cisco PE (IOS or IOS-XR), no checking is done at all and if this next-hot meets conditions to become the "best" it is selected as such, causing service disruption because of traffic black-holing

I would like you to be aware of the importance this feature has for us and take into account we have always had this feature on Juniper routers, but we found it was not available in Cisco devices, which is amazing for us.

I also would like to know if you have plans to continue developing this draft.

Best Regards,

Antonio Huete | Telefónica Global Solutions
IP Technology - Network Area
Ronda de la Comunicación, s/n
Oeste 1. Pl. 3, 28050 Madrid, Spain
[phone]| [phone]
[e-mail]<mailto:[e-mail]>

www.internationalservices.telefonica.com<http://www.internationalservices.telefonica.com/>
www.multinationalsolutions.telefonica.com


________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição