IETF Logo Mail Archive

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

Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> Thu, 23 November 2017 13:04 UTC

Return-Path: <muthu.arul@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 8EB1F128B88 for <rtgwg@ietfa.amsl.com>; Thu, 23 Nov 2017 05:04:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.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, HTML_MESSAGE=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 FUldNgWvALLy for <rtgwg@ietfa.amsl.com>; Thu, 23 Nov 2017 05:04:02 -0800 (PST)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 9F6A0128B4E for <rtgwg@ietf.org>; Thu, 23 Nov 2017 05:04:02 -0800 (PST)
Received: by mail-io0-x22d.google.com with SMTP id w127so26561327iow.11 for <rtgwg@ietf.org>; Thu, 23 Nov 2017 05:04:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UoXy8HMqam/tDjlsRQbBfN4ehxCOknRFV0loWMjCSPI=; b=izAu/rSjNJhEZ2yCD3s8ttOtQC//Ip3fxwP69LCI6oRbANvnknXU9ni+BJsGO/0v14 M3I8qzSZkzSbaeYL16+4wPMUoW++9jWhU2YUXsm46KEvXcj7wF+0nCo88bnvY2dmqcPp 8Hzij7d25iRoiEt7jGq5XhPtzO5f7+U5SdDkM73gcevv0SCYOxzBNpeftJODAcDXhROm mASGfjfFKyEhqWjQJLMpUEdvifBKiIoCROA3r4D1nfUv8RlL2c/PtzeoGVvY4F2dIAsK EYQ+/Pe4M/hUyZXMQmsa96nipLu0ws/JIUjDeFwf0nsFt2WlUN3HcjW8ACiuIb5i0G2F ZJ3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UoXy8HMqam/tDjlsRQbBfN4ehxCOknRFV0loWMjCSPI=; b=GXDtICuAuUPQFhutJ0i4k3J6vXLvh1cv7ITPesY4/IL5r2MjB6Tt4d+Ws0w0pCLpb/ si89wYD4DJakM1jKtNhHOODaoU9IpTKZ6ZYL6kobiGB/ImXRwl7fOJ41bh28uxqWzCYJ LgGukHxHfzdBbm/PtsUVxzXGgiPw5+Uv0pHT1L+1qPZZkqumc86W7W4k+9pU/B7DAG2y fjnDggg82lkD3Y1Kapt7eV4NAL82g/o2wayJ2EvXaXUu05hzLXApr7/h+11boRfnSoVM dGjOu5EagUQqwvDVBYoCkm9c6c8UAyKRbad5svMwTITssI/LgWbciRxjc71EC9oUH8dV 098w==
X-Gm-Message-State: AJaThX5pMCWeszQMENmRTRWAPQG36m4s5E29WHf44bT/oxYGlUIm41DD gE2E2fWe5gtz9hCye/uo2CrommC0LKr1oGr04Fk=
X-Google-Smtp-Source: AGs4zMYP1y6jOwXQu4pZCYpXYgAuZA5W3oVg/tRnX6iXSpLFqt5lP06RrGZYni1i3LubMwVNn6Lr4xkgO+e2yUEIZzc=
X-Received: by 10.107.51.136 with SMTP id z130mr2224343ioz.176.1511442241817; Thu, 23 Nov 2017 05:04:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.2.134.37 with HTTP; Thu, 23 Nov 2017 05:04:01 -0800 (PST)
In-Reply-To: <210606893.1211556.1511362363266@mail.yahoo.com>
References: <CAKz0y8wLYjkSO486w5WpSuDYV3Cjvgkv6887o9-Ky9o_ViWMrQ@mail.gmail.com> <210606893.1211556.1511362363266@mail.yahoo.com>
From: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
Date: Thu, 23 Nov 2017 18:34:01 +0530
Message-ID: <CAKz0y8xeYnqOjLxADVwndtOp8QQaPeQBiAO2TtnCi6pYfebONA@mail.gmail.com>
Subject: Re: Protecting SR policy midpoints (draft-bashandy-rtgwg-segment-routing-ti-lfa)
To: "sasha@axerra.com" <sasha@axerra.com>
Cc: "rtgwg@ietf.org" <rtgwg@ietf.org>
Content-Type: multipart/alternative; boundary="001a113a8d64ec1222055ea6110c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/lfeOyUW6CysSjfESwSzqMBCquqA>
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 13:04:04 -0000

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

v2.23.0 | Report a Bug | By Email