Re: [Pce] AD review of draft-ietf-pce-binding-label-sid-10

John Scudder <jgs@juniper.net> Thu, 30 September 2021 20:15 UTC

Return-Path: <jgs@juniper.net>
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 A5DF73A0AAC; Thu, 30 Sep 2021 13:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=qslMmgpk; dkim=pass (1024-bit key) header.d=juniper.net header.b=Ky5yxvqT
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 XRaCoUPxAXD2; Thu, 30 Sep 2021 13:14:53 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 513533A0AB6; Thu, 30 Sep 2021 13:14:18 -0700 (PDT)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 18UIMOaq024282; Thu, 30 Sep 2021 13:14:14 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=0gsziJqByTp0dmn/efWvA07XXTse1CCK/P9lzK/M3tQ=; b=qslMmgpkpDAWmZjSv3i8k+9IDZMQzCg8v1LuAHoqwjDfaxKZDKhp7l6D0DHyGHzK191c EaXFSnJLWo7hjdy4OKLw71m4DeXKUIoDRP2wSozAS8qlj7p6IA8ug0pdyUSVfloT5OGz VLnIpZdn1K+sq1o+p7XMaQ4rRm95YPW9AzSwPnndgD0lDSf4SYgJTWa/NcfFEbYn6Ybu iDGLjl6SXsPDOAyA2nCuK4HlaGuCVgM/IVe8vwQuSTqWwDj+cqWC+NyZuvGkRbpCBjnU KfOT9HYR0nu8pe9gj4PfqgNhiz4y/TfFWz8tiPF2wUOufHFCFcTpBzfnbL2zNjl2EXig CQ==
Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2169.outbound.protection.outlook.com [104.47.56.169]) by mx0a-00273201.pphosted.com with ESMTP id 3bdfw6rq6m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Sep 2021 13:14:13 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HOkWzt+r2tYRrGvB28vRusBP+0j6UQluP9BuMSTGVI5AAUchJM/YlEegu1XhKfUUZEatGJsrsqRSIvACyvmE9x3jOzCvlLZ/qBOs9oAAso0DWoZvEFkz9xNSk3A7KY6igIykyzy2uumRAxlDz69h3LvNUHqTRjt+U/5XHIefyxAxrRup72Qe5DwZJXKYb0eEaZX2Y9MlJ99FPrtMH7tURSNfUPBl4FnHlAHR+BDF9e1Q2FoPcoMy3HcViSxRjQx+1JoK5hT8gxSRi7JXd+0koxaSWzi1Hp4OmHXMH+HXimpSPknUMsx73TKni+7JuKfwm84AzlckP1z9aFTXCRAzjQ==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0gsziJqByTp0dmn/efWvA07XXTse1CCK/P9lzK/M3tQ=; b=S8oCS2u1KYanLdrNy3qjNKvCd/JSwqACA9dD29GUFh/2Dalt7gaqghjfWh5ACLqNIxh2/M/GZxdtUAXkX7ouv0wEhxLPa4Go3+cFjnIVoLBoJl2vj9UgoahNk42ovKMxGkWhXJNRQQpyiboKZ53eI5oTH4WT0MPEtErfBtDzklPFKfDhi2BUryWHhJ6d1sqYegUFlSmtEbVR8OrKmgOv4MSdyNqODDSRd6ODdRexVXELl2Xs+GC3zmRfXz2fiBGqiy8nCxfgS3HErMXGF6DAN4YhIQOpX8VIohf2H+nlGxFE8jOnF+ml1pGzpWPHTFHIRN/51snuDe3pXRbE5R39iw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0gsziJqByTp0dmn/efWvA07XXTse1CCK/P9lzK/M3tQ=; b=Ky5yxvqTFE3L5KVsp15A5x+bHO7buAlTZQeBgVRPdRvFqxuCoQSA8cHbMJ3W3kVgsSiAC709V/adRiznW6eFNVBPbD5/+GelXtxszmLMXWN3m2mQxBG6zSeNY28sEkM77NiiB2g8O12vpv6QfBrRW8rfSl4JGBxCzyVnAHcmuac=
Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by MN2PR05MB6669.namprd05.prod.outlook.com (2603:10b6:208:df::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.11; Thu, 30 Sep 2021 20:14:06 +0000
Received: from MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::d4ec:65ce:b1f:d98b]) by MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::d4ec:65ce:b1f:d98b%5]) with mapi id 15.20.4587.009; Thu, 30 Sep 2021 20:14:06 +0000
From: John Scudder <jgs@juniper.net>
To: Dhruv Dhody <dhruv.ietf@gmail.com>
CC: "draft-ietf-pce-binding-label-sid@ietf.org" <draft-ietf-pce-binding-label-sid@ietf.org>, pce-chairs <pce-chairs@ietf.org>, "pce@ietf.org" <pce@ietf.org>
Thread-Topic: [Pce] AD review of draft-ietf-pce-binding-label-sid-10
Thread-Index: AQHXtJ9bMBn576oAFUaTdM4yRToOiau6tIKAgAJRroA=
Date: Thu, 30 Sep 2021 20:14:06 +0000
Message-ID: <219BD519-4889-4CB8-BAD1-D0A08CA5AFE0@juniper.net>
References: <3EF2EBC1-9EDA-4B73-8CFA-8449738ABEEB@juniper.net> <CAB75xn5Uc6KwF0EaMZyhbaZR4mo2gcY=ZgwMogpKb9n=OMzvPg@mail.gmail.com>
In-Reply-To: <CAB75xn5Uc6KwF0EaMZyhbaZR4mo2gcY=ZgwMogpKb9n=OMzvPg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3654.120.0.1.13)
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 80183169-042b-4460-e618-08d9844edac6
x-ms-traffictypediagnostic: MN2PR05MB6669:
x-microsoft-antispam-prvs: <MN2PR05MB6669CB03C370ADC89D2AB760AAAA9@MN2PR05MB6669.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 33vRTvR5m34j33yMnFHoCUnvE0u6nT1hh7vSO8+GGS1oQgdh6OXVJsL3G4Z13C9kh/efMPyhXNj3B7JDdasDWsKOip/j6TzBzknCSlK8FtK0uYqmXg07CvsvX9Vm3zgN+9kbBF0JKw/8wbQjQ89lgSdC+57eZuYRYh1bCA7+BqVxvTT/dkrQ06X2C4XRPge+LbnWl3aPExrR3oD76MLhTNCX7FpjiFHb+j5giVcDGgT/BADuOHWKKLZXPKnN6mppuJ8Udo2w7RrtnMWSTyl4ShXxM5OhEVJBv5BOG0nj+pS/2MfLwRl3Rop4AbdHyew+TOjY93FMazKGiigy1/ekA3x8dVlDjgLHP1v9JcewyPae6Yjy7Uv732VOQteeXtj6UvsxeVdj8GDh2OfPBKEz/exM3xCzl78ZvUeLJV8Z3DJcUdXxR1TYa7TJ29X4wdQePw7ivtSeCfOeq/w23JAhoDV4Obxm6it/LrzGKy6S/P5ka8vmt20XzGg9/w6Jq6kL/ylybmf5a3KgZKvx4Objdcq2SkFwgrAAYR+kNqmBanarGa6bqVPcjPguYVU5KoXp1Mh28TORJ7cscIVugJGcSa38USkEo7kJuzttMF/qf5iS2F+PUek1JEIY9lkxeZCQ+HJZpPMgfHQrz8Hm89tkao9NF88xWdz3ZGAIEQYmnbtxfAfpY8wmpzDWLaFqVnkZ5Yv5G6ZN1t14+6XxS/5p4mvA9dEuM4rzEIgljPDCXePczBpILMJF+5lxyS1xUxxY6rCb9jl5libIhSUTshKTvlZ3B20LMSndAdnrcBLp88Awf5xBFcbb2KZVC0HZuSGg
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB6109.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(84040400005)(76116006)(966005)(91956017)(6506007)(53546011)(33656002)(66946007)(54906003)(186003)(5660300002)(8936002)(38070700005)(26005)(86362001)(83380400001)(8676002)(6916009)(66556008)(4326008)(38100700002)(64756008)(66446008)(2616005)(122000001)(316002)(66476007)(508600001)(6512007)(6486002)(2906002)(36756003)(71200400001)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 99lFST4wpXzpbI9X5ZHe4kqIR+N8q0Wzr8hV2ffGyNv55X8P9IrmEfZjsp4K7yj55vtJaycaodx49rZQDKPKTAYVS2wbDJmHmwFH05n+wL/iKsyZwPNDGjt0OXG3F47F/NOXOYRIUJzjMEIwrJ3COxFb0C9BwuJL7MeOZdbecpLNLRwwJAuoIskV2ftXkG+uP3f31f2RZ5e8nf0IJL2xpftQDSrsQLzADOa4158HvBubScIYfVqXONoj7rLRwjwGRtN5yODaIQcLRWWCFbfbfmQzBneGb2i3BRjGdyCgCvDhKlfzNJ0t3W/cxm92m4RBTfaals5ygVgjtzjvmx61jxwosZVdnwNzs6XambpqnDO7h1Kyd3GKxrqcNPAYqDVoYMj8LcnC29CWyr5sSH7qRHoWaF9BWV6bSwjQyoJmjMRXjHwNIkg0jWSbVN4pvKx+SlRDlO15wtB7iLG+kdqfkMWK9et6V1AYhKfQWLA3DygkQpyW3kcpkYFfBLmeJJGtj9OWase3JZ4ZFpl/L6ae2Y8OT+7encGCzwKhAJm+JDdAqTEZE+TmiSLbNfNwTFsxJhVnbkdhgaOgJ3Ss4FYH9I+g/6Wa7O69xCyTr1uN0mcGzxSUAYg73EdrNMugCYuAg+B0U582KvUUGyR8OElu4ICl8Q9e3mbp/UTnJ1KB3sbhGgiaoduV8de9hY1aR3pZqKkMIcreXS/t8+ObLXjdG11TPro5VqBO/+WbUcTau7eFAtQNM5UFMyMIGnJ7q71rmfnukD/92sWCNZjE50TgD45ruWaKQ/Vdr3VF8k5XLkdi6dX8GiTZGGdxxF2kqM+4zv7Sdg9jUlblziDyP2o8Ilnv9nvINqmenAde9XxFsQafKth/zz4sxXkTGlx+CDDKL9lq6c1N21815fjTSRSNkwriSQl0Pz7Tk04hC/XkskNCA/GGAUyovuoIlKGkIxnQy/vT/to5AqNWl/DvPRKbKCIErsgwJH5PNyThfspHquOA782wyV/88y+FYUBKKBRtXqxbvTPTsRa+PEDqpEdlipmOtyBbTvc7M68uMMMZyRSQUiqE5F8W/YRs8qNf3bafmhXaoE+oCjaZQzkoCHdz5H5vIWeb8nGkGa8i8rU0NAKHLhRAcXN0dI9GyEAccDrha3VR8xudK5Numcx/Nip6AQ98f+aciLKzw6knlQ2WcuVKs2wRZ8djpd0ou2FgruX4fTQHzo8QhYpJdjj8C4OKbA+otjeMNmEaPeueHlFvYZ0e4sa/ownX9sBu+oH/tB7b94YAjVllnjEweghDmHVYEE+4a3mSsRUy9GnrAvYXH6utIu/9A9+hMBr67wIqZILf430CGsJ5zf6G/T6eaCVeHA==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <3FEBF9C603B623449C01EFD60D5899AA@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB6109.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 80183169-042b-4460-e618-08d9844edac6
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2021 20:14:06.0720 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: BeLONgtXFNbtdidKSzoYkYzZN9b7IzOJmxsfanf+J6n/7X2exjMt+aFUJRpluXyb
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6669
X-Proofpoint-ORIG-GUID: 9AD6lvqvJ5Sbk3Mo86pmjuZZjYcwUdRF
X-Proofpoint-GUID: 9AD6lvqvJ5Sbk3Mo86pmjuZZjYcwUdRF
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-09-30_07,2021-09-30_01,2020-04-07_01
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1011 mlxscore=0 lowpriorityscore=0 malwarescore=0 impostorscore=0 mlxlogscore=999 priorityscore=1501 spamscore=0 suspectscore=0 adultscore=0 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2109300125
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/pvSvkuxDe0ElPTFNgWaqUIdGGIU>
Subject: Re: [Pce] AD review of draft-ietf-pce-binding-label-sid-10
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: Thu, 30 Sep 2021 20:15:01 -0000

