Re: Microloop protection as discussed in today's meeting

Stewart Bryant <stewart.bryant@gmail.com> Wed, 20 July 2016 11:30 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09E312DBE0 for <rtgwg@ietfa.amsl.com>; Wed, 20 Jul 2016 04:30:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0B4dkibfJkcJ for <rtgwg@ietfa.amsl.com>; Wed, 20 Jul 2016 04:30:08 -0700 (PDT)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A8512DBD5 for <rtgwg@ietf.org>; Wed, 20 Jul 2016 04:30:07 -0700 (PDT)
Received: by mail-wm0-x230.google.com with SMTP id f65so171704343wmi.0 for <rtgwg@ietf.org>; Wed, 20 Jul 2016 04:30:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=og0XY0aFqWV7b0JfxWw4GPHqw8/zKOc2zNOV11u8mzE=; b=AfNHbxuoizyHzdoQAwsFcTmI59RcTdzQFR05wdOyu3SWtKKKOjokgnWbqAgVH+xqnM PdrLOe1oJptydlY+FOtdc2LqiVmSt1tqJIbkStnkaDYGjEWZrO59Ycl80wmB94gHxn3v 5NVAFhDyDUQNgbmCEdql20YZfgTwp3NSkthG+e/6e2UMWLtjfx9CSjryGhwDs8HgdwRR T5b8HcCL2ZE4ZcV69TlZ/cTPj/yDsEBqgcwx2xTj4YUdxPFhZPs8bWfLZNcZsZ3VGwSY 70KIUkYaiwSaF+f4TQPNLRjjuiQHronrXQ5Md8+17WPGqdTvHB48zyJqcmwoxif0yjOG qMlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=og0XY0aFqWV7b0JfxWw4GPHqw8/zKOc2zNOV11u8mzE=; b=GWwPAxxu5mt/49FjGJikt0R99z1qsaPnu2wAcPm3Y8P/9M1wvO02K4yIojrAIVKokA rZbeyYShiKy3xV2y4Sn+Z1lIdfJEI2QSjKHIYZ/Kwg44t0SiYUE2jpClJfp340logVWx 2oPPcyw5Y4vCyYDrBNZkDbxX2YB4Espu0hpPa36ELZeVoQTXI1/5Ck7ep9pl34L4Bs+c /EAPHv6eeC3aX30TQ0yqjfWm8cQPh0yw1rfWXSbsi21Gu4JvjS3p7TVS3qJ9GuzidFE/ rmE2bQiUrpnzURgJyKxO3r2C166hRm5dOO5j3uxlj17IGlOk113I8cJmdX+p80/0bYG4 LULg==
X-Gm-Message-State: ALyK8tJcE3ZIR2MUyn00BYEtYrymQUHo9Ah1Yp93IPj5hgO6HLniPStw+SwRBzIReW4o0g==
X-Received: by 10.194.185.38 with SMTP id ez6mr930393wjc.65.1469014204898; Wed, 20 Jul 2016 04:30:04 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:160:acc5:f3f9:b7f9:ac6e? ([2001:67c:370:160:acc5:f3f9:b7f9:ac6e]) by smtp.gmail.com with ESMTPSA id 17sm4681988wmf.6.2016.07.20.04.30.03 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Jul 2016 04:30:03 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
Subject: Re: Microloop protection as discussed in today's meeting
From: Stewart Bryant <stewart.bryant@gmail.com>
X-Mailer: iPhone Mail (13F69)
In-Reply-To: <578F3E93.3020403@cisco.com>
Date: Wed, 20 Jul 2016 12:30:03 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <C46C4400-3109-4FF6-9361-A6C4C7EE8383@gmail.com>
References: <578E3DBD.9030702@gmail.com> <578F3E93.3020403@cisco.com>
To: "Ahmed Bashandy (bashandy)" <bashandy@cisco.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/NB4ISs6f4B5GWA6XYc2leQzn0cI>
Cc: rtgwg@ietf.org
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jul 2016 11:30:17 -0000


> On 20 Jul 2016, at 10:04, Ahmed Bashandy (bashandy) <bashandy@cisco.com> wrote:
> 
> 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:)

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


> Ahmed
> 
> 
> 
> 
>> On 7/19/2016 7:48 AM, Stewart Bryant wrote:
>> 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
>> 
>> _______________________________________________
>> rtgwg mailing list
>> rtgwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtgwg
>