Subject: [Int-area] Re: comments on draft-atlas-icmp-unnumbered-02

From: "Alia Atlas" <[email-masked]>
Date: Mon, 14 May 2007 17:41:50 -0700

Hi Pekka,

Thanks for the fast feedback.  I'm sorry for my long delay in responding.

On 3/18/07, Pekka Savola <[email-masked]> wrote:
>
> On Sun, 18 Mar 2007, Alia Atlas wrote:
> > For a slightly different approach at the problem, take a look at
> > draft-atlas-icmp-unnumbered-02.txt. It has the ability to report on
> > what would have been the outgoing interface, as well as the incoming
> > interface.  The information can include an ifIndex, an IP address,
> > and a brief string description.
> >
> > I'd be very interested in your feedback.
>
> The draft is unclear wrt 'description'.  It says that it SHOULD report
> 'ifName' but other info can be reported as well. This is very
> confusing as 'description' has established meaning in the ops
> community and that meaning is NOT ifName.  The object should be named
> 'Interface name' (ifName) because that's distinct from description
> (ifAlias).

Yes, I'll change it to interface name now.

I'd very strongly object to reporting 'description' (ifAlias).  In
> deployments I've seen this often includes confidential information
> (e.g., customer numbers, link identification numbers, etc.).  I
> suggest rephrasing this so that the name of the object is 'Interface
> name' (ifName).  If description (ifAlias) would be retained, the spec
> should require that by default it MUST NOT be reported.

Yes, I agree and have changed it to be interface name, and clearly ifName
as a SHOULD.

In general, I find the specification having features that I don't see
> necessary. Reporting ifIndex is not necessary (and the index is not
> very useful as is to a human) if ifName is reported.  Addresses are
> already known from the source address though somewhat less reliably so
> those need not be reported for outgoing interface use, and could also
> result in reporting IPv6 link-local addresses (or IPv4 private
> addresses) which wouldn't necessarily be useful or desired.

The idea with reporting the ifIndex is to provide the easy ability to
correlate
that to MIB data.  It is a common look-up key and I believe it to be useful.

Using simply the source address doesn't handle topologies with parallel
links between routers.  In that case, knowing the exact outgoing link for
troubleshooting
is useful.  I believe that even IPv6 link-local addresses & IPv4 private
addresses
would be useful in distinguishing between two interfaces; however, if that
isn't desired,
it would be under operator control.

There also seems to be some specification about incoming/outgoing
> interface (which is probably why addresses are supported).  This is
> distinct from what draft-watkins-icmptype11code0 is about because that
> draft reports next-hops which this doesn't do.

Yes, I'm primarily interested in the incoming interface, for better
traceroute
troubleshooting support, but others were interested in the outgoing
interface.
If there is a desire to include the outgoing next-hops, that could be added
as
a sub-object.

Personally, I'd prefer seeing either one big document or two
> documents, one describing 'ifName' reporting and one describing IP
> address reporting (nexthop, possibly input/output interface).
> Currently input/output address reporting seems to be out of scope of
> this draft though: the title, draft name, abstract, etc. don't reflect
> these address extensions (meant to identify the incoming interface) so
> some rewording at the very least is needed there.

Well, my initial focus for the draft was on handling unnumbered interfaces,
but other authors were also interested in the IP addresses.  The abstract
does address appending the IP address to facilitate troubleshooting; this
is primarily using the incoming interface.

I'd be happy to add another sub-object if that addresses the concerns of
obtaining the next-hop and that is desirable.

As a more editorial issue, the first two paragraphs could maybe use
> slight modification to better account for IPv6 (e.g., ref to ICMPv6
> spec).  As a detail, source address selection for ICMPv6 is specified
> slightly differently, but it's spec-compliant to do it the same way as
> for IPv4.  It's not guaranteed though.

I'll add the ref to the ICMPv6 spec.

Thanks for the feedback,
Alia

--
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Pekka Savola <[email-masked]>
Date: Tue, 15 May 2007 08:45:00 +0300 (EEST)

On Mon, 14 May 2007, Alia Atlas wrote:
> The idea with reporting the ifIndex is to provide the easy ability 
> to correlate that to MIB data.  It is a common look-up key and I 
> believe it to be useful.
>
> Using simply the source address doesn't handle topologies with 
> parallel links between routers.  In that case, knowing the exact 
> outgoing link for troubleshooting is useful. ...

(A potentially interesting note: at least one implementation has an 
internal 'interface index' which is different from 'SNMP ifIndex'. 
The intent should be clear in the spec.)

If ifName is reported, is there significant benefit in reporting 
ifIndex as well?

It could be more easily used for correlation, but that's only useful 
for the operators of the network who could know the ifIndexes on the 
routers, not outsiders.  On the other hand, those network operators 
can very well map the ifName to ifIndex using SNMP or similar tools as 
well.

I'm not strongly against being able to report ifIndex (but I'd rather 
that it doesn't get reported by default, at least to everyone), but it 
seems like a feature that's more likely to clutter the traceroute 
output with little added value: ifName should already provide the same 
benefits and is a more generic mechanism.

[[ I don't have further to say about ifName vs IP address/nexthop/iif 
reporting, so I've deleted it below ]]

---

From: "Alia Atlas" <[email-masked]>
Date: Mon, 14 May 2007 23:43:29 -0700

> The intent should be clear in the spec.)

Do you have improved phrasing you might suggest?

> can very well map the ifName to ifIndex using SNMP or similar tools as

True -  I guess some of it depends whether the name or ifIndex is more
private
and how many steps an operator has to take to get decent results.
On the other hand, normal traceroute gives both the IP address and the DNS
name, if any.  I was looking to provide the equivalent.

> benefits and is a more generic mechanism.

All of the additional info is optional and an operator could determine what
to show based upon the incoming IP address or such.

Again, I was going for duplicating the information provided if an IP address
existed.

Alia