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

From: <[email-masked]>
Date: Sat, 13 Jul 2013 05:45:00 -0700 (PDT)

A new draft has been posted, at http://tools.ietf.org/html/draft-servin-v6ops-monitor-ds-ipv6. Please take a look at it and comment.

---

From: Arturo Servin <[email-masked]>
Date: Sat, 13 Jul 2013 10:46:29 -0300

Hi,

    We have sent this draft about considerations and recommendations to
monitor IPv6 and dual-stack networks and services. We have been talking
with people deploying IPv6 and we have found that not all monitor their
networks and not many monitor them properly. We also found some
challenges in monitor implementations that not fully support IPv6
monitoring technologies (snmp, netflow, ipfix, ipv6 transport). Even
though monitoring v6 networks is as critical as doing it in v4, we have
not found many documents explaining how that has to be done (at least
guides with free access or up to date).

    There are also some misconceptions about monitoring IPv6, for
example SNMPv3 != SNMP+IPv6, or that you cannot collect IPv6 data and
send them on IPv4 that we wanted to clarify.

     We collected some recommendations from informal conversations with
people during some training and NOGs meeting during this year but we
need some more input. We will be sharing this draft with other forums to
get more inputs but we wanted to share it here first.

Best wishes,
Arturo and Mariela

On 7/13/13 9:45 AM, [email-masked] wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Alejandro Acosta <[email-masked]>
Date: Mon, 15 Jul 2013 06:14:49 +0200

Hi Arturo,
  Great to see there is some working on this.
  Just two comments, not big changes:
  Both in the introduction section:

1)
"A good monitor solution allows to:"

I think it should be changed for something like this:

"A good monitor solution -among other things- allows to":

2)
:

Change "Determinate which actions may solve a problem"
by
"Determine which actions may solve a problem"

Best regards,

Alejandro,

On 7/13/13, Arturo Servin <[email-masked]> wrote:
>> A new draft has been posted, at
>> http://tools.ietf.org/html/draft-servin-v6ops-monitor-ds-ipv6. Please take
>> a look at it and comment.

-- 
=====
^A.......o$

---

From: "Diego R. Lopez" <[email-masked]>
Date: Mon, 15 Jul 2013 09:46:53 +0000

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

2) The implications of the usage of local addresses and privacy-protection address allocation techniques

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

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Arturo Servin <[email-masked]>
Date: Mon, 15 Jul 2013 08:44:19 -0300

Thanks Alejandro for the comments.

    I have made the edits and I will pushing a revision today with some
other recommendations that we have received off-list.

Best regards,
as

---

From: Arturo Servin <[email-masked]>
Date: Mon, 15 Jul 2013 08:49:52 -0300

Diego,

    Thanks for the comments.

    I will try to incorporate some changes before the deadline. Some
questions in line.
   
> 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

---

From: Ariel Weher <[email-masked]>
Date: Mon, 15 Jul 2013 11:20:22 -0300

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 <[email-masked]> wrote:

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

---

From: Arturo Servin <[email-masked]>
Date: Mon, 15 Jul 2013 11:57:07 -0300

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.
> 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 <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Diego,
>
>         Thanks for the comments.
>
>     > 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.
>     >
>     monitoring, that I'd say is not that close even in v4 space, and
>     that probably would deserve some discussion as well...
>
>     [email-masked] <mailto:[email-masked]>

---

From: "Diego R. Lopez" <[email-masked]>
Date: Tue, 16 Jul 2013 00:07:36 +0000

Hi Arturo,

> reference, perhaps some previous work about this topic?

A couple of them I have used elsewhere:
https://www.usenix.org/legacy/event/inmwren10/tech/full_papers/Ballard.pdf

http://sharkfest.wireshark.org/sharkfest.12/presentations/A-4_Leveraging_Openflow_to_create_a_Large_Scale_and_Cost_Effective_Packet_Capture_Network.pdf

I can send you some information on our Deeper system, that leverages OpenFlow for a cloud-based DPI...

> do it, but if you have some pointers or references would be very great

The references I have are related to the outcomes of the ETICS project, in which I have participated. A short intro to the monitoring issues can be found here: https://bscw.ict-etics.eu/pub/bscw.cgi/d44518/IndustrialWorkshop_Demo-NMON.pdf

And a more detailed info can be found at https://bscw.ict-etics.eu/pub/bscw.cgi/d47594/D4.4_Final.pdf (pages 90 to 101, essentially)

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: "George, Wes" <[email-masked]>
Date: Wed, 17 Jul 2013 14:39:03 -0400

This is a useful draft.

I've been doing some IPv6-only testing of websites listed in the world v6 launch participants, and found a lot of supposedly IPv6-capable sites that aren't fully functional over IPv6-only because some portion of them are still reliant on IPv4-only content/CDNs for images, CSS, subdomains, etc. Worse, I've found sites that simply aren't working over IPv6 anymore, and the operator of the site is unaware. This would be quite obvious if the site maintainers were completing their unit testing and monitoring over single-stack IPv6, but may well be masked by happy eyeballs if done dual-stack, so this draft will help to publicize this problem.

A few comments on the draft itself:

Section 2.1 and 6- an explicit recommendation to vendors that they SHOULD support use of IPv6 for all transport (RFC 6540) of monitoring, provisioning, and management data might be useful here. This is an area where vendors often lag because they've been focused on enabling support for IPv6 through the box, but it's becoming increasingly important for operators trying to conserve IPv4 addresses for end-customer use.

For completeness, you may want to briefly discuss NTP, Syslog, ssh, and other OAM-type traffic somewhere in section 2.

There is also a draft in progress in MPLS dealing with IPv6-only operation of MPLS networks (draft-george-mpls-ipv6-only-gap) that may contain some things relevant to this draft since it covers some of the aspects of OAM for MPLS networks.

Another consideration for this draft might be a recommendation to transition to single-stack (IPv6) as rapidly as possible for any tools that do not need to explicitly verify IPv4 operation. In other words, things like flow data transport, SSH, etc might be able to operate only over IPv6, while SNMP polls, HTTP tests, etc would need to remain dual stack so that they can verify IPv4 is working properly. Since dual-stack support means duplicating a lot of operations complexity (filters, troubleshooting path problems, monitoring configuration, etc), eliminating the need to support both IPv4 and IPv6 for as much management traffic as possible potentially allows for simplification of configuration, reclamation of addresses, etc.

Thanks,

Wes George

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Arturo Servin
> Sent: Saturday, July 13, 2013 9:46 AM
> To: [email-masked]
> Subject: Re: [v6ops] new draft: draft-servin-v6ops-monitor-ds-ipv6
>
> Hi,
>
> > A new draft has been posted, at http://tools.ietf.org/html/draft-
> servin-v6ops-monitor-ds-ipv6. Please take a look at it and comment.

Anything below this line has been added by my company's mail server, I have no control over it.
-----------------

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Arturo Servin <[email-masked]>
Date: Sat, 27 Jul 2013 04:38:40 -0400

Diego,

	Thanks for the information.

	We will read it and include it in the draft.

Regards,
as

---

From: Arturo Servin <[email-masked]>
Date: Sat, 27 Jul 2013 04:40:18 -0400

Wes,

	Thank you for the review.

	We will include your comments in the next version of the draft.

Thanks
as

---

From: John Mann <[email-masked]>
Date: Tue, 30 Jul 2013 16:54:54 +1000

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.
All existing network graphs and statistics are likely to be useless for
monitoring IPv6 (separate from IPv4).

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.

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?

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

Thanks,
    John

On 13 July 2013 23:46, Arturo Servin <[email-masked]> wrote:

> http://tools.ietf.org/html/draft-servin-v6ops-monitor-ds-ipv6. Please
> take a look at it and comment.

---

From: Arturo Servin <[email-masked]>
Date: Tue, 30 Jul 2013 11:18:42 +0200

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

Taken, thanks.

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

	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.

> You can snoop for rogue IPv6 routers even if you don't have your
> router's interface enabled to route IPv6 traffic.
> 

	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