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 On Thu, Sep 11, 2008 at 10:14 PM, Naiming Shen <[EMAIL PROTECTED]> wrote: > > 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 >
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
