Re: [OPSAWG] comments on draft-georgiades-opsawg-intercar-oam-req-00

Michael Georgiades <michaelg@prime-tel.com> Mon, 11 July 2011 12:56 UTC

Return-Path: <michaelg@prime-tel.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE27721F8B51 for <opsawg@ietfa.amsl.com>; Mon, 11 Jul 2011 05:56:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Hm5knjUoEU5 for <opsawg@ietfa.amsl.com>; Mon, 11 Jul 2011 05:56:41 -0700 (PDT)
Received: from cezanne.office-net.spidernet.net (cezanne.office-net.spidernet.net [194.154.133.233]) by ietfa.amsl.com (Postfix) with ESMTP id 450A121F89E9 for <opsawg@ietf.org>; Mon, 11 Jul 2011 05:56:38 -0700 (PDT)
Received: from [10.5.10.157] (10.5.10.157) by cezanne.office-net.spidernet.net (194.154.133.233) with Microsoft SMTP Server id 8.2.255.0; Mon, 11 Jul 2011 15:56:37 +0300
Message-ID: <4E1AF3A1.5060305@prime-tel.com>
Date: Mon, 11 Jul 2011 15:59:13 +0300
From: Michael Georgiades <michaelg@prime-tel.com>
Organization: Primetel
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc13 Thunderbird/3.1.7
MIME-Version: 1.0
To: "Berechya, David (NSN - IL/Hod HaSharon)" <david.berechya@nsn.com>
References: <C722CE901289D346829ED0E2AEB09D0102973945@blackhole.ftw.local> <09E7BC852F58D54A9F315D504296B8C10474895C@DEMUEXC006.nsn-intra.net>
In-Reply-To: <09E7BC852F58D54A9F315D504296B8C10474895C@DEMUEXC006.nsn-intra.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Cc: "opsawg@ietf.org" <opsawg@ietf.org>
Subject: Re: [OPSAWG] comments on draft-georgiades-opsawg-intercar-oam-req-00
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsawg>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jul 2011 12:56:42 -0000

Dear Hannes,

The points you are raising are of interest, however they are more
related on how to monitor performance degradation for the different
transport technologies offered by a single carrier as opposed to
inter-carrier requirements which we have tried to differentiate. The
mentioned issues should also be considered when dealing with
inter-operability issues between carriers using different transport
technologies. However we avoided inter-operability or technology
oriented requirements for this draft as this should be addressed by the
SLA agreement between the carriers.

Maybe though we can add a requirement that the Maintenance Entity at
each carrier should make inter-carrier service OAM independent of
transport technologies. David?

Cheers,

Michael

On 07/04/2011 04:38 PM, Berechya, David (NSN - IL/Hod HaSharon) wrote:
>   Dear Hannes,
>
> Regarding service aspects in OAM: there are OAM in the service level
> that monitors the service end-to-end, and OAM in the network level that
> monitors the paths that carry many services.
>
> Regarding the scope of the draft: the draft focuses in the special
> requirements that the multi carrier scenario raises, e.g.  Reliable
> means to the network service providers to prove, in case of failure,
> which is the failing transit segment.
>
> Best Regards,
> David Berechya
>
> -----Original Message-----
> From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf
> Of ext Weisgrab, Hannes [Lists]
> Sent: Wednesday, June 29, 2011 12:50 AM
> To: opsawg@ietf.org
> Subject: [OPSAWG] comments on
> draft-georgiades-opsawg-intercar-oam-req-00
>
>
> Dear list members,
>
> as this is the first time I post to this list I'd like to briefly
> introduce myself.
> I'm researcher at the Telecommunications Research Center Vienna (FTW;
> http://www.ftw.at) and I'm involved in the EU FP7 project ETICS
> (http://www.ict-etics.eu/). In this project we investigate - among other
> things - how QoS can be enabled across domains utilizing different
> transport technologies (above all: connection oriented AND connection
> less technologies). In this respect we also deal with network monitoring
> and SLA assurance (the latter of which is the final goal).
>
> My core concern is that I think it could be beneficial if an
> inter-carrier OAM system would be aware of the (network transport)
> services and the way how they are transported at a given interconnection
> point. I further assume that such an interconnection point (link) would
> also make a perfect monitoring point.
> But how to identify the various (network transport) services and the way
> they are transported via this point?
>
> Let me explain this in more detail:
> If two or more providers want to offer a QoS-enabled (network transport)
> service they also need to agree on a mechanism to transport this service
> through their networks. There are various mechanisms which could be used
> like utilizing the DSCP field of the IP-header (*) or using tunneling
> (e.g. IP-in-IP [RFC2003], GRE [RFC2784], or even other mechanisms, which
> are proprietary or not yet standardized).
> However, if such mechanisms are applied between domains, this
> information needs to be transferred also to the monitoring device, which
> could be external to the router (which would be beneficial both in terms
> of trust and router (CPU) utilization).
> Without information about the transported services and the exact way
> they are transported, the monitoring capability would be reduced to
> simple link monitoring, which would be of much less benefit for the
> operator.
>
> I'm not so familiar with the OAM topic and if there are already
> discussions in this direction, so I was wondering, if this topic has
> already been addressed or if this could possibly be another requirement?
>
> Looking forward to your comments, br,
> Hannes Weisgrab.
>
>
> (*) various RFCs are related to this, like:
> RFC791 ;-)  , RFC2474, RFC2983 ,RFC4594, ...
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg


--
Dr Michael Georgiades
The Maritime Center
PrimeTel PLC - www.prime-tel.com
Omonia Avenue 141, 3045 Limassol, Cyprus
Tel: +357 2586 7212  Fax: +357 2210 2211
michaelg@prime-tel.com


CONFIDENTIALITY NOTICE AND DISCLAIMER
This message contains information, which may be confidential and privileged. Unless you are the intended recipient (or authorized to receive this message for the intended recipient), you may not use, copy, disseminate or disclose to anyone the message or any information contained in the message. If you have received the message in error, please advise the sender by reply e-mail, and delete the message.
PrimeTel Plc