Subject: Router Alert based Monitoring

From: "Alan Davy" <[email-masked]>
Date: Fri, 26 Feb 2010 16:19:04 -0000 (GMT)

Hi All,

Previously we circulated a proposal [Nov 4th 09] about defining a new IPv6
Hop by Hop extension header whereby performance metrics can be collected
per node along a path. Based on feedback received from the list the
recommendation was to consider utilising Router Alert as per RFC2113.

After researching this mechanism we propose to define a protocol using
Router Alert where a network operator can request a sequence of managed
objects to be collected at each node along a specific path within an
administrative domain augmenting existing protocols and practices so that
the managed objects can be quickly associated to a specific path for
further diagnosis without the need for mining large volumes of data using
DPI, IPFIX, active or passive probes etc. This could be in response to an
alarm, customer initiated trouble ticket or periodic service assurance for
premium services/customers. This mechanism would not be used to calculate
the latency on a path so fast processing is not requirement. One sample
scenario of use would be to gather a report of the current queue lengths
at each interface that the packet traverses on the path.

We would like to keep this as customizable as possible, so we are
considering a solution whereby an operator can specify the managed objects
by means of an Object Identifier (so any supported MIBs data could be
collected). Each node would report both the OID instance and its value as
the packet traverses the path. The operator can then use this information
to
perform more targeted diagnostics as required.

The main technical challenge we forsee is the feasibility of determining the
OID instances and their value at each hop.

We would like to know if such a monitoring protocol would be viewed as
desirable and technically a reasonable approach.

Best Regards,

Alan Davy

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 26 Feb 2010 11:53:20 -0500

router alert, and all things that depend/need it should die a horrible
death. Stealing resources from my network devices is not a nice thing
to do, ever.

On Fri, Feb 26, 2010 at 11:19 AM, Alan Davy <[email-masked]> wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 26 Feb 2010 09:00:18 -0800

Hi Alan,

Based on working on protocols that use Router Alert (RSVP) esepcially for
IPv6 I have to say that Router Alert is not the best way forward.

It has not been properly implemented in most OS network stacks. It also
causes security issues. Infact there was a proposal recently to reccomend
that Router Alert is not used in any new protocol, besides ones that already
do.

Thanks,
Vishwas

---

From: Jason Schiller <[email-masked]>
Date: Fri, 26 Feb 2010 17:53:17 +0000 (UTC)

Alan,

I agree with Chris and Vishwas.  Using router alert or other IP options 
create a DoS vector towards the network elements I operate.  If this was 
implemented I would certainly filter things outside my  network from using 
this monitoring.  

Internally, if we did use it, we would be very careful about restricting 
the number of addresses that could send such traffic, and limiting the 
amount of traffic they would generate.  

__Jason  

==========================================================================
Jason Schiller                                               (703)886.6648
Senior Internet Network Engineer                         fax:(703)886.0512
Public IP Global Network Engineering                       [email-masked]
UUNET / Verizon                         [email-masked]

The good news about having an email address that is twice as long is that
it increases traffic on the Internet.

On Fri, 26 Feb 2010, Vishwas Manral wrote:

|Date: Fri, 26 Feb 2010 09:00:18 -0800
|From: Vishwas Manral <[email-masked]>
|To: [email-masked]
|Cc: [email-masked]
|Subject: Re: Router Alert based Monitoring
|
|Hi Alan,
|
|Based on working on protocols that use Router Alert (RSVP) esepcially for
|IPv6 I have to say that Router Alert is not the best way forward.
|
|It has not been properly implemented in most OS network stacks. It also
|causes security issues. Infact there was a proposal recently to reccomend
|that Router Alert is not used in any new protocol, besides ones that already
|do.
|
|Thanks,
|Vishwas
|On Fri, Feb 26, 2010 at 8:19 AM, Alan Davy <[email-masked]> wrote:
|
|> Hi All,
|>
|> Previously we circulated a proposal [Nov 4th 09] about defining a new IPv6
|> Hop by Hop extension header whereby performance metrics can be collected
|> per node along a path. Based on feedback received from the list the
|> recommendation was to consider utilising Router Alert as per RFC2113.
|>
|> After researching this mechanism we propose to define a protocol using
|> Router Alert where a network operator can request a sequence of managed
|> objects to be collected at each node along a specific path within an
|> administrative domain augmenting existing protocols and practices so that
|> the managed objects can be quickly associated to a specific path for
|> further diagnosis without the need for mining large volumes of data using
|> DPI, IPFIX, active or passive probes etc. This could be in response to an
|> alarm, customer initiated trouble ticket or periodic service assurance for
|> premium services/customers. This mechanism would not be used to calculate
|> the latency on a path so fast processing is not requirement. One sample
|> scenario of use would be to gather a report of the current queue lengths
|> at each interface that the packet traverses on the path.
|>
|> We would like to keep this as customizable as possible, so we are
|> considering a solution whereby an operator can specify the managed objects
|> by means of an Object Identifier (so any supported MIBs data could be
|> collected). Each node would report both the OID instance and its value as
|> the packet traverses the path. The operator can then use this information
|> to
|> perform more targeted diagnostics as required.
|>
|> The main technical challenge we forsee is the feasibility of determining
|> the
|> OID instances and their value at each hop.
|>
|> We would like to know if such a monitoring protocol would be viewed as
|> desirable and technically a reasonable approach.
|>
|> Best Regards,
|>
|> Alan Davy
|>
|> --------------------------------------------------------------------
|> IETF IPv6 working group mailing list
|> [email-masked]
|> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
|> --------------------------------------------------------------------
|>
|

---

From: "Frank Bulk" <[email-masked]>
Date: Sat, 27 Feb 2010 11:03:33 -0600

Why not implement Router Alert with a "deny all" by default and require the
router engineer to configure ACLs for its use?  Doesn't that address the
DoS/resource concern?

Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jason Schiller
Sent: Friday, February 26, 2010 11:53 AM
To: Vishwas Manral
Cc: [email-masked]
Subject: Re: Router Alert based Monitoring

Alan,

__Jason  

|that Router Alert is not used in any new protocol, besides ones that
already
|> Previously we circulated a proposal [Nov 4th 09] about defining a new
IPv6
|> alarm, customer initiated trouble ticket or periodic service assurance
for
|> considering a solution whereby an operator can specify the managed
objects

---

From: Christopher Morrow <[email-masked]>
Date: Sat, 27 Feb 2010 12:32:32 -0500

> router engineer to configure ACLs for its use?  Doesn't that address the

out of curiousity, what's the use case for this monitoring thing that
SNMP doesn't already get? How can I decide which thing is using
resources on the router/switch if I have routing-protocol-churn,
interface hellos, ssh/telnet management, snmp polling, normal ip error
handling.

Why do we need to add another monitoring thing here?

Inside a single ASN there's probably less of a concern for this,
provided you can drop this at the edges that aren't your
monitoring/management systems connections, since this could very well
span many ASN's between 'remote office #1' and 'remote office #2' the
folks doing the monitoring are monitoring something 'not theirs'. This
is a very bad thing...

As I said before... 'all things that depend upon/use router alert need
to die. we should never create another protocol/dependency upon this
bit.'

-chris

---

From: "Frank Bulk" <[email-masked]>
Date: Sat, 27 Feb 2010 11:48:43 -0600

I'd rather not SNMP instrument the multiple in/out queues, status, load, etc
of each interface on each router in my network.  I'd rather have a tool that
when there is an issue, or systematically, lets me know what's going on at
each hop in the path of the traffic.  And since some paths are asymmetric
and many can change, router alert would provide a round-trip snapshot. 

Perhaps there are other ways to deal with these things.

Frank

-----Original Message-----
From: Christopher Morrow [mailto:[email-masked]] 
Sent: Saturday, February 27, 2010 11:33 AM
To: [email-masked]
Cc: Jason Schiller; Vishwas Manral; [email-masked]
Subject: Re: Router Alert based Monitoring

-chris