Re: [lisp] Design discussion -06-(1) -> DF=1

[Sam Hartman <[e-mail]>]

>>>>> "Dino" == Dino Farinacci <[e-mail]> writes:

    Dino> A description of the design issue: (1) Use stronger language
    Dino> to have the outer IPv4 header set DF=1 so we can avoid
    Dino> fragment reassembly in an ETR or PETR.  This will also make
    Dino> IPv4 and IPv6 encapsulation have consistent behavior.

    Dino> Right now the spec does not recommend a preference on the DF
    Dino> setting of an outer IPv4 header. If a LISP encapsulator (a ITR
    Dino> or PITR/PTR) sets DF=0 an intermediate router could fragment
    Dino> the packet to the tunnel destination endpoint. That would be a
    Dino> ETR or PETR. We don't want to force ETRs and PETRs to
    Dino> reassemble packets if we can be practical. We want Path MTU
    Dino> discovery to be used on the path.

I support recomminding/requiring the DF bit be set in the V4 header.

Based on our discussion of deployment model I think that we're really
going to have to take a look at PMTU issues.  I think this
recommendation will be consistent with our eventual results in this
space, but I don't think it will get us all the way there.


Fred and others have implied that PMTU discovery depends on getting ICMP
packet too big messages.  I'd like to remind people that the current
standards-track state of the art in this area (RFC 4821) actually deals
with lost ICMP messages.  The current LISP architecture is not rich
enough to support RFC 4821 between the ITR and ETR because it does not
have the right kind of probe packet support, although that would be a
relatively easy enhancement.

I'm surprised to find that RFC 5405 (particularly section 3.2) gives us
very little guidance in this area.