On 7/26/07, Shane Amante <[EMAIL PROTECTED]> wrote: > > Mark, > > Mark Townsley wrote: > > > > 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. > > 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.
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 > > > > - Mark > > > > Alia Atlas wrote: > >> 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 PROTECTED] > >> <mailto:[EMAIL PROTECTED]>> wrote: > >> > >> On 5/14/07, *Pekka Savola* <[EMAIL PROTECTED] > >> <mailto:[EMAIL PROTECTED]>> 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 protected] > >> https://www1.ietf.org/mailman/listinfo/int-area > >> > > > > > > _______________________________________________ > > Int-area mailing list > > [email protected] > > https://www1.ietf.org/mailman/listinfo/int-area > > > > _______________________________________________ > Int-area mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/int-area >
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
