Shane, On Sep 10, 2008, at 3:06 PM, Shane Amante wrote:
> 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> <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 > > 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
