Hi Pekka, Thanks for the fast feedback. I'm sorry for my long delay in responding.
On 3/18/07, Pekka Savola <[EMAIL PROTECTED]> wrote:
On Sun, 18 Mar 2007, Alia Atlas wrote: > For a slightly different approach at the problem, take a look at > draft-atlas-icmp-unnumbered-02.txt. It has the ability to report on > what would have been the outgoing interface, as well as the incoming > interface. The information can include an ifIndex, an IP address, > and a brief string description. > > I'd be very interested in your feedback. The draft is unclear wrt 'description'. It says that it SHOULD report 'ifName' but other info can be reported as well. This is very confusing as 'description' has established meaning in the ops community and that meaning is NOT ifName. The object should be named 'Interface name' (ifName) because that's distinct from description (ifAlias).
Yes, I'll change it to interface name now. I'd very strongly object to reporting 'description' (ifAlias). In
deployments I've seen this often includes confidential information (e.g., customer numbers, link identification numbers, etc.). I suggest rephrasing this so that the name of the object is 'Interface name' (ifName). If description (ifAlias) would be retained, the spec should require that by default it MUST NOT be reported.
Yes, I agree and have changed it to be interface name, and clearly ifName as a SHOULD. 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. I believe that even IPv6 link-local addresses & IPv4 private addresses would be useful in distinguishing between two interfaces; however, if that isn't desired, it would be under operator control. There also seems to be some specification about incoming/outgoing
interface (which is probably why addresses are supported). This is distinct from what draft-watkins-icmptype11code0 is about because that draft reports next-hops which this doesn't do.
Yes, I'm primarily interested in the incoming interface, for better traceroute troubleshooting support, but others were interested in the outgoing interface. If there is a desire to include the outgoing next-hops, that could be added as a sub-object. Personally, I'd prefer seeing either one big document or two
documents, one describing 'ifName' reporting and one describing IP address reporting (nexthop, possibly input/output interface). Currently input/output address reporting seems to be out of scope of this draft though: the title, draft name, abstract, etc. don't reflect these address extensions (meant to identify the incoming interface) so some rewording at the very least is needed there.
Well, my initial focus for the draft was on handling unnumbered interfaces, but other authors were also interested in the IP addresses. The abstract does address appending the IP address to facilitate troubleshooting; this is primarily using the incoming interface. I'd be happy to add another sub-object if that addresses the concerns of obtaining the next-hop and that is desirable. As a more editorial issue, the first two paragraphs could maybe use
slight modification to better account for IPv6 (e.g., ref to ICMPv6 spec). As a detail, source address selection for ICMPv6 is specified slightly differently, but it's spec-compliant to do it the same way as for IPv4. It's not guaranteed though.
I'll add the ref to the ICMPv6 spec. Thanks for the feedback, Alia --
Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
