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: > 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
