Re: [spring] 答复: Questions about the life span of Path Segment

"Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com> Thu, 01 August 2019 12:11 UTC

Return-Path: <rgandhi@cisco.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 D1D3812009C; Thu, 1 Aug 2019 05:11:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=F9YG3t4v; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=itBy3pVM
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 ogixdkW7TriW; Thu, 1 Aug 2019 05:11:26 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F9B312008C; Thu, 1 Aug 2019 05:11:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29593; q=dns/txt; s=iport; t=1564661486; x=1565871086; h=from:to:cc:subject:date:message-id:mime-version; bh=CtAnAU5SEiPAT3u9ZAzhxh4VilBdlubmz6F4OcmYfOc=; b=F9YG3t4vSzMaZb4wmt2cGBhq9lnNT4uIZiGtJF0oKjZfn83Dreu2tPRs T9J6dZ+KZsYtnusyLDMNeVsiqjjSqvKrQ3xymYvfPFlvxTrBMO1y3wFZO iJOgfk53+SITHLtrP1q6q1zXnUtHNMfgGZPAQnlxeOlAdF0Q7CF4orOw3 8=;
IronPort-PHdr: 9a23:JSDeAxIZHiecKrKVZ9mcpTVXNCE6p7X5OBIU4ZM7irVIN76u5InmIFeBvad2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUgMdz8AfngguGsmAXFf0Jfjmby0SF8VZX1gj9Ha+YgBY
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AoAAA41kJd/4ENJK1lGgEBAQEBAgEBAQEHAgEBAQGBVgIBAQEBCwGBFS8kBScDbVUgBAsqhB6DRwOLJ4Jbl1eBQoEQA1QJAQEBDAEBLQIBAYRAAheCPSM3Bg4BAwEBBAEBAgEGbYUeDIVKAQIBAxIRChMBATcBDQQBBgIRAwECIQoCBBQcGgMKBAENBRkJgwABgR1NAx0BApBOkGECgTiIYHGBMoJ6AQEFhQMYghMJBYEvAYtfF4FAP4E4H4IeLj6EDAUBEgEmBwkIAQcRglMygiaMFIJxhQSXDgkCghqIHot9G4IuhyiOQoMpiHaBI5dlAgQCBAUCDgEBBYFmImdxcBVlAYJBgkIMFy9UAQKCSIpTcoEpijqCQwEB
X-IronPort-AV: E=Sophos;i="5.64,334,1559520000"; d="scan'208,217";a="607426861"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Aug 2019 12:11:24 +0000
Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x71CBOna015333 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Aug 2019 12:11:24 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 1 Aug 2019 07:11:24 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 1 Aug 2019 07:11:23 -0500
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 1 Aug 2019 08:11:23 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WEnqaR3dDsfEwCjyMEz9vCTHRpfGU5IYaOFwoC67XY2XlQeO9dZf23oCmh0ek9W+ZZW6Da9UV7WKR9OCKY10W4b3a3JjDlj54N6M/a8F+X+Ci3UzSIqRQb9CtRfrsQk1Dbr+1kanw8LIR08VbMpeJJ5PgBTrJ/r4szGpaNAtXPp2YsKoSOp2Ck4euzFMT0YEiYsfBpps37p7Qd2/+ICZXWJtXTJOz2cGhsSCfDxagcbX6Rfrl9qJ5tyY4+KSFiHgj3N4W+X1WGgf1yziykWh6PLn1IXvMlcF+X6WfIYrsTlrr7aFlB8PCBaUNEPIQlaOWJ1qx0Q7nQKL+ezOGtKVNA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CtAnAU5SEiPAT3u9ZAzhxh4VilBdlubmz6F4OcmYfOc=; b=GTrWAR4ySXM7TEj7LIoTfMCxVfNjx5wjK6J8pg165oKwRO/G8gxBdSHX6xJxYilcZUJ1SACZhhmkQONLRYX1KkfytG9qEHoi4oafuvxIb1UGHEkCEhFwFCigoEBFJUf00WpIochCvMJj5Gek1L9uYninhvjgPO7zttFtFXujewTbuhZFy0UB07uRJa//Myld1Q1/pow75nLmd7QMmrmAmARW8GLND1bOcM2gCe/s5xXjalLs/Z3q/2yzySGaI619OXl/AzlMfy0hMW8WYJ+65vU44/08KoKgagDL0kzcqI12LSW0a5MhqfE5NXj/Z9MdTpiBKocmr/1x7+5u6cGU5w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CtAnAU5SEiPAT3u9ZAzhxh4VilBdlubmz6F4OcmYfOc=; b=itBy3pVMTNoNQHwkwlzW5ss6oHzxf8aOgubciVUAMkNxIBKCfpg/udyLuoL0weOAOx1/09WRE8ryx04p2/lamEJlS3cRJ1CMG3oOZQdmSP6kV6lwbysnIxtWnnW5NQK2YvoEzGby92/6lCoEMV1Zk4wHbpIAGMkm0XHDwpQbhA4=
Received: from SN6PR11MB3278.namprd11.prod.outlook.com (52.135.109.11) by SN6PR11MB2976.namprd11.prod.outlook.com (52.135.124.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.16; Thu, 1 Aug 2019 12:11:21 +0000
Received: from SN6PR11MB3278.namprd11.prod.outlook.com ([fe80::d97f:e2dd:1ea6:303f]) by SN6PR11MB3278.namprd11.prod.outlook.com ([fe80::d97f:e2dd:1ea6:303f%5]) with mapi id 15.20.2094.013; Thu, 1 Aug 2019 12:11:21 +0000
From: "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>
To: "Chengli (Cheng Li)" <chengli13@huawei.com>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "draft-ietf-spring-mpls-path-segment.authors@ietf.org" <draft-ietf-spring-mpls-path-segment.authors@ietf.org>
CC: "spring@ietf.org" <spring@ietf.org>
Thread-Topic: 答复: Questions about the life span of Path Segment
Thread-Index: AQHVSGI7V57QNfT8nUODjh+CEYl+Mw==
Date: Thu, 01 Aug 2019 12:11:21 +0000
Message-ID: <A48750D3-3B63-45A3-A593-B81AEC2DFBB4@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.c.190715
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rgandhi@cisco.com;
x-originating-ip: [2001:420:c0c4:1002::65]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9cee10b8-8408-4b95-e529-08d716795df1
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:SN6PR11MB2976;
x-ms-traffictypediagnostic: SN6PR11MB2976:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <SN6PR11MB29768651F13D938EA5413BDBBFDE0@SN6PR11MB2976.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01165471DB
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(39860400002)(366004)(376002)(396003)(51874003)(199004)(189003)(14444005)(9326002)(6306002)(54896002)(478600001)(6512007)(81156014)(81166006)(229853002)(46003)(2616005)(25786009)(186003)(6506007)(6436002)(66946007)(66476007)(66446008)(66556008)(64756008)(91956017)(76116006)(14454004)(36756003)(102836004)(2906002)(6486002)(53546011)(8936002)(6116002)(790700001)(71200400001)(86362001)(58126008)(2501003)(53936002)(71190400001)(224303003)(6246003)(110136005)(7736002)(256004)(486006)(99286004)(68736007)(5660300002)(316002)(476003)(4326008)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR11MB2976; H:SN6PR11MB3278.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: SsZQXn9HWWtgYUvDLmfswuOqZM1GElZMZUorYLMnP8LSG6Iet0YwX/Di8rPHwsPr3MIAcDMbkMIvw5CTdc1RVV6QL+lD+shdiOCtiW/ixxX5p0BndpGIf8H/V0vvb2GYjleseUxwkCnGip3mhCFv2GluSFeI3WuEMQtv2AmkA2HiYXE1l3OnBJc3wYwFnNnlqilymTI6QCGRsj9vH2gaGx6VchErBK0kzHcdTtvn8aaLOGsRKyuiNqIrNODCrSbLjmCr0kRJi2mo4t7hicH628qC+l31BsGWGxTY0878sP16CaDs7uvj2SqRGR8Kw8CshcSp6Fi9OG0V0sA1qdREEi419RQ57b1fvdpeNX7qOl1X2Ffm32FmmUoiW63IxG6wjZsl4lg/bl0P9+QXRWjek+Y8Ra+eTrXueD/fCuCP/Xc=
Content-Type: multipart/alternative; boundary="_000_A48750D33B6345A3A593B81AEC2DFBB4ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 9cee10b8-8408-4b95-e529-08d716795df1
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Aug 2019 12:11:21.8102 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: rgandhi@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2976
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.29, xch-aln-019.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/Ptx0RL37XvE_l515GuemwHPu7e0>
Subject: Re: [spring] 答复: Questions about the life span of Path Segment
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, 01 Aug 2019 12:11:29 -0000

Hi Sasha,
For PM loss measurement use-case, the same path segment ID can be used during the life span of SR Policy.

Thanks,
Rakesh


From: "Chengli (Cheng Li)" <chengli13@huawei.com>
Date: Friday, July 26, 2019 at 11:43 AM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "draft-ietf-spring-mpls-path-segment.authors@ietf.org" <draft-ietf-spring-mpls-path-segment.authors@ietf.org>
Cc: "spring@ietf.org" <spring@ietf.org>
Subject: 答复: Questions about the life span of Path Segment
Resent-From: <alias-bounces@ietf.org>
Resent-To: <chengweiqiang@chinamobile.com>, <lihan@chinamobile.com>, <mach.chen@huawei.com>, "=SMTP:rgandhi@cisco. com" <rgandhi@cisco.com>, <royi.zigler@broadcom.com>
Resent-Date: Friday, July 26, 2019 at 11:43 AM

Hi Sasha,

Many thanks for you comments and sorry for my delay. Please see my reply inline.

Cheng

________________________________
发件人: spring [spring-bounces@ietf.org] 代表 Alexander Vainshtein [Alexander.Vainshtein@ecitele.com]
发送时间: 2019年7月24日 23:27
收件人: draft-ietf-spring-mpls-path-segment.authors@ietf.org
抄送: spring@ietf.org
主题: [spring] Questions about the life span of Path Segment
Dear colleagues,
I have a couple of questions about the life span of the Path Segment.

Suppose that some entity has computed and instantiated an SR LP that follows a specific path from the ingress node to the  egress node across a single IGP domain. This path is expressed as a sequence of valid IGP Segments (e.g., Node and/or Adjacency segments) .
Suppose also that a Path Segment has been allocated by the egress node for this path, and the ingress node is aware of this and inserts the label acting as the SID for the Path segments immediately after the last SID of the path.

Now my questions:

1.       What happens to the Path Segment when one of the IGP segments defining the original path fails?

a.       To the best of my understanding the path itself becomes invalid

[Cheng] Agree. But IMO, the path segment has the same life circle with the associated LSP. so it MAY not be invalid in FRR since the egress, ingress even the controller does not know that until the Reroute is triggered, then it should be treated as invalid.



b.       Will the Path Segment that identifies the now invalid path be retained indefinitely, or would it be invalidated as well and the label acting as its SID released?

[Cheng] Honestly, I think it depends on implementation. The the LSP fails, then the related Path Segment is invalid. But when the Rerouted LSP is installed, the path segment should be allocated, and we don't make any assumption of the value of the path segment. It CAN be the same value as the previous one.



2.       Suppose that the entity that has computed and instantiated the original path re-computes it and instantiate a new valid path.

a.       Should the new path (that replaces the invalidated original one) be allocated with the same Path Segment as the original path, or should a new Path Segment be allocated for it?

[Cheng] Same as above. As long as the information is synchronized between the controller and the data plane, any value is OK. But the same path segment should be recommended.



b.       If the Path Segment allocated for the invalidated path is released (see (1b) above), can the label that identified it be re-used as the Path Segment ID immediately, or only after some delay?

[Cheng] It depends on the implementation. Just to make sure that the path segment can be available.



From my POV the answers to these questions do not depend on the actual method by which the Path Segments are allocated and propagated from the egress node to the ingress one.
And while my questions explicitly mention IGP Segments that define the SR LSP for which the Path Segment is allocated, the desired behavior should not depend on the type of segments used in the definition of the path.
[Cheng] Sure.

Your feedback would be highly appreciated.

Regards, and lots of thanks in advance,
[Cheng] Thank you as well for valuable comments.
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________