> I'm looking at the Map-Request message format and cannot quite convince
> myself that there would never be a situation where MTU would be exceeded.
> 99.999% of the time it would be fine, but I think we need to describe (if
> not fix) what happens when its not. How about adding the following item to
> the Section 1 experimental list:
I don't really understand how MTU could be an issue here. If there is an
MTU restriction, fragmentation would occur upon entry into an ALT GRE
tunnel and reassembly would be done when the ALT datagram is received by
an ETR.
> "o effects of limited possibilities for returning an ICMP message from ALT"
It is certainly possible for an intermediate ALT router to be unable to
forward an ALT Datagram for some other reason, such as there being no
matching next hop (i.e. the destination is not an EID and therefore is not
reachable via the ALT). In such cases, the ALT router which cannot forward
the datagram would drop it. Section 4.2 describes what an ETR can do if
it receives an ALT datagram destined for a non-EID: it returns a negative
Map-Reply. An ALT router that understands LISP (i.e. a Map Server or Map
Resolver connected to ALT) could similarly send a negative Map-Reply if
it cannot forward a Map-Request over the ALT.
An ALT router could attempt to return an ICMP message to the RLOC source
in a Map-Request received over the ALT. Whether that ICMP message would
be received by the Map-Request source (ITR) would depend on whether the
ALT router has legacy Internet connectivity in addition to being on the
ALT virtual network. The current Cisco LISP implementations do not attempt
to return ICMP messages when a failure occurs forwarding on the ALT VRF.
If an ITR were to send a Map-Request into the ALT that cannot be delivered
over the ALT due to some IP-layer problem, it may very well not receive
any positive failure indication. Since such a scenario could only arise
through misconfiguration or another serious problem on the ALT network,
having an ITR treat the destination as non-LISP-reachable is, in my opinion,
the right thing to do, so I don't see a need for additional machinery.
> and this text somewhere:
>
> "Given that packets delivered through ALT have an RLOC source address and
> an EID destination address, returning an ICMP error may not always be
> possible. Since Map-Request messages are typically small, it is unlikely
> that an MTU violation will occur for a Map-Request forwarded on the ALT and
> if it did, it may be possible to deal with it through fragmentation of GRE
> packets. But in the unlikely event of having to generate an ICMP error due
> to MTU or other problems, an ALT node MAY attempt to deliver the error to
> the source RLOC outside ALT. If it turns out to be not possible to deliver
> the ICMP error, the sender of the Map-Request message will retry, and
> failing again, will time out.This could lead to considering the dstination
> not LISP-capable. Note that ICMP errors are more likely with Data Probes,
> and may lead to the unreported loss of the encapsulated data packet."
If you feel it is important enough, we can certainly add text of this sort
stating that an ALT router may attempt to return an ICMP message if it cannot
forward an ALT Datagram. None of the authors think that this is really
necessary.
--Vince
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
