Re: [CCAMP] OVRLY - signaling extensions

"Adrian Farrel" <> Wed, 19 March 2014 22:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AFBCF1A0444 for <>; Wed, 19 Mar 2014 15:33:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -99.483
X-Spam-Status: No, score=-99.483 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, RCVD_IN_SORBS_WEB=0.77, USER_IN_WHITELIST=-100] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UV8SU8q09XV1 for <>; Wed, 19 Mar 2014 15:33:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 92F051A0319 for <>; Wed, 19 Mar 2014 15:33:50 -0700 (PDT)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id s2JMXZHe032370; Wed, 19 Mar 2014 22:33:35 GMT
Received: from 950129200 ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id s2JMXXdB032358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Mar 2014 22:33:34 GMT
From: "Adrian Farrel" <>
To: "=?utf-8?Q?'Pawe=C5=82_Brzozowski'?=" <>, "'Zhangxian \(Xian\)'" <>, "'Gert Grammel'" <>
References: <> <> <> <132301cf3bd5$cf0a8640$6d1f92c0$> <> <16a401cf3ca2$00152cf0$003f86d0$> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Date: Wed, 19 Mar 2014 22:33:34 -0000
Message-ID: <030901cf43c3$448081f0$cd8185d0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKw9VnQoF4V3YxjmEICO2ejjnzt1AEhTKUlAglrOgUB0bWIvQCZY09HAj9NAYsCGWUQCgHzSdUhApWswUwC2NhpPwGEvn5XAQy2vgwBlIDClQJha+NvmGbV+yA=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--17.814-10.0-31-10
X-imss-scan-details: No--17.814-10.0-31-10
X-TMASE-MatchedRID: C/snMIRQLS04HKI/yaqRmwDPuhU4P53KI5K4Cd+0ao9+cnZjTDV6gwWd mgeRGy0yIwuO97ZnkxnX6HMmO9YwlPHacMrT9DrcbvssW25GCBa6QCTCuzfiVf5Ndkm9jGh50Si YkslPgq73N18Nvx2T5UQCTHaXiIjpL0W1btd8e54OrlBkQa9qFkMYW8F4Hadc+Cckfm+bb6AsNa UkYQ2H0a4Jhlx7vdJeFcP1yKpmWPf+BikoAvJRQSlrosmS0SOA0X0X5dpeBd7agsZM0qVv1xuCq m239cCoZW5WXoFxG7ZwjOy9PqV09KwUHwBRC6FfO8dpCBNpmLUUkWvaqUqLH7HjjZhCJenCKEk0 2YQnxK6JzymcOF3UR7XrthZZJbug1OGXhAFLw8tT46Ow+EhYOA/80a3o2lzSs/uo6bL1AFQtUJB 9LGI9xvWYc2FM436tcOOBryZ2cTlsBh6o4Ba1xAArNgt5xpQYNACnndLvXweyINijCt+LdaPFjJ EFr+olSXhbxZVQ5H+OhzOa6g8KrZRMZUCEHkRt
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, 19 Mar 2014 22:33:52 -0000

H Pawel,

> On the side note, I believe that e-mail exchange on the
> group does not push us in any direction. It really does
> seem people are sending e-mails just for the sake of 
> conversation. 

Please don't take that tone (unless, maybe, you were referring to yourself :-).

I have found the exchanges useful. They have caused me to go back and look at I-Ds that people have referenced (and to realise they said things I didn't recall that they said). 

More importantly, they caused me to understand better the line between fixing stuff to work with what we have, and dreaming up new extensions for a potential use in the future.

> If you are interested in discussing the points I’ve raised, I’ll be happy
> to have a conference call with you. If not, no problem than, let’s just
> forego this topic.

It's OK if you want to drop out of the discussion, and it's OK for you to talk to whoever you please, but please don't suggest that I should not talk about this topic on this list.

Anyway, your revised email says:

> I believe everybody agrees that there is a need in signaling for
> indication that “this service should be diverse from services/
> paths A-Z”, since it is a generic extension.

But there we go, I have to dash your belief.
The problem is that you are talking about "services". 
A "service" is "connectivity" not "a connection".
You don't talk about a service having diversity, you talk about it having resilience. The resilience is achieved by mapping the service request to a number of underlying connections and to making those connections observe a number of diversity and protection group relationships.

I don't know whether your use of "service" was accidental and you meant "LSP" or whether it indicates a more fundamental issue.

I think that for a transport equipment provider (I was one) there is a tendency to think of addressing a request of an LSP as providing a service. But it isn't except in the most simple case of a service.

This is the thing I have been banging on about for a while. The UNI is not a service request interface it is an LSP signaling interface. 

> I agree with Adrian, from architectural perspective, there needs to
> be a line beyond which putting steroids into a protocol becomes a 
> mess. E.g. I hope there will be no attempts to overcome multi-homed
> clients’ deficiencies via extensions to signaling.

Nice to be agreed with once in a while.
But, of course, we have a number of I-Ds kicking about that are trying to do exactly this. It isn't clear to me that the line is being drawn and features are creeping.