Hi Dhruv,

Thanks for your comments, and some replies in line:

> On Sep 29, 2021, at 4:49 AM, Dhruv Dhody <dhruv.ietf@gmail.com> wrote:

(…snip...)

> ***************
> *** 490,495 ****
> --- 512,546 ----
>      error, the PCC rejects the PCUpd or PCInitiate message in its
>      entirety and can include the offending TE-PATH-BINDING TLV in the
>      PCEP-ERROR object.
> +    
> + Rejecting the message in its entirety makes sense, but it does imply
> + that an implementation MUST be prepared to unwind any actions it has
> + taken earlier on the basis of the message. It's a pretty common 
> + pattern for an implementation to take individual actions implied by
> + a message immediately as they're encountered, which means this 
> + unwinding is potentially non-trivial. For example, suppose a PCE 
> + requires a PCC to allocate three specific binding values, so it
> + sends a PCUpd containing three TE-PATH-BINDING TLVs. The first one 
> + is successfully allocated, and so is the second, but for some reason
> + the third is unable to be allocated. Now the PCC must de-allocate
> + the first two, in addition to sending a TBD2+TBD4 PCErr message and
> + possibly includes the third TLV in the PCEP-ERROR object.  
> + 
> + Also, I guess the PCE must infer that the first two bindings were not 
> + allocated, even though it has only received an error for the third.
> + This would be true even if the PCC implementation doesn't have to do
> + any de-allocation -- suppose the PCC has a clever implementation that
> + only commits the actions in the PCUpd once it knows they will all 
> + succeed, it's still the case that the PCE will get an error for one
> + but must know that the error applies to the others that were carried
> + in the PCUpd.
> + 
> + Is this analysis correct, or if not, why not? If it's correct, it 
> + seems to me as though it might well be worth devoting a few sentences
> + to it, unless these issues are already well covered in one of the
> + foundational RFCs (in which case, I'd appreciate a pointer, I haven't
> + done a thorough enough review of the normative documents to catch all 
> + such things).
> 
> 
> [Dhruv]: It is a normal practice to reject the whole message in PCEP. Say a PCE sends a PCUpd message for an LSP with multiple updated parameters, one would apply the update only once it has verified all the parameters and send an error in case any are found to be invalid. The PCErr message includes an SRP object that identifies the full PCUpd message is being rejected with the reason for the rejection optionally identified. 
> 
> This was discussed during the WGLC and the conclusion was to reject the whole message in the case of multiple binding TLVs as well. The SRP in PCErr would identify that the complete message is being rejected here as well. 

As long as this is a well-known pattern in the PCE world, that this spec is just continuing, I’m fine with letting the text stand without modification.

>  
>      If a PCE wishes to request the withdrawal of a previously reported
>      binding value, it MUST send a PCUpd message with the specific TE-
> ***************
> *** 507,513 ****
> --- 558,573 ----
> 
> 
>      In some cases, a stateful PCE can request the PCC to allocate any
> +                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>      binding value.  It instructs the PCC by sending a PCUpd message
> +    ^^^^^^^^^^^^^
> +    I don't understand what that means. My *guess* is that you mean
> +    the PCE is just saying "hey PCC, please allocate a binding value
> +    and tell me what it is".  Is that right?  If so I think this 
> +    could be worded even more clearly, perhaps "a stateful PCE may
> +    want to request that the PCE allocate a binding value of the PCE's 
> +    own choosing"?
> +    
> 
> [Dhruv]: It should be PCC's own choosing.

Were you just correcting my comment (to say I should have written “PCC” the latter two times, I agree, my mistake), or was your point also to say that yes, my guess is correct? If the latter, then as I mentioned, I’d appreciate having the wording improved.

> <snip> 
> ***************
> *** 655,660 ****
> --- 742,758 ----
>         *  Send a PCErr message with Error-Type=19 (Invalid Operation) and
>            Error-Value=16 (Attempted PCECC operations when PCECC
>            capability was not advertised)
> +          
> + You need to update your reference to point to RFC 9050. You should 
> + then either reference §5.4 and NOT copy-and-paste the relevant text,
> + or you should (less desirably, IMO) update your copy-and-paste to 
> + the text published with RFC 9050.  Notably, RFC 9050 covers the case
> + of a legacy PCEP speaker, whereas the text in this spec doesn't. 
> + 
> + IMO since RFC 9050 already specifies what to do when the capability
> + isn't exchanged, there is no need to say anything at all in this 
> + document, so unless you have a compelling reason (what?) to keep it,
> + please remove this bullet and its two sub-bullets.
> 
>         *  Terminate the PCEP session
> 
> 
> 
> [Dhruv]: The only reason to include this text is for "P=1 in the LSP object" i.e. the presence of the LSP object with P flag set is to be considered as a PCECC operation, which would not be the case in RFC9050. 

