IETF Logo Mail Archive

Re: Protecting SR policy midpoints (draft-bashandy-rtgwg-segment-routing-ti-lfa)

Alexander Vainshtein <vinesasha@yahoo.com> Tue, 28 November 2017 16:12 UTC

Return-Path: <vinesasha@yahoo.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 B21061271FD for <rtgwg@ietfa.amsl.com>; Tue, 28 Nov 2017 08:12:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.652
X-Spam-Level:
X-Spam-Status: No, score=-3.652 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, REPTO_QUOTE_YAHOO=0.646, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 h12g6CROzfmg for <rtgwg@ietfa.amsl.com>; Tue, 28 Nov 2017 08:12:22 -0800 (PST)
Received: from sonic304-11.consmr.mail.bf2.yahoo.com (sonic304-11.consmr.mail.bf2.yahoo.com [74.6.128.34]) (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 20944126B72 for <rtgwg@ietf.org>; Tue, 28 Nov 2017 08:12:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1511885541; bh=JuD40jxpQMWyqXQ2O2oxZPLPA45zmHH4xLvp58T07uY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=ZXGxWUqJl94cl7Jgnax6FQ0AxEGPJvbcrAxdS8iO+1TxAM5xbg+6VtGrbUkSUYxLlB6N9u8A++Vdfj2zhiFUEd6sb1wayl6xA0sK3k/jhqBbxOpAB00WLl7Eg5uYE4MklYbO/EKv4k6nje18TflvknN+sd4rSF7PFOnApFHt3ONSGFKSJZ39FVVqkQpXKhbXXukMI7Mt/nW8LiObo56t6Me5neHX1Vx+/Ykn8FlVTtk/Ime14JSAcjPOwbqE/T5H3M7ZFVlAb95sJaKuTcCj6h5zzRseJnQ6KvTLddb8eYs1/Kp8+wiFd2CL0afCSISS7eLygKd6R/8K4cZsPloZjQ==
X-YMail-OSG: eeHCfAgVM1nUs5Yviyo1jytJ4nXGMMWoGbnkkgfIUEs.9LleYpy8JP4kZT0BoH. 2L5mcnrvvYmmqPNp3OwqJ11Nbnn5YI8q7UVmj9_Vq5T0Oltm63GJ4OdZxxrkHdGpi5PnrO0QRc7g TecEKERhwa2D613aXhvBr29ZtQtc9ukWxQftPRN3BKTpBvioxDNxrOJIyu6XFTDyJlNQZ3DNSbZ0 saZqR0J6if3t95pXWys7S_nvoes_ARG_NbVGURu_NG1B3Bl4RXyrIDvpGpUL4vQV5MzVUM1Loa.d V5uWBrc74NX_gIVqVlc777UTb01KayBZLaHGoEEcCokqJKzdKONf_kCoMtD9Ydgyw57oh75Tw4vR Vj5t40ts_hmXa7a3wVDzuhI7Wbg._Uo6.kdnOlI1jzvU5NIYX0pQsz1vuf92kgEHZmrzvG9B1s8W NVX6xmyPG4g0_rnHZQt1bHU1DCetDniE5jZVZdg7NGVqPinnzQzDmjsxygYoBE09V8IPhH0BktR8 aBxG7vKZyDfLdM0uUOI1BCPntNxwlx2WV
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Tue, 28 Nov 2017 16:12:21 +0000
Date: Tue, 28 Nov 2017 16:12:20 +0000
From: Alexander Vainshtein <vinesasha@yahoo.com>
Reply-To: "sasha@axerra.com" <sasha@axerra.com>
To: "stewart.bryant@gmail.com" <stewart.bryant@gmail.com>, "Ahmed Bashandy (bashandy)" <bashandy@cisco.com>, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>, "vinesasha@yahoo.com" <vinesasha@yahoo.com>
Cc: "rtgwg@ietf.org" <rtgwg@ietf.org>
Message-ID: <1697824571.4923773.1511885540152@mail.yahoo.com>
In-Reply-To: <8948158b-6fbe-4458-476a-ea1f8f34ee6c@gmail.com>
References: <CAKz0y8wLYjkSO486w5WpSuDYV3Cjvgkv6887o9-Ky9o_ViWMrQ@mail.gmail.com> <210606893.1211556.1511362363266@mail.yahoo.com> <CAKz0y8xeYnqOjLxADVwndtOp8QQaPeQBiAO2TtnCi6pYfebONA@mail.gmail.com> <5A1D50E5.7030302@cisco.com> <8948158b-6fbe-4458-476a-ea1f8f34ee6c@gmail.com>
Subject: Re: Protecting SR policy midpoints (draft-bashandy-rtgwg-segment-routing-ti-lfa)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_4923772_271825858.1511885540151"
X-Mailer: WebService/1.1.10982 YahooMailAndroidMobile YMobile/1.0 (com.yahoo.mobile.client.android.mail/5.21.2; Android/6.0.1; MMB29M; j5xnlte; samsung; SM-J510MN; 5.2; 1280x720; )
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/evzIHoGI_LwKvKS1tbpajqn4pXY>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 28 Nov 2017 16:12:24 -0000

Stewart,I understand your concern. However, as I see it, the alternatives to local protection of a failed pinned node of a SR-TE LSP are somewhat limited:
1. You can wait (with no traffic) until failure of the pinned node is recognized (e.g., fillowing IGP cobversion) and a new policy(that does not inckude the failed node) is recomputed and installed. 
2. You can pre-compute and pre-install a backup policy that does not have any common pinned nodes with the original ones and, once the origibal policy fails, switch ti the backup one end-to-end.
My 2c.


Sent from Yahoo Mail on Android 
 
  On Tue, Nov 28, 2017 at 9:15, Stewart Bryant<stewart.bryant@gmail.com> wrote:   

On 28/11/2017 12:04, Ahmed Bashandy (bashandy) wrote:
>
> - The top label of incoming packet to node "S" is either a prefix SID 
> owned by node "F" or an adjacency SID for (S,F)

If it is an adjacency SID for (S,F) then you are violating the original 
intent of the ingress PE which was to send the packet along the path 
S->F. I really don't think you can blindly repair such a packet since to 
do so violates the policy applied to the packet. You have to do a policy 
check, and you have to make sure that the packet is not subject to ECMP 
along the repair path since ECMP avoidance might have been the intent of 
using the SR Adjacency in the first place.

- Stewart

_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

v2.23.0 | Report a Bug | By Email