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

Arturo Servin <aservin@lacnic.net> Mon, 15 July 2013 14:57 UTC

Return-Path: <aservin@lacnic.net>
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 9C45421F9DAF for <v6ops@ietfa.amsl.com>; Mon, 15 Jul 2013 07:57:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 fS97bYNSWWbn for <v6ops@ietfa.amsl.com>; Mon, 15 Jul 2013 07:57:08 -0700 (PDT)
Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 4048821F9DB9 for <v6ops@ietf.org>; Mon, 15 Jul 2013 07:57:08 -0700 (PDT)
Received: from Arturos-MacBook-Pro.local (unknown [IPv6:2001:13c7:7001:7000:5c53:3609:f51c:ca56]) by mail.lacnic.net.uy (Postfix) with ESMTP id EF6AC308464; Mon, 15 Jul 2013 11:56:45 -0300 (UYT)
Message-ID: <51E40DC3.3040409@lacnic.net>
Date: Mon, 15 Jul 2013 11:57:07 -0300
From: Arturo Servin <aservin@lacnic.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Ariel Weher <aweher@gmail.com>
References: <201307131245.r6DCj0d01032@ftpeng-update.cisco.com> <51E15A35.2090603@lacnic.net> <E6D8B95470ED0845B3376F61DCAB1A049CD16B1A@EX10-MB2-MAD.hi.inet> <51E3E1E0.9090203@lacnic.net> <CAPYwJbJhxnqnbfZ_huAVKe7iTaxiq40U_EtLY34BKMiW7YJdcg@mail.gmail.com>
In-Reply-To: <CAPYwJbJhxnqnbfZ_huAVKe7iTaxiq40U_EtLY34BKMiW7YJdcg@mail.gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/alternative; boundary="------------070508090405070607000906"
X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information
X-LACNIC.uy-MailScanner: Found to be clean
X-LACNIC.uy-MailScanner-SpamCheck:
X-LACNIC.uy-MailScanner-From: aservin@lacnic.net
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:57:09 -0000

Ariel

    Noted.

    I will add and correct.

    Thanks for the suggestions.

Best regards,
as

On 7/15/13 11:20 AM, Ariel Weher wrote:
> 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
> <mailto: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 <mailto:v6ops@ietf.org>
>     https://www.ietf.org/mailman/listinfo/v6ops
>
>