IETF Logo Mail Archive

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

Stewart Bryant <stewart.bryant@gmail.com> Thu, 23 November 2017 14:58 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 B80E512E048 for <rtgwg@ietfa.amsl.com>; Thu, 23 Nov 2017 06:58:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 I8a0JpwpDGGs for <rtgwg@ietfa.amsl.com>; Thu, 23 Nov 2017 06:58:54 -0800 (PST)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 E812112E047 for <rtgwg@ietf.org>; Thu, 23 Nov 2017 06:58:53 -0800 (PST)
Received: by mail-wm0-x22f.google.com with SMTP id r68so17505343wmr.3 for <rtgwg@ietf.org>; Thu, 23 Nov 2017 06:58:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=0hGD4DPzwBMUkf2ni4k9+UYLtbW6AkckkHI7796dB7w=; b=iNxDOcTgDDjQZpnmIovx7P5vP1wy+9B3iq6388fZ1XiwXtLhPdvrAIThFwSjy9swKe pM+uBNB+O0pGD/hvxySvTY2GvLXBiz6msKZdUAkBZ6x//F/iPETG3dMkynBEgGmflyyu 98Ax/7gJDioDSqh2kNRn9wgJgqR2B/2AhQCB2w+7eeyfpzf6cssTnjrSNBnM4DoUmqlm tJlCBaqNmSnQb1BbJcg0vnVULoll1LaCy7YGww0hcE6Qpo8sEsvivQAi/vFQl+J+3jIL 76GghId4TsNDQ5AlmZ+K0ZY4XBsr3GlVAG1Rn1o/kDZ06FHBU8JYiJtQZuiFkPjSyArn ojIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=0hGD4DPzwBMUkf2ni4k9+UYLtbW6AkckkHI7796dB7w=; b=uEGRJZ8EC/z6JG27EDF4Cp+eIvuOGVztQS2r+FBsc+Ui6Td54t+7EbqgLhVMBixvdh 9ZPt/kcSDJRusPyNh5mqXB3uao5uLF2+OuoFjkfMS8EHyPuuGrMraJ0K1lUdLc5qYZUK AFG/cj0dwvs32cH1DG5rT8hCzoisPcOSnwmQlEdXHGt8m5RD1zcYQQUPiB2oHnzSqO0+ kaZznP6roqAg9pIn4L9sAkCBh2ppMPwrtO+VHsztPHGMFy7GULwV7OuxIRHTAvVebk8R bfwTR9bIYdqkIc/nMSaMhfBC6LGYvnaM9a/nQrNZqURV8XenKBW6fEHToDNCBpucS7k2 4LTQ==
X-Gm-Message-State: AJaThX4cQ7vN1GGSMcAhLRnyOL3/WFIal+/BeZgsNerFplF1arOyvKhD MI7uf5tvL9GF8fL67ScLtOscE7KPgvI=
X-Google-Smtp-Source: AGs4zMZi1+Fkd8QHOfjEfRTX7q0T7CQPsIy+jLJNtxy0BwOAOxhK7KBTJtJeQUq2KDf/U780ecmlSA==
X-Received: by 10.28.66.19 with SMTP id p19mr7319949wma.64.1511449131886; Thu, 23 Nov 2017 06:58:51 -0800 (PST)
Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id 186sm6960796wmm.47.2017.11.23.06.58.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Nov 2017 06:58:51 -0800 (PST)
From: Stewart Bryant <stewart.bryant@gmail.com>
Subject: Re: Protecting SR policy midpoints (draft-bashandy-rtgwg-segment-routing-ti-lfa)
To: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>, "sasha@axerra.com" <sasha@axerra.com>
Cc: "rtgwg@ietf.org" <rtgwg@ietf.org>
References: <CAKz0y8wLYjkSO486w5WpSuDYV3Cjvgkv6887o9-Ky9o_ViWMrQ@mail.gmail.com> <210606893.1211556.1511362363266@mail.yahoo.com> <CAKz0y8xeYnqOjLxADVwndtOp8QQaPeQBiAO2TtnCi6pYfebONA@mail.gmail.com>
Message-ID: <c2ebcd37-ba10-485f-868b-72980e5fde54@gmail.com>
Date: Thu, 23 Nov 2017 14:58:48 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CAKz0y8xeYnqOjLxADVwndtOp8QQaPeQBiAO2TtnCi6pYfebONA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------906BF6659FE736BA53ACC46A"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/FcE2vi08KjC1iPpNSxrq7Geq2Xo>
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: Thu, 23 Nov 2017 14:58:56 -0000

 From my reading of the draft the proposal is  only to try to find the 
conventional shortest repair path from the PLR to the node specified by ToS

I have always though that this needed a health warning, as presumably 
the SR path was calculated for a reason and FRR needs to respect that 
reason.

This is true if ToS is an node-SID, it is even more the case if the ToS 
is an adj-SID.

- Stewart


On 23/11/2017 13:04, Muthu Arul Mozhi Perumal wrote:
> My understanding is that draft wants to provide a solution for the 
> problem where the active segment is a prefix/adjacency segment of the 
> neighbor and the neighbor fails. A solution to this is possible only 
> at a node that is enforcing the SR policy (consisting of the segment 
> list). For a transit node, its data plane would have to peek into the 
> label stack and determine the type of the segment/label following the 
> active segment and act accordingly, which is not inline with the SR 
> architecture which requires SR to work 'as is' on traditional MPLS 
> data plane
>
> ​Muthu​
>
> On Wed, Nov 22, 2017 at 8:22 PM, Alexander Vainshtein 
> <vinesasha@yahoo.com <mailto:vinesasha@yahoo.com>> wrote:
>
>     Muthu and all,
>     I do not see how the draft in quesrion us related to "SR Policy".
>
>     From my POV its scope is a SR LSP comprised of multiple Node SIDs
>     within a single IGP domain, and it provides local fast protection
>     against failure of a node that terminates one of the segments
>     comprising this LSP. Pritection action is performed by the
>     penultimate node.
>
>     My 2c.
>
>     Sent from Yahoo Mail on Android
>     <https://overview.mail.yahoo.com/mobile/?.src=Android>
>
>         On Wed, Nov 22, 2017 at 3:27, Muthu Arul Mozhi Perumal
>         <muthu.arul@gmail.com <mailto:muthu.arul@gmail.com>> wrote:
>         Section 5.3 of draft-bashandy-rtgwg-segment-routing-ti-lfa
>         describes protecting SR policy midpoints against node failure
>         for the case where the active segment is the prefix or
>         adjacency segment of a neighbor.
>
>         I believe the steps described in the procedure is applicable
>         only for a node steering packets into the SR policy. This
>         could be an ingress PE steering IP packets into a SR-TE tunnel
>         or an intermediate node steering labeled packets received with
>         a BSID into a SR-TE tunnel identified by that BSID.
>
>         A transit node that has no idea about the SR policy itself is
>         not expected to perform the procedure described in that section.
>
>         Is my understanding correct?
>
>         Regards,
>         Muthu
>         _______________________________________________
>         rtgwg mailing list
>         rtgwg@ietf.org <mailto:rtgwg@ietf.org>
>         https://www.ietf.org/mailman/listinfo/rtgwg
>         <https://www.ietf.org/mailman/listinfo/rtgwg>
>
>
>
>
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg

v2.23.0 | Report a Bug | By Email