Re: [Teas] Secdir last call review of draft-ietf-teas-rsvp-egress-protection-09

Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> Fri, 23 February 2018 14:06 UTC

Return-Path: <rifaat.ietf@gmail.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 119D612E054; Fri, 23 Feb 2018 06:06:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 I0nNFql7O4xr; Fri, 23 Feb 2018 06:06:49 -0800 (PST)
Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 494FF12E046; Fri, 23 Feb 2018 06:06:49 -0800 (PST)
Received: by mail-ua0-x231.google.com with SMTP id x4so5767278uaj.11; Fri, 23 Feb 2018 06:06:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B9UPCHQt0auNhIgIhjeYyUyGm8NawEBTLzUekcD8yIM=; b=IdWmz6/poRayKhlloAEBo49vRUmFbi8ErlLSX1dyES2uYs2cpkGFMR+HVYaPC349XB x4d4d2e2VFfdiRfgPfT2gF0sc/LgqKDwVkA/rol4M+wlGHSlddiZM0oyKUoVVG0/3C5L BUdnYCoZpEm7Sd8jrMkxt8mLABv2ASdM+i7F50nya53Yqc8ztGhiJlI9dd7ouer3FSsb BHPP08xmHYOe5Ww2CpUPxpSB3/OrXOWVKtgpQ3E6QVFoTIvOOQTmskiP2SxBDGE/UTF/ 3jdvO9Zo+Hu11xVd+cPImU2pLqLOITl/2XPlPJlll1T8M0T+01Hz3sClWb7W3w0AG84K NR+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B9UPCHQt0auNhIgIhjeYyUyGm8NawEBTLzUekcD8yIM=; b=Zs2C5KhjG8kRPVQ6X6/zFC4E8UJru8EhZ7bskX/atZXKtaOE7ez7mJP6wHxS64inu7 XbskVSEUuvvY6Zxn3GrfHwtNpgTb9UonHaT5QNpRCAcYs6avjM1B+B+j7jIW+7B34S+/ Veik+LUejZ060f1SWcjDFOqpM6WMyB4yur/dwmumv7d8HfMxwTzK64GNqlE988Q0YG71 jTbfcC7oravE1tLrMydr5krJ87RdIxDGplF17pMkxrnkTkT2S8+tsIqJ3xuzO2zO7bYx h57Oq6+oYixvIEp0ka5VFtghD9moXBcu5iRp5iUKUGz0hCsiVIMtWMTC7kUKdzzHX0y7 hhOQ==
X-Gm-Message-State: APf1xPDMWTvl3G+oRF0uNGR3UN05wreL5gw5PFmCRPTrsuIjRGUmiPKF QDpvOmbipTzKhfiST4bNKVmPE5BoZCHJE06E8w4=
X-Google-Smtp-Source: AG47ELv9OT/3ukcjrkUvIKvJLuiavnH/S1BXDA+3PqgqkGmj5F0+7IC1vjOj/nJu48z3Gxob8omgaH6mYrpRqlNBJWs=
X-Received: by 10.176.78.203 with SMTP id x11mr1317977uah.194.1519394808376; Fri, 23 Feb 2018 06:06:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.45.148 with HTTP; Fri, 23 Feb 2018 06:06:47 -0800 (PST)
In-Reply-To: <5316A0AB3C851246A7CA5758973207D463A52635@sjceml521-mbs.china.huawei.com>
References: <151914767152.4003.2724168782038044771@ietfa.amsl.com> <5316A0AB3C851246A7CA5758973207D463A52635@sjceml521-mbs.china.huawei.com>
From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Fri, 23 Feb 2018 09:06:47 -0500
Message-ID: <CAGL6epJohJuFL4GQ+2sk5482QE1cLohGGgg5-TQYWMo6jrStPQ@mail.gmail.com>
To: Huaimo Chen <huaimo.chen@huawei.com>
Cc: "secdir@ietf.org" <secdir@ietf.org>, "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>
Content-Type: multipart/alternative; boundary="089e08e4f993d3b4f10565e1ab34"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/wRyo6kMDdSfkra-nbTI82ykGni4>
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: Fri, 23 Feb 2018 14:06:51 -0000

Hi Huaimo,

I am fine with the new suggested changes to the text.

Regards,
 Rifaat


On Thu, Feb 22, 2018 at 4:45 PM, Huaimo Chen <huaimo.chen@huawei.com> wrote:

> 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
>
>
>