Subject: Re: Reconvergence micro-loops: problem and solutions overview

From: Stewart Bryant <[email-masked]>
Date: Fri, 01 Oct 2004 08:58:26 +0100

Alia Atlas wrote:

<snip>

>
> The benefit of U-Turn alternates is that it doesn't require MPLS or 
> any tunneling mechanism; without the tunneling, the full mesh for LDP 
> (if that is of interest) is not necessary. 

But the downside of U-turn is that it is a short range repair mechanism
that can only direct over at most two hops and hence requires a
downstream path within one hop of the repairer.

- Stewart

_______________________________________________
Rtgwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rtgwg

---

From: Alex Zinin <[email-masked]>
Date: Fri, 1 Oct 2004 12:41:33 -0400

Alia, folks

Wednesday, September 29, 2004, 9:21:51 PM, Alia Atlas wrote:
...
> The claim that only the tunnel egress needs to understand this mechanism
> appears to conflict with the argument being made that 100% coverage without 
> any network change is utterly critical and worth any complexity.

I'd like to understand where this "100% without any network change" requirement
is coming from. While I understand the desire to maximize coverage, I also have
learned a while ago that trying to get that 100 or solve every corner case often
comes at the price of greater complexity. I'm sure service providers knows even
better than I do, so I'm wondering what the reasons behind this requirement are.

Alex

---

From: Alia Atlas <[email-masked]>
Date: Fri, 01 Oct 2004 12:56:12 -0400

At 03:58 AM 10/1/2004, Stewart Bryant wrote:
>Alia Atlas wrote:
>
><snip>
>
>>
>>The benefit of U-Turn alternates is that it doesn't require MPLS or any 
>>tunneling mechanism; without the tunneling, the full mesh for LDP (if 
>>that is of interest) is not necessary.
>

It is important to engineer the network; how they are currently engineered 
is extremely close to what is needed.  Network engineering is necessary 
anyway, to ensure that a network remains at least 2-connected after a 
failure and to ensure that the use of links for alternates does not cause 
excessive congestion.

Alia

---

From: Albert Tian <[email-masked]>
Date: Fri, 01 Oct 2004 11:52:01 -0700

Hi,

Another downside of U-turn seems to be that it is a unicast only strategy, which
(correct me if I'm wrong) has no easy way to cover multicast traffic.

If we would like to go one step further from basic loopfree, it would very
desirable to have a mechanism that covers both unicast and multicast, perferably
LDP as well.

For link protection, if we use explicit repair paths that terminate on nexthops,
all types of traffic are covered: unicast, multicast, LDP traffic. No extension
is needed for PIM or LDP (except some minor ones to fix the RPF). Using explicit
repair paths, node protection for all these traffic types is also achievable
with more extensions.

Thanks,

Albert

---

From: Alia Atlas <[email-masked]>
Date: Fri, 01 Oct 2004 15:30:58 -0400

Albert,

The loop-free alternates are a unicast only strategy.  One can extend them 
in multiple directions.  One such direction is to look for a multicast 
solution.  It would be interesting to consider what modifications to the 
RPF check might be possible for just loop-free.

I believe that node protection is also quite interesting.

Alia

---

From: Albert Tian <[email-masked]>
Date: Fri, 01 Oct 2004 15:30:45 -0700

Hi, Alia,

I'm starting a new thread as multicast seems to a big topic. (Our real subjects
have drifted thousand miles from micro-loop prevention already :-)

We all know multicast routing protocols build distribution trees to deliver
multicast packets. When a link or node on the tree fails, some of the sub trees
downstream to the failure will be detached. So the key to protect multicast
traffic is to construct the repair paths to reattach the root of these subtrees
without going through the link or node being protected. Therefore the repair
paths have to terminate on these subtree roots. 

Because of this, both the basic loopfree and the U-turn will not work for
multicast. You can not find an alternative that is not on the distribution tree
and send traffic to it since that alternative will not have proper multicast
forwarding state.

Also because multicast forwarding states only exists on the distribution tree,
rerouted multicast traffic has to be encapsulated while traversing the repair
path. In other words, the repair paths have to be tunnels.

A clear solution is to use explicit paths to attach the subtree roots. In most
cases the subtree roots will be the nexthop or next-nexthops from unicast
routing point of view. 

