Naiming, Naiming Shen wrote: > Jari, > > Some comments inline. > > Jari Arkko said the following on 09/09/2008 11:11 PM: >> 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. > > 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
<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 _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
