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* <
akatlas at gmail.com
>> <mailto:akatlas at gmail.com>> wrote:
>>
>> On 5/14/07, *Pekka Savola* <
pekkas at netcore.fi
>> <mailto:pekkas at netcore.fi>> 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
>> Int-area at lists.ietf.org
>> https://www1.ietf.org/mailman/listinfo/int-area
>>
>
>
> _______________________________________________
> Int-area mailing list
> Int-area at lists.ietf.org
>
https://www1.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
Int-area at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area
