Re: [Int-area] updated to draft-atlas-icmp-unnumbered-03

[Carlos Pignataro <cpignata at cisco.com>]

On 7/26/2007 2:12 PM, Alia Atlas said the following:
> On 7/26/07, *Shane Amante* <shane at castlepoint.net
> <mailto:shane at castlepoint.net>> 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* < akatlas at gmail.com
>     <mailto:akatlas at gmail.com>
>     >> <mailto: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>
>     >>     <mailto: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 <mailto:Int-area at lists.ietf.org>
>     >> https://www1.ietf.org/mailman/listinfo/int-area
>     >>
>     >
>     >
>     > _______________________________________________
>     > Int-area mailing list
>     > Int-area at lists.ietf.org <mailto:Int-area at lists.ietf.org>
>     > https://www1.ietf.org/mailman/listinfo/int-area
> 
> 
> 
>     _______________________________________________
>     Int-area mailing list
>     Int-area at lists.ietf.org <mailto: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

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems


_______________________________________________
Int-area mailing list
Int-area at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area