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
>
> 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
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