I see, thanks. In that case, then I guess the copy-paste needs to be updated to follow the text in 9050, or if that doesn’t work for some reason I’ve overlooked, in any case the text needs to be updated to cover the case of a legacy speaker. 

> ***************
> *** 745,754 ****
>      [RFC8281] and [RFC8664] are applicable to this specification.  No
>      additional security measure is required.
> 
> !    As described [RFC8664], SR allows a network controller to instantiate
>      and control paths in the network.  A rogue PCE can manipulate binding
>      SID allocations to move traffic around for some other LSP that uses
>      BSID in its SR-ERO.
> 
>      Thus, as per [RFC8231], it is RECOMMENDED that these PCEP extensions
>      only be activated on authenticated and encrypted sessions across PCEs
> --- 843,857 ----
>      [RFC8281] and [RFC8664] are applicable to this specification.  No
>      additional security measure is required.
> 
> !    As described in [RFC8664], SR allows a network controller to instantiate
>      and control paths in the network.  A rogue PCE can manipulate binding
>      SID allocations to move traffic around for some other LSP that uses
>      BSID in its SR-ERO.
> +    
> + Try as I might, I'm not able to figure out what, specifically, the above
> + sentence (that begins "a rogue PCE") means.  I mean, I get it, a rogue 
> + PCE can misdirect traffic.  Beyond that, can you help me understand what
> + you meant to convey here?
> 
> [Dhruv]: IMHO it highlights how this new capability of "allocating binding SID" can be exploited by a rogue PCE to misdirect traffic. Path {A, B, BSID_1}  can be misdirected just by assigning the BSID_1 value to a different LSP making it a lot easier (and harder to detect).  

I think it would be helpful to add something concrete like that.

>      Thus, as per [RFC8231], it is RECOMMENDED that these PCEP extensions
>      only be activated on authenticated and encrypted sessions across PCEs
> ***************
> *** 773,778 ****
> --- 876,889 ----
> 
>      The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to
>      include policy configuration for binding label/SID allocation.
> +    
> + It looks like pcep-yang expired a couple months ago, but I think 
> + that's just an oversight and doesn't reflect the WG abandoning
> + the work.  Is there any intention on the part of the WG, to 
> + extend it as described?  My understanding is that yes, the WG does
> + intend to do this -- in that case I think this section would be 
> + stronger if you indicated that, something like "The PCEP YANG module
> + will be extended..." instead of "could be". 
> 
> 
> 
> [Dhruv]: This one is my fault. It is on my to-do list to update.

OK, thanks. If the WG has consensus that the YANG module will be extended as described, I think making the suggested change might help avoid questions during IESG review.

> ***************
> *** 809,814 ****
> --- 920,928 ----
>      apply to the PCEP extensions defined in this document.  Further, the
>      mechanism described in this document can help the operator to request
>      control of the LSPs at a particular PCE.
> +    
> + I don't understand the final sentence (the one that begins "further"). 
> + Can you help me?
> [Dhruv]: My guess would be it is leftover text -- needs to be removed.

OK.

>   12.  IANA Considerations
> 
> ***************
> *** 852,857 ****
> --- 966,976 ----
>                            Behavior and
>                            Structure
>                   4-255    Unassigned            This document
> +                 
> + Just curious, have you considered any Experimental Use values?  The 
> + PCEP registries are inconsistent in that regard so I can't tell 
> + whether this is a "you should" or "you could" or even something that
> + doesn't make sense in this specific case.
> 
> [Dhruv]: The experimantal values are kept limited (see https://www.rfc-editor.org/rfc/rfc8356.html#appendix-A). In the case of new BT, there needs to be agreemeent accross WGs, not sure if it is particularly helpful to have experimental codepoint in this case! 

Thanks for the reference. Makes sense.

—John