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

From: Xu Xiaohu <[email-masked]>
Date: Wed, 28 Apr 2010 10:40:54 +0800

Hi Robert,

I just realized that in the following scenario as I described, PIC
(Prefix-Independent Convergence) can not do any help on the FIB convergence
since it is the BGP next-hop, rather than the recursive IGP next-hop only
that has to be updated in the FIB. Please see the details inline. 

> -----邮件原件-----
> 发件人: Xu Xiaohu [mailto:[email-masked]]
> 发送时间: 2010年2月22日 14:48
> 收件人: [email-masked]'
> 抄送: [email-masked]'
> 主题: re: [Idr] Transient loop prevention when using the best external and
> add-path approaches
> 
> Hi Robert,
> 
> Sorry for late response due to Chinese New Year holiday. Please see my
response
> inline.
> 
> > -----邮件原件-----
> > 发件人: Robert Raszuk [mailto:[email-masked]]
> > 发送时间: 2010年2月10日 18:18
> > 收件人: Xu Xiaohu
> > 抄送: [email-masked]
> > 主题: Re: [Idr] Transient loop prevention when using the best external
and
> > add-path approaches
> >
> > Hi Xu,
> >
> > I think we need to step back and define what transient loop you may be
> > referring to.
> >
> >  From your description I infer that the loop you are referring to
> > happens  from the moment of R1 to AS#2 connection down or AS#2's ASBR
> > down and lasts till BGP withdraws the prefix P from R1 ?
> 
> Yes.
> 
> > Is this true ? If so - yes it would be relatively long and undesired.
> >
> > But I would say that this is wrong network design.
> >
> > The alternative network design would be to use IGP within AS#1 for fast
> > flooding of AS#2's ASBR next hop down event. That event would be
> > propagated within AS#1 in single miliseconds therefor each BGP speaker
> > can switch upon reception of this trigger to an alternative path.
> 
> Does that mean the local ASBR (i.e., R1) MUST disable the "next-hop-self"
when
> advertising iBGP updates to its iBGP peers?
> 
> > Tools like PIC (prefix independent convergence) and preinstallation of
> > backup paths in RIB and FIB are available in shipping implementations
> > and can improve the actual connectivity restoration times significantly
> > from the reception of the IGP next hop down event trigger.

Taken the FIB on R3 (Assuming PIC is enabled) as an example, its FIB looks
like:

   +-------+-----------+          +------------+-------------+
   |Prefix |BGP Nexthop|          |BGP Nexthop | IGP Nexthop |
   +-------+-----------+          +------------+-------------+
   |  P1   |  ASBR2    |          | ASBR2      |     R1      |
   +-------+-----------+          +------------+-------------+
   |  P2   |  ASBR2    |
   +-------+-----------+
   |  Pn   |  ASBR2    |
   +-------+-----------+ 
(Assume ASBR2 is the ASBR in AS#2 which is connected to R1)

So once ASBR2 becomes unreachable, all the FIB entries with BGP next-hop
being ASBR2 must be updated on the per-prefix basis. That's to say, the
convergence is not prefix-independent. Even there was a field of "Backup BGP
Nexthop" on the first table (i.e., pre-installation of backup route is
available), those FIB entries still have to be updated entry by entry. As a
result, the FIB rewriting operation for a large amount of route entries will
still cost much time. Is my understanding correct?

Best wishes,
Xiaohu

