Re: [CCAMP] Supplementary question on draft-ietf-pce-gmpls-aps-req

"Ogaki, Kenichi" <ke-oogaki@kddi.com> Thu, 06 June 2013 08:08 UTC

Return-Path: <ke-oogaki@kddi.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3948121F92E3 for <ccamp@ietfa.amsl.com>; Thu, 6 Jun 2013 01:08:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 0yPEpCTGZxGO for <ccamp@ietfa.amsl.com>; Thu, 6 Jun 2013 01:08:48 -0700 (PDT)
Received: from UTMC1101.kddi.com (athena.kddi.com [210.141.112.39]) by ietfa.amsl.com (Postfix) with ESMTP id 3E26921F9263 for <ccamp@ietf.org>; Thu, 6 Jun 2013 01:08:47 -0700 (PDT)
Received: from UTMC1134 (unknown [10.5.16.201]) by UTMC1101.kddi.com (Postfix) with SMTP id 813A214B5; Thu, 6 Jun 2013 17:08:46 +0900 (JST)
Received: from UTMC1122.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 7BEC21924; Thu, 6 Jun 2013 17:08:42 +0900 (JST)
Received: from LTMC1006.kddi.com (unknown [10.5.16.217]) by UTMC1122.kddi.com (Postfix) with ESMTP id 61B221CB4; Thu, 6 Jun 2013 17:08:42 +0900 (JST)
Received: from LTMC1006.kddi.com (localhost.localdomain [127.0.0.1]) by LTMC1006.kddi.com with ESMTP id r5688gTM010288; Thu, 6 Jun 2013 17:08:42 +0900
Received: from LTMC1006.kddi.com.mid_18060911 (localhost.localdomain [127.0.0.1]) by LTMC1006.kddi.com with ESMTP id r567weFe031375; Thu, 6 Jun 2013 16:58:40 +0900
Received: from KDDI0802PC0412 ([10.200.132.0] [10.200.132.0]) by post-zip.kddi.com with ESMTPA; Thu, 6 Jun 2013 16:58:39 +0900
From: "Ogaki, Kenichi" <ke-oogaki@kddi.com>
To: <adrian@olddog.co.uk>, <draft-ietf-pce-gmpls-aps-req.all@tools.ietf.org>
References: <059201ce611b$7665aff0$63310fd0$@olddog.co.uk>
In-Reply-To: <059201ce611b$7665aff0$63310fd0$@olddog.co.uk>
Date: Thu, 6 Jun 2013 16:58:39 +0900
Message-Id: <011c01ce628b$a8004810$f800d830$@kddi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIkyvGXtTWlwtUhjt7omraTzNv/TJh7c41w
Content-Language: ja
X-SA-MID: 18060911
X-WAuditID: 1306061708420000428068
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] Supplementary question on draft-ietf-pce-gmpls-aps-req
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2013 08:08:52 -0000

Dear Adrian,

> Just talking about this I-D with someone and we wondered where and how you
> see the RSVP-TE ASSOCIATION object with your work.

IMHO, ASSOCIATION object should be handled by RSVP-TE handling process on an
LSP head-end node, separated from PCC process on this node.
However, PCC should indicate a protection type how a protecting LSP protects
the protected one in PCReq as described in 3.1(7) and 3.2(3). In this case,
the PCC process receives both calculated protecting and protected routes
from PCE, then informs the RSVP-TE process of these routes. After that,
RSVP-TE process should appropriately add ASSOCIATION object to Path messages
for these LSPs. 

If we touch on ASSOCIATION object in this draft, a sentence may be added to
3.2(3)Roles of the routes as follows.

When a PCC specifies the protection type of an LSP, the PCE should compute
the working route and the corresponding protection route(s). Therefore, the
PCRep should allow to distinguish the working (nominal) and the protection
routes. According to these routes, RSVP-TE procedure appropriately creates
both the working and the protection LSPs for example with ASSOCIATION object
[RFC6689].

Is this reasonable answer?

Thanks,
Kenichi
--
Kenichi Ogaki
KDDI | IP Transport Network Development Dept.
+81-(0)80-5945-9138 | www.kddi.com


> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: Tuesday, June 04, 2013 9:03 PM
> To: draft-ietf-pce-gmpls-aps-req.all@tools.ietf.org
> Cc: ccamp@ietf.org
> Subject: [CCAMP] Supplementary question on draft-ietf-pce-gmpls-aps-req
> 
> Hi,
> 
> Just talking about this I-D with someone and we wondered where and how you
> see the RSVP-TE ASSOCIATION object with your work.
> 
> Thanks,
> Adrian
> 
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp