Re: [CCAMP] OVRLY - signaling extensions

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 19 March 2014 22:33 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBCF1A0444 for <ccamp@ietfa.amsl.com>; Wed, 19 Mar 2014 15:33:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.483
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UV8SU8q09XV1 for <ccamp@ietfa.amsl.com>; Wed, 19 Mar 2014 15:33:50 -0700 (PDT)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 92F051A0319 for <ccamp@ietf.org>; Wed, 19 Mar 2014 15:33:50 -0700 (PDT)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s2JMXZHe032370; Wed, 19 Mar 2014 22:33:35 GMT
Received: from 950129200 (15.21.90.92.rev.sfr.net [92.90.21.15]) (authenticated bits=0) by asmtp2.iomartmail.com (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" <adrian@olddog.co.uk>
To: "=?utf-8?Q?'Pawe=C5=82_Brzozowski'?=" <PBrzozowski@advaoptical.com>, "'Zhangxian \(Xian\)'" <zhang.xian@huawei.com>, "'Gert Grammel'" <ggrammel@juniper.net>
References: <650AA355E323C34D9D4AAEED952E053D3FC6BBEA@SV-EXDB-PROD2.infinera.com> <F82A4B6D50F9464B8EBA55651F541CF85CAD5E4C@SZXEMA504-MBS.china.huawei.com> <650AA355E323C34D9D4AAEED952E053D3FC6D4AE@SV-EXDB-PROD2.infinera.com> <132301cf3bd5$cf0a8640$6d1f92c0$@olddog.co.uk> <8f71d3e2fb1f47e7858721caf9f894a7@MUC-SRV-MBX1.advaoptical.com> <16a401cf3ca2$00152cf0$003f86d0$@olddog.co.uk> <7d1ddc68ad6b4e2d9c5acf3dc2ea1e39@MUC-SRV-MBX1.advaoptical.com> <CA+YzgTty-DyVZeAAHg-HJ=zNXSgUhn-kNx3SMOP5fj4JGrbSpQ@mail.gmail.com> <C636AF2FA540124E9B9ACB5A6BECCE6B30212CC6@SZXEMA512-MBS.china.huawei.com> <c3f259e79eab4cee83a5937ade2f6c4d@MUC-SRV-MBX1.advaoptical.com> <4d4817c349bc4969b2f6a8451b31017b@BN1PR05MB041.namprd05.prod.outlook.com> <13c577bed9ee44d3a13e8096c177a9f5@MUC-SRV-MBX1.advaoptical.com> <C636AF2FA540124E9B9ACB5A6BECCE6B30213C7A@SZXEMA512-MBS.china.huawei.com> <73f39a063bbe4dd98db3075cf21b9198@MUC-SRV-MBX1.advaoptical.com>
In-Reply-To: <73f39a063bbe4dd98db3075cf21b9198@MUC-SRV-MBX1.advaoptical.com>
Date: Wed, 19 Mar 2014 22:33:34 -0000
Message-ID: <030901cf43c3$448081f0$cd8185d0$@olddog.co.uk>
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-7.1.0.1576-7.5.0.1017-20576.002
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
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/exxU6P_-CtDEM9qagEFga-kiFCo
Cc: 'CCAMP' <ccamp@ietf.org>
Subject: Re: [CCAMP] OVRLY - signaling extensions
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
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: 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.

Adrian