> I'm not sure whether all the deployed routers can support the PIC feature
or
> even be able to support that feature through upgrading their softwires (i.
e.,
> OS) only.
> 
> Best wishes,
> Xiaohu
> 
> > If one would be still concerned about the transient loops for the
> > duration of IGP single next hop flooding time which is IMHO
> > insignificant and happens today each time IGP converges there is set of
> > IPFRR solutions available as well.
> >
> > There is clearly no need to move entire Internet routing to RFC3107 or
> > mpls encapsulation when best external is enabled.
> >
> > The similar point you make regarding add-paths also can be addressed by
> > the proper design. In fact IMHO with the proper network design enabling
> > add-paths can be avoided all together - but this is a separate topic not
> > for this thread :).
> >
> > Cheers,
> > R.
> >
> >
> > > Hi all,
> > >
> > > In the following scenario where the BGP best external approach (see
> > > draft-ietf-idr-best-external-01) is enabled on the BGP speakers of
AS#1
> > > (i.e., R1, R2 and R3), assuming R1 and R2 each learns a route to the
same
> > > destination P from AS#2 and AS#3 respectively, and the route learnt
from
> > > AS#2 is selected as the best route by R1, R2 and R3. According to the
best
> > > external approach, R2 will advertise its best external route to P
(i.e.,
> the
> > > route learnt from AS#3) to its iBGP peers, R1 and R3. When R1's
connection
> > > to AS#2 is broken, a transient forwarding loop will be formed during
the
> > > time the network takes to converge to the alternate path (i.e., the
route
> > > learnt from AS#3). That is: R3 still forward packets destined to P
towards
> > > R1, R1 in turn will forward them to R2 due to fast local repair, and
R2
> will
> > > then forward them back to R1... therefore, a forwarding loop is formed
> > > between R1 and R2 till the network is converged.
> > >
> > >          AS#2        AS#3
> > >            |           |
> > >            |           |
> > >     +------+-----------+------+
> > >     |   +--+--+     +--+--+   |
> > >     |   |  R1 +-----+  R2 |   |
> > >     |   +-\---+     +--/--+   |
> > >     |      \          /       |
> > >     |       \        /        |
> > >     |        *------*         |
> > >     |        |  R3  |         |
> > >     |        +------+         |
> > >     |         AS#1            |
> > >     +-------------------------+
> > >
> > > In fact, the above transient loop can be avoided as long as the best
> > > external route is processed according to the approaches defined in
Carrying
> > > Label Information in BGP-4 [RFC3107]. For example, R2 will assign a
unique
> > > MPLS label for its best external route (i.e., the route to P learnt
from
> > > AS#3) and then install it into its MPLS forwarding table. When
advertising
> > > the best external route to its iBGP peers, R2 will attach the
corresponding
> > > MPLS label in the BGP update. Upon receiving the best external route,
R1
> and
> > > R3 will install it into their own MPLS forwarding table respectively
as
> a
> > > backup route to destination P.  In this way, R1 will forward packets
> > > destined to P towards R2 with the MPLS label attached. As a result, R2
will
> > > use the corresponding MPLS forwarding entry (i.e., its best external
route
> > > to P), rather than the route entry in its Routing table (i.e., its
best
> > > route to P), to forward the packets. Of course, if R1 and R2 are not
> > > directly connected, an IP or MPLS tunnel from R1 to R2 is required
since
> the
> > > above MPLS label has local meanings only on R2.
> > >
> > > By the way, I think the add-path approach (see
draft-ietf-idr-add-paths-03)
> > > may cause the same transient loop problem which can be avoided
similarly
> > > with the above approach.
> > >
> > > Hence I wonder whether it would be better that the approach defined in
> > > [RFC3107] is STRONGLY recommended in the two WG drafts mentioned
above.
> > >
> > > Comments?
> > >
> > > Best wishes,
> > > Xiaohu
> > >
> > > _______________________________________________
> > > Idr mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/idr
> > >

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 29 Apr 2010 11:53:03 +0200

Hello Xu,

> Is my understanding correct?

Unfortunately not. PIC's #1 assumption is that for backup you are using
paths with different bgp next hop. And it is prefix independent in
nature as thx to hierarchical FIB you will _not_ need to go via each
prefix to update it's bgp next hop at the bad event time. Depending on
the scenario it could be just one pointer rewrite from original BGP next
hop to pre-programmed BGP backup next hop or if not all the bgp paths
had identical set of original-backup bgp next hop you will get few more
pointer adjustments. But in each case this is prefix independent
considering how many BGP prefixes we would be fixing with at most only a
few FIB rewrites.

You are clearly confusing PIC edge with PIC core technologies. In the
latter *PIC core* you have the IGP next hop adjustment towards the same
BGP next hop. Those two PIC technics are orthogonal to each other and
customers need to use both to achieve required fast connectivity
restoration goals.

Anyway many thx for the question which allowed me to clarify the above
difference.

Cheers,
R.

PS. To fully complete the story there is also a PIC mid-point technology
which one could use between POP and core when ABRs are acting as RRs and
are in the data plane. In those PIC mid-points you are capable of doing
both in the same time .. PIC edge and PIC core.

PS2: Sometimes you may hear others refering to PIC core as "indirect
next hop" feature. But in my email I was talking about PIC edge.