Re: [Teas] Secdir last call review of draft-ietf-teas-rsvp-egress-protection-09
Huaimo Chen <huaimo.chen@huawei.com> Thu, 22 February 2018 21:46 UTC
Return-Path: <huaimo.chen@huawei.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4404C12D950; Thu, 22 Feb 2018 13:46:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Level:
X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 6D9TF7Y42OIx; Thu, 22 Feb 2018 13:46:02 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 5B3A012420B; Thu, 22 Feb 2018 13:46:02 -0800 (PST)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id EAFF27615A615; Thu, 22 Feb 2018 21:45:57 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 22 Feb 2018 21:45:59 +0000
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.168]) by SJCEML703-CHM.china.huawei.com ([169.254.5.179]) with mapi id 14.03.0382.000; Thu, 22 Feb 2018 13:45:56 -0800
From: Huaimo Chen <huaimo.chen@huawei.com>
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, "secdir@ietf.org" <secdir@ietf.org>
CC: "draft-ietf-teas-rsvp-egress-protection.all@ietf.org" <draft-ietf-teas-rsvp-egress-protection.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: Secdir last call review of draft-ietf-teas-rsvp-egress-protection-09
Thread-Index: AQHTqnAoz+h2spacWkiZ4uzsCmYfVaOwjCSg
Date: Thu, 22 Feb 2018 21:45:55 +0000
Message-ID: <5316A0AB3C851246A7CA5758973207D463A52635@sjceml521-mbs.china.huawei.com>
References: <151914767152.4003.2724168782038044771@ietfa.amsl.com>
In-Reply-To: <151914767152.4003.2724168782038044771@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.155.146]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/IB9SdEvJZ0YnX08CRZzC1Wv3H3g>
Subject: Re: [Teas] Secdir last call review of draft-ietf-teas-rsvp-egress-protection-09
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Feb 2018 21:46:04 -0000
Hi Rifaat, Thank you much for your time and your valuable comments. Answers to your questions are inline below with prefix [HC]. Would you mind reviewing them to see if they address the issues? Best Regards, Huaimo -----Original Message----- From: Rifaat Shekh-Yusef [mailto:rifaat.ietf@gmail.com] Sent: Tuesday, February 20, 2018 12:28 PM To: secdir@ietf.org Cc: draft-ietf-teas-rsvp-egress-protection.all@ietf.org; ietf@ietf.org; teas@ietf.org Subject: Secdir last call review of draft-ietf-teas-rsvp-egress-protection-09 Reviewer: Rifaat Shekh-Yusef Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. "A backup egress MUST be configured on the ingress of an LSP to protect a primary egress of the LSP if and only if the backup egress is not indicated in another place." Can you define "another place"? Is it the "primary egress"? others? [HC] Yes. Another place in this context is the primary egress. We will update the document accordingly as below: "A backup egress MUST be configured on the ingress of an LSP to protect a primary egress of the LSP if and only if the backup egress is not configured on the primary egress." "To protect a primary egress of an LSP, a backup egress MUST be configured on the primary egress of the LSP to protect the primary egress if and only if the backup egress is not indicated in another place." Can you define "another place"? Is it the "ingress"? others? [HC] Yes. Another place in this context is the ingress. We will update the document accordingly as below: "To protect a primary egress of an LSP, a backup egress MUST be configured on the primary egress of the LSP to protect the primary egress if and only if the backup egress is not configured on the ingress." "Note that protecting a primary egress of a P2P LSP carrying service traffic through a backup egress requires that the backup egress trust the primary egress for the information received for a service label as UA label." Can you elaborate on this statement? How would the backup egress trust the primary egress? [HC] The information may be sent to the backup egress from the "primary egress" through another protocol such as BGP. The backup egress need to make sure that the "primary egress" that another protocol uses is the same primary egress to be protected. The backup egress may check whether the remote end of the BGP session is the primary egress if BGP is used to send the information to the backup egress from the "primary egress". We will update the document accordingly as below: "Note that protecting a primary egress of a P2P LSP carrying service traffic through a backup egress requires that the backup egress make sure that the "primary egress" sending the backup egress the information on a service label as UA label through another protocol such as BGP is the same primary egress to be protected." Regards, Rifaat
- [Teas] Secdir last call review of draft-ietf-teas… Rifaat Shekh-Yusef
- Re: [Teas] Secdir last call review of draft-ietf-… Huaimo Chen
- Re: [Teas] Secdir last call review of draft-ietf-… Rifaat Shekh-Yusef