[Pce] LC comments on draft-ietf-pce-interas-pcecp-reqs-04.txt

JP Vasseur <jvasseur@cisco.com> Sat, 29 March 2008 19:15 UTC

Return-Path: <pce-bounces@ietf.org>
X-Original-To: ietfarch-pce-archive@core3.amsl.com
Delivered-To: ietfarch-pce-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FDD528C274; Sat, 29 Mar 2008 12:15:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.966
X-Spam-Level:
X-Spam-Status: No, score=-100.966 tagged_above=-999 required=5 tests=[AWL=-0.756, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tl-zGZLvB3Ax; Sat, 29 Mar 2008 12:15:45 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C6F13A6BC4; Sat, 29 Mar 2008 12:15:45 -0700 (PDT)
X-Original-To: pce@core3.amsl.com
Delivered-To: pce@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776573A6BC4 for <pce@core3.amsl.com>; Sat, 29 Mar 2008 12:15:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUB8myvubMUV for <pce@core3.amsl.com>; Sat, 29 Mar 2008 12:15:40 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 692743A6BE0 for <pce@ietf.org>; Sat, 29 Mar 2008 12:15:40 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.25,575,1199682000"; d="scan'208";a="3416436"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 29 Mar 2008 15:15:39 -0400
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m2TJFdV4025228 for <pce@ietf.org>; Sat, 29 Mar 2008 15:15:39 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2TJFcUr019300 for <pce@ietf.org>; Sat, 29 Mar 2008 19:15:38 GMT
Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Mar 2008 15:15:38 -0400
Received: from 10.86.104.186 ([10.86.104.186]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Sat, 29 Mar 2008 19:15:38 +0000
User-Agent: Microsoft-Entourage/11.4.0.080122
Date: Sat, 29 Mar 2008 15:15:37 -0400
From: JP Vasseur <jvasseur@cisco.com>
To: pce@ietf.org
Message-ID: <C4140D99.3149F%jvasseur@cisco.com>
Thread-Topic: LC comments on draft-ietf-pce-interas-pcecp-reqs-04.txt
Thread-Index: AciR0UTjg1Fibf3EEdym2wANk8WjQA==
Mime-version: 1.0
X-OriginalArrivalTime: 29 Mar 2008 19:15:38.0897 (UTC) FILETIME=[4604C810:01C891D1]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7200; t=1206818139; x=1207682139; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20<jvasseur@cisco.com> |Subject:=20LC=20comments=20on=20draft-ietf-pce-interas-pce cp-reqs-04.txt |Sender:=20 |To:=20<pce@ietf.org>; bh=ZK41aBCc+v9ErY12v8WUPtKJQAF09nvyXGTlzFprEV8=; b=OR1wzwQe62oU2hvcnhTwi5Hf2fLZg+1MMP8QpeYqzMUFbjhPHaXXKqwkqQ kXkE4PdAaO5BzTsxU9dE03zNPKoZ67BaDSlQMwl+jMJy815JsdQ1KIp0IUwh mOYJW2CBmT;
Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
Subject: [Pce] LC comments on draft-ietf-pce-interas-pcecp-reqs-04.txt
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/pce>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: pce-bounces@ietf.org
Errors-To: pce-bounces@ietf.org

Hi,

Here are some last call comments on draft-ietf-pce-brpc-07.txt

  Checking references for intended status: Informational
  
----------------------------------------------------------------------------

== Outdated reference: draft-ietf-ccamp-inter-domain-rsvp-te has been
   published as RFC 5151

== Outdated reference: draft-ietf-ccamp-lsp-stitching has been published as
   RFC 5150

== Outdated reference: draft-ietf-ccamp-inter-domain-pd-path-comp has been
   published as RFC 5152

Other comments
##############

* First page: All authors are editors so you can remove "Editors" after the
names.

* Please make sure that the title and all section headings use capitals

* Just to be consistent with several other documents: s/ MPLS-TE/ MPLS TE

* s/definition/Terminology for the title of section 2.

* There are several places in the document where it would be preferable to
replace "path" by "constrained path". Ex:
" The mechanisms in [INTERD-TE-PDPC]
do not guarantee an optimum path across multiple ASes where an
optimum path for an LSP is one that has the smallest cost"

*  s/ TE-constraints/TE constraints.

* You may want to use a consistent terminology throughout the document:
"inter-AS route", "inter-AS path", "inter-AS TE LSP".

* In the introduction please expand acronyms when first used: LSPs, (G)MPLS.

* Section 3

- s/ "R1 in AS1 wants to setup a MPLS-TE or a GMPLS path"/ "R1 in AS1 wants
   to setup (G)MPLS TE LSP"
- s/ "R1, as a PCC, sends a PCECP path request to PCE1"/ "R1, as a
   PCC, sends a PCECP path computation request to PCE1".
- s/ " PCE1 sends a PCECP path request to PCE2"/" PCE1 sends a PCECP path
computation request to PCE2"
- You wrote:  " R4 returns a PCECP path response to PCE2 with ASBR3 as
    the entry point to AS2 from AS1 and ASBR7 as the exit point to AS3.
   PCE2 then sends a PCECP path request to PCE3 to compute the path
   segment across AS3, starting at ASBR7 and terminating at R7."

You may want to indicate that the choice of ASBR7 is taken for the sake of
illustration.


* Section 4:

- " This section discusses detailed PCECP requirements for inter-AS
   MPLS-TE and GMPLS LSPs."
May be a bit confusion ... How about " This section discusses detailed PCECP
requirements for inter-AS (G)MPLS TE"

- " Specifically, some requirements are more applicable to inter-
   provider inter-AS MPLS-TE and GMPLS operations than to intra-
   provider operations. "

Is a bit ambiguous. How about:

 " Specifically, some requirements are more applicable to inter-
   provider inter-AS than to intra-provider inter-AS MPLS TE and GMPLS
operations. "

- " 1. [RFC4657] states the requirement for a priority level to be
   associated with each path computation request. This document does
   not change that requirement, but, in addition, it MUST be possible
   for an inter-AS PCE to apply local policy to vary the priority of
   path computation requests received across AS borders."

Since the policy is local, why is this a requirement for the PCECP?

- "4. A PCECP path request from one inter-AS PCE to another MUST
   include the previous AS number in the path of the LSP to enable the
   correct application of local policy at the second inter-AS PCE. "

Don't you mean ? :

"4. The PCECP MUST provide the ability to include the previous AS number in
the path of the LSP in a path computation request from one inter-AS PCE to
another. That to enable the correct application of local policy at the
second inter-AS PCE. "

- "6. PCECP MUST support the disjoint path requirements specified in
   [RFC4657] and MUST further allow the specification of AS-diversity
   for the computation of a set of two or more paths. "

The first MUST should be removed here since it is specified in RFC4657. It
should read:

"6. As specified in [RFC4657], PCECP must support the disjoint path
requirements. In addition to this requirement, PCECP MUST further allow the
specification of AS-diversity for the computation of a set of two or more
paths. "

Section 4.1.2

- " 6. A PCECP path computation response MUST be able to identify
diversified paths for the same (G)MPLS-TE LSP."

What did you mean by "same" here?

Section 4.3

- " The PCECP MIB module MUST provide objects to control the behavior of
   PCECP in inter-AS applications.  They include the ASes within the
   scope of an inter-AS PCE, Inter-AS PCEs in neighboring ASes to which
   the requesting PCE will or will not communicate, confidentiality and
   policies, etc.. "

Since you enumerate "objects", it is a bit awkward to terminate the sentence
by "etc ..." You may want to either provide the exhaustive list or remove
the "etc".

Section 4.4

- S/" Confidentiality rules may also apply among ASes under a single
Provider"/" Confidentiality rules may also apply among ASes under a single
SP"

- Just a terminology issue:

" Each SP will in most cases designate some PCEs for inter-AS
MPLS-TE or GMPLS path computation within its own administrative domain
and some other PCEs for inter-provider inter-AS MPLS-TE or GMPLS path
computation."

In several places you use the term "inter-AS MPLS-TE or GMPLS path
computation". You may want to replace it by "inter-AS (G)MPLS TE path
computation".

- s/" PCECP SHOULD allow an SP to hide from other SPs the set of hops
   within its own ASes that are traversed by an inter-AS inter-provider
   LSP (c.f., Section 5.2.1 of [RFC4216])."/" PCECP SHOULD allow an SP to
hide from other SPs the set of hops within its own ASes that are traversed
by an inter-AS inter-provider TE LSP (c.f., Section 5.2.1 of [RFC4216])."
                             ^^^^
Please make sure to consistently use "TE LSP": you are using LSP, TE LSP,
...

- In section 4.1.2:

" 2. A PCECP path computation response from one inter-AS PCE to the
requesting inter-AS PCE MUST be able to carry an identifier for a path
segment it computes to preserve path segment and topology
confidentiality. The objective of the identifier is to be included in
the LSP signaling, whose mechanism is out of scope of this document, to
be used for path expansion during LSP signaling."

Then in section 4.4, you write:

" PCECP SHOULD allow an SP to hide from other SPs the set of hops
   within its own ASes that are traversed by an inter-AS inter-provider
   LSP (c.f., Section 5.2.1 of [RFC4216]). "

And in section 5.3:

"5.3. Confidentiality
 
The PCECP SHOULD also provide mechanism to preserve the confidentiality
of path segments computed by a PCE in one AS and provided to a
computation response in another AS. "


Should the SHOULD be MUST here to be consistent?

Section 5.3

- "Not only is it necessary for such
mechanisms to be provided in PCECP responses, but signaling messages
MUST also provide mechanisms such that an ASBR receiving an incoming
signaling request can apply policy to reject signaling messages that do
not contain the computation responses produced by the local PCE."

The issue is that the MUST applies to signaling ... This document is about
PCECP.

Thanks.

JP.

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce