[CCAMP] Signaling extensions for FA-LSPs (comment on draft-ietf-ccamp-gmpls-signaling-g709v3-01)

Ben Wright <Ben.Wright@metaswitch.com> Mon, 06 February 2012 17:05 UTC

Return-Path: <Ben.Wright@metaswitch.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 103E421F86CE for <ccamp@ietfa.amsl.com>; Mon, 6 Feb 2012 09:05:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id A9eVYsyBFNPb for <ccamp@ietfa.amsl.com>; Mon, 6 Feb 2012 09:05:25 -0800 (PST)
Received: from ENFICSETS3.metaswitch.com (enficsets3.metaswitch.com []) by ietfa.amsl.com (Postfix) with ESMTP id 5819221F86BE for <ccamp@ietf.org>; Mon, 6 Feb 2012 09:05:25 -0800 (PST)
Received: from ENFIRHCAS1.datcon.co.uk ( by ENFICSETS3.metaswitch.com ( with Microsoft SMTP Server (TLS) id; Mon, 6 Feb 2012 17:05:17 +0000
Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHCAS1.datcon.co.uk ([fe80::85a7:aa4e:2516:c2ad%11]) with mapi id 14.02.0247.003; Mon, 6 Feb 2012 17:05:22 +0000
From: Ben Wright <Ben.Wright@metaswitch.com>
To: "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" <draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org>
Thread-Topic: Signaling extensions for FA-LSPs (comment on draft-ietf-ccamp-gmpls-signaling-g709v3-01)
Thread-Index: Aczk8YJ2S9X0jt8bQEec+MWkSS9DMg==
Date: Mon, 6 Feb 2012 17:05:21 +0000
Message-ID: <B3B6FD81D3159A45B5421AF9DD500F8846DE20CE@ENFICSMBX1.datcon.co.uk>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B3B6FD81D3159A45B5421AF9DD500F8846DE20CEENFICSMBX1datco_"
MIME-Version: 1.0
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: [CCAMP] Signaling extensions for FA-LSPs (comment on draft-ietf-ccamp-gmpls-signaling-g709v3-01)
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: Mon, 06 Feb 2012 17:05:27 -0000

Hi Fatai et al,

We have been thinking about function we will need to add to draft-ietf-ccamp-gmpls-signaling-g709v3-01 to fully support automatically provisioned FA-LSPs.   I wanted to see whether you agree with our analysis.

We think that the RSVP-TE signalling should be extended to carry more information in order to allow other nodes on the signalling path to set up the correct FA-LSP.    For example, in the network in http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-01#section-7, we believe that N1 should be able to prescribe to N2 the set of hops that it should use to set up the ODU2 FA-LSP, and the signal type of the FA-LSP it should set up, and (probably) the multiplexing hierarchy to be used at either end.   Typically, we'd expect N1 would want to explicitly prevent N2 from querying routing to set up the FA-LSP  - otherwise, a routing calculation triggered by N2 could compute a path for the FA-LSP inconsistent with N1's intentions (e.g. which could break some SRLG diversity requirement).

What do you think?   Is this an issue that you anticipate addressing in the text for section 7.1 (alluded to as being for future study)?


Ben Wright and Steve Balls