Re: [Pce] Comment on draft-barth-pce-segment-routing-policy-cp

"Mike Koldychev (mkoldych)" <mkoldych@cisco.com> Wed, 20 March 2019 16:36 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 40065131153; Wed, 20 Mar 2019 09:36:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, 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, 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=Ob3hum7F; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=PlBq//Oc
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 Mj9Sni4k4i3C; Wed, 20 Mar 2019 09:36:07 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20ACA13114C; Wed, 20 Mar 2019 09:36:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20029; q=dns/txt; s=iport; t=1553099766; x=1554309366; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GKt5hZ4K0GsthPSJOzGWXRrSG/BCAPc9LW4TPORVgtQ=; b=Ob3hum7F/ZSyoFhjQw1pwb4793SIppP2ZoTGXUQr+EOHvqGf2Ywhn2gK Quu2/qFfJX/7VQ/bJELN2ccyTzP5lYK1M62vj6r8PF4rqSRaoT8yetklo /L5M5E+CR5FlHochAxYwqWaraMSiEUa59EPQh+fudgVx2u5WMiNUfxULm E=;
IronPort-PHdr: 9a23:Ua39RBTVqnOLI36twsZAXvL6X9psv++ubAcI9poqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH15g640NmhA4RsuMCEn1NvnvOik5G8BORVRl13q6KkNSXs35Yg6arw==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AEAABza5Jc/4sNJK1jGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ4vUANodAQLJ4dUA4RSilSCV4UkMYNdAY1UgS6BJANUCwEBGAEMB4RAAoRnIjQJDQEBAwEBCQEDAm0cDIVKAQEBAwEBASUGEwEBJQcLAQ8CAQgOAwQBASgHIQYLFAkIAgQBDQUIgxuBEUwDDQgBDp9aAooUgW0zgk4qAQEFgTUCg1cNC4IMAwWBLwGLMReBQD+BEAFGgkyCV0cBAQIBgWAkBwmDBYImiziFSx6HIowGNgkCh16DRoQJQoNYgiaOFoMpixKFfYE2i1sCBAIEBQIOAQEFgUw4gVZwFTuCbAmCAQwXg0uEWTuFP3IBAQGBJYtkAQE
X-IronPort-AV: E=Sophos;i="5.60,249,1549929600"; d="scan'208,217";a="319519085"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Mar 2019 16:35:33 +0000
Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x2KGZW0T027798 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Mar 2019 16:35:32 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 20 Mar 2019 11:35:32 -0500
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 20 Mar 2019 12:35:31 -0400
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 20 Mar 2019 11:35:30 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IMa872rkeyCAH06aAYB+6g31K5NAyAP99dGuKPCsCmU=; b=PlBq//Oc/qS+5GoRIo/8dylKKJW9MRVFDlf+hFLhRx3jZhDxuYw4DcWhtkBVXp6Bc73wcEJs4A4CMjrO0hoDq3EdXrbdwrGRjKjRNlhLTGctJpyTOs0Q2ZOUOqP2+THyGCtQ4clNHCv7SI54bihbqmXBeXSG2aKjCvXCVEDtiz0=
Received: from CY4PR11MB0055.namprd11.prod.outlook.com (10.171.254.156) by CY4PR11MB1703.namprd11.prod.outlook.com (10.169.253.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.14; Wed, 20 Mar 2019 16:35:29 +0000
Received: from CY4PR11MB0055.namprd11.prod.outlook.com ([fe80::d9dd:216b:6f2d:343]) by CY4PR11MB0055.namprd11.prod.outlook.com ([fe80::d9dd:216b:6f2d:343%3]) with mapi id 15.20.1709.015; Wed, 20 Mar 2019 16:35:29 +0000
From: "Mike Koldychev (mkoldych)" <mkoldych@cisco.com>
To: Tarek Saad <tsaad.net@gmail.com>, Dhruv Dhody <dhruv.ietf@gmail.com>
CC: "draft-barth-pce-segment-routing-policy-cp@ietf.org" <draft-barth-pce-segment-routing-policy-cp@ietf.org>, "pce@ietf.org" <pce@ietf.org>
Thread-Topic: [Pce] Comment on draft-barth-pce-segment-routing-policy-cp
Thread-Index: AQHU3cKmVnx6g4EH702v4Ayr58dKmKYUo5YAgAAEyACAABAeAIAAAFrg
Date: Wed, 20 Mar 2019 16:35:29 +0000
Message-ID: <CY4PR11MB0055F0B1EBEF7D40729CB884D3410@CY4PR11MB0055.namprd11.prod.outlook.com>
References: <BN8PR06MB6289556736B7C5412DFE85FDFC470@BN8PR06MB6289.namprd06.prod.outlook.com> <CAB75xn4Qx+GFF1uC-=a9XHCef2tjLEuCs64d9Y_5+OAab3a9GA@mail.gmail.com> <CY4PR11MB0055F280B2DC7B7D51147867D3410@CY4PR11MB0055.namprd11.prod.outlook.com> <BN8PR06MB6289AD8778F83DBAB0F3431EFC410@BN8PR06MB6289.namprd06.prod.outlook.com>
In-Reply-To: <BN8PR06MB6289AD8778F83DBAB0F3431EFC410@BN8PR06MB6289.namprd06.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mkoldych@cisco.com;
x-originating-ip: [2001:420:2840:1250:f9ef:bdfe:66ff:5a09]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 60e2d820-38c5-48a1-3485-08d6ad5210a2
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:CY4PR11MB1703;
x-ms-traffictypediagnostic: CY4PR11MB1703:
x-ms-exchange-purlcount: 17
x-microsoft-antispam-prvs: <CY4PR11MB1703A6BBC3A2F731AF643EB4D3410@CY4PR11MB1703.namprd11.prod.outlook.com>
x-forefront-prvs: 098291215C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(346002)(396003)(39860400002)(376002)(199004)(189003)(93886005)(81166006)(25786009)(14444005)(97736004)(476003)(52536014)(14454004)(256004)(46003)(71190400001)(606006)(105586002)(7736002)(110136005)(6116002)(966005)(106356001)(790700001)(68736007)(54906003)(8936002)(71200400001)(316002)(478600001)(8676002)(229853002)(6506007)(2906002)(76176011)(9686003)(6306002)(11346002)(53936002)(33656002)(99286004)(236005)(4326008)(74316002)(6246003)(55016002)(53546011)(5660300002)(446003)(9326002)(86362001)(7696005)(54896002)(486006)(102836004)(186003)(6436002)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR11MB1703; H:CY4PR11MB0055.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: KV2o+DNAOfKhvE/t+oEX1ZD4sYicnAe+MzU5ASbMx9NMW6Gd5tRPxG/jda3S9BVvsoCBZWxe8eTvbe8zQoicjrtaOzSkCbMTh0t1WqvwnogsNHPjaKXAe/AuE0jc9zjUdd58YP/IfczWZu6oIZMKBdfETczTPZIiOpz5tEbvJgwC4uQJkNjXpN5tDxkBT3I54kOQ4twuUW8IkCjaK+Z1T692JnEdn/XCJHMiddV/3CTVl5ROox/mYLJbfF90F47y99sdiwTIgy1KTrTBtdylZR2gQ8f5mvvr92erRWPGi3BHBYvhhSShY2mz8cb1c3asB6PNPtVk7RG9Un97bYI/iNCxqD1WMU91TAUAD62MAL3cEEPJvGV9TeoklxfnwGXoH0WehxgnJlOpu8kZrRHBs7/trw7RNTpRygiQc4ArFZU=
Content-Type: multipart/alternative; boundary="_000_CY4PR11MB0055F0B1EBEF7D40729CB884D3410CY4PR11MB0055namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 60e2d820-38c5-48a1-3485-08d6ad5210a2
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2019 16:35:29.5851 (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-Transport-CrossTenantHeadersStamped: CY4PR11MB1703
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.24, xch-rcd-014.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/DdOhyW96-dA6OX_3FZ2QRUcVu88>
Subject: Re: [Pce] Comment on draft-barth-pce-segment-routing-policy-cp
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: Wed, 20 Mar 2019 16:36:10 -0000

Hi Tarek,

Yes, because draft-barth-pce-segment-routing-policy-cp covers both "controller -> device" and "device -> controller" signaling, these extra attributes are needed for us. I agree that draft-ietf-idr-segment-routing-te-policy does not need them because they are implicit in BGP.

Thanks,
Mike.

From: Tarek Saad <tsaad.net@gmail.com>
Sent: Wednesday, March 20, 2019 12:29 PM
To: Mike Koldychev (mkoldych) <mkoldych@cisco.com>; Dhruv Dhody <dhruv.ietf@gmail.com>
Cc: draft-barth-pce-segment-routing-policy-cp@ietf.org; pce@ietf.org
Subject: Re: [Pce] Comment on draft-barth-pce-segment-routing-policy-cp

Hi Mike,

>> Hi Tarek,
>> In addition to what Dhruv has said, I don't believe draft-ietf-idr-segment-routing-te-policy provides a way to encode "Protocol Origin", "Originator ASN" and "Originator Address". These are essential for reporting existing policies from the PCC to the PCE.
[TS]: Agreed. However, as far as I see, draft-ietf-idr-segment-routing-te-policy covers the "controller -> device" signaling only. The attributes you mention are for reporting state from "device -> controller".

Regards,
Tarek

Thanks,
Mike.

From: Dhruv Dhody <dhruv.ietf@gmail.com<mailto:dhruv.ietf@gmail.com>>
Sent: Wednesday, March 20, 2019 11:14 AM
To: Tarek Saad <tsaad.net@gmail.com<mailto:tsaad.net@gmail.com>>
Cc: draft-barth-pce-segment-routing-policy-cp@ietf.org<mailto:draft-barth-pce-segment-routing-policy-cp@ietf.org>; pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Pce] Comment on draft-barth-pce-segment-routing-policy-cp

Hi Tarek,

As a individual WG member, I think reusing BGP sub-TLV in PCEP in this case(*) is problematic, mainly because -

(1) PCEP already has some other objects and TLVs which were defined much before the BGP SR Policy work, such as -
- SR-ERO subobject to carry SID (compared to BGP's Segment sub-TLV)
- TE-PATH-BINDING TLV for BSID (compared to BGP's Binding SID sub-TLV)

(2) PCEP has a very specific format for all its TLVs as per https://tools.ietf.org/html/rfc5440#section-7.1, you would notice that BGP does not follow that.

(3) SR-POLICY is a top level container, in PCEP-SR for each LSP (or candidate path) we carry its associated Policy information in the ASSOCIATION object.

That said, it is important that fields and encoding are aligned between BGP and PCEP and I would request the authors to make sure that is the case.

Thanks!
Dhruv

(*) We were able to do this successfully in case of Flowspec

On Tue, Mar 19, 2019 at 1:12 AM Tarek Saad <tsaad.net@gmail.com<mailto:tsaad.net@gmail.com>> wrote:
Hi authors,

The I-D "draft-ietf-idr-segment-routing-te-policy" defines sub-tlvs for SR Policy attributes that are carried in BGP (see below) for SR policy and its attributes. Ideally, with PCEP can achieve what is supported with BGP signaling and hence can leverage the most of those definitions? Is there a reason not to?



     2.4<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2..4>.  SR Policy Sub-TLVs  . . . . . . . . . . . . . . . . . . .   9<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-9>

       2.4.1<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.1>.  Preference Sub-TLV  . . . . . . . . . . . . . . . . .   9<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-9>

       2.4.2<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.2>.  Binding SID Sub-TLV . . . . . . . . . . .. . . . . . .  10<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-10>

       2.4.3<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.3>.  Segment List Sub-TLV  . . . . . . . . . . . . . . . .  11<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-11>

       2.4.3.1<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.3.1>.  Weight Sub-TLV

       2.4.3.2<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.3.2>.  Segment Sub-TLV

       2.4.4<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.4>.  Explicit NULL Label Policy Sub-TLV  . . . . . . . . .  27<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-27>

       2.4.5<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.5>.  Policy Priority Sub-TLV . . . . . . . . .. . . . . . .  28<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-28>

       2.4.6<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.6>.  Policy Name Sub-TLV . . . . . . . . . . .. . . . . . .  29<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-29>


Regards,
Tarek
_______________________________________________
Pce mailing list
Pce@ietf.org<mailto:Pce@ietf.org>
https://www.ietf.org/mailman/listinfo/pce