Re: [RTG-DIR] [Last-Call] Rtgdir last call review of draft-ietf-teas-gmpls-signaling-smp-07
Jeong-dong Ryoo <ryoo@etri.re.kr> Fri, 15 October 2021 09:21 UTC
Return-Path: <ryoo@etri.re.kr>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27543A18DA for <rtg-dir@ietfa.amsl.com>; Fri, 15 Oct 2021 02:21:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=dooray.com
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 CFptnNMx9cvx for <rtg-dir@ietfa.amsl.com>; Fri, 15 Oct 2021 02:21:06 -0700 (PDT)
Received: from mscreen.etri.re.kr (mscreen.etri.re.kr [129.254.9.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F6F03A18D7 for <rtg-dir@ietf.org>; Fri, 15 Oct 2021 02:21:03 -0700 (PDT)
Received: from unknown (HELO send001-relay.gov-dooray.com) (211.180.235.152) by 129.254.9.16 with ESMTP; 15 Oct 2021 18:21:01 +0900
X-Original-SENDERIP: 211.180.235.152
X-Original-MAILFROM: ryoo@etri.re.kr
X-Original-RCPTTO: rtg-dir@ietf.org
Received: from [10.162.225.103] (HELO send001.gov-dooray.com) ([10.162.225.103]) by send001-relay.gov-dooray.com with SMTP id f32ddf87616947fd; Fri, 15 Oct 2021 18:21:01 +0900
DKIM-Signature: a=rsa-sha256; b=s1KkMDlq1WQd3y2i+fuGEypp63nxsfkgjqwOYLwCJvzHfZyswihkfTZguSUnNnFG7IxH4qCmeg 5MHHeSlqjbVag/x1za1/LuvlUua+MBEgbWe7jbPBacmlyLUemYObwtUFNkeLNAQBgi1wYhgiAiaM ebiTEqujeruAFKiFITzLu17FPlqeWMELDo8ncvojTDs4NKGQP9gTuUPuY46FQzL0S/nSbxLKtguB nXhItXKRQgsPYmXaoKW7fow8TeXskRyub+RAjd6nkLvJegZFMFx+fwwXWpVl4tPR2priNAg+tTRQ iCgPHH02ADHxYF5JYk5/NjHXF31UsFptL3I5p9Sw==; c=relaxed/relaxed; s=selector; d=dooray.com; v=1; bh=cnojJYwIr7phesaGOiDJKsM85IvxoNioEEypN2snMog=; h=From:To:Subject:Message-ID;
Dooray-Meta-Signature: /ANB+2U2MLNca0gW9KcnulSYeyPoDVlQBZP0irJ+fFk00Y5mz2cdE JGM2+MSUY4V6s915o7W1VucUCd+W2Cmmzb1Yz6hTpO6WkJGj6mVBaiigzlMafiLUfPLuVCEGghQD 6h4WyFM4T6X/sHqnf2tKykA6SRHVU9TsMbFTbRePlWgOfqN6u5M3J1tLyKOsroCvZ3M6xd1IttMu bwTiaFZTuIfs5rYNDb4su9yAM2iwEGg+kjelb3zJouvP7C4v1j5z+3M2u7qgRe8+G5UPfCl1v7M8 tD/mX8oZc3SDFIaylfOI+31yegaRQQbkWIWeMyA6RVgJr68i5gAPanEhgNYVgWzZhkPIz0jYs6ZW c5QsKw=
Received: from [129.254.197.129] (HELO 129.254.197.129) ([129.254.197.129]) by send001.gov-dooray.com with SMTP id 60aa4cd3616947fc; Fri, 15 Oct 2021 18:21:00 +0900
From: Jeong-dong Ryoo <ryoo@etri.re.kr>
To: rtg-dir@ietf.org, Ines Robles <mariainesrobles@googlemail.com>
Cc: last-call@ietf.org, teas@ietf.org, draft-ietf-teas-gmpls-signaling-smp.all@ietf.org
Message-ID: <npgz0r4lhigg.npgz0r4lddsv.g1@dooray.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
X-Dsn-Request: true
X-Dooray-Agent: mail-api
X-Dooray-Mail-Id: 3120426906578250928
Importance: Normal
X-Priority: Normal
X-MSMail-Priority: Normal
X-Dooray-Attached: c3+LUOpPU/IB7Wl+oemm0lw5HiI/bJHHYClX72L8E3o=
Sender: ryoo@etri.re.kr
Date: Fri, 15 Oct 2021 18:21:00 +0900
References: <163373157043.2600.17836122324811433931@ietfa.amsl.com>
In-Reply-To: <163373157043.2600.17836122324811433931@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/BnK3lyvwNGm647MzEgRkLS6Wa1s>
Subject: Re: [RTG-DIR] [Last-Call] Rtgdir last call review of draft-ietf-teas-gmpls-signaling-smp-07
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Oct 2021 09:21:12 -0000
Dear Ines, Thank you for your review and for giving us your comments. The co-authors of this draft have discussed, and we think all of your comments should be reflected. We are proposing text modifications as shown below: #1: OLD: ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects of a shared mesh protection (SMP) mechanism NEW: TU-T Recommendation G.808.3 [G808.3] defines the generic aspects of a shared mesh protection (SMP) mechanism, which are not specific to a particular network technology in terms of architecture types, preemption principle, and path monitoring methods, etc. #2: Add the following new sentence after the sentence you indicated: Examples of shared resources include the capacity of a link and the cross-connects in a node. #3: Modify the text as you suggested #4-1: Modify the text as you suggested #4-2: OLD: (1) the ability to identify a "secondary protecting LSP" (hereby called the "secondary LSP") used to recover another primary working LSP (hereby called the "protected LSP") NEW: (1) the ability to identify a "secondary protecting LSP" (LSP [A,E,F,G,D] or LSP [H,E,F,G,K] from Figure 1, hereby called the "secondary LSP") used to recover another "primary working LSP" (LSP [A,B,C,D] or LSP [H,I,J,K] from Figure 1, hereby called the "protected LSP"). #5: OLD: The security threats discussed in [RFC4872] also apply to this document. Additionally, it may be possible to cause disruption to traffic on one protecting LSP by targeting a link used by the primary LSP of another, higher priority LSP somewhere completely different in the network. To prevent such an additional risk factor, it is important not only to use security mechanisms as discussed in [RFC4872] but also to preserve privacy of information about protecting LSPs within the network. NEW: Since this document makes use of the exchange of RSVP messages including a Notify message, the security threats discussed in [RFC4872] also apply to this document. Additionally, it may be possible to cause disruption to traffic on one protecting LSP by targeting a link used by the primary LSP of another, higher priority LSP somewhere completely different in the network. For example, in Figure 1, assume that the preemption priority of LSP [A,E,F,G,D] is higher than that of LSP [H,E,F,G,K] and the protecting LSP [H,E,F,G,K] is being used to transport traffic. If link B-C is attacked, traffic on LSP [H,E,F,G,K] can be disrupted. To prevent such an additional risk factor, it is important not only to use security mechanisms as discussed in [RFC4872] but also to preserve privacy of information about protecting LSPs within the network. If you have any comments on the proposed changes, please let us know. Best regards, Jeong-dong (on behalf of co-authors) -----Original Message----- From: "Ines Robles via Datatracker" <noreply@ietf.org> To: <rtg-dir@ietf.org>; Cc: <last-call@ietf.org>; <teas@ietf.org>; <draft-ietf-teas-gmpls-signaling-smp.all@ietf.org>; Sent: 2021-10-09 (토) 07:20:42 (UTC+09:00) Subject: [Last-Call] Rtgdir last call review of draft-ietf-teas-gmpls-signaling-smp-07 Reviewer: Ines Robles Review result: Has Nits Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-teas-gmpls-signaling-smp-07 Reviewer: Ines Robles Review Date: 2021-10-08 IETF LC End Date: 2021-10-08 Intended Status: Standards Track Summary: This document updates RFC 4872 to provide the extensions to the Generalized Multi-Protocol Label Switching (GMPLS) signaling to support the control of the Shared Mesh Protection. I did not find major issues, I have some questions/comments. Major Issues: Not found Minor Issues: Not found Nits: 1- Section 1: Which are the generic aspects of SMP signaling? Maybe it would be nice to add "Only the generic aspects (such as....) for signaling SMP..." 2- Section 4: "...resource sharing along nodes E, F and G..." Maybe it would be nice to add examples of resources that can be shared between the nodes E, F and G. 3- Section 4, page 5: Maybe? the intermediate node MUST send.... => the intermediate node (node E) MUST send... 4- Section 4, page 6: ... with a new sub-code "Shared resources unavailable"=>... with a new sub-code "Shared resources unavailable"(TBD1)... ... with a new sub-code "Shared resources available" => ... with a new sub-code "Shared resources available" (TBD2)... 4- Section 4, page 6: Maybe it would be nice to associate with an example the five points outlined on how LSPs using SMP can be signaled in an interoperable fashion, e.g. ..(1) the ability to identify a "secondary protecting LSP", from Figure 1, which would be the secondary LSP "E,F,G"? 5- Section 7: The Security considerations do not explain clearly how the RFC4872-security-considerations applies to the Shared Mesh Protection and to the preemption priority. Thanks for this document, Ines. -- last-call mailing list last-call@ietf.org https://www.ietf.org/mailman/listinfo/last-call
- [RTG-DIR] Rtgdir last call review of draft-ietf-t… Ines Robles via Datatracker
- Re: [RTG-DIR] [Last-Call] Rtgdir last call review… Jeong-dong Ryoo
- Re: [RTG-DIR] [Last-Call] Rtgdir last call review… Ines Robles
- Re: [RTG-DIR] [Last-Call] Rtgdir last call review… Jeong-dong Ryoo