Hi Charlie,
Am 27.04.2015 um 22:07 schrieb Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>:
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>:
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.
