Re: [mpls] Benjamin Kaduk's No Objection on draft-ietf-mpls-summary-frr-rsvpte-08: (with COMMENT)
Tarek Saad <tsaad@juniper.net> Wed, 26 February 2020 16:54 UTC
Return-Path: <tsaad@juniper.net>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 332453A0B88; Wed, 26 Feb 2020 08:54:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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=c12+U6av; dkim=pass (1024-bit key) header.d=juniper.net header.b=kBPvd59M
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 rHQGkBjdIFfy; Wed, 26 Feb 2020 08:54:16 -0800 (PST)
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 D144F3A0B2B; Wed, 26 Feb 2020 08:54:16 -0800 (PST)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 01QGmuBn022186; Wed, 26 Feb 2020 08:54:16 -0800
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=on36G8j26+CctR3MeeALhV9qB8jiD9NxadFF9qBrzqY=; b=c12+U6avw26p9Wt8vKuNlrpscDkkkRlxf0tEgIEQ08rrgHptSb4iJEWIscSntGVy44Ue sX4v8lpu4XF9g5HP5NaaZkX/mrdv1aLF8tcsRf138jwBxUlN2VFmaWgRJApdV8cc8lSg Y6I92Lana4Hcz13Udh5dGXa5OlTBZmRjPxlkvqJcgDkHjehG7jlu1f4hstNHkoQmbBYQ gZab0stwVdCqhhS3e0+EE7AxWbjDE0WBU+Smop1Ct10q8QON3cuYTTh/vOpkM9u0Yh/P 8Ttt2+Yp3Pc4rBUNU1/3yL+n7rq5gPkGWH5QtnK3VdS/jtqd6m1kNQS8dEAkgeJL0LhB 4g==
Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2177.outbound.protection.outlook.com [104.47.55.177]) by mx0a-00273201.pphosted.com with ESMTP id 2ydcqfhmjq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 26 Feb 2020 08:54:16 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jDfXwYFcpB0erhTVKK7lgWz8kD1td8rcWe0T1YL2wAeF+BjYmlnHxEXO3HVFSvOmGiB4i/mLE34UXCiUSfgfOREjDriw5ludBaSL7y78vLQ91tkFrjLyB/AdsffDwWYY6quKeBYeIzFlILjZdSfgftzX3pBki3rVa1W+VGsW/ppxJk0MgQ18B0YH4KITrs0U5EyQW8h7NKVnxcnr+IevLuwILJBHxlBbsKsTCj1QeqvI42SFq1YKlW60jfkT9MzM+YFJ44cNW0XeuCLBHjKbVH93ZGIpksAbV8YizbX6MJtgXbUfjKcsww+ow+617NbzEaxfGeBpkIpsmy4NNjaqzw==
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=on36G8j26+CctR3MeeALhV9qB8jiD9NxadFF9qBrzqY=; b=ENF57V15fGXTsMWwjkMGZX23VG1m2Lvp86k5BmAzAO1clchZmnP5fXzooREYQvYb9WaN784vAUsPDJme68hohCMb1SuF2glW22xwbQrpWtpseXW8YEllX8qebPLYBbhHeRbeUCCTxGax7vEw5uz2ZyR3VZb4BuZWLkeP2ANWe4i4joTWQr31jv1fg5NdzFYyX7TEXaPRCPKL1ItYt61Buy5FmvfR82/f/m7AXMLn2IGglXAMlJYg5jeKFaVAHIAnM4D4kfRZPr23qqUsXARKo7UspYYFQDnJTKm53th9TBjpR1z47ShrBRVIX/7DQj8fBx3CsuC33U1ZIHLDCiYhgQ==
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=on36G8j26+CctR3MeeALhV9qB8jiD9NxadFF9qBrzqY=; b=kBPvd59MvEmvloVETVAScViK7xQaq0Zca9Al7hYXqQsLhKxEKcN//HjYNTTXJ3cYYW5pJrnoPXsD6OOnUVs5NnPBHAU7TDcdnB5AnLW8Ur4gs+shfrxnScPxwGKihbjZ6//yrCiboGRTiPgN7MLdOqg4irGEKUUnt/qOjgOe1ls=
Received: from BL0PR05MB5027.namprd05.prod.outlook.com (2603:10b6:208:81::16) by BL0PR05MB4914.namprd05.prod.outlook.com (2603:10b6:208:5f::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.10; Wed, 26 Feb 2020 16:54:14 +0000
Received: from BL0PR05MB5027.namprd05.prod.outlook.com ([fe80::715e:dfde:cf1:f90f]) by BL0PR05MB5027.namprd05.prod.outlook.com ([fe80::715e:dfde:cf1:f90f%3]) with mapi id 15.20.2772.012; Wed, 26 Feb 2020 16:54:14 +0000
From: Tarek Saad <tsaad@juniper.net>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "draft-ietf-mpls-summary-frr-rsvpte@ietf.org" <draft-ietf-mpls-summary-frr-rsvpte@ietf.org>, Nicolai Leymann <n.leymann@telekom.de>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-mpls-summary-frr-rsvpte-08: (with COMMENT)
Thread-Index: AQHV54PWNMFiWeVDqUeTwmjBPMckgKgtZ+OA
Date: Wed, 26 Feb 2020 16:54:12 +0000
Message-ID: <39197CBE-AA3E-4B60-92B8-B80D1E1A3030@juniper.net>
References: <158215814449.17742.13589957997277399910.idtracker@ietfa.amsl.com>
In-Reply-To: <158215814449.17742.13589957997277399910.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Enabled=true; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Name=Juniper Business Use Only; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Enabled=true; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_ContentBits=0; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_Method=Standard; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_ActionId=7664fc77-fd1e-426e-a085-000059d8bc97; MSIP_Label_9784d817-3396-4a4f-b60c-3ef6b345fe55_SetDate=2020-02-26T15:57:13Z;
user-agent: Microsoft-MacOutlook/10.22.0.200209
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: b906571e-f220-47c5-4559-08d7badc828a
x-ms-traffictypediagnostic: BL0PR05MB4914:
x-microsoft-antispam-prvs: <BL0PR05MB4914669D90F3EB0F6C54E52AB7EA0@BL0PR05MB4914.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0325F6C77B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(366004)(39860400002)(346002)(376002)(396003)(189003)(199004)(54906003)(110136005)(86362001)(36756003)(71200400001)(186003)(81166006)(316002)(81156014)(966005)(8936002)(8676002)(2616005)(2906002)(5660300002)(26005)(76116006)(66446008)(6512007)(64756008)(66556008)(66476007)(66946007)(30864003)(4326008)(478600001)(6486002)(33656002)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR05MB4914; H:BL0PR05MB5027.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 3haw6clgROmbEmiaD+yJP6w7NbfXqfqpU2Zf8A7cJyZIMPu9+dGBVnKUjAOmFaDel35GYroZloY1Ip/OpTpoiNV/6NLhTgD/F2YIjOnxelwAlCapfwtgC+weEECQQYRLtm6LcJm7bzaTQ4O6JwKrDaipbQKNe8KEv6LUm+imcWRll6bJ2+g4xxZV0wf+GGvEt/eSGcjuyyQJXMSlRTV9A1wfaVm6WYfy4qakW5bi9hP6+PnfwRLJt4heWLNdYF5WeydU6s3rvWJRYMzkBwxAgKe6X6c84nJcNbjhllx58OeSxcRZV2TbiSReTYtrW4f2BteYv9SCq/09Fsqbx32T88P+ZrKUwi0r2K97G26VkAKobM3tQFyrSPbStisH1jNyODAF7TUwJo8ATPZM2ERPZOPimyHJkDt2FAKa9Ozhh9AXEFjKd1Ju+pFlNh9Wa0kEePLmloc7qJvxv+dH3bBtXMzE4Giks8aZbG0Y/+iTmsEmvydIdDK6yY5i3kVK3tybXDnPWDlCya2wCgty+Ng2ew==
x-ms-exchange-antispam-messagedata: YZcQA4xkkGK0iyF89Cl/vhxyRHVmdeGGxU50ir9+gavS/ykMN1FEXA+mlCVwbqlzCTh337xM/7iF4G7N1IlPLiFHGpoCvKM7Y1vPXRUGPMXIO3tIJYFNGyAsZJcRmRdVmCTuMQEX/7M5w4VEwiLqtg==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <1F518F20045B804D8C1A1CBCF2490925@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: b906571e-f220-47c5-4559-08d7badc828a
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2020 16:54:13.9707 (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: 1FK4Q+m9qDgvYeV/EFNnYM1MTUI0e/73eGb3mV+x0ThGcWYWrxPllQqobm6LFGcBMvXogmXN+l7G+6EWnbJi+Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB4914
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-26_06:2020-02-26, 2020-02-26 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 lowpriorityscore=0 clxscore=1011 phishscore=0 mlxlogscore=999 adultscore=0 spamscore=0 mlxscore=0 impostorscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002260113
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/GfYLc8lMdDBgZaHmKJcwuXlC-vA>
Subject: Re: [mpls] Benjamin Kaduk's No Objection on draft-ietf-mpls-summary-frr-rsvpte-08: (with COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Feb 2020 16:54:19 -0000
Hi Benjamin, Thank you much for reviewing the document and for the provided comments. We have uploaded version -09 which addresses those - diffs at: https://tools.ietf.org/rfcdiff?url2=draft-ietf-mpls-summary-frr-rsvpte-09.txt Please see inline for further clarification. On 2/19/20, 7:22 PM, "Benjamin Kaduk via Datatracker" <noreply@ietf.org> wrote: Benjamin Kaduk has entered the following ballot position for draft-ietf-mpls-summary-frr-rsvpte-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!NEt6yMaO-gk!SGyRA2gLM4trHPJWqXsD2TAPzQ9xZ1xLq3IBuMDFFNYXAFNS-dAL8YO1QCvSbQ$ for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-mpls-summary-frr-rsvpte/__;!!NEt6yMaO-gk!SGyRA2gLM4trHPJWqXsD2TAPzQ9xZ1xLq3IBuMDFFNYXAFNS-dAL8YNzdi70mQ$ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Nice and simple. Thanks! RFC 2961 says that MESSAGE_ID objects are "always generated and processed over a single hop between RSVP neighbors", but IIRC the PLR and MP need not be immediate neighbors. Has this restriction from RFC 2961 already been lifted by some other document that we can reference (e.g., in Section 3.1.x where we say "a MESSAGE_ID object as defined by [RFC2961]")? [TS]: the PLR and MP can be multiple hops away. However after FRR, the signaling from the PLR is tunneled over the bypass tunnel, so the PLR and MP will appear as 1-hop away so RFC2961 is applicable without changes. Is it generally understood that "Reserved for future use." means "set to zero on transmit and ignore on receipt, until further notice"? [TS]: this was modified to: NEW: Reserved for future use. MUST be set to zero when sending and ignored on receipt. END Section 1 similar number of LSPs that ingress on the same link. In the event of the failure of the link or neighbor node, the RSVP-TE control plane of the node when acting as a PLR becomes busy rerouting protected LSPs signaling over the bypass tunnel(s) in one direction, nit: I think there's a singular/plural (possessive?) mismatch near "LSPs". [TS]: this was revised to: NEW: In the event of the failure of the link or neighbor node, the RSVP-TE control plane of the node (when acting as a PLR node) becomes busy rerouting protected LSPs over the bypass tunnel(s) in one direction . . . END Section 3 The PLR SHOULD assign the same Bypass_Group_Identifier to all protected LSPs that egress the same protected interface and are protected by the same bypass tunnel. This minimizes the number of bypass tunnel SFRR groups, and optimizes the amount of signaling needed between the PLR and the MP after FRR. [...] The PLR SHOULD assign the same Bypass_Group_Identifier to all protected LSPs that share the egress link, and bypass tunnel as long as the protected LSP(s) have the common group attributes, including the modified tunnel sender address used for backup path identification as described in [RFC4090]. Is one of these a superset of the other? [TS]: this was revised to eliminate repetition. NEW: A PLR node SHOULD assign the same Bypass_Group_Identifier to all protected LSPs provided that the protected LSPs: o share the same outgoing protected interface, o are protected by the same bypass tunnel, and o are assigned the same tunnel sender address that is used for backup path identification after FRR as described in [RFC4090]. END The MP maintains the PLR group assignments learned via signaling, and acknowledges the group assignments via signaling. Once the PLR receives the acknowledgment, FRR signaling can proceed as group based. nit: "group-based" is (1) hyphenated, and (2) an adjective, so we need a noun to hang it off of. [TS]: revised to: NEW: The MP maintains the PLR node group assignments learned from signaling, and acknowledges the group assignments to the PLR node via signaling. Once the PLR node receives the group assignment acknowledgment from the MP, the FRR signaling can proceed based on Summary FRR procedures as described in this document. END The PLR node that supports Summary FRR procedures adds an Extended ASSOCIATION object with B-SFRR-Ready Extended Association ID in the nit: I'd suggest s/The/A/ since there's probably more than one PLR node that meets these criteria, globally. [TS]: addressed globally, as suggested. Section 3.1.2 to [RFC2961]. The MESSAGE_ID object flags SHOULD be cleared when transmitted by the PLR and ignored when received at the MP. When might this SHOULD be ignored? (Are there cases where a MP might assign semantics to a received flag that was not intentionally set by the PLR with intent to induce those semantics?) [TS]: this was changed to MUST - see below: NEW: according to [RFC2961]. The MESSAGE_ID object flags MUST be cleared when transmitted by the PLR node and ignored when received at the MP node. END Resv message (with exception of the MESSAGE_ID). If the fields do not match, or if B-SFRR-Ready Extended ASSOCIATION object is absent in a subsequent refresh, the PLR node MUST consider the protected LSP as not Summary FRR capable. This "absent in a subsequent refresh" makes me wonder about race conditions where the PLR tries to refresh and the MP removes the B-SFRR-Ready nature in its Resv, but the PLR attempts to engage the bypass before the Resv makes its way to the PLR -- the PLR thinks the bundled protection is active but the MP does not. Is this just "normal operation" and not worth worrying about? [TS]: thanks for highlighting it. This case will recover using normal protocol mechanisms. A new paragraph was added to clarify this case: NEW: A race condition may arise for a previously Summary FRR capable protected LSP when the MP node triggers a refresh that does not contain the B-SFRR-Ready Extended ASSOCIATION object, while at the same time, the PLR triggers Summary FRR procedures due to a fault occurring concurrently. In this case, it is possible that the PLR triggers Summary FRR procedurees on the protected LSP before it can receive and process the refresh from the MP node. As a result, the MP will receive a Srefresh with a Message_Identifier that is not associated with any state. As per [RFC2961], this results in the MP generating an Srefresh NACK for this Message_Identifier and sending it back to the PLR. The PLR processes the Srefresh NACK and replays the full Path state associated with the Message_Identifier, and subsequently recovering from this condition. END Section 3.2.x The Bypass_Group_Identifier that is previously signaled by the PLR using the Extended Association object. One or more Bypass_Group_Identifiers MAY be included. nit: s/is/was/ (I think?) [TS]: OK, adopted. Replacement TIME_VALUES object to be applied to all LSPs associated with each of the following Bypass_Group_Identifiers after receiving the B-SFRR-Active Extended ASSOCIATION Object. nit: s/following/preceding/ (I think?) [TS]: OK, adopted. Section 3.3 The facility backup method introduced in [RFC4090] takes advantage of MPLS label stacking (PLR imposing additional MPLS label post FRR) to allow rerouting of protected traffic over backup path. The backup nit: s/over backup path/over the backup path/ [TS]: OK, adopted. Section 3.3.2 Note, an MP may receive more than one RSVP Path message with the B- SFRR-Ready Extended ASSOCIATION object from different upstream PLR node(s). In this case, the MP node is expected to save all the received MESSAGE_IDs from the different upstream PLR node(s). After a failure, the MP node determines and activates the associated Summary Refresh ID to use once it receives and processes the RSVP Path message containing B-SFRR-Active Extended ASSOCIATION object that is signaled over the bypass tunnel from the PLR, as described Section 3.4 What is a "Summary Refresh ID" and where is it defined? I don't see it either here or in RFC 2961. [TS]: the correct term that RFC2961 uses is Srefresh Message_Identifier from the MESSAGE_ID object. NEW: After a failure, the MP node determines and activates the state(s) associated with the Bypass_Group_Identifier(s) received in the RSVP Path message containing B-SFRR-Active Extended ASSOCIATION object that is signaled over the bypass tunnel from the PLR node, as described Section 3.4 END The PLR MUST signal non-Summary FRR capable LSPs over the bypass tunnel before signaling the Summary FRR capable LSPs. This is needed to allow for the case where the PLR node recently changed a bypass assignment and the MP has not processed the change yet. Talking through this, there's two main cases for "changed a bypass assignment", right -- "added an LSP to a group" and "removed an LSP from a group"? For the "removed from a group" case I see how this helps, since the PLR sends an explicit change and the MP can assume that the explicit change overrides any former group membership. But I'm not sure how/whether this helps with the "added to a group" change. [TS]: In case of adding a protected LSP to a group, the PLR only declares it Summary FRR capable after the MP acknowledges the B-SFRR back - as described in section 3: " Once the PLR node receives the group assignment acknowledgment from the MP, the FRR signaling can proceed based on Summary FRR procedures as described in this document. " Section 3.4.1 The RSVP_HOP_Object field in the B-SFRR-Active Extended ASSOCIATION ID is set to the common RSVP_HOP that was used by the PLR in Section 3.3 of this document. I see something more plausible as a target for this reference in Section 3.2(.x) than in Section 3.3(.x). [TS]: this was revised as below: NEW: The RSVP_HOP_Object field in the B-SFRR-Active Extended ASSOCIATION ID is set to a common object that will be applied to all LSPs associated with the Bypass_Group_Identifiers that are carried in the B-SFRR-Active Extended ASSOCIATION ID. END Section 3.4.2 1. The RSVP_HOP object is copied from the B-SFRR-Active Extended ASSOCIATION ID. 2. The TIME_VALUES object is copied from the TIMES_VALUE field in the B-SFRR-Active Extended ASSOCIATION ID. The TIME_VALUES nit: I suggest using a parallel linguistic construction for all the steps (e.g., always or never include "from the <FOO> field in"). [TS]: the steps were normalized as suggested. Section 5 When using procedures defined in this document, FRR (or the reroute of protected LSP(s) on to the bypass tunnel) can be activated on per group of protected LSP(s). This allows an intruder to potentially impact and manipulate a set of protected LSP that are assigned to the same bypass tunnel group. I'd consider saying something about how "new attacks enabled by these mechanisms would also be possible without these mechanisms, just at a higher cost in signalling messages" (with the possible exception of the race condition I mentioned earlier). [TS]: Indeed, added. Such attacks are possible even without the mechanisms proposed in this document at the higher cost resulting from the extra per LSP signaling. Regards, Tarek
- [mpls] Benjamin Kaduk's No Objection on draft-iet… Benjamin Kaduk via Datatracker
- Re: [mpls] Benjamin Kaduk's No Objection on draft… Tarek Saad