On 7/26/2007 2:12 PM, Alia Atlas said the following: > On 7/26/07, *Shane Amante* <[EMAIL PROTECTED] > <mailto:[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.
I also support publishing this document in 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. I agree that the document is much more aligned with and structured around solving the problem of identifying the incoming interface of an undeliverable datagram, and that's a very useful troubleshooting tool. It also cleaned some of the issues previously identified. Please find a couple of comments: I think that the "Usage" section can use some finer/stricter definition; the report of the "numberedness" of the interface in question can also help (and is currently not directly covered). In the bitfield definition of the C-Type, one bit can be saved by merging together the IPv4 and IPv6 bits in a single field, since only one is meaningful for a given ICMP. It may also help to discuss what a NAT should do with extension fields containing addresses, if anything. Finally, regarding ECMPs and LAGs, I think that the router behavior should be deterministic in always including the same interface, (e.g., the LAG and not individual members), so that the receiving end can interpret it a given way. Thanks, --Carlos. > > 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]> > >> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote: > >> > >> On 5/14/07, *Pekka Savola* < [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > >> <mailto:[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] <mailto:[email protected]> > >> https://www1.ietf.org/mailman/listinfo/int-area > >> > > > > > > _______________________________________________ > > Int-area mailing list > > [email protected] <mailto:[email protected]> > > https://www1.ietf.org/mailman/listinfo/int-area > > > > _______________________________________________ > Int-area mailing list > [email protected] <mailto:[email protected]> > https://www1.ietf.org/mailman/listinfo/int-area > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Int-area mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/int-area -- --Carlos Pignataro. Escalation RTP - cisco Systems _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
