Re: [CCAMP] OVRLY - signaling extensions

"Adrian Farrel" <> Wed, 12 March 2014 22:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1DFE21A07A9 for <>; Wed, 12 Mar 2014 15:56:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -100.253
X-Spam-Status: No, score=-100.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WdcUBgAcAbgs for <>; Wed, 12 Mar 2014 15:56:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2490E1A07AD for <>; Wed, 12 Mar 2014 15:56:06 -0700 (PDT)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id s2CMtwGo022204; Wed, 12 Mar 2014 22:55:58 GMT
Received: from 950129200 ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id s2CMtg0K022162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Mar 2014 22:55:56 GMT
From: "Adrian Farrel" <>
To: "'John E Drake'" <>, "'Igor Bryskin'" <>, "'Gert Grammel'" <>, "'Vishnu Pavan Beeram'" <>, "=?UTF-8?Q?'Pawe=C5=82_Brzozowski'?=" <>
References: <> <> <> <132301cf3bd5$cf0a8640$6d1f92c0$> <> <16a401cf3ca2$00152cf0$003f86d0$> <>, <> <>, <> <>, <> <> <>
In-Reply-To: <>
Date: Wed, 12 Mar 2014 22:55:41 -0000
Message-ID: <1d8f01cf3e46$3b55df30$b2019d90$>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKw9VnQoF4V3YxjmEICO2ejjnzt1AEhTKUlAglrOgUB0bWIvQCZY09HAj9NAYsCGWUQCgHzSdUhAepqiqACEVvDRgJSefwnAZDJ2tMCy6Oy0gFmQnb5mFsJQfA=
Content-language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--12.882-8.0-31-10
X-imss-scan-details: No--12.882-8.0-31-10
X-TMASE-MatchedRID: O4MXc7QxKnFDZFBd1jLr/qfXIl6Cf6VrFJFr2qlKix+VIU9/CM32keHw oKIjQi1uSkapL89WOamG8tCUP4olEzQYriqcplwNiwo1o2HzwJBTes6dDCWUQ4fAYSb4KlgZxLg b7Z5yc7EcsXeHntqoegs60ZhuyYev+OpCNxgj1X5CnGIuUMP0VZk5wDFwka0zauHKE5Laxl/vH2 neBQK1q5QSFib+kOaacgRuMUq2K0gHi42AsEQjAlPjo7D4SFg4hsTH7uxpJveTMTaQzhvoeuJG1 LfRUmRXBIrttSBaeS5ahCXD7tGnneVHGbcDbAq6gxsfzkNRlfLdB/CxWTRRu25FeHtsUoHuLSrZ 4sFIjq/VXBkfJuXn1MmKT3a80jq7cjjeii1DizrrpcchznD6Bw==
Cc: 'CCAMP' <>
Subject: Re: [CCAMP] OVRLY - signaling extensions
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Mar 2014 22:56:09 -0000

Backing off a bit, and catching something Dieter said.

I have a bit of a grump about the UNI being seen as a "service request interface." In my book it is a "connection request interface" and I see that as fundamentally different.

The range of I-Ds we are seeing that "enhance" the UNI are understandable (there is deployed code that needs to be made to do things) but are all rooted in the fact that the UNI was never intended to do the things that folk want to do with it. We can see this if we go way back to the original dual-homed destination UNI-C problem that surfaced in OIF work.

The solution in my world view is to recognise that the service request is somewhere else and gives rise to a number of connections that can be requested at the UNI. I think this model addresses even Dieter's dual-ingress problem.

Now, once upon a time back when 3475 was still a twinkle in Lou's now-cloudy-and-red eye, there was a bit of a discussion about whether GMPLS was used to request a service or set up an LSP. The conclusion I recall then was that it set up LSPs, and I don't think anything really changed. Of course, this does not mean that the service request interface could not be realised using RSVP-TE, just that up-to-now there has been no such interface. My belief is that we are stretching reality to make that interface the UNI, and while I completely understand the drive to keep modifying and shipping, I would also like to have an architectural view that is a little less prone to "continual enhancement".