Hi Charlie,
I've split your email to match the bits you replied to, and replied inline:
On Thu, Apr 30, 2015 at 7:42 PM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:
Hello Vicky,Address Block TLV?
<cut and pasted below>
I hope the above statements can be matched with the discussion below.
Regards,
Charlie P.
On 4/30/2015 7:20 AM, Victoria Mercieca wrote:
Hi all,
Still catching up on emails:
On Mon, Apr 27, 2015 at 9:07 PM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:
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.
So to sum up all recent emails on this:
PktSource should go in the AddressBlock since it is an IP address. If we
do this, we should change the PktSource TLV to be an AddressBlockTLV, and
use it to mark which address in AddressBlock is the PktSource. For now, we
leave all others unmarked, and let MANET complain at a later date (...and
maybe have to give in at some point in the future and put one extra TLV in
to apply to all other addresses except for PktSource, which signals that
they are unreachable addresses).
To duplicate from the other thread ("RFC5444 tables"), the changes this
involves are:
In the IANA section, we can remove PktSource from the Message TLV
section, define it as an address block TLV, Type 14 (TBD), Length 0
(because it wont need to contain a value) and reference back to section on
RERR messages.
In the RFC5444 section we'd move PktSource into the address block, and
in the address block TLV block, we'd have a section for PktSource, where we
associate the PktSource TLV, with no value or extension type.
In the RERR section, PktSource wont be a data element. I can update that
section to have PktSource added to the AddressList. The text will need a
bit of work in the generation/reception/regeneration sections.
Shall I go ahead and do this?
CP: Wouldn't the PktSource still be a data element even if it is an
unreachable addresses, unless a TLV is associated to signal that it is aundeliverable data packet SHOULD inhibit sending of new RERR packets for a
different type of address.
Looking at the other comments in this thread:
a RERR for the first one, but more are already coming through the network,
- 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.
I was thinking, what if a stream of packets was in progress, we send
and before the RERR reaches the sender, it's already sent many more packets
for the same destination... Do we resend the RERR for every packet we cant
deliver? Or should we try to notice its the same source and destination and
refrain from duplicating a RERR, at least for a certain length of time?
CP: I agree with you that sending an RERR upon reception of an
otherwise- When creating the RERR, MetricType might come from some type ofwe avoid wasting messages (first the one C sends to B, then the one B might
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.
Why dont we just multicast it anyway? By multicasting from the start,
send to A, then the one A might send to PktSource), and we KNOW that
PktSource will get it. And if our route isnt used by a router that
receives our RERR, it wont regenerate it, simple. It only goes as far as
it needs to.
Alternatively, Charlie's MAC address idea from the email about precursors
will work.
CP: Generally, the reason for not multicasting is to avoid bothering
Vicky.
