Jari, On Wed, Sep 10, 2008 at 2:11 AM, Jari Arkko <[EMAIL PROTECTED]> wrote:
> 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. > As you say, given that it is optional, I don't see it as a big concern and it is useful functionality. 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. > > 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? > Well, I was thinking of the case of an MPLS tunnel, where traffic inside might be IPv4 or IPv6 or something else. If it is an IP packet, then the ICMP packet is either IPv4 or IPv6 based on the type of the encapsulated packet. The same MPLS LSP can be carrying both & the next-hop info would be of only one type. In that case, the IP addresses can either not be included for version mismatches or we could go back to having an IPv4 address flag and an IPv6 address flag and have the next-hop info get the last interface role value. Alia > 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
