Vince,
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.
OK.
(Maybe this should be said somewhere in the draft. Or maybe it already is and I
just missed it...)
"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).
OK. Lets focus on the general issue, not the specific MTU problem.
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.
Yes, and this is good. But FWIW -- and maybe this is one reason why the issue
has been unclear to me -- Section 4.2 seemed to talk about this only in the
context of aggregate prefixes and their holes. And it does talk about only
ETRs, not ALT routers. Would it be possible to add something from your above
description to the text?
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.
This may well be so. And I agree that additional machinery might not be helpful.
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.
I think I understand the situation now better, thanks for the explanation. I
don't think we need to specify a way to send ICMP messages, but I still think
it would be reasonable to explain the situation to the reader. Here's a second
try for new text:
"Given that packets delivered through ALT have an RLOC source address and an EID
destination address, returning an ICMP error may not be possible. As described in Section
4.2., the reception of a packet that has no destination in ALT can be treated by ETRs or
even the ALT routers by sending a negative Map-Reply. It is expected that MTU problems
are handled as a part of GRE tunnels. Other problems can only occur through
misconfiguration or other serious problems with the ALT network. The ALT design treats
the remaining cases as packet loss. The sender of a Map-Request may retry sending a
message, and failing again, will eventually time out. This leads to treating the
destination as not reachable through LISP, which is is the the best or only course of
action that can be performed under such circumstances."
Comments? Feel free to propose your own text. But I'd like to have something in
the draft about this, and this is the only thing preventing the draft going to
Last Call...
Jari
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