In link protection, only one subtree can be detached due the link failure. So
the solution is to use an explicit repair path to connect the downstream node to
the upstream via a different route. The same explicit path can also be used for
unicast/LDP traffic protection, so in most of the cases no additional explicit
tunnels are needed.

In node protection, several subtrees can be detached due to node failure. So
multiple repair paths have to be established to connect each of the subtree
roots to the upstream nodes. The upstream must replicate the packets and send
onto each repair paths. In most cases, the subtree roots will be next-nexthops
for unicast routing.

Regarding the RPF, packets arriving from the repair path has to be accepted.
They may arrive on wrong interface and fail the RPF check.

So here are the requirements in summary:

a) repair paths have to terminate at the nexthops or next-nexthops (subtree
roots)
b) rerouted traffic must be encapsulated. (repair paths must be tunnels).
c) rerouted traffic must be accepted (pass the RPF check)

The TE tunnel based FRR solution satisfies all these requirements, and in most
cases no (or very few) additional tunels need to be maintained compares to
unicast FRR.

The current U-turn solution can not satisfy the first two requirements. The last
one is beyond the point if the first two issues can not be solved.

The tunnel based FRR solution satisfies the first requirement, but will need
double encapsulation (two GRE headers probably) for repair traffic when comes to
the second, since they used one encapsulation already. 

Thanks,

Albert

---

From: Alia Atlas <[email-masked]>
Date: Mon, 04 Oct 2004 22:55:58 -0400

Hi Albert,

I am not convinced that tunnels are the only way to go for 
multicast.  Don't they reduce or remove the benefit of sending the traffic 
as multicast for that portion of the network?  If the alternate path is to 
protect against a node failure and there are multiple neighbor's neighbors 
to be sent to, then it seems that bandwidth is wasted by doing the 
replication at the PLR.

Alia

---

From: Naiming Shen <[email-masked]>
Date: Tue, 05 Oct 2004 06:59:37 -0700

Alia,

We are discussing in the context of FRR multicast traffic during
the nexthop link/node failure, for a limited number of nexthop
or next-nexthop nodes, for a limited time such as a couple of
seconds. I don't think efficiency of bandwidth usage is a
major concern in this case.

thanks.

 ] Hi Albert,
 ] 
 ] I am not convinced that tunnels are the only way to go for 
 ] multicast.  Don't they reduce or remove the benefit of sending the traffic 
 ] as multicast for that portion of the network?  If the alternate path is to 
 ] protect against a node failure and there are multiple neighbor's neighbors 
 ] to be sent to, then it seems that bandwidth is wasted by doing the 
 ] replication at the PLR.
 ] 
 ] Alia
 ] 
 ] At 06:30 PM 10/1/2004, Albert Tian wrote:
 ] >Hi, Alia,
 ] >
 ] >I'm starting a new thread as multicast seems to a big topic. (Our real 
 ] >subjects
 ] >have drifted thousand miles from micro-loop prevention already :-)
 ] >
 ] >We all know multicast routing protocols build distribution trees to deliver
 ] >multicast packets. When a link or node on the tree fails, some of the sub 
 ] >trees
 ] >downstream to the failure will be detached. So the key to protect multicast
 ] >traffic is to construct the repair paths to reattach the root of these 
 ] >subtrees
 ] >without going through the link or node being protected. Therefore the repai
r
 ] >paths have to terminate on these subtree roots.
 ] >
 ] >Because of this, both the basic loopfree and the U-turn will not work for
 ] >multicast. You can not find an alternative that is not on the distribution 
 ] >tree
 ] >and send traffic to it since that alternative will not have proper multicas
t
 ] >forwarding state.
 ] >
 ] >Also because multicast forwarding states only exists on the distribution tr
ee,
 ] >rerouted multicast traffic has to be encapsulated while traversing the repa
ir
 ] >path. In other words, the repair paths have to be tunnels.
 ] >
 ] >A clear solution is to use explicit paths to attach the subtree roots. In m
ost
 ] >cases the subtree roots will be the nexthop or next-nexthops from unicast
 ] >routing point of view.
 ] >
 ] >In link protection, only one subtree can be detached due the link failure. 
So
 ] >the solution is to use an explicit repair path to connect the downstream 
 ] >node to
 ] >the upstream via a different route. The same explicit path can also be 
 ] >used for
 ] >unicast/LDP traffic protection, so in most of the cases no additional expli
cit
 ] >tunnels are needed.
 ] >
 ] >In node protection, several subtrees can be detached due to node failure. S
o
 ] >multiple repair paths have to be established to connect each of the subtree
 ] >roots to the upstream nodes. The upstream must replicate the packets and se
nd
 ] >onto each repair paths. In most cases, the subtree roots will be next-nexth
ops
 ] >for unicast routing.
 ] >
 ] >Regarding the RPF, packets arriving from the repair path has to be accepted
.
 ] >They may arrive on wrong interface and fail the RPF check.
 ] >
 ] >So here are the requirements in summary:
 ] >
 ] >a) repair paths have to terminate at the nexthops or next-nexthops (subtree
 ] >roots)
 ] >b) rerouted traffic must be encapsulated. (repair paths must be tunnels).
 ] >c) rerouted traffic must be accepted (pass the RPF check)
 ] >
 ] >The TE tunnel based FRR solution satisfies all these requirements, and in m
ost
 ] >cases no (or very few) additional tunels need to be maintained compares to
 ] >unicast FRR.
 ] >
 ] >The current U-turn solution can not satisfy the first two requirements. 
 ] >The last
 ] >one is beyond the point if the first two issues can not be solved.
 ] >
 ] >The tunnel based FRR solution satisfies the first requirement, but will nee
d
 ] >double encapsulation (two GRE headers probably) for repair traffic when 
 ] >comes to
 ] >the second, since they used one encapsulation already.
 ] >
 ] >Thanks,
 ] >
 ] >Albert
 ] >
 ] >
 ] >Alia Atlas wrote:
 ] > >
 ] > > Albert,
 ] > >
 ] > > The loop-free alternates are a unicast only strategy.  One can extend th
em
 ] > > in multiple directions.  One such direction is to look for a multicast
 ] > > solution.  It would be interesting to consider what modifications to the
 ] > > RPF check might be possible for just loop-free.
 ] > >
 ] > > I believe that node protection is also quite interesting.
 ] > >
 ] > > Alia
 ] > >
 ] > > At 02:52 PM 10/1/2004, Albert Tian wrote:
 ] > > >Hi,
 ] > > >
 ] > > >Another downside of U-turn seems to be that it is a unicast only strate
gy,
 ] > > >which
 ] > > >(correct me if I'm wrong) has no easy way to cover multicast traffic.
 ] > > >
 ] > > >If we would like to go one step further from basic loopfree, it would v
ery
 ] > > >desirable to have a mechanism that covers both unicast and multicast,
 ] > > >perferably
 ] > > >LDP as well.
 ] > > >
 ] > > >For link protection, if we use explicit repair paths that terminate on
 ] > > >nexthops,
 ] > > >all types of traffic are covered: unicast, multicast, LDP traffic. No
 ] > > >extension
 ] > > >is needed for PIM or LDP (except some minor ones to fix the RPF). Using
 ] > > >explicit
 ] > > >repair paths, node protection for all these traffic types is also 
 ] > achievable
 ] > > >with more extensions.
 ] > > >
 ] > > >Thanks,
 ] > > >
 ] > > >Albert
 ] > > >
 ] > > >Stewart Bryant wrote:
 ] > > > >
 ] > > > > Alia Atlas wrote:
 ] > > > >
 ] > > > > <snip>
 ] > > > >
 ] > > > > >
 ] > > > > > The benefit of U-Turn alternates is that it doesn't require MPLS o
r
 ] > > > > > any tunneling mechanism; without the tunneling, the full mesh for 
LDP
 ] > > > > > (if that is of interest) is not necessary.
 ] > > > >
 ] > > > > But the downside of U-turn is that it is a short range repair mechan
ism
 ] > > > > that can only direct over at most two hops and hence requires a
 ] > > > > downstream path within one hop of the repairer.
 ] > > > >
 ] > > > > - Stewart
 ] 
 ] 
 ] 
 ] _______________________________________________
 ] Rtgwg mailing list
 ] [email-masked]
 ] https://www1.ietf.org/mailman/listinfo/rtgwg

- Naiming