Alia,
Thank you for your answers, please see inline.
On 10/1/2007 9:23 PM, Alia Atlas said the following:
On 9/19/07, Carlos Pignataro
<cpignata at cisco.com>
wrote:
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.
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.
There may not be strong usage cases that would aid in identifying the
incoming interface (and the numberdness might be inferred from the
other fields based on the Section 4.4 usage rules). It was more of a
having all the pieces, strike out this comment :)
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.
Thank you.
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.
This is when the ICMP originates on the private side and traverses the
NAT, correct?
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.
I'm not sure what a NAT should do, although it might need different
behavior for the different fields (IP Address, ifIndex and
Description)? one further option for the IP address is a similar to the
Router-x|y source IP address treatment in Section 4.2.1 and 4.2.2
(respectively) of draft-ietf-behave-nat-icmp-05, that is depending on
external/private network. draft-ietf-behave-nat-icmp-05 says:
In addition, if the ICMP Error payload contains ICMP extensions
([ICMP-EXT]), the NATs are encouraged to support ICMP extension
objects. At the time of this writing, the authors are not aware
of any standard ICMP extension objects containing realm
specific information.
And revision -03 explored something like that. But it could treat the
IP address in the object similarly than the source IP address in those
sections (they might be the same). This could be coupled, as you say,
with an option (or even a default?) to remove the extension (or
overwrite it with a description). The other aspect of extension-NAT
interaction is the risk when the ICMP is generated from the private
network sent outside, to leak "internal information". This risk may
fall under the existing text:
It may be
desirable to provide this information to a particular network's
operators and not to others.
Although it might help to call it out separately.
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?
I agree it is a real problem. My comment is that if someone sources a
traceroute and receives an interface extension object, it should be
clear if it is reporting a member or the LAG. Agreed, the ifIndex can
be used for identification, but that would typically need an extra
(offline) query step; the Description might help, if included.
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?
Or a new "Interface Role" / C-type. Currently, only one incoming
interface object can be included, the question I think is how can the
receiving end know it points to a member interface.
Thanks,
--Carlos.
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* <
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
--
--Carlos Pignataro.
Escalation RTP - cisco Systems
|
