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

Alexander Vainshtein <vinesasha@yahoo.com> Tue, 28 November 2017 17:15 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 B64DA126DED for <rtgwg@ietfa.amsl.com>; Tue, 28 Nov 2017 09:15:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.872
X-Spam-Level:
X-Spam-Status: No, score=-0.872 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, REPTO_QUOTE_YAHOO=0.646, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 Vp55JSERBupk for <rtgwg@ietfa.amsl.com>; Tue, 28 Nov 2017 09:15:56 -0800 (PST)
Received: from sonic315-13.consmr.mail.bf2.yahoo.com (sonic315-13.consmr.mail.bf2.yahoo.com [74.6.134.123]) (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 81CE5128896 for <rtgwg@ietf.org>; Tue, 28 Nov 2017 09:15:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1511889355; bh=TfvlYxtEPV2xgWFUB+288fs4kVMR5iri+yhKuMgzkBY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=dBbSQczWiyu61ToBLATy3LsJzSqo5QYQhpWC8IxnbP6dMsZBbIwmWzL/Q04SawP06qdvCUTABh+Fcr0WsHO6cSfguz+LmxV7GFDIVwkjSwP8PNT96JcVlKBajvg0BhKgFsTLBZsqggBabXXtZSL4EJTQlhCRuigCHQqibM69PN2Bjqx0u7r0ODABAdGb3H/5ri7qhs50fbyZabEsQdAL3clAkbybMGDADHy/u/1uf943o6uVEvmegpyjNtGCl8S7mKp40L4QjD620tufoSQxxvBFAjJucoB6vHR8V9ju6FJvL3qRgAmCjS0lvw4IkEV+v+ckRSfPW6U0HU0ismTobQ==
X-YMail-OSG: br4EZHoVM1l.saXriFOzkZCV8GkwF2Yt8i2wJ.wNKvLteLOd.2Rz4QTaCr3C_Z5 XHhbA6iq960aIMZQrXjJMj6CdoduEfGtnHwyH2k_BEmutXBAE8RHoh1Ua_tfqgUL8_odVxSkRDID L.g5p8IvhwnBpvCIgkmnNshkbmbb4_bNdV2k2PUHfKQXx7.Gdn9tgj8FMmTZBa0oWTI2vhaGYOAH m68R.NlBWHZ9OZDfiWSQA4JQjUxvDmgBxdOQcVqAd6aJu8sEvQBe5w0yVb1r5r4RIzuQclIQWZVe svNYpaFYvopIEMz0DoCCjfF6.XZv2q6YI0s.KVWdgd0EWybdYOvXRqAreP0_DWUvSZo5ciq5jMp1 k_0WsEKTStPXAQQadYdLxMd.WQiCOwKWugXfiQx3Kiv_Oi_KJBVDa8aK80Xhn_XtOETn8rbHjo9V EzurikSf8VWTBtEZJScFlcgR_dZ.OmiDQl1.DUx9H2ryNJZlS67VpOiT2JUkJCHsCJ6cWwetGXaa LJmV0JqQGXN2Opp4S8frislbONlWAemEE
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Tue, 28 Nov 2017 17:15:55 +0000
Date: Tue, 28 Nov 2017 17:15:50 +0000
From: Alexander Vainshtein <vinesasha@yahoo.com>
Reply-To: "sasha@axerra.com" <sasha@axerra.com>
To: "bashandy@cisco.com" <bashandy@cisco.com>, Stewart Bryant <stewart.bryant@gmail.com>, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>, "sasha@axerra.com" <sasha@axerra.com>
Cc: "rtgwg@ietf.org" <rtgwg@ietf.org>
Message-ID: <1801950905.4960953.1511889350900@mail.yahoo.com>
In-Reply-To: <5A1D967F.4020905@cisco.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> <5A1D967F.4020905@cisco.com>
Subject: Re: Protecting SR policy midpoints (draft-bashandy-rtgwg-segment-routing-ti-lfa)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_4960952_1076717765.1511889350898"
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/WajCDDsxSQVaFKGU681wn2mOSNk>
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 17:15:58 -0000

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 
 
  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
https://www.ietf.org/mailman/listinfo/rtgwg