Hi Naiming, Jari, Please find some follow-ups inline.
On 9/10/2008 3:01 PM, Naiming Shen said the following: > 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. 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. > > 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 > > >> 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 >> >> _______________________________________________ >> Int-area mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/int-area > -- --Carlos Pignataro. Escalation RTP - cisco Systems _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
