Subject: [Int-area] updated to draft-atlas-icmp-unnumbered-03

From: "Alia Atlas" <[email-masked]>
Date: Tue, 24 Jul 2007 17:51:28 -0400

I have updated the draft to reflect its goal of providing better
identification of the receiving interface to aid in troubleshooting
with traceroute.

There are a few common scenarios that this draft is intended to help
with.

First, the receiving interface may be different than the outgoing
interface (which gives the source IP address in the ICMP packet)
because of either asymmetric link costs or ECMP.

Second, the receiving interface may be unnumbered, so that the source
IP address can't identify the interface.  This is a problem for
troubleshooting when there are parallel unnumbered links.

I would welcome any comments or discussion on this draft.

Thanks,
Alia

On 5/15/07, Alia Atlas <[email-masked]> wrote:
>
> On 5/14/07, Pekka Savola <[email-masked]> wrote:
> >
> > On Mon, 14 May 2007, Alia Atlas wrote:
> > > 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. ...
> >
> > (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.)
>
>
> Do you have improved phrasing you might suggest?
>
> 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.
>
>
> 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.
>
> 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.
>
>
> 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
>
_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Mark Townsley <[email-masked]>
Date: Wed, 25 Jul 2007 12:51:33 -0500

Please also give us feedback on whether or not this document should be 
published, and on what track. I am considering the Standards Track, 
shepherded directly by either me or Jari.

- Mark

Alia Atlas wrote:
> On 5/15/07, *Alia Atlas* <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On 5/14/07, *Pekka Savola* <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         >>  already known from the source address though somewhat less
>         reliably so
>         >>  those need not be reported for outgoing interface use, and
>         could also
>     True -  I guess some of it depends whether the name or ifIndex is
>     more private
>     All of the additional info is optional and an operator could
>     determine what
>     Again, I was going for duplicating the information provided if an
>     IP address existed.
>
>     Alia
>
>
> ------------------------------------------------------------------------
>

---

From: Shane Amante <[email-masked]>
Date: Thu, 26 Jul 2007 11:29:24 -0600

Mark,

> shepherded directly by either me or Jari.

I would support Standards Track.

In addition, Alia and I have been speaking about another use case for 
this draft.  In particular, I would like to see it extended to account 
for identification of component-links inside ECMP and LAG's, which 
should be a straightforward use case given what's already specified in 
this draft.  This use case has become prevalent over the last several 
years and will become even more so in the future.

-shane

---

From: "Alia Atlas" <[email-masked]>
Date: Thu, 26 Jul 2007 14:12:26 -0400

> years and will become even more so in the future.

I believe that these cases can be handled by the router deciding which
ifIndex or IP address to include.  For instance, a router might include the
ifIndex of the member interface of a LAG.

Alia

-shane