On 9/19/07, Carlos Pignataro <[EMAIL PROTECTED]> wrote: > > > > 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.
I have added a bit to the usage mentioning that the outgoing interface information can be used to create a destination map. I would be happy to add additional usage details. On those lines, please let me know what the usage case is for reporting the numberedness of an interface. I have consolidated the IPv4/IPv6 bits into 1 - it causes a parsing dependency on the packet type that was received, but given how short we are of bits, I think that is acceptable. I would welcome discussion on what a NAT should do. I can see a couple possibilities and I'm sure there are more. One possibility that would expose that there are different paths would be for the NAT to replace an IP address with a "fake ifindex" or a "description" that indicates the external (address, port) or something along those lines. I.e., the NAT doesn't try to hide the multiplicity of paths behind it; I can see usage cases where this would be very helpful for trouble-shooting. The second option would be to remove the IP address and ifindex info and overwrite the description with something indicating the address of the NAT that did so (or the authority or something) or just remove the object. Let me know what you'd prefer - or if we should define both for policy-based behavior - or if you see another option. As for the LAG, this is a real problem that exists in networks today. I don't want to lose the ability to solve that problem due to a desire for determinism. An ifindex has meaning that is router-specific already; wouldn't the description provide the necessary information for a clearer interpretation? Are you picturing something more sophisticated than a traceroute output? Given the desire to preserve the ability to tell the member of a LAG taken, what would you suggest? Are we onto another sub-object? Thanks, Alia 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
