Subject: Re: [Idr] Transient loop prevention when using the best external and add-path approaches

From: Xu Xiaohu <[email-masked]>
Date: Wed, 03 Mar 2010 11:17:48 +0800

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 xuxiaohu
> 41208
> 发送时间: 2010年2月27日 23:18
> 收件人: [email-masked]
> 抄送: [email-masked]
> 主题: Re: [Idr] Transient loop prevention when using the best external and
> add-path approaches
> 
> Hi Robert,
> 
> ----- 原邮件 -----
> 发件人: Robert Raszuk <[email-masked]>
> 日期: 星期六, 二月 27日, 2010 下午7:16
> 主题: Re: [Idr] Transient loop prevention when using the best external and
> add-path approaches
> 收件人: Xu Xiaohu <[email-masked]>
> 抄送: [email-masked]
> 
> > Hi Xu,
> >
> > >> It sure can. "Tracking all atomic next hops" is the key here.
> > >
> > > For example, one remote peer is down while another one is still
> > OK, should
> > > the IGP route to the local ASBR itself be withdrawn?
> >
> > The simplest (but not only approach) is to remove the local next hop
> > from the IGP only when all original next hops go down.
> >
> > That is still better then to attract traffic to such ASBR when all
> > external peering go down.
> >
> > But the main question to ask is why to set next hop to self on
> > ASBR for
> > IPv4 Internet ?
> 
> There does exist some scenarios where the local ASBR should set the
next-hops
> of iBGP routes to self. BGP-free core and Softwire Mesh are two examples.
Even
> in a normal BGP scenario, if a given local ASBR is connected to a remote
AS
> via two remote peers (e.g., P1 and P2), it would be better for the local
ASBR
> to set the next-hops of the iBGP routes to self. In case that the nexthop
of
> a learnt eBGP route is changed from P1 to P2, if all of
> the path attributes except the nexthop attribute are identical, there is
no
> need for the local ASBR to withdraw the previous route update and then
advertise
> a new one. In this way, the route advertisement traffic can be reduced
greatly.

Hi Robert,

What's your thought about the scenarios mentioned above?

> > That clearly seems to have the disadvantage of blocking the original
> > fast next hop down event propagation of peering ASBR or interface
> > to it.
> >
> > In fact this is not related to best external or add-paths or
> > diverse-path ways of distributing additional paths. The same issue
> > happens with simple IBGP full mesh today.

Yes, this issue is not specific to the best external or the add-path
mechanism. However, by using them, the transient loop issue will become
worse. Right?

Best wishes,
Xiaohu

> > In the past I had one proposal to still signal it in BGP to
> > address the
> > case you are pointing out:
> >
> > http://ftp.iptel.org/pub/standards/internet-drafts/draft-raszuk-
> > ext-failure-propagation-00.txt
> >
> > But it seemed that it is much better and faster to leave the next hop
> > unchanged.
> >
> > Cheers,
> > R.
> >
> >
> >
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 03 Mar 2010 04:30:51 +0100

Hello Xiaohu,

> What's your thought about the scenarios mentioned above?

BGP-free core does not require setting next hop self on the ASBRs. You
can very well build LSPs in the core between your ASBRs to both LDP FEC
/30 as well as IGP /30 being ASBR to ASBR numbered link.

Softwire mesh or other applications like L3VPNs are not what we are
discussing here. Let's just keep it limited for IPv4 and IPv4 Interent.

> mechanism. However, by using them, the transient loop issue will become

Full mesh has the same set of "issues" today if IBGP path is selected as
best. The issue you point our arises by masking the original next hop
failure by new next hop. It may happen today as well in full mesh easily.

As said about by constructing LSPs today to connected interfaces you
don't have this issue. You don't have this issue when you are advertsing
original next hop liveness within your IGP (not even needed domain wide
as discussed recently on nanog or apricot).

So to conclude I think we can consider this topic as solved.

Cheers,
R.

---

From: Andy Davidson <[email-masked]>
Date: Sun, 14 Mar 2010 04:56:09 +0000

> So to conclude I think we can consider this topic as solved.

I agree with Robert.  RFC3107 is only one of multiple options for solving loop prevention in our add-path and best-external enriched futures.  Instead of mandating (or strongly recommending) RFC3107, perhaps the draft should describe the loop problem, but make no specific resolution information.

Andy