Subject: [Int-area] comments on draft-atlas-icmp-unnumbered

From: Jari Arkko <[email-masked]>
Date: Sat, 06 Sep 2008 12:51:46 +0300

Overall, this draft specifies a useful function and I believe it should 
move forward.

There are a number of details that need a bit of adjustment before the 
draft is ready, however. Please see details further down in this e-mail.

There is one big question as well. There has been some discussion about 
the usefulness of next hop information and whether 
draft-watkins-icmptype11code0 should also move forward, or if the drafts 
should merge. Having read the two drafts together now, my opinion is 
that adding a flag and 2nd IP address for the next hop for an outgoing 
interface object seems like a good approach. This would allow reporting 
an outgoing interface AND its next hop information (where available).

Another interesting issue is treatment by NATs. Given that the 
information is primarily for debugging and that any modification or 
removal of this information by a NAT could interfere with that, my 
suggestion is that NAT devices SHOULD merely pass this extension along.

Technical:

> Extending ICMP to Identify the Receiving Interface
> Abstract
>
> This memo defines ICMP extensions, using ICMP multi-part messages,
> through which a router or host can explicitly identify the interface
> upon which an undeliverable datagram anrrived.
>
> ...
>
> Using the extension defined herein, an IP device can explicitly
> identify the incoming interface by any or all of the following:
>
> o  IPv4 address
> o  IPv6 address
> o  name
> o  ifIndex
>
> Using the extension defined herein, an IP device can explicitly
> identify by the above the outgoing interface and next-hop over which
> a datagram would have been forwarded if that datagram had been
> deliverable.
>
> ...
>
> 3.2. Policy and MTU Detection
>
> A general application would be to identify which outgoing interface
> triggered a given function for the original packet.
> ...
> 0 : This object describes the incoming interface.
> 1 : This object describes the outgoing interface.
>   

First, the title is misleading, and the abstract does not mention the 
ability to identify outgoing interfaces. Second, how does the 
identification of the outgoing interface follow from the identification 
of the incoming interface, given things like ECMP?

Since the draft does, after all, support identifying outgoing interfaces 
as well that fact should be better reflected in title, abstract, etc.

> 3 : When set, this bit indicates the ifIndex of the interface is 
> included.  When clear, the ifIndex is not included.
Encoded how? How many bytes?

> Another issue is when a device inside a private region generates an 
> ICMP message with some of these extensions and that ICMP message will 
> transit a NAT to reach its destination.  A NAT may choose to remove or 
> overwrite the extensions.
First, please clarify whether leaving the extension alone is also legal. 
This is obviously what a legacy NAT would do, of course, so I don't feel 
good about outlawing it.

Second, I think we need a stronger recommendation on what the NATs 
should do about this, so that the NAT vendors can do the right thing. 
However, its not entirely clear to me what the right thing is. In 
particular, even if this extension passes a NAT the optional addresses 
included in it may or may not still be valid on the other side of the 
NAT. And this has nothing to do with the type of the addresses (private 
or public), it has to do with the topology of the network -- and this 
may not be something that the NAT device understands.

One approach would be to say that this information is for debugging 
only, and therefore SHOULD be left alone. Thoughts?

>  Interface Name Sub-Object
Shouldn't there be some discussion about truncation in case the real 
name does not fit this object?

Editorial:

> upon which an undeliverable datagram anrrived.  The incoming
Typo

>    Bit   7     6      |   5       4       3       2       1       0
>       +-------+-------+-------+-------+-------+-------+-------+-------+
>       | Interface Role| Rsvd  | Rsvd  | index | IP    | Rsvd  | descr |
>       +-------+-------+-------+-------+-------+-------+-------+-------+
>   
For what it is worth, I found this figure illustrative, but the text 
that accompanied it was confusing. For one thing, the text discusses two 
fields "Interface Role" and "Included Information" which are not shown 
here. For another, the bits are later referred to by their numbers, not 
names. I would suggest sticking to the names in the figure and removing 
the concept of the "Included Information" field.

> The information/sub-objects MUST be sent and received inside the 
> Interface Information Object in the order that they are listed in the 
> final 6-bits included-information field.
Just say:

"The ifIndex, address, and name follow the C-type octet, in this order, 
if present."

or something to that effect. Avoid referring to the confusing 
included-information field. Also, the ifIndex and address were by my 
understanding not proper objects, it was just bytes following the C field.

> 4.3. Interface Information Object Description

Wouldn't this be better as "Examples"?

> Figure 4 depicts the Interface Information Object, with two of the 
> valid permutations.

Three, but who's counting :-)

>    o  Bit 3: ifIndex include

included

Jari

_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Joe Touch <[email-masked]>
Date: Tue, 09 Sep 2008 10:30:09 -0700

Hi, all,

I agree with Jari's suggestion about merging the mechanisms described.

Regarding NATs, they already don't listen to MUSTs, so I don't see the
point in issuing SHOULDs they're going to ignore as well ;-)

Joe

---

From: Jari Arkko <[email-masked]>
Date: Tue, 09 Sep 2008 22:46:55 +0300

Joe,

> point in issuing SHOULDs they're going to ignore as well ;-)

I guess this was said at least partially tongue in cheek. But if not, we 
need to talk about the distinction between helping well-behaved 
implementations vs. forcing everyone to do something. We don't always 
succeed in the latter (or even want to), but the former is still valuable.

Jari

---

From: Joe Touch <[email-masked]>
Date: Tue, 09 Sep 2008 12:51:47 -0700

> succeed in the latter (or even want to), but the former is still valuable.

Agreed to the former. IMO, though, it's not always clear how much effort
is useful, since I expect more of the latter to be actual practice.

Joe

---

From: Jari Arkko <[email-masked]>
Date: Wed, 10 Sep 2008 09:11:37 +0300

Alia,

I wanted to comment on the issue of including next hop information. You 
wrote:

> The concern is that it adds substantially to the implementation 
> complexity to support this feature.  Basically, that requires knowledge
> of dynamic information beyond the local system and may not be easily
> available.
> Others may be able to comment more extensively on their concerns.
>
> Given that the outgoing interface's information is available, this is
> an issue for non-point-to-point interface types.  
>
> If we were to include the next-hop information, do we only care about
> numbered next-hops (i.e., ignoring unnumbered point-to-point
> interfaces)?
> What if the next-hop information is not of the same IP version as the
> packet?
> Do we just not include it?
>
> As I said, the concern was with implementation complexity from the added
> information and not, obviously, the details of encoding it in this
> draft.  If there is sufficient consensus to have this ability, then it
> could be added.
>   

I understand that this might imply more work, depending on your 
implementation even substantially more work.

However, from my point of view ALL of these extensions are optional. 
That is, if you think the cost is justified you add code to return the 
interface information. Similarly, if you think the cost is justified, 
you add even more code to return the next hop information. The protocol 
needs to be designed so that it can return the amount of information it 
has or it cares to find out for you. In conclusion, I do not see a big 
problem about the implementation complexity, if the functionality is 
optional.

The next-hop information should of course only be returned if (a) the 
outgoing interface is known, (b) the next hop in the outgoing interface 
is known, and (c) per above the implementation wants to return this 
information.

I'm trying to get my head around the different IP version issue. When 
would this happen? The only case that I can think of is a router that 
tunnels IPv6 over IPv4. But in this case your forwarding is actually 
from a physical interface to a tunnel interface, not to another physical 
interface. And if its a tunnel, its a point-to-point link and there is 
no next hop. Am I missing something?

Jari

---

From: Naiming Shen <[email-masked]>
Date: Wed, 10 Sep 2008 12:01:23 -0700

Jari,

Some comments inline.

