Hello Lotte,
If there are addresses in the RERR and they aren't otherwise marked,
they should certainly be Unreachable addresses. I don't see why not.
Would you require the same for every other sort of TLV that might be
applied to addresses, in addition to SeqNum?
This would be an unmitigated disaster.
I'd rather prohibit SeqNum for all RERR messages and forget about the
small improvement in correctness, than require SeqNum for all RERR
messages.
Regards,
Charlie P.
On 4/17/2015 4:37 AM, Lotte Steenbrink wrote:
Hi Charlie, hi all,
Am 17.04.2015 um 00:41 schrieb Charlie Perkins <charles.perkins@xxxxxxxxxxxxx <mailto:charles.perkins@xxxxxxxxxxxxx>>:
Hello Vicky,
On 4/16/2015 7:02 AM, Victoria Mercieca wrote:
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):
* What happens if we get another packet with the same source and
destination - do we send a RERR every time?
That would mean that the previous RERR didn't "work", so maybe it's a good idea to
allow RERR to go out again.
* 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.
Yes, definitely SeqNum should be optional.
If SeqNum is optional, I'd urge us to add a rule in the “RFC 5444 Representation” section that says “if there is no SeqNum associated with an address, add a SeqNum Address TLV with the value 0” or something.
Otherwise, if all TLVs attached to the addresses are optional, we have *the same problem* that we have with our orphaned TargNodeAddresses– In case of any extension, we will have no way of determining what these Addresses are all about.
* 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?
I don't think we can do any better with the existing protocol.
QoS routing is NP hard, by the way.
* 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?
That operation is explained in the text... since route table entries are longest-match,
you can create an invalid route to the single host and you will be O.K. to still reach the
other hosts on the subnet prefix.
* 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.
I have not heard of this being a problem. However, if it needs to be prevented,
we could say that the second RERR from missing route to a destination should
be multicast.
Regards,
Charlie P.
