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

Arturo Servin <arturo.servin@gmail.com> Tue, 30 July 2013 09:22 UTC

Return-Path: <arturo.servin@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 D086821E8091 for <v6ops@ietfa.amsl.com>; Tue, 30 Jul 2013 02:22:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 GYHnjQorf2-6 for <v6ops@ietfa.amsl.com>; Tue, 30 Jul 2013 02:21:59 -0700 (PDT)
Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0960121F9AD2 for <v6ops@ietf.org>; Tue, 30 Jul 2013 02:18:40 -0700 (PDT)
Received: by mail-ve0-f172.google.com with SMTP id oz10so3751344veb.31 for <v6ops@ietf.org>; Tue, 30 Jul 2013 02:18:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lSU2KbPIgfGKtXT9/uqxYdqYoJVLWvcJowwu8BLKLPc=; b=pjDFNB2dlEfiUK9rROQP+9l0ob0LJ/mjDh6hG7sD5Dse9HmwovRlA/H+cRVxHrIwiP wdbnkiWX9Ig5gT+ClvvHvWHs6rPf2Ixcbkoge18XF7lXUKgrAumOCelTwRI+0ntbF6xt Dwn/K4Pq+UWjpOg91GE+LbVg/uiHwu2KFqYMSx16TkQ+yQc1ZR9O5K5wCLUzOCoa9CsO 6PKKt83bhOEBsR6pf2Q5ABsoznoH9G00+0r1BoCz7L5al1Pawv5k3wlsqsUYbxRadBMn N8enndKa4eBQR29weP8evEQECGJMPl/uP3Pa0ayzBys4m5FpLjKOCsdl//K7zY1pLtgX xZEA==
X-Received: by 10.220.104.74 with SMTP id n10mr9767039vco.74.1375175920409; Tue, 30 Jul 2013 02:18:40 -0700 (PDT)
Received: from Arturos-MacBook-Pro.local ([2001:df8:0:16:55a5:2b76:65f9:9f6a]) by mx.google.com with ESMTPSA id wf4sm29665095vdb.12.2013.07.30.02.18.38 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Jul 2013 02:18:39 -0700 (PDT)
Message-ID: <51F784F2.1090904@gmail.com>
Date: Tue, 30 Jul 2013 11:18:42 +0200
From: Arturo Servin <arturo.servin@gmail.com>
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: John Mann <john.mann@monash.edu>
References: <201307131245.r6DCj0d01032@ftpeng-update.cisco.com> <51E15A35.2090603@lacnic.net> <CA+OBy1OYeY-fn+ExTV3RSgx6J7=0QcxpZmkT3-xKg2w7-px05g@mail.gmail.com>
In-Reply-To: <CA+OBy1OYeY-fn+ExTV3RSgx6J7=0QcxpZmkT3-xKg2w7-px05g@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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: Tue, 30 Jul 2013 09:22:01 -0000

John,

	Thanks for your comments. We really appreciate them.

	We will add them to the next revision. Some comments in line for
clarification.

On 7/30/13 8:54 AM, John Mann wrote:
> Hi,
> 
> Some culture shift may be necessary when changing from monitoring IPv4
> to IPv4+IPv6 .
> 
> For example, "interface counters" may count all packets, not just IPv4
> packets.

Taken, thanks.

> All existing network graphs and statistics are likely to be useless for
> monitoring IPv6 (separate from IPv4).

Ok, this seems to be implicit to me. Do you want us to add some specific
advice (or perhaps I didn't properly understand your point)?

> 
> Also, just because IPv4 is working over a network path and IPv6 is
> enabled over the same path, does not prove that IPv6 is working over the
> same path.


> How about backup links - 
> It is necessary to send real IPv6 traffic over every path to test that
> it does go through.
> Pinging the GUA or ULA of every IPv6 router interfaces could be used to
> test if routing is working and ACLs permit traffic.

	OK, I think that I got your point.

	Is this practice common?

	Even if not common, if you or the WG find it useful we would add it.


> 
> Aim to test the IPv6 network the same ways as you test for IPv4 -
> management traffic, pings, application-layer tests etc.
> 
> ===
> There are also new things that you can monitor that are IPv6-specific.
> 
> For example, poll each router to see what IPv6 routers it can see.
> On point-to-point or HSRP/VRRP router interfaces, you expect to see one
> other router;
> on non-HSRP/VRRP user interfaces, you expect to see no other routers.
> Are the other routers you can see "your" routers, or are they rogues
> advertising bogus routes, like 6to4 prefixes?
> 
> You can snoop for rogue IPv6 routers even if you don't have your
> router's interface enabled to route IPv6 traffic.
> 
> Are the RA's the router received recent, or received a while ago?

	Basically the idea is to recommend to monitor RA in your network?
Something else?

	The means could be what you suggest or to use something like NDPmon, right?

> 
> If your router has OSPFv3 neighbors, are they all in state FULL? 

	Is this something that is normally done, perhaps for large ISPs or
Enterprises?

Thanks!
as