Re: [spring] Beyond SRv6.

"Bernier, Daniel" <daniel.bernier@bell.ca> Thu, 12 September 2019 03:41 UTC

Return-Path: <prvs=151929c4c=daniel.bernier@bell.ca>
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 B5AB51200B7; Wed, 11 Sep 2019 20:41:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 eGz7MnJdSWeq; Wed, 11 Sep 2019 20:41:07 -0700 (PDT)
Received: from ESA4-Wyn.bell.ca (esa4-wyn.bell.ca [67.69.243.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CF30120086; Wed, 11 Sep 2019 20:41:06 -0700 (PDT)
Received: from dm5czo-d01.bellca.int.bell.ca (HELO DG1MBX02-WYN.bell.corp.bce.ca) ([198.235.102.33]) by esa04corp-wyn.bell.corp.bce.ca with ESMTP; 11 Sep 2019 23:41:05 -0400
Received: from DG1MBX04-WYN.bell.corp.bce.ca (2002:8eb6:120e::8eb6:120e) by DG1MBX02-WYN.bell.corp.bce.ca (2002:8eb6:120c::8eb6:120c) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 11 Sep 2019 23:41:05 -0400
Received: from DG1MBX04-WYN.bell.corp.bce.ca ([fe80::c426:98cc:c3a7:f8d2]) by DG1MBX04-WYN.bell.corp.bce.ca ([fe80::c426:98cc:c3a7:f8d2%22]) with mapi id 15.00.1473.003; Wed, 11 Sep 2019 23:41:05 -0400
From: "Bernier, Daniel" <daniel.bernier@bell.ca>
To: "xiechf@chinatelecom.cn" <xiechf@chinatelecom.cn>, List <spring@ietf.org>
CC: Rob Shakir <robjs@google.com>, 6man <6man@ietf.org>, Tarek Saad <tsaad.net@gmail.com>, Robert Raszuk <robert@raszuk.net>
Thread-Topic: [EXT]Re: [spring] Beyond SRv6.
Thread-Index: AQHVZL2AD+D3qA4K6UCn/8wcduqXface9VOAgAKvwgCAAfpbgIADoVU7gAAi7mw=
Date: Thu, 12 Sep 2019 03:41:05 +0000
Message-ID: <1568259664564.62561@bell.ca>
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>, <F09C2D09-D769-4817-AF73-97D6ED1BC4BF@lapishills.com>, <201909120857387140042@chinatelecom.cn>
In-Reply-To: <201909120857387140042@chinatelecom.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.24.25.6]
Content-Type: multipart/alternative; boundary="_000_156825966456462561bellca_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/sC8NIlr81sVDzp5bXsoFQSSBL9Y>
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: Thu, 12 Sep 2019 03:41:11 -0000

+1


The ability of using a single SRH to convey behaviour information wether they are per-segment or per-path has proven to be very simple and quick to define in various data plane targets.


At first analysis, trying to replicate with CRH + DOH variants, the logic required for service programs is more com​plex.


What happens if I need TLVs mid-point in a path but not at its end (e.g. referring to the Ole's ACME analogy) ? Would they now be defined in a seg-end-opt or a vpn-dest-opt ? If seg-end-opt then it means non-interested midpoint devices will have to lookup beyond the TLVs to get to CRH for next segment ?


Similar question would be on how would we implement proxy behaviours either dynamic or static ? If I read https://tools.ietf.org/html/draft-bonica-6man-seg-end-opt-04 correctly, we then need NSH for richer service chains constructs (think Gi-LAN). This means I need CRH, some variants of DOH + NSH​.


I fail to see the simplicity there.


Dan B

________________________________
From: spring <spring-bounces@ietf.org> on behalf of xiechf@chinatelecom.cn <xiechf@chinatelecom.cn>
Sent: Wednesday, September 11, 2019 8:57 PM
To: List
Cc: Rob Shakir; 6man; Tarek Saad; Robert Raszuk
Subject: [EXT]Re: [spring] Beyond SRv6.


Hi, folks,
Last year China Telecom begun to implement SRv6 trial in Sichun province for the bearing and interconnection of video platforms which are  located in different cities, service agilities,secure sepertion, traffic steering and other features of SRv6 have been demonstrated in this trial. Based on this, SRv6 will be implementated in larger-scale in CT.
No technologies is 100% perfect,I agree that compression mechanism is needed to reduce the the overhead of long SID in the long term, but it is better to be compatible withe SRH, instead of designing a complete new one. CRH is a complete new design, it move the complexities from SRH to DOH.
Moreover, I hope more efforts of SRv6 should be given on how to support new services,for instance, Application-aware network (APN). Meanwhile, we should consider more on how to implmement smooth transition and protect the network assetof carriers.

Best regards
Chongfeng


From: Dirk Steinberg<mailto:dirk@lapishills.com>
Date: 2019-09-09 21:31
To: Gyan Mishra<mailto:hayabusagsm@gmail.com>
CC: SPRING WG List<mailto:spring@ietf.org>; 6man@ietf.org<mailto:6man@ietf.org>; Robert Raszuk<mailto:robert@raszuk.net>; Rob Shakir<mailto:robjs@google.com>; Tarek Saad<mailto:tsaad.net@gmail.com>
Subject: Re: [spring] Beyond SRv6.
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<mailto: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..