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

Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> Tue, 20 February 2018 17:27 UTC

Return-Path: <rifaat.ietf@gmail.com>
X-Original-To: teas@ietf.org
Delivered-To: teas@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 939E1124F57; Tue, 20 Feb 2018 09:27:51 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
To: secdir@ietf.org
Cc: draft-ietf-teas-rsvp-egress-protection.all@ietf.org, ietf@ietf.org, teas@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.72.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151914767152.4003.2724168782038044771@ietfa.amsl.com>
Date: Tue, 20 Feb 2018 09:27:51 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/ONi2G2w5eM3BfUlEKNX724ueVqA>
Subject: [Teas] Secdir last call review of draft-ietf-teas-rsvp-egress-protection-09
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 20 Feb 2018 17:27:52 -0000

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?
 

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

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

Regards,
 Rifaat