[Pce] Comments on draft-crabbe-pce-stateful-pce-mpls-te-00

Dhruv Dhody <dhruv.ietf@gmail.com> Mon, 11 March 2013 15:15 UTC

Return-Path: <dhruv.ietf@gmail.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733C211E80CC for <pce@ietfa.amsl.com>; Mon, 11 Mar 2013 08:15:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1+RnGtAZivG for <pce@ietfa.amsl.com>; Mon, 11 Mar 2013 08:15:18 -0700 (PDT)
Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id D128411E80A4 for <pce@ietf.org>; Mon, 11 Mar 2013 08:15:18 -0700 (PDT)
Received: by mail-ie0-f177.google.com with SMTP id 16so4956182iea.36 for <pce@ietf.org>; Mon, 11 Mar 2013 08:15:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:x-google-sender-delegation:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=eSCjWxZG8OXjkFhWHyUs883CLEGfsgBlSCgRfXAcmXI=; b=QBJ1+RnlA89QpqNiBQTWSPT+u+SK0f+qcSysvj7YDIPRF4GNK77h8PS/LYMbg2NNFF J4OcAXKhDJ4Eo6Ff7YJ2CWrxYGq+GDnJxtr6O3pkZii1VIHMCdQNKOpvyiotJY0IXn4q 8W5mvrDwj9Hr/6e29tPcus3pdNBZzMCW4OocwkmoemxBCDRRW2Ww20Vg3RxJJZLwDt1g KL5Xx45S+SB+DVPp3xuofB6pIdPACx0hhboM4B08twIoC/WVp1qu/XMWY4XE+LJjuRjX 8HUTwMBuMkT8oYWAf/MXwBQREOA8JcPi285McdqOaT+gNo4GpCy4NSZLVe7dYIqDXRmG g+jQ==
MIME-Version: 1.0
X-Received: by 10.50.190.233 with SMTP id gt9mr7542217igc.80.1363014918435; Mon, 11 Mar 2013 08:15:18 -0700 (PDT)
Sender: dhruvdhody@gmail.com
X-Google-Sender-Delegation: dhruvdhody@gmail.com
Received: by 10.50.16.110 with HTTP; Mon, 11 Mar 2013 08:15:18 -0700 (PDT)
Date: Mon, 11 Mar 2013 20:45:18 +0530
X-Google-Sender-Auth: aRhR5k6xqyed0JV4RYLqgLKlSNs
Message-ID: <CAB75xn64rxEoeCjDjkanmGRDKX6S19JLWRhNovJvyj5w7ns4ng@mail.gmail.com>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
To: pce@ietf.org
Content-Type: multipart/alternative; boundary="14dae9341177099a2704d7a7a474"
Subject: [Pce] Comments on draft-crabbe-pce-stateful-pce-mpls-te-00
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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>
X-List-Received-Date: Mon, 11 Mar 2013 15:15:19 -0000

Hi,

Please find some review comments for this draft...

*(1) PCRpt Message*
a. There is a different in RBNF between this
and draft-ietf-pce-stateful-pce-02
b. <path-list>::=<path>[<path-list>]. The status of the paths needs to
reported separately in case of standby but we have only one LSP object here
to specify the operational status. Also LSP-ID of primary and backup would
be different.
c. Incase of the delegate, all constraints configured at PCC needs to be
sent to PCE. The PCRpt message should support this.
d. ERO is a mandatory object and incase of the LSP's first delegate message
there will be no existing path and thus no path to encode in the ERO.
Either we send empty ERO i.e ERO but with no sub-objects or make ERO
optional.
e. In case of the first delegate message how to send the destination
information? ENDPOINT object is needed.
f. Support for IRO, XRO should be supported in case of PCRpt message.

Most of the above comments are also applicable for PCUpd message.

*(2) LSP Identifier TLVs*
a. The relationship between LSP-ID in LSP Object and LSP Identifier TLV
should be described.
b. Maybe Tunnel Destination Address can be encoded too similar to
LSP_TUNNEL_IPvX sender template
c. The use of tunnel-id to describe when the traffic switches from primary
and secondary is not very clear to me, maybe you can describe this here or
in protection document in more details.

*(3) Tunnel ID TLV*
What is the need of this TLV? The description is the same as the tunnel-id
already present in the LSP Identifier TLV.

Regards,
Dhruv