Re: [spring] Beyond SRv6.

Dirk Steinberg <dirk@lapishills.com> Mon, 09 September 2019 13:31 UTC

Return-Path: <dirk@lapishills.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6463F12023E for <spring@ietfa.amsl.com>; Mon, 9 Sep 2019 06:31:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NO_DNS_FOR_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lapishills-com.20150623.gappssmtp.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 0inJ6-y-j7i6 for <spring@ietfa.amsl.com>; Mon, 9 Sep 2019 06:31:54 -0700 (PDT)
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 0B95212008F for <spring@ietf.org>; Mon, 9 Sep 2019 06:31:53 -0700 (PDT)
Received: by mail-wm1-x334.google.com with SMTP id 7so4234433wme.1 for <spring@ietf.org>; Mon, 09 Sep 2019 06:31:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lapishills-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=1FVEcBPkbhQlmoqAhDtV/YPsXXPM5DFRRn2V1SbQ0Do=; b=Q7j0cxMhmccNE6BqwIc9JR/rmMBS8FXwSGYfrNNErROmReQBe7oe6NIr54gyM2VMyx Ntce+Tu50o5TR5G7PmmutwmDG4yQ9+PzEjAtrSGEXqm6T5qtCSiBRtufBoDf52Y/R5av zjgdstrBI7EtIDYlmq74T07fleZAimyWnTzet3d+u6j1XVnAUci3v/fWPpokDzVgfwTN Dt9do0WNH7UH2apAAXgCCGy2OaZXdzNZCqqgBN8Mp/Z7l6nr/Sarw6p47JLJPsXNkkNd z3hAjfo9LHMaBtj3fPAiwtdSBNLWXi3sH4fvoss3wiQJxQN8YnNgp2SVUdc8JaGu//df fH7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=1FVEcBPkbhQlmoqAhDtV/YPsXXPM5DFRRn2V1SbQ0Do=; b=ROQtUVWMXGl4ZL5V1e+1KEBh/yR/KuRjFXKiqM7hud5gmuAE6CVxTI/tIEc70l08NH WrbXnp1Y22VZqubmSs7306TQGsE2xrYEFkQTko0SOC1+4bISk7I/suykCKLfdpnTw6Cc oOXtWc0C5kenUsgFJ8Je4RCzmk8zvGdAap4d1QrXVMFxev8mOh1Qb/XE9tK2HNiRRD+d XX1/Cu3Vz87csaBF3wHevHoc76trVXPlgh+WjWmhDRi+oj+BsvmtY/jdVqJS7TE18dNO zSedn6Kl/T8k5zni2s6+E0D1vvBmrpg0N9yq+Dy1g0Vn3vE33Wj+0h7RBcoczukxuOod Qotw==
X-Gm-Message-State: APjAAAWt3BjRDVe4PC+ragiMKXCW49yuY4vWyQ9+mZ06UZ94RfGsoyz8 lIBgTuJThgctbBBBLEnBUTmr4A==
X-Google-Smtp-Source: APXvYqw3NpWI+kfICNFW7jjkyuNKaFPgQyLdouk1B37ExXaDlnzKOkg/u6K31J/Wg+m1nEHWVvdb9Q==
X-Received: by 2002:a7b:c745:: with SMTP id w5mr17443151wmk.86.1568035911664; Mon, 09 Sep 2019 06:31:51 -0700 (PDT)
Received: from ?IPv6:2003:e6:171e:ce00:6878:62ae:587f:8f67? (p200300E6171ECE00687862AE587F8F67.dip0.t-ipconnect.de. [2003:e6:171e:ce00:6878:62ae:587f:8f67]) by smtp.gmail.com with ESMTPSA id d28sm16128984wrb.95.2019.09.09.06.31.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Sep 2019 06:31:50 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_9B28E1A8-6C27-4A03-9550-E1542EC3F3E8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Dirk Steinberg <dirk@lapishills.com>
In-Reply-To: <2F604D74-51CF-4F2F-AEA9-1CBDEEA9B9F7@gmail.com>
Date: Mon, 09 Sep 2019 15:31:49 +0200
Cc: Robert Raszuk <robert@raszuk.net>, SPRING WG List <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>, Ron Bonica <rbonica@juniper.net>, Srihari Sangli <ssangli@juniper.net>, Rob Shakir <robjs@google.com>, "Zafar Ali (zali)" <zali@cisco.com>, Tarek Saad <tsaad.net@gmail.com>
Message-Id: <F09C2D09-D769-4817-AF73-97D6ED1BC4BF@lapishills.com>
References: <CAHd-QWtA21+2Sm616Fnw0D-eB7SNb_BeG8-A-MCLLFgTwSpOsg@mail.gmail.com> <BYAPR05MB54632F09C712ADB30138CFA9AEBE0@BYAPR05MB5463.namprd05.prod.outlook.com> <BYAPR19MB3415D21403394F8129A4BAD8FCB90@BYAPR19MB3415.namprd19.prod.outlook.com> <30491F13-C652-45C3-AB2B-95F765FBB4EA@juniper.net> <65C5CB04-3A2F-4F83-A7C8-2045154F93AE@cisco.com> <BYAPR05MB5463EC3250F2A303A3641839AEBA0@BYAPR05MB5463.namprd05.prod.outlook.com> <91CBADAD-EFE6-46E1-A9D3-DAA111357179@juniper.net> <CAOj+MMGyUFRPDqCBo5SbLX486o_9GLpM6Zxf8KSt1voWiqhkGQ@mail.gmail.com> <E8D473B5-3E8D-4339-9A79-0CAE30750A55@juniper.net> <CAOj+MMFOy5PyTo=jPJkVrQOctdWjsTbD=7ix-2n89vodKzT3gQ@mail.gmail.com> <2F604D74-51CF-4F2F-AEA9-1CBDEEA9B9F7@gmail.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/c1m9mvCy5Tpj5FIhY8KcJusGuZw>
Subject: Re: [spring] Beyond SRv6.
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Sep 2019 13:31:56 -0000

There seems to be some confusion regarding TI-LFA.
A couple of comments:

- Remote LFA tunnel is not used with SR, only TI-LFA which 
  only operates on the node that is the PLR (point of local repair).

- Any encapsulation on the ingress PE with or without EH has nothing 
  to do with TI-LFA except for the special case where the ingress PE
  itself is the PLR.

- TI-LFA is not an IGP extension and does not require one. 
  It is a purely local computation based on IGP topology.

- The PLR for TI-LFA may need to insert some SIDs into the SID
  list to steer the packet around the failure. For the LFA base case
  no SIDs are needed at all. If SID insertion is needed, the PLR 
  will push the required number of labels in the MPLS case. 

  For SRv6, the equivalent operation to the label push is to 
  insert an EH with the required SID list. The packet will already 
  have been encapsulated on the ingress PE and in the most 
  common Internet or VPN base use case it will not even have 
  an EH so that this EH insertion will result only in a single EH.

  Alternatively, the PLR could also be configured to perform
  encapsulation with a new IPv6 header using the repair SID
  as IPv6 destination address, without needing any EH.
  This will work for the vast majority of cases. 
  Remember that one 128-bit SID in SRv6 is in most cases
  equivalent to 2 MPLS labels, i.e. a node label plus an
  adjacency SID can be encoded in a single SRv6 SID.

  Only in extreme cases would the PLR need to add an 
  EH to the new IPv6 header with more SIDs.

- EH insertion for TI-LFA has nothing to do with stitching SRv6 domains.

Hope it helps.

Cheers
Dirk

> Am 08.09.2019 um 09:19 schrieb Gyan Mishra <hayabusagsm@gmail.com>:
> 
> From reading through all the discussion threads the SR insertion is two fold one being for FRR capabilities using Ti-LFA or remote LFA tunnel so end up requiring double EH insertions on the Ingress PE tunnel head end SRv6 source node and then second scenario being a possible EH insertions occurrence on intermediate nodes.  I have not read through the drafts or RFC regarding Ti-LFA with SR but since that is an IGP extension I am guessing an opaque LSA and is not the traditional MPLS FRR link/node/path protection that adds an additional mpls shim so not sure why an EH insertion needs to occur for Ti-LFA.  Can someone clarify that use case for me.  Also the EH insertion on intermediate node what is the use case or reason for that.  My guess is it’s for special use case of stitching SRv6 domains together.  Please clarify..
>