Hi all,
While going through the draft I've come up with a load of questions and
notes. Addressing these will make the draft more complete and resolve some
of the ambiguity which might affect an implementation.
I'm going to divide these into a number of emails so that it should be
easier to follow each discussion.
This email contains questions about sending a RERR for an undeliverable
packet (Section 9.3 in Version 9a, or Section 7.4 in Version 9b):
1. What happens if we get another packet with the same source and
destination - do we send a RERR every time?
2. When creating the RERR, MetricType might come from some type of
service value in the packet, but SeqNum and PrefixLength are unlikely to be
known (unless we can match it to an invalid route) - SeqNum doesn't look
optional though, should we include SeqNum zero? Will it be assumed to be
zero (unknown) if not included anyway? I've made SeqNumList optional for
now.
3. If we didn't include a MetricType, the receiver will assume it
relates to the default metric. Is this acceptable? We could end up deleting
the wrong route? Maybe we can't do any better if we can't work out what
MetricType we should have associated with the packet?
4. If we receive this RERR and there's no prefix length, we'll assume
prefix length is address length, i.e. one host is unreachable. If our route
is to the subnet that address is on, what should we do?
5. If we send the RERR to the next hop on our route to PktSource, how
can we be sure this is the route PktSource used to forward the packet? (See
also the email on precursors - the following scenario is duplicated in that
email in the context of precursors)
Consider:
source -----> A ---------> B ----------> C ----------> destination
| | ^
| | |
V V |
E --------> D -------------------------|
C's next hop to the source is B. When C receives a packet from source which
it cannot forward to destination, C sends a RERR to B using the PktSource
data element.
However, the packet might have come via D - the source could be using the
route via EDC. If the RERR goes to B, B might regenerate it to A (or it
might not be regenerated at all), then A might regenerate it to source (or
not regenerate at all), and if it reaches the source, the source will say
"thats not my next hop, I don't care" and ignore it. It will carry on
sending packets via E and D, and C will again say "I've got no route, send
a RERR to PktSource" (and the same thing happens again).
Either way, just because C's next hop to PktSource is B, doesnt necessarily
mean that PktSource used the route via B and C to reach the destination. If
the RERR goes back a different way to the route PktSource is using, it will
get ignored, if not at an intermediate node, it will get ignored by source.
Comments welcome :-)
Kind regards,
Vicky.