> is known, and (c) per above the implementation wants to return this 

Carlos (cc'ing him here) first suggested to us to include IP nexthop info
in this icmp-unnumbered-00 draft in Jan 2006, I had extensive discussion
with him on the email, and finally decided not to include that.

Some of my reasons at the time:

  - in a distributed platfrom with multiple linecards, the icmp reply
    is sent back in the inbound linecard, which usually does not have
    the outbound exact forwarding information, such as the nexthop. In
    some of the platform implementation, the nexthop is not even downloaded
    into the forwarding chain, since it's not needed for the forwarding
    purpose(only the MAC address is needed).

    ok, one can argue since it's optional, if you don't have it, then
    don't include it in the reply.

  - the nexthop will be learned when the traceroute gets to the nexthop.
    if you can not get to the nexthop, then it could be an ACL intentionally
    block that, it can be a security issue to expose the nexthop if this
    is the case. there probably should be some extensive mechanism to
    describe all the issues and how to handle them.

  - the nexthop may not be on the same routing domain, in l3vpn, the vrf
    lookup actually has the nexthop of global routing domain; first it's
    useless to pass this information to the source of the trace, second
    that is another security issue, since it reveals the provider internal
    BGP PE information. that probably need another extensive description
    and handling. at least the VRF, multi-topology, and multi-instance
    information is also invovled to be really meaningful.

  - for the normal case, nexthop is not a big deal, as long as you know
    the outbound interface. but in ECMP loadsharing cases, that's where
    nexthop would be useful information.

    But, majority of the loadsharing algorithm used in the network today
    is based on source and destination IP addresses, and also could include
    the upper layer port numbers. So to use traceroute(since the source is
    certainly different, and also the port number is different), even it
    returns a nexthop in this case, it could be a totally misleading
    information.

    and in the per packet load sharing case, each packet uses a different
    nexthop, that's even more meaningless.

I would suggest leave this out for the base unnumbered draft, this can be
an extensive issue to study to explore. it's an interesting topic to
me at least.

But if majority of the folks are willing to just stuff this in as
a simple option to the unnumbered draft, i'm fine too.

thanks.
- Naiming

---

From: "Alia Atlas" <[email-masked]>
Date: Wed, 10 Sep 2008 17:59:27 -0400

Jari,

> problem about the implementation complexity, if the functionality is

As you say, given that it is optional, I don't see it as a big concern and
it is
useful functionality.

> no next hop. Am I missing something?

Well, I was thinking of the case of an MPLS tunnel, where traffic inside
might be IPv4 or IPv6 or something else.   If it is an IP packet, then the
ICMP packet is either IPv4 or IPv6 based on the type of the encapsulated
packet.  The same MPLS LSP can be carrying both & the next-hop info would
be of only one type.

In that case, the IP addresses can either not be included for version
mismatches or we could go back to having an IPv4 address flag and
an IPv6 address flag and have the next-hop info get the last interface role
value.

Alia

---

From: Shane Amante <[email-masked]>
Date: Wed, 10 Sep 2008 16:06:36 -0600

Naiming,

> a simple option to the unnumbered draft, i'm fine too.

<Speaking as an operator for a large-ish network>

While I agree with you that returning next-hop information is a 
difficult problem to solve, I would (strongly) advocate we do so sooner 
rather than later, i.e.: in this draft.

Operators make extensive use of fairly large 802.3ad LAG's and ECMP 
paths and will continue to do so indefinitely, since physical layer 
transmission media is rarely able to keep up with network growth. 
Without the ability to return next-hop information, it's very difficult 
and time consuming for customer's and NOC's to troubleshoot problems 
where LAG or ECMP is used in the path.

At the very least, putting down the details now would, hopefully, help 
vendors to at least start building the necessary software and hardware 
components to adequately troubleshoot these problems in today's networks.

-shane

---

From: Naiming Shen <[email-masked]>
Date: Wed, 10 Sep 2008 22:12:31 -0700

Shane,

On Sep 10, 2008, at 3:06 PM, Shane Amante wrote:

>>> I wanted to comment on the issue of including next hop  
>>> information. You wrote:
>>>
>>>
>>> However, from my point of view ALL of these extensions are  
>>> optional. That is, if you think the cost is justified you add  
>>> code to return the interface information. Similarly, if you think  
>>> the cost is justified, you add even more code to return the next  
>>> hop information. The protocol needs to be designed so that it can  
>>> return the amount of information it has or it cares to find out  
>>> for you. In conclusion, I do not see a big problem about the  
>>> implementation complexity, if the functionality is optional.
>>>
>>> The next-hop information should of course only be returned if (a)  
>>> the outgoing interface is known, (b) the next hop in the outgoing  
>>> interface is known, and (c) per above the implementation wants to  
>>> return this information.

<I used to work with Joe, Roy and Jack in iMCI, so I'm not completely  
vendor'ish :-) >
BTW, Kirk Spessard said hello.

The issues I raised above are not purely hardware supporting related.  
But I'm fine with
putting down the details as you suggested.

thanks.
- Naiming

> difficult problem to solve, I would (strongly) advocate we do so  
> sooner rather than later, i.e.: in this draft.
>
> Without the ability to return next-hop information, it's very  
> difficult and time consuming for customer's and NOC's to  
> troubleshoot problems where LAG or ECMP is used in the path.
>
> At the very least, putting down the details now would, hopefully,  
> help vendors to at least start building the necessary software and  
> hardware components to adequately troubleshoot these problems in  
> today's networks.
>
> -shane

---

From: Jari Arkko <[email-masked]>
Date: Thu, 11 Sep 2008 12:07:40 +0300

> gue since it's optional, if you don't have it, then

That was the argument I was making.

> So to use traceroute(since the source is
True. It would be correct for the traceroute, though, but it wouldn't 
necessarily match what is happening with payload packets.

Jari

---

From: "Alia Atlas" <[email-masked]>
Date: Thu, 11 Sep 2008 09:12:46 -0400

> necessarily match what is happening with payload packets.

Sure - but that argument applies for all the information that  traceroute
returns.

I think the fix for that is elsewhere, where one can use the
application-specific information with a modified traceroute.  The
difficulty,
of course, is knowing when to terminate the traceroute at the destination
without messing up the application.

Alia

---

From: Carlos Pignataro <[email-masked]>
Date: Thu, 11 Sep 2008 20:36:16 -0400

Jari, Alia,

Please find some comments and my 2¢ inline.

On 9/9/2008 8:11 PM, [email-masked] said the following:
>  Jari,
> 
>> -----Original Message-----
>> From: Jari Arkko [mailto:[email-masked]] 
>> Sent: Saturday, September 06, 2008 5:52 AM
>> To: Internet Area; 
>> [email-masked]; 
>> [email-masked]
>> Subject: comments on draft-atlas-icmp-unnumbered
>>
>> Overall, this draft specifies a useful function and I believe 
>> it should move forward.

+1 !

>>
>> There are a number of details that need a bit of adjustment 
>> before the draft is ready, however. Please see details 
>> further down in this e-mail.
>>
>> There is one big question as well. There has been some 
>> discussion about the usefulness of next hop information and 
>> whether draft-watkins-icmptype11code0 should also move 
>> forward, or if the drafts should merge. Having read the two 

I think that in general, NH information is extremely useful even with a
number of limitations (I'll reply to Naiming's posting regarding this).

But I don't think that draft-watkins-icmptype11code0 should be merged.
The main reason is that draft-atlas-icmp-unnumbered already supports
providing next-hop information in a more generic way. It may need to add
some clarifying text exemplifying how/when it may/should_not be used (as
an applicability of the next-hop info), but encoding and support is there:

Specifically, this extension contains the Interface-Role field that can
take values for either incoming or outgoing interface (and outgoing may
need to have more descriptions in presence of ECMPs, etc). I remember
discussing it with Alia, along with outgoing mtu topics. The text says
this already:

   Using the extension defined herein, an IP device can explicitly
   identify by the above the outgoing interface and next-hop over which
   a datagram would have been forwarded if that datagram had been
   deliverable.  This can be used for creating a downstream map.

And it says in the "Usage":

   In an ICMP message, more than one Interface Information Object with a
   given interface role MUST NOT be included.  Multiple Interface
   Information Objects, each with a different interface role, MAY be
   included.

This was included to allow for both incoming and outgoing information in
the same message (i.e., which can be exemplified to saying that an ICMP
response can include two extension objects): one for the incoming
information and one for the outgoing information. Each of these two, in
turn, can describe the respective interface by either (or a combo of)
ifIndex, IP address, description.

The definition in draft-atlas-icmp-unnumbered allows support for nh info
for both IPv4 and IPv6. Additionally, the other generalization is that
draft-watkins-icmptype11code0 seems to apply to timexceeded only, and
not e.g., unreachables (and it's important in `traceroute -M`, etc).

>> drafts together now, my opinion is that adding a flag and 2nd 
>> IP address for the next hop for an outgoing interface object 
>> seems like a good approach. This would allow reporting an 
>> outgoing interface AND its next hop information (where available).
> 
> As you say, it is not difficult to add the next-hop information.
> As I recall, we did discuss doing this.
>> Another interesting issue is treatment by NATs. Given that 
>> the information is primarily for debugging and that any 
>> modification or removal of this information by a NAT could 
>> interfere with that, my suggestion is that NAT devices SHOULD 
>> merely pass this extension along.
> 
> The concern I've heard expressed is that this would interfere with the
> hiding of the IP addresses inside the NATed region.
> 
> The only way to resolve both concerns seems to be for the NAT to
> allocate
> a unique "ifIndex" for the interface info being hidden and report that?
> 
> Is it better for a SHOULD to argue for less security in favor of
> troubleshooting
> or leave it up to the designer/customer as to which trade-off is
> preferable.
> 
>> Technical:
>>
>>> Extending ICMP to Identify the Receiving Interface Abstract
>>>
>>> identify by the above the outgoing interface and next-hop 
>> over which a 
>>> datagram would have been forwarded if that datagram had been 
>>> deliverable.
>>>
>>> ...
>>>
>> First, the title is misleading, and the abstract does not 
>> mention the ability to identify outgoing interfaces. Second, 
>> how does the identification of the outgoing interface follow 
>> from the identification of the incoming interface, given 
>> things like ECMP?
> 
> Yes, the abstract and title need to be updated to reflect the
> possibility
> of outgoing interface information.
> 
> Given things like ECMP, the device needs to do the ECMP algorithm based
> upon
> the packet and report where the packet would have gone.  This requires
> the
> ability to either (ideally) get that information from the forwarding
> path or
> else to compute what the forwarding path would have decided.  It is an
> important
> ability.
> 
>> Since the draft does, after all, support identifying outgoing 
>> interfaces as well that fact should be better reflected in 
>> title, abstract, etc.
>>
>>From Sec 4, " The ifIndex of the interface of interest MAY be included.
> This
>        is the ifIndex assigned to the interface by the router in as
>        specified by the Interfaces Group MIB [RFC2863]."
> I can specify it more clearly as being 4 octets written in big endian
> order.
> The MIB specifies it as an Integer32.
> 
>  
>> This is obviously what a legacy NAT would do, of course, so I 
>> don't feel good about outlawing it.
> 
> Yes, leaving the extension alone is legal.
>  
>> Second, I think we need a stronger recommendation on what the 
>> NATs should do about this, so that the NAT vendors can do the 
>> right thing. 
>> However, its not entirely clear to me what the right thing 
>> is. In particular, even if this extension passes a NAT the 
>> optional addresses included in it may or may not still be 
>> valid on the other side of the NAT. And this has nothing to 
>> do with the type of the addresses (private or public), it has 
>> to do with the topology of the network -- and this may not be 
>> something that the NAT device understands.
>>
>> One approach would be to say that this information is for 
>> debugging only, and therefore SHOULD be left alone. Thoughts?
> 
> The only concern with this is the desire to hide the addresses
> entirely inside the NAT.  It should be only for debugging, but
> we don't want to introduce a new security concern.  
> 
> Carlos had some useful insights here; perhaps he will have time
> to comment?

In the presence of NATs, I think that the behavior can go from removing
the extension (to avoid leaking info), re-writing it, to leave it alone
(prioritizing troubleshooting). But the behavior could potentially be
different for address versus non-address information.

Specifically regarding the addresses, IMHO the case is conceptually
similar to the NAT treatment of source IP addresses in ICMPs, and I
think that the NAT should be asked to do the same that for router source
addresses in draft-ietf-behave-nat-icmp. That is, request the NAT to
treat the IP in the extension as it treats the "Router-x" address when
"ICMP Error Packet Received from External Realm", and to treat the IP
address in the extension as "Router-y" address in "ICMP Error Packet
Received from Private Realm". I just found some text (on the
possibilities, mostly without taking sides on the normativeness) that
I'd sent to Alia on this, which might be totally outdated, but perhaps
can serve as a starting point:

<nat>
5. Network Address Translation Considerations

   [NAT-ICMP] encourages Traditional IP Network Address Translators
   (Traditional NATs, see [RFC3022]) to support ICMP extension objects.
   This document defines ICMP extensions that include IP addresses and
   therefore contain realm specific information, and consequently
   describes possible NAT behaviors in presence of these extensions.

   In the most general case, a NAT device may choose to remove or
   overwrite these extensions (see [Section Security]). The action may
   be different for the different fields: The ifIndex can either be
   transparently passed or removed, the Description can be transparently
   passed, removed or re-written (adding some text to the effect that a
   NAT was crossed and the description was removed, as a matter of
   policy or other), and IP addresses can either be removed or
   translated.

   When translating IP address-related fields of the extension defined
   in this document, the behavior should be equivalent to that of the
   treatment of Router-x and Router-y source IP address in Sections
   4.2.1 and 4.2.2 of [NAT-ICMP] (respectively). That is:

   o  For ICMP Error Packets received from an External Realm: IP
      Addresses included in this extension remain unchanged because they
      correspond to the external domain (e.g., correspond to a router
      that generated the ICMP in the external realm).

   o  For ICMP Error Packets received from a Private Realm: This
      extension includes an IP address corresponding to the Private
      realm, let's refer to it as IP-Private, and its translation
      depends on whether Basic NAT or NAPT function ([RFC3022]) is
      enforced by the NAT:

      -  Basic NAT: If the NAT has an active mapping for IP-Private, the
         NAT translate it within the extension with the IP-Public in
         said mapping.  If not, the NAT translates the IP-Private
         address using its own IP address on the external domain.

      -  NAPT: the NAT translates the IP-Private address in the
         extension to its own IP address on the external domain.

Additional Informational References:

[NAT-ICMP]  draft-ietf-behave-nat-icmp
[RFC3022]   RFC3022
</nat>

Unless it's desired to always let this extension through unchanged, this
allows for troubleshooting while not leaking private-realm addresses
outside.

The Security Considerations section mentions possibilities, taking the
extension as a monolith (not describing sub-TLV-specific behaviors):

   Another issue is when a device inside a private region generates an
   ICMP message with some of these extensions and that ICMP message will
   transit a NAT to reach its destination.  A NAT may choose to remove
   or overwrite the extensions.

One additional comment: The Security Considerations section mentions
potential policy controls on reply to which sources to add the extension
to. I wonder if it should point to draft-shen-udp-traceroute-ext to
allow for a more dynamic or granular enforcement of this.

Thanks,

--Carlos.

>> Shouldn't there be some discussion about truncation in case 
>> the real name does not fit this object?
> 
> True; truncation would give just the first 62 octets of the ifName.
> I can specify this clearly.
> 
>> Editorial:
>>
> will fix
>> For what it is worth, I found this figure illustrative, but 
>> the text that accompanied it was confusing. For one thing, 
>> the text discusses two fields "Interface Role" and "Included 
>> Information" which are not shown here. For another, the bits 
>> are later referred to by their numbers, not names. I would 
>> suggest sticking to the names in the figure and removing the 
>> concept of the "Included Information" field.
>>
>> "The ifIndex, address, and name follow the C-type octet, in 
>> this order, if present."
>>
>> included-information field. Also, the ifIndex and address 
>> were by my understanding not proper objects, it was just 
>> bytes following the C field.
> 
> This is true as far as it goes - but if the additional reserved flags
> are
> allocated, I'd expect them to follow the same restriction.  That is
> captured
> in the existing language and not in your suggested text.
> 
> The ifIndex and address are just bytes as you say and not sub-objects.
> That's
> why I specified information/sub-objects.
> 
> Yes
> laziness in editing strikes again...
>  
>>>    o  Bit 3: ifIndex include
>> included
> 
> will fix
> 
> Thanks for the review,
> Alia
> 

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

---

From: Carlos Pignataro <[email-masked]>
Date: Thu, 11 Sep 2008 20:47:22 -0400

Hi Naiming, Jari,

Please find some follow-ups inline.

> with him on the email, and finally decided not to include that.

Yes, I remember it was a looong and very enjoyable/fruitful
discussion; right before, I had coded an very basic extension (different
encoding, I think 3 different Class-Nums actually) that returned the
next-hop IP address, MTU and name string of the outgoing interface, to
play and try in the lab in-house.

The main issue IIRC was the inability to always *expect* to be able to
glean next-hop information; it's not really an issue if support for the
field is optional (as it is), unless the cases where it's likely,
possible or desired are a vast minority.

Some scenarios make it difficult or impossible (not necessarily because
of implementation limitations, but technically). Some corner scenarios
include point-to-point unnumbered or /32 interfaces (where sometimes you
don't *know* the nh, you can snoop it from routing updates, etc, but may
not), ECMPs (where the software slow-path algorithm needs to know/mimic
the fast-path algo in use, or the result applies only to the traceroute
probe and not the interesting protocol), distributed platforms (where
the ingress LC generates the icmp but might not know the actual outgoing
interface), fear of leaking NH information that would have been ACLed
out in the datapath, etc. There was also the argument of "how
much is too much to include".

However, all that said, I believe that operationally it is extremely
useful information, and since the draft (now explicitly) allows for
encoding next-hop information, it should probably: first set the
expectation that there are cases in which it's not possible or practical
to produce next-hop info (i.e., somewhat of a best-effort expectation),
and possibly list some of the cases in which you don't want to generate
it. Even without 100% applicability, and all the caveats, it is IMHO
useful info to have.

Thanks,

--Carlos.

---

From: Naiming Shen <[email-masked]>
Date: Thu, 11 Sep 2008 19:14:04 -0700

Hi Carlos,

I agree with your comments. put this one in with the caveats.
thanks much.

- Naiming

On Sep 11, 2008, at 5:47 PM, Carlos Pignataro wrote:

>>> information. You

---

From: "Alia Atlas" <[email-masked]>
Date: Tue, 16 Sep 2008 09:34:00 -0400

It sounds like we have consensus on carrying the next-hop information as
well.
I will respin the draft to reflect this and the comments from Jari, Dave,
and Carlos.

Any other comments before I start?

Alia