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

From: Antonio Huete <[email-masked]>
Date: Tue, 12 Mar 2013 22:10:56 +0000

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
+34 670419485| +34 914830596
[email-masked]<mailto:[email-masked]>

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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Mar 2013 18:44:53 +0100

Hello Antonio,

> §  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

Why wouldn't you use cisco ios build in LSP health monitor: http://goo.gl/vCLW0

You could also combine LSP ping with object tracking provided that
proper hooks are in place - I have not tested this myself, but found
object tracking to be a very powerful yet quite unknown tool ...

And above all you could just use IP mGRE automatic encapsulation
between PEs rather then LDP to architecturally solve your problems of
broken MPLS LSPs for good !

Cheers,
R.

PS. Before others will point it out this thread is more applicable to
c-nsp alias rather then IDR WG.

> On Tue, Mar 12, 2013 at 11:10 PM, Antonio Huete <[email-masked]> wrote:
>
> 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.
>
>
>
> -          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.
>
>
>
> §  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.
>
>
>
> IP Technology – Network Area
>
> [email-masked]
>
>
>
> www.internationalservices.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
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>