Re: [Pce] Change Path Attrubute Object to a Sub-object

"Mike Koldychev (mkoldych)" <mkoldych@cisco.com> Tue, 12 May 2020 15:49 UTC

Return-Path: <mkoldych@cisco.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056143A0B72; Tue, 12 May 2020 08:49:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=mdTLYR8v; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=kFAMbOzO
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 0mstagzjhcIP; Tue, 12 May 2020 08:49:48 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67D2B3A0B7D; Tue, 12 May 2020 08:49:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29266; q=dns/txt; s=iport; t=1589298586; x=1590508186; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+KZ9YMvI7be7WNe+DOdYrSvEzDL+5K1BSBTQhG97Ww4=; b=mdTLYR8vytNoYcDpz0Fk+ESoHU3bhz5zTIN9H8dNEwRjVMP3s5CnKtbX SVQUFG/phoEYA/zqPffwQ4jFSZ7AgkPsJYioiuEFiMufnOcRY46rbrgOV SFdcqg47JdmzPCqK9tpCxjqRCpP8HXj6UcbkBwKduPLgvfZxezJ3sUCcr M=;
IronPort-PHdr: =?us-ascii?q?9a23=3AVer28RT+Q8e34a27H/bylVLF+tpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBNmJ7fVHiuOQuKflCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFvVoXy7qzUVH0?= =?us-ascii?q?a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6zR?= =?us-ascii?q?6arw=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAABgxLpe/4oNJK1mGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAYF2AwEBAQsBgSQvUQVvWC8shCSDRgONRZg3glIDVAs?= =?us-ascii?q?BAQEMAQElCAIEAQGERAIXgW4kNwYOAgMBAQsBAQUBAQECAQUEbYVWDIVxAQE?= =?us-ascii?q?BAQMSEQoTAQElEgEPAgEIEQMBAQEhBwMCAgIwFAkIAgQBDQUIGoMFgX5NAy4?= =?us-ascii?q?BDqUYAoE5iGF2gTKDAQEBBYE2AoN5GIIOAwaBOAGCYolhGoFBP4EQAUOBT1A?= =?us-ascii?q?uPoJnAQECAYEcSBUJBgcJgl4zgi2OJ4Mrhh6Kb48TfQqCSogbkCqCXIhnhQG?= =?us-ascii?q?MdpAdiVqTUAIEAgQFAg4BAQWBaCOBVnAVgyRQGA2QQINyhRSFQnQCNQIGAQc?= =?us-ascii?q?BAQMJfI4HAQE?=
X-IronPort-AV: E=Sophos;i="5.73,384,1583193600"; d="scan'208,217";a="477463240"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 May 2020 15:49:45 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 04CFnjZr000878 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 May 2020 15:49:45 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 12 May 2020 10:49:45 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 12 May 2020 10:49:44 -0500
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 12 May 2020 10:49:44 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CIgr7o6N2vBsoPKktfg76HntMne56ApyhxpihwM/zj0epiMYxTJ9dm0+uig2lrk+sgonLTgxW25zuKfCGfd5fkPQf9S2/vTZpjVBrKi4GOpMRXFue5C1BTkrWYJCiSqorgzEQW8lZyTd4/mVowBivDkiPL+/YKuphblofAhBt07BBCEKicOI1K1iTcR4Cy2kSsAxX8BEjLoHlvriAoZ5sMp+HsaBnh1FxJ8tafRUQNMlmPFwLKpxkg7ox1ORKRMNUhsKX131KD1vy32I3rLm506MiEHtEzX9f2WrYzFokTIz85ocqeSenwu2LgOFSrsh8IJXaxV2a7I4h5xgYoRulQ==
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=+KZ9YMvI7be7WNe+DOdYrSvEzDL+5K1BSBTQhG97Ww4=; b=FTAJcOXP6WJyMKX6sAW5C5WoQLR6ev6Vx/bzjmdxrDpRgsMxMuywa3VL8gnSz3yrkI93G74ZJixmTNLGPsqjppL1qmLKo3mWUcuxmQnYSkKYGqmbyd+/dokySSFpAfgkLP8qSj48W81raVDUes8v1zFN71d7XAriGp1JLThzc8Z+qa3noKjC2M5lbAUmtxQhpq9xwbqOgI6d+dkJl5AJx8CZCc1ZeIM3BmKsMWMQAcTsoiidtn/2RJ8/kQ1DcrF91oBTtyRkVisphrbUMtPaaCdC03K/mGsKkCyg8yIFlDMd2qmHAtPifD2QqvDQ6RjTJ0+RPdytNgdl0t93kaecbg==
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=+KZ9YMvI7be7WNe+DOdYrSvEzDL+5K1BSBTQhG97Ww4=; b=kFAMbOzOM8R4YmMeufJxcPEUaqXnGVZID8TEfh27rr0pYtj1LjauqPvE78iPCJqPexLKtSERLAITU+qQ+Dx5DP5qgPckBiSt5eVvI4jdUG6vpZj40VkQcPdlVmwJPVutVgcpNd8yVHRerzwrFT8YA3ci/Gh+ChKFGw8x2sACsTI=
Received: from DM6PR11MB3802.namprd11.prod.outlook.com (2603:10b6:5:143::30) by DM6PR11MB4756.namprd11.prod.outlook.com (2603:10b6:5:2a7::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.34; Tue, 12 May 2020 15:49:42 +0000
Received: from DM6PR11MB3802.namprd11.prod.outlook.com ([fe80::244e:bbbc:1bf3:7fd6]) by DM6PR11MB3802.namprd11.prod.outlook.com ([fe80::244e:bbbc:1bf3:7fd6%7]) with mapi id 15.20.2979.033; Tue, 12 May 2020 15:49:42 +0000
From: "Mike Koldychev (mkoldych)" <mkoldych@cisco.com>
To: "Stone, Andrew (Nokia - CA/Ottawa)" <andrew.stone@nokia.com>, huruizhao <huruizhao@huawei.com>, "pce@ietf.org" <pce@ietf.org>, "draft-koldychev-pce-multipath@ietf.org" <draft-koldychev-pce-multipath@ietf.org>
CC: Lihanlin <lihanlin@huawei.com>, Tanren <tanren@huawei.com>
Thread-Topic: [Pce] Change Path Attrubute Object to a Sub-object
Thread-Index: AQHWKGohfSDQuYjWlkWLEwUx/xZ5Y6ikh8EA
Date: Tue, 12 May 2020 15:49:42 +0000
Message-ID: <DM6PR11MB380297BB4B675CB005552A44D3BE0@DM6PR11MB3802.namprd11.prod.outlook.com>
References: <7A73983B-25EC-4F23-976D-587313D51A8A@nokia.com>
In-Reply-To: <7A73983B-25EC-4F23-976D-587313D51A8A@nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2607:fea8:e380:fce:90b2:1d40:6e0a:1269]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0827e0c2-87e4-4993-be0d-08d7f68c1664
x-ms-traffictypediagnostic: DM6PR11MB4756:
x-microsoft-antispam-prvs: <DM6PR11MB4756D4B962D102F92F99E93DD3BE0@DM6PR11MB4756.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0401647B7F
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: cbAQGdKuNyoRtlnrjIQATctd5Qd+4aUxHQhfaLP8g7kvMfeelQkMEYKHjkFJmAgV8w6WJmT/Te1NeX95fqT2wnSYX7Aw2zVzI+nRqqyZGprolL8UDO9nEd5vlFoXVivvcrnDuJANBkal3/KJWKJ/fFP9G/ieMIOJ/uhJI5y3nZ6KOQ4EL5n6C3lY+NTR4ExV+A2rjvD1paC1L5GYd/l4JQUzb6n100K/+njeecfqa5JOJr6l+TAqGVcIp+qDYkGeDUPXqqjMC0w14i2Cd/EsKIVAx+p5aqLnI30Knounvj0/QiDynzis48OUtzGIt8tYoWGvnGxmxKFW3NUZZ5jLDq4YHOworCVIPjMAXUUhH99/phjRsWO260CMlN4Tvj9vEiZ6iW1RZB8hpkcavG4eFd0KW4E0LG9EkhvoUwIjfvFEae7t5bbGftqbknWu2TYsc3yZRfGd+SYDKVTCJ+aM6R5WwpMCiAB45mlR1D7IFt6U6bb8n7Fb0X/kPa0g/LTeW5PeXX49Up3LRN0Ex3vI4Uqce1VNnPgssLqKLnG3U/+KkwE9gbrGDGqMSsLLaULW8eqnL0iM4sOF35I7WhMXjvP5nLfECaYJQpF/aYjyv0U=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3802.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39860400002)(346002)(136003)(366004)(396003)(33430700001)(316002)(86362001)(53546011)(76116006)(66476007)(8676002)(66946007)(966005)(66556008)(66446008)(64756008)(33440700001)(33656002)(478600001)(166002)(186003)(4326008)(110136005)(54906003)(2906002)(52536014)(296002)(8936002)(6506007)(5660300002)(71200400001)(9686003)(7696005)(9326002)(55016002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: t4O1PIm9W76+QZjxv57dC1Jq2NqvMpHBLldPzGaJTNhK2d8utlXmLsuQ/iIsEFpUmvXTMW+Gr5CfUlKLAM3FqFBfHA+8NGofIrmPB27j4EOY+VgXgiTmtUYCVnowPOOvQrUEEQPGOkBTNEEbDzeHPilD8lNk0HNwzJ0lF08QGx0AWBwpA+LNSy+DsMHok/I5KyIjKAa5BN7+BdrRO5wQ+yiSUigs2wag2pBJfy5WsAdzUf/UYeqnuAREInXcR1dKR0n0XNHHeCpZWzkopSUz14m/6GxJNPyMxRx+97QEtfMsPd59jDD5EKLw44+eaB5tX+jUyuGuAvWy8Lf1YIdqHjiRb6Ipj1pzdiCdCZuYojcoc2G6YEIN+jthiaH/y1XIohKgRNBbj7NIcA0GcvpoTRJJIgbk/vrmc6P5ZyCZfzACerirp9xBV7aC2BHozm1ti5VyZ+5t8DvEqc92ESKwsc4QgfxwfCrOgKvI3xFBU1jzQhInlWUJbKROiTawXXEL5GwX/WPzNdrLV/z3QO7SvO5n+xJbsVcIsgmpCYiAA64TN6P8GWeLUJLAwXXqq/Sw
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM6PR11MB380297BB4B675CB005552A44D3BE0DM6PR11MB3802namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0827e0c2-87e4-4993-be0d-08d7f68c1664
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2020 15:49:42.7280 (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: WNqbvjPxhN7HFSqW0F8MPpYG6LN1DmPmMYT2kxwYTbRWsNbiLS/SVC1X8nSql5TD6Dcl9MhgLkUMXPevnhpMYw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4756
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/8lLXh6XTMUkepE7pIfoiA-KzkSA>
Subject: Re: [Pce] Change Path Attrubute Object to a Sub-object
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 May 2020 15:49:50 -0000

Hi Andrew,

Thanks a lot for compiling all the information very nicely!

Hi Ruizhao,

The idea of putting PATH-ATTRIBUTES inside the ERO object was actually considered at IETF 105 in Montreal. We decided against it, for the reasons that Andrew listed.

Thanks,
Mike.

From: Stone, Andrew (Nokia - CA/Ottawa) <andrew.stone@nokia.com>
Sent: Tuesday, May 12, 2020 10:32 AM
To: huruizhao <huruizhao@huawei.com>om>; pce@ietf.org; draft-koldychev-pce-multipath@ietf.org
Cc: Lihanlin <lihanlin@huawei.com>om>; Tanren <tanren@huawei.com>
Subject: Re: [Pce] Change Path Attrubute Object to a Sub-object

Hi Ruizhao,

Thanks for the feedback and suggestion on the draft. I’m not an author, but do have a few comments regarding your proposal. Not sure I agree that embedding the Path Attribute object as a sub-object of the ERO would be better, due to Path Attribute Object being an object that describes a complete path definition and not an individual hop inside of the path definition. As well, it appears to me a precedence exists in somewhat related, but not PCEP, RFCs to use the ERO sub objects as per-hop information, and embed complete path attributes outside of the ERO.

Some snippets:

https://tools.ietf.org/html/rfc5440#section-7.9 states:

   The ERO is used to encode the path of a TE LSP through the network.
   The ERO is carried within a PCRep message to provide the computed TE
   LSP if the path computation was successful.

   The contents of this object are identical in encoding to the contents
   of the Resource Reservation Protocol Traffic Engineering Extensions
   (RSVP-TE) Explicit Route Object (ERO) defined in [RFC3209],
   [RFC3473], and [RFC3477].  That is, the object is constructed from a
   series of sub-objects.  Any RSVP-TE ERO sub-object already defined or
   that could be defined in the future for use in the RSVP-TE ERO is
   acceptable in this object.


https://tools.ietf.org/html/rfc8664 section 4.3 states:

   An ERO carrying
   an SR-TE path consists of one or more ERO subobjects, and it MUST
   carry only SR-ERO subobjects.

   When building the MPLS label stack from ERO, a PCC MUST assume that
   SR-ERO subobjects are organized as a last-in-first-out stack.  The
   first subobject relative to the beginning of ERO contains the
   information about the topmost label.  The last subobject contains
   information about the bottommost label.


https://tools.ietf.org/html/draft-koldychev-pce-multipath-01 states:

  We define the PATH-ATTRIB object that is used to carry per-path
  information



Taking the above snippets into consideration:

- When I read the above, to me it says ERO is the path. Path Attribute Object carries attributes about the path definition, not the path itself. The Path Attribute object isn't actually part of the path, so it shouldn't really be contained within the path definition but instead "wrap around it" / attach to it at a higher level.
- Carrying path attribute as a subObject would go against RFC 8664 statements. Those can be amended/extended of course, but something I think is relevant to point out.
- For a similar use case, RFC5420 also embeds “complete path” attributes outside of the ERO object construct in the context of RSVP signalled, and uses the RRO subobjects to capture per-hop feedback.
- From my p.o.v, https://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xhtml#rsvp-parameters-24 (which defines the sub-objects used in PCEP as well) defines sub objects that are related to a specify node/hop in the path, not about the complete path. For example, RFC7570 defines a sub-object that is per-hop specific, not for the overall path.

Cheers
Andrew

From: Pce <pce-bounces@ietf.org<mailto:pce-bounces@ietf.org>> on behalf of huruizhao <huruizhao@huawei.com<mailto:huruizhao@huawei.com>>
Date: Monday, May 11, 2020 at 6:35 AM
To: "pce@ietf.org<mailto:pce@ietf.org>" <pce@ietf.org<mailto:pce@ietf.org>>, "draft-koldychev-pce-multipath@ietf.org<mailto:draft-koldychev-pce-multipath@ietf.org>" <draft-koldychev-pce-multipath@ietf.org<mailto:draft-koldychev-pce-multipath@ietf.org>>
Cc: Lihanlin <lihanlin@huawei.com<mailto:lihanlin@huawei.com>>, Tanren <tanren@huawei.com<mailto:tanren@huawei.com>>
Subject: [Pce] Change Path Attrubute Object to a Sub-object

Hi authors,

   In the section 4.2 of [draft-koldychev-pce-multipath-01], Path Attribute Object is defined as a new object that is used to carry per-path information and to act as a separator between several ERO/RRO objects..
   The newly defined object describes the attributes of the ERO object (path ID, Multipath Weight TLV, Multipath Backup TLV). Therefore, we recommend changing it to a Sub-object carried in the ERO / RRO object. This way can make the information in the ERO object centralized and complete. And from an implementation perspective, this approach can avoid the operational complexity when dealing with the pairing of Path Attribute Object and ERO Object.
    If you have other considerations, please contact me. Thanks.


Best Regards,
Ruizhao.