Re: [CCAMP] OVRLY - signaling extensions

Igor Bryskin <IBryskin@advaoptical.com> Thu, 20 March 2014 14:37 UTC

Return-Path: <IBryskin@advaoptical.com>
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 7BD121A076C for <ccamp@ietfa.amsl.com>; Thu, 20 Mar 2014 07:37:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.147
X-Spam-Level:
X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547] autolearn=ham
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 15VR5X5PkR1E for <ccamp@ietfa.amsl.com>; Thu, 20 Mar 2014 07:36:59 -0700 (PDT)
Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) by ietfa.amsl.com (Postfix) with ESMTP id B40041A08D4 for <ccamp@ietf.org>; Thu, 20 Mar 2014 07:36:55 -0700 (PDT)
Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id s2KEabXE019753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Mar 2014 10:36:37 -0400
Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%16]) with mapi id 14.03.0174.001; Thu, 20 Mar 2014 10:36:37 -0400
From: Igor Bryskin <IBryskin@advaoptical.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, Paweł Brzozowski <PBrzozowski@advaoptical.com>, "'Zhangxian (Xian)'" <zhang.xian@huawei.com>, 'Gert Grammel' <ggrammel@juniper.net>
Thread-Topic: [CCAMP] OVRLY - signaling extensions
Thread-Index: Ac85YJDrYXZOuOMaR1Gk+fcsuXhJCgBBUEbQAA/KqYAAVJX/AAAJzQ4AACk+9wAAIMvNnwCJLFaAAKjszwAAAtUXAAAATJcAAFoZggAAD8AbgAAIcR4AABh/U6A=
Date: Thu, 20 Mar 2014 14:36:36 +0000
Message-ID: <CDAC6F6F5401B245A2C68D0CF8AFDF0A403E93E4@atl-srv-mail10.atl.advaoptical.com>
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> <030901cf43c3$448081f0$cd8185d0$@olddog.co.uk>
In-Reply-To: <030901cf43c3$448081f0$cd8185d0$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.222.2.70]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-20_04:2014-03-20, 2014-03-20, 1970-01-01 signatures=0
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/S61FLGgKwzEFyQUzOcsQd9cS3G8
Cc: 'CCAMP' <ccamp@ietf.org>
Subject: Re: [CCAMP] OVRLY - signaling extensions
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Mar 2014 14:37:04 -0000

Hi Adrian,

I largely agree with what you said except for this:
" 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"

Using your own definition of service the client (albeit using RSVP-TE) actually requests a connectivity rather than LSP. For example, it is possible that that the network has nothing to do with GMPLS except for supporting UNI - the connectivity across the network domain is managed by an SDN controller and achieved in a form of an arbitrary mixture of individual cross-connects, stitched connection segments, etc.
Whether it is UNI, ENNI, Netconf, etc. the client actually requires a connectivity of some sort across the network with certain set of properties: resilience to network failures, optical signal quality, delay characteristics, etc.

Cheers,
Igor

-----Original Message-----
From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Wednesday, March 19, 2014 6:34 PM
To: Paweł Brzozowski; 'Zhangxian (Xian)'; 'Gert Grammel'
Cc: 'CCAMP'
Subject: Re: [CCAMP] OVRLY - signaling extensions

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

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp