Re: [v6ops] new draft: draft-servin-v6ops-monitor-ds-ipv6

Ariel Weher <aweher@gmail.com> Mon, 15 July 2013 14:21 UTC

Return-Path: <aweher@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1DB311E80DC for <v6ops@ietfa.amsl.com>; Mon, 15 Jul 2013 07:21:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CWZ4fmJOlo4 for <v6ops@ietfa.amsl.com>; Mon, 15 Jul 2013 07:21:14 -0700 (PDT)
Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD4411E80D5 for <v6ops@ietf.org>; Mon, 15 Jul 2013 07:21:04 -0700 (PDT)
Received: by mail-ob0-f177.google.com with SMTP id ta17so13890935obb.8 for <v6ops@ietf.org>; Mon, 15 Jul 2013 07:21:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IGD8YB33KQu4EiXbXG+MesHzSpVXNIp3ydE9tUrJ3lY=; b=PI79tdfb+DQdbVbWmcD/ETW1cageF9wf0dXPlay/+PcVl5EjPaYvtXZ+Tqi5ICZfj6 nvnCEGmPkPDA6gNI0IOTvzwZGx4KAEnLHypapoRAUq2W5ubaqZfvy4jawgbOj/qM8llo WmulH79lucy1oKRfIKwSujqyZdZEA2nIyqqEuj9MUtf6ZBTTckf6XYSDExg58xYD/K6h 5vlXCRmBjSFDtVFbJ7M3dm0ugeYatbDJrUIN3JAGIVwA4J7uWp24SfTUuUUCdpcKWFA/ YCK2L1QCiO2V0Y45lYwfYBWh/NbyErJLzUcT6lwAMM/EG5xLcdED4NHxEceyfvocDacD MJwg==
X-Received: by 10.60.97.34 with SMTP id dx2mr43320834oeb.54.1373898062192; Mon, 15 Jul 2013 07:21:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.153.198 with HTTP; Mon, 15 Jul 2013 07:20:22 -0700 (PDT)
In-Reply-To: <51E3E1E0.9090203@lacnic.net>
References: <201307131245.r6DCj0d01032@ftpeng-update.cisco.com> <51E15A35.2090603@lacnic.net> <E6D8B95470ED0845B3376F61DCAB1A049CD16B1A@EX10-MB2-MAD.hi.inet> <51E3E1E0.9090203@lacnic.net>
From: Ariel Weher <aweher@gmail.com>
Date: Mon, 15 Jul 2013 11:20:22 -0300
Message-ID: <CAPYwJbJhxnqnbfZ_huAVKe7iTaxiq40U_EtLY34BKMiW7YJdcg@mail.gmail.com>
To: Arturo Servin <aservin@lacnic.net>
Content-Type: multipart/alternative; boundary="089e011619bef4693a04e18d911c"
Cc: "<v6ops@ietf.org>" <v6ops@ietf.org>
Subject: Re: [v6ops] new draft: draft-servin-v6ops-monitor-ds-ipv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 14:21:18 -0000

Hi all!

My review and proposals:

In the section 1 avoid the use of the word "problem", you can use incident.
Maybe  "Detect and avoid network incidents" fits better.
Same to "Determinate which actions may solve or explain an incident"

In section 2.3 you can include the ipv6 traffic metering based on
forwarding ipv4 and ipv6 traffic through separate paths, and monitoring
them as usual with octets/time counters.

Another technique may be to apply some kind of access-lists or policy-maps
which usually have MIB support.

Regards.



On Mon, Jul 15, 2013 at 8:49 AM, Arturo Servin <aservin@lacnic.net> wrote:

> Diego,
>
>     Thanks for the comments.
>
>     I will try to incorporate some changes before the deadline. Some
> questions in line.
>
> On 7/15/13 6:46 AM, Diego R. Lopez wrote:
> > Hi,
> >
> > I'd say collecting the current state-of-the-art and the operational
> practice in monitoring will be of great help, especially when it comes to
> the tricky inequalities you mention... I really hope to see a comprehensive
> collection of these detail, collected as you say from direct experiences
> across the WG and other fora.
> >
> > Regarding the current contents, I'd like to ask you to include
> considerations for at least:
> >
> > 1) The usage of SDN (OpenFlow in particular) as an alternative
> technique, probably under 2.3
>     I have never thought about it but it seems plausible. Do you have a
> reference, perhaps some previous work about this topic?
>
> >
> > 2) The implications of the usage of local addresses and
> privacy-protection address allocation techniques
>     Noted.
> >
> > And there is always the matter of cross-provider or federated
> monitoring, that I'd say is not that close even in v4 space, and that
> probably would deserve some discussion as well...
>
>     I'll ask some operators that I know have virtual services how they
> do it, but if you have some pointers or references would be very greate
> >
> > Be goode,
> >
> >
>     Thanks for the comments, as I said we will try to incorporate as
> many as possible before the deadline.
>
> Regards,
> as
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>