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

"Ahmed Bashandy (bashandy)" <bashandy@cisco.com> Fri, 01 December 2017 18:02 UTC

Return-Path: <bashandy@cisco.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 E9C311277BB for <rtgwg@ietfa.amsl.com>; Fri, 1 Dec 2017 10:02:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level:
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ExfqUyIxpVgS for <rtgwg@ietfa.amsl.com>; Fri, 1 Dec 2017 10:02:57 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A1521275C5 for <rtgwg@ietf.org>; Fri, 1 Dec 2017 10:02:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7430; q=dns/txt; s=iport; t=1512151377; x=1513360977; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=VX2j2NgjMWIMPzrGAbkHuco2/dLk24pJq9eInHWwHfU=; b=f/tINcQrGaa6LbpJlDfWPWUm1hi0bIn35+eXShc6cBpRFJqraDd5nZB2 WTWU2giOloDIqm/7sRWi3oM0pErYK4Uu6Yk2Fsfw2T8vLuLzlg+wmk1aP y1ePpxv8ZR1FdvjHq63ayKjioDoPTUU8tUfigMS5AekPcNOigMCPJJcQ8 E=;
X-IronPort-AV: E=Sophos; i="5.45,346,1508803200"; d="scan'208,217"; a="38511868"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Dec 2017 18:02:57 +0000
Received: from [10.82.177.212] ([10.82.177.212]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id vB1I2t5P016565; Fri, 1 Dec 2017 18:02:55 GMT
Message-ID: <5A21994F.6070505@cisco.com>
Date: Fri, 01 Dec 2017 10:02:55 -0800
From: "Ahmed Bashandy (bashandy)" <bashandy@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "sasha@axerra.com" <sasha@axerra.com>, Stewart Bryant <stewart.bryant@gmail.com>, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
CC: "rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: Re: Protecting SR policy midpoints (draft-bashandy-rtgwg-segment-routing-ti-lfa)
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> <5A1D967F.4020905@cisco.com> <1801950905.4960953.1511889350900@mail.yahoo.com>
In-Reply-To: <1801950905.4960953.1511889350900@mail.yahoo.com>
Content-Type: multipart/alternative; boundary="------------030707050303050409070900"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/N4rYe90lc7lGqO9TQLrHRXT_FNs>
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: Fri, 01 Dec 2017 18:02:59 -0000

Not necessarily. However even if the intention of marking the adj-SID as 
protected is to protect against the failure of the link but not the far 
end of the link, then it is the responsibility of operator who 
instantiated the policy creator to know what is the type of protection 
that he/she configured on the link.


Ahmed

On 11/28/2017 9:15 AM, Alexander Vainshtein wrote:
> Ahmed,
> I believe that the so-called protected Adj-SID simply means that if 
> the link that it represents fails, it can be replaced with the 
> Node-SID of the node at the remote end if the adjacency.
> It does not help at all if the downstream node fails.
>
> Sent from Yahoo Mail on Android 
> <https://overview.mail.yahoo.com/mobile/?.src=Android>
>
>     On Tue, Nov 28, 2017 at 11:02, Ahmed Bashandy (bashandy)
>     <bashandy@cisco.com> wrote:
>     Stewart,
>
>     I am sure you are aware that ISIS and OSPF adj-SID advertisements
>     indicate whether an adj-SID is protected or not. If the ingress
>     router
>     decided to use a protected adj-SID for a policy, then the
>     protection of
>     such adj-SID is within the policy.
>
>     Ahmed
>
>     On 11/28/2017 7:15 AM, Stewart Bryant 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 <mailto:rtgwg@ietf.org>
>     https://www.ietf.org/mailman/listinfo/rtgwg
>