On Mon, Nov 30, 2015 at 02:53:46PM -1000, Nicholas Bastin wrote:
> On Sun, Nov 29, 2015 at 9:38 AM, Ben Pfaff <[email protected]> wrote:
>
> > I've filed a bug report EXT-559 with the ONF working group, so perhaps
> > we can at least get "invalid TTL" defined for OF1.6.
>
> My $0.02 - this shouldn't be in the spec at all. It's a wart that a given
> packet field gets special handling, although I realize this at least
> partially reflects some existing ASIC realities.
>
> The "right" way, I think, to deal with this would be to permit matching on
> TTL and then executing the user instructions - then we don't get into a
> silly discussion over what is "invalid", the user/controller simply sets
> their intention. At the very least perhaps it can move into a table
> config, but I *definitely* don't want the spec written to say that packets
> with TTL==(0|1) having some specific handling, when there's no
> one-size-fits-all answer.
That's reasonable. I added that comment to the bug report I filed.
> > You probably can't, at least not in a wholly satisfactory way, without
> > > modifying the source to OVS, or inlining a function (linux tap interface
> > > driver, etc.) in the path on each port. What you really want to do is
> > get
> > > OVS to issue a packet-out of an ICMP Time Exceeded when an incoming
> > packet
> > > reaches a TTL of 0 within the pipeline (modulo the times when you
> > actually
> > > should send a Destination Unreachable reply), but this has all kinds of
> > > nasty edge cases.
> >
> > We're working to make this possible. What kinds of nasty edge cases do
> > you have in mind? I'd like to make everything as correct as possible,
> > obviously.
>
> Well, my first question would be what is "this" that you're working to make
> possible.. :-) If it's "traceroute", that's a tricky mess, because of
> course traceroute is just a tool that relies on a side-effect of another
> protocol. As there's no actual traceroute protocol, you can't classify
> packets as belonging to traceroute, and thus if you "only" implement the
> bits that make traceroute work, you're likely to break a lot of other
> things that experience half-implemented IP error handling (traceroute works
> but PMTU-D doesn't? That's going to confuse some hosts. There are more
> things along these lines.)
>
> If the answer is "match TTL=0 (or X) packets and send them to the
> controller", that's the easiest solution from the datapath standpoint as it
> just punts the responsibility to the controller. Even in a perfect world
> this will result in the timing information presented by the traceroute tool
> to be even more useless than it already is given the extra RTT and
> encapsulation/decapsulation time. If you were to try to handle this within
> the datapath without going to the controller, the configuration gets a bit
> out of hand (you need at the very least one MAC, and you need to have an IP
> you're at least pretending to be, and if you have more than one of each now
> you need some way to figure out which one you actually use in a given
> circumstance, and you need to handle a traceroute actually ending at your
> own IP, and don't look now but you're halfway to making a router.. :-))
> Similarly you need to identify when MPLS ICMP extensions apply (RFC 4950,
> I think), and whether you want to enable supporting traceroute using IP
> options (although I think it was later deprecated due to lack of
> deployment). There are actually more complications (fragmentation, as
> always, etc.), but I'm mostly writing this off the top of my head... I'm
> happy to be more thorough when I know more specifically what you're
> actually trying to enable.
I guess I need to step back a bit. So far, with OVN, we're planning to
implement:
- TTL exceeded handling via ICMP. I believe that this is the
primary requirement for "traceroute" to succeed.
- Replies to ICMP echo requests, for packets directed to an L3
logical router IP.
- UDP port unreachable, TCP reset, and protocol unreachable replies,
for packets directed to an L3 logical router IP.
- Network unreachable replies, for packets for which an L3 logical
router has no route.
I don't need much guidance on the implementation mechanisms for these;
I'm comfortable with how to do it. I'm really looking for advice of the
form "You're forgetting about <important message>." Your information
about MPLS extensions to ICMP, for example, is interesting and new to
me, although I'm not sure whether it's relevant given that OVN doesn't
yet have anything to do with MPLS.
PMTU is a good point. We don't have a good story around MTU issues yet.
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss
