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

"Weisgrab, Hannes [Lists]" <weisi2@FTW.at> Tue, 28 June 2011 21:49 UTC

Return-Path: <weisi2@FTW.at>
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 D374811E816C for <opsawg@ietfa.amsl.com>; Tue, 28 Jun 2011 14:49:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.637
X-Spam-Level:
X-Spam-Status: No, score=0.637 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_NUMERIC_HELO=2.067]
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 jn2XU-xdctps for <opsawg@ietfa.amsl.com>; Tue, 28 Jun 2011 14:49:49 -0700 (PDT)
Received: from mail.ftw.at (mail.ftw.at [213.235.244.131]) by ietfa.amsl.com (Postfix) with ESMTP id BA07611E8143 for <opsawg@ietf.org>; Tue, 28 Jun 2011 14:49:48 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: from 86.59.24.216 ([86.59.24.216]) by blackhole.ftw.local ([192.168.0.250]) with Microsoft Exchange Server HTTP-DAV ; Tue, 28 Jun 2011 21:49:47 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11
Content-class: urn:content-classes:message
Date: Tue, 28 Jun 2011 23:49:34 +0200
Message-ID: <C722CE901289D346829ED0E2AEB09D0102973945@blackhole.ftw.local>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: comments on draft-georgiades-opsawg-intercar-oam-req-00
Thread-Index: Acw13UxWpjyl52VTQgmffa6FHpeTQA==
From: "Weisgrab, Hannes [Lists]" <weisi2@FTW.at>
To: opsawg@ietf.org
Subject: [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: Tue, 28 Jun 2011 21:49:49 -0000

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, ...