Subject: Microloop protection as discussed in today's meeting

From: Stewart Bryant <[email-masked]>
Date: Tue, 19 Jul 2016 15:48:29 +0100

Appologies if this is a duplicate.

The RFC that had all of the generic methods that were known at the time 
of publication is RFC5715.

The two phase methods were in section 6.2 (near-side) and section 6.3 
(far-side). The first describing tunnelling the traffic towards the 
repair (and continue to use the repair), the second describing 
tunnelling traffic towards the destination. For the purposes of this 
discussion source routing of all flavours can be considered a type of 
tunnel.

If this approach is a new  genetric  two phase method, it would be 
useful to articulate it in general terms.

The type of topology that I was trying to explain in the meeting is as 
follows

A-B-C-D-E-F-H-I-J.....W
|                     |
|                     |
+------X-Y-Z----------+

All costs are 1 and Y has failed.

Traffic to Z can enter enywhere, and is protected by X.

When the network starts to converge ALL the routers A..J will need to 
update their fib to forward towards Z via W rather than towards X via A.

If they do this in a random order as would be the case without LF 
convergence then you may precipitate microlooping.

What you need to do is to force the packets toward either X or Z using a 
tunnel, or a source routed path, and as far as I can see you need to do 
that at every point of potential entry into the network, in the above 
case A..J, else you risk a microloop.

Now I suppose that if ALL packets were source routed, then you could 
consider that the network was constantly in the first phase, but I think 
that you would need to use strict source routing, rather than loose 
source routing else it reduces the the problem I describe above.

- Stewart

---

From: "Ahmed Bashandy (bashandy)" <[email-masked]>
Date: Wed, 20 Jul 2016 02:04:19 -0700

Stewart,

You are stating the most obvious:)
For a feature to work, e.g. encapsulating into an RSVP tunnel, the entry 
point of the packet must be able to support that feature. That is not a 
problem. That how the entire world works:)

SR-based ti-uloop avoidance is no different. So if a packet arrives at 
node "D" for example, then node "D" must be able to steer the packet 
such that it guarantees loop-freeness.
Once "D" source-routes the packet into the loop-free path towards the 
destination "Z" , downstream routers from "D" towards "Z" need NOT have 
the ability to do uloop avoidance or even know that packets was 
source-routed by node "D"

As for the need for using "strict" vs "loose" source routing, that is 
topology dependent. The same applies for ti-lfa, rLFA, or even directly 
connected LFA.

One last thing, if you think that source routing can reduced to a 
"tunnel" we might as well shutdown SPRING WG:)

Ahmed

On 7/19/2016 7:48 AM, Stewart Bryant wrote:
> The RFC that had all of the generic methods that were known at the 
> time of publication is RFC5715.
>
> What you need to do is to force the packets toward either X or Z using 
> a tunnel, or a source routed path, and as far as I can see you need to 
> do that at every point of potential entry into the network, in the 
> above case A..J, else you risk a microloop.
>
> consider that the network was constantly in the first phase, but I 
> think that you would need to use strict source routing, rather than 
> loose source routing else it reduces the the problem I describe above.
>
>
> - Stewart
>
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 20 Jul 2016 12:30:03 +0100

> On 20 Jul 2016, at 10:04, Ahmed Bashandy (bashandy) <[email-masked]> wrote:
> 
> Stewart,
> 
> For a feature to work, e.g. encapsulating into an RSVP tunnel, the entry point of the packet must be able to support that feature. That is not a problem. That how the entire world works:)

So are you saying that your scheme only works in an rsvp only network, or in an SR only network. If so that constraint was not clear to me.

If you are saying that this works in an ordinary hop by hop network, then it needs to be made much clear to the WG that EVERY ingress router needs to apply the loop avoidance two phase strategy.

The diagram and presentation you used yesterday used too simple a topology to make that clear.

> 
> SR-based ti-uloop avoidance is no different. So if a packet arrives at node "D" for example, then node "D" must be able to steer the packet such that it guarantees loop-freeness.
> Once "D" source-routes the packet into the loop-free path towards the destination "Z" , downstream routers from "D" towards "Z" need NOT have the ability to do uloop avoidance or even know that packets was source-routed by node "D"

> 
> As for the need for using "strict" vs "loose" source routing, that is topology dependent. The same applies for ti-lfa, rLFA, or even directly connected LFA.
> 

> One last thing, if you think that source routing can reduced to a "tunnel" we might as well shutdown SPRING WG:)
> 

SR in an mpls network can be viewed as a set of concatenated tunnels. The complexity is all in the naming of the tunnel end points and the control plane.

Stewart

>> The RFC that had all of the generic methods that were known at the time of publication is RFC5715.
>> 
>> The two phase methods were in section 6.2 (near-side) and section 6.3 (far-side). The first describing tunnelling the traffic towards the repair (and continue to use the repair), the second describing tunnelling traffic towards the destination. For the purposes of this discussion source routing of all flavours can be considered a type of tunnel.
>> 
>> If this approach is a new  genetric  two phase method, it would be useful to articulate it in general terms.
>> 
>> The type of topology that I was trying to explain in the meeting is as follows
>> 
>> A-B-C-D-E-F-H-I-J.....W
>> |                     |
>> |                     |
>> +------X-Y-Z----------+
>> 
>> When the network starts to converge ALL the routers A..J will need to update their fib to forward towards Z via W rather than towards X via A.
>> 
>> If they do this in a random order as would be the case without LF convergence then you may precipitate microlooping.
>> 
>> What you need to do is to force the packets toward either X or Z using a tunnel, or a source routed path, and as far as I can see you need to do that at every point of potential entry into the network, in the above case A..J, else you risk a microloop.
>> 
>> Now I suppose that if ALL packets were source routed, then you could consider that the network was constantly in the first phase, but I think that you would need to use strict source routing, rather than loose source routing else it reduces the the problem I describe above.
>> 
>> 
>> - Stewart
>>