Subject: Re: [OPSAWG] I-D Action: draft-janapath-intarea-traceflow-00.txt

From: Ronald Bonica <[email-masked]>
Date: Sun, 5 Feb 2012 12:43:27 -0500

Hi Balaji,

This draft appears to be an attempt to squeeze more information out of traceroute.  Could you tell me what information you are probing for, beyond that which can already be obtained using ICMP extensions defined in RFCs 4950 and 5837?

Why is a new approach required? If additional information is required, why not extend the ICMP response, as  RFCs 4950 and 5837 did?

                                                                                                  Ron
                                                                                                /speaking as individual contributor

From: [email-masked] [mailto:[email-masked]] On Behalf Of Balaji Venkat Venkataswami
Sent: Wednesday, January 25, 2012 11:12 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [OPSAWG] FW: I-D Action: draft-janapath-intarea-traceflow-00.txt

Hi all,

Cross-posting this draft to the opsawg-group for comments / suggestions
as it may be of relevance.

thanks and regards,
Jana and team.

From: Balaji venkat Venkataswami [mailto:[email-masked]]
Sent: Thursday, January 26, 2012 9:40 AM
To: Balaji Venkat Venkataswami
Subject: Fwd: I-D Action: draft-janapath-intarea-traceflow-00.txt

---

From: Melinda Shore <[email-masked]>
Date: Sun, 05 Feb 2012 08:53:28 -0900

On 2/5/12 8:43 AM, Ronald Bonica wrote:
> Why is a new approach required? If additional information is required,
> why not extend the ICMP response, as RFCs 4950 and 5837 did?

Hi, Ron:

Speaking as an individual contributor and as someone who's worked on
what are essentially path-coupled diagnostics, ICMP is probably not
a great approach at all, given our frankly limited ability to secure
both requests and responses, complete inability to route messages
(it may be desirable to pin the reverse path to the forward path when
sending diagnostics) and a whole host of other limitations.  Using
ICMP for this sort of thing is a quick hack, but I don't think it's
very robust as a general-purpose diagnostic transport.  Which, of
course, raises the question of whether or not a general-purpose
diagnostic transport is what's wanted in the first place.

Melinda

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 6 Feb 2012 00:26:45 -0500

Hi Melinda,

It seems that two sets of tools are required. The first set of tools offers a general view of the device. These tools give operators access to fibs, ribs, mibs and everything else you can think of. CLI, NETCONF and SNMP occupy this space. Those protocols already offer decent authentication capabilities.

The seconds set of tools give operators an opportunity to directly observe forwarding behavior. Ping and traceroute fit the bill here. Because these tools offer relatively little information, they can be secured on an all-or-none bases (either you filter selected ICMP messages or you don't).

Am I missing a third set of tools?

My question remains: What information is draft-janpapath trying to obtain that isn't accessible already?

                                                            Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Melinda Shore
> Sent: Sunday, February 05, 2012 12:53 PM
> To: [email-masked]
> Subject: Re: [OPSAWG] I-D Action: draft-janapath-intarea-traceflow-
> 00.txt
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Melinda Shore <[email-masked]>
Date: Sun, 05 Feb 2012 21:01:23 -0900

> Am I missing a third set of tools?

Maybe.  Traceroute is an interesting case because you're inferring
router behavior or path characteristics from observed side-effects.
When something goes wrong you really don't know why.  If there's
an asymmetry in the path it's very possible for everything to be
copacetic in one direction but not in the other, and it's sometimes
extremely difficult to differentiate the two.

But aside from that we were interested in the ability to trigger
diagnostics and provide some flexibility in what was returned.

> My question remains: What information is draft-janpapath trying to obtain that isn't accessible already?

It looks like they're interested in some of the same things we were.
A packet goes into a network and disappears.  What happened?  Quite
often it's the result of some sort of policy decision inside a router,
or, heaven help us, firewall.  As ACLs get increasingly hairy (research
results show that literally 99% of firewall rulesets contain errors)
it would be excellent to have a tool that shows you what rules were
triggered at which device in a network.  Better still is to have a
reasonably general (but not unreasonably general) tool to trigger or
collect diagnostics in a network.

I don't love this draft (I think it's excessively blithe about
transport) but I think it represents a real problem, and one for which
we've seen interest from the community.

Melinda

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 6 Feb 2012 01:22:59 -0500

> From: Melinda Shore [mailto:[email-masked]]
> Sent: Monday, February 06, 2012 1:01 AM
> To: Ronald Bonica
> Cc: [email-masked]

[snip]

> we've seen interest from the community.

OK. I'll bite. Let's take some time to articulate that problem. We might to do that on the mailing list before jumping too deeply into the solution.

                                                   Ron

---

From: Melinda Shore <[email-masked]>
Date: Wed, 08 Feb 2012 16:42:29 -0900

Hi, Balaji:

I think this is where we stand with the draft:

1.  There's a good chance there's a good idea lurking within
     all those TLV packetization diagrams
2.  Unfortunately it's not presented very well and would need
     substantial revision.  Specifically we'd really like to see
     a strong problem statement and a framework before diving
     into protocol details.  And this is my *personal* bugaboo but
     wow, I really do not like seeing packet formats getting more
     attention than messaging and protocol operations.
3,  In the best of all possible worlds you'd be able to find
     someone to work with who's been through the process and has
     experience writing successful IETF documents - at least
     we'd have a better basis for discussion
4.  I hope this is with the understanding that even if you go
     ahead and produce a clearer document that doesn't mean that
     it necessarily becomes a working group item.  But at least
     we'd have, as I mentioned, a better basis for further
     consideration.

As a sort of corollary to all that, is there someone on the list who'd
like to help clarify this document?

Thanks,

Melinda
-- 
Melinda Shore
[email-masked]
Software longa, hardware brevis

---

From: Balaji Venkat Venkataswami <[email-masked]>
Date: Thu, 9 Feb 2012 10:31:19 +0530

Hi Melinda,

Thank you for your perusal of the document and subsequent comments.
We will strive to present this in a more clearer fashion taking into account the points you have mentioned.

thanks and regards,
balaji venkat

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]] 
Sent: Thursday, February 09, 2012 7:12 AM
To: Balaji Venkat Venkataswami
Cc: [email-masked]
Subject: Re: [OPSAWG] I-D Action: draft-janapath-intarea-traceflow-00.txt

Hi, Balaji:

Thanks,

Melinda