https://www.iana.org/assignments/rpl-routing-metric-constraint/rpl-routing-metric-constraint.xhtml
Looks like the registry of metric type numbers is defined specifically for
RPL. Thomas' argument probably stands even if we just refer to the
registry. I'd say remove it. Define our own numbers like RPL did. And the
only one so far is hopcount.
Kind regards,
Vicky.
On 7 Apr 2016 14:53, "Victoria Mercieca" <vmercieca0@xxxxxxxxx> wrote:
Super quick resolution idea to the 6551 issue, can we refer to the iana
registry itself? Simple simple text change. No more 6551 argument but still
reference the type values?
On 7 Apr 2016 2:38 pm, "Charlie Perkins" <charles.perkins@xxxxxxxxxxxxx>
wrote:
Hello Stan,
I admit to being slightly unclear on what you are requesting. Do you
mean that I should provide text for citing a new registry for metrics? Is
there anything else at issue?
Would someone allow me to be lazy and provide to me a pointer to any
relevant OLSR text?
Regards,
Charlie P.
On 4/7/2016 10:24 AM, Ratliff, Stanley wrote:
Sent from my iPhone
On Apr 7, 2016, at 2:22 PM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:Then make a proposal. Suggest what should happen if we can't take the
Hello Stan,
I am not advocating a long drawn out discussion, since I think the
current text is O.K. Even if we don't cite RFC 6551 we could simply ask
IANA for yet another metric table. I could write that text in minutes.
32-bits for a metric is terrible. I really don't understand why we so
often have to stoop to the lowest common denominator.
cheap way out, and reference RFC6551.
Stan
Regards,
Charlie P.This electronic message and any files transmitted with it contains
On 4/7/2016 10:16 AM, Ratliff, Stanley wrote:
Charlie,
If Alvaro knows all the Roll vs. non- roll issues, and approves, then
I'm ok. If not, we'll need to craft new text.
If new text is needed, I'm voting for a single metric, 32-bits,
carried by the TLV originally created for OLSR. Now is NOT the time for a
long, drawn-out discussion on multiple metrics, and how they are handled.
Remember, we want to wrap this up in April.
Stan
Sent from my iPhone
On Apr 7, 2016, at 2:10 PM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx<mailto:charles.perkins@xxxxxxxxxxxxx>>
wrote:
Hello Vicky,
First, I would of course be delighted to include TDPB as a useful
metric for AODV, but I don't propose to insert any delay for the current
draft.
My interest in using an existing metric table was to avoid having
multiple registries. Looking at the table in RFC 6551, it says:
6.1. Routing Metric/Constraint Type
IANA has created a sub-registry, called "Routing Metric/Constraint
Type", for Routing Metric/Constraint object types, which range
from 0
to 255. Value 0 is unassigned.
Value Meaning Reference
1 Node State and Attribute This document
2 Node Energy This document
3 Hop Count This document
4 Link Throughput This document
5 Link Latency This document
6 Link Quality Level This document
7 Link ETX This document
8 Link Color This document
*None* of these are inherently specific to [roll]. However, I think
that some of them are not specified very well -- see below. IANA is not
requested to make the table specific to [roll].
The quoted passage:
Low-Power and Lossy Networks (LLNs) have unique characteristics
compared with traditional wired and ad hoc networks that require
the
specification of new routing metrics and constraints.
does not say that the routing metrics are specific to [roll]. In the
context of the document as I understand it, the passage means that new
metrics are needed because measuring traditional values often fails to
capture performance details that are more important for wireless.
For instance TDPB makes very much more sense for wireless than it does
for Ethernet.
By the way, the computation in RFC 6551 for ETX is highly suspect in
my opinion. I have another document that is based on the corresponding
IEEE Layer 2 routing specification; in my opinion it does much better.
One
problem with ETX as stated is that it degenerates to hop count in many,
many situations.
Regards,
Charlie P.
On 4/7/2016 8:44 AM, Victoria Mercieca wrote:
I completely agree that we want to allow different metric types but I
think this is still achievable if we reuse the Olsr metric TLV, since we
can use the extension type field exactly as we intended to do for our own
metric tlv.
I also think it's a good idea to reuse existing type number
allocations, but the text from rfc6551 which Thomas quoted seemed to say
"these metric types don't apply to ad hoc networks" which is a bit of a
conflict. Thanks for asking advice, I think it's a brilliant way of
settling that issue.
I do remember looking at your draft but admittedly it was a while ago,
apologies for not giving feedback at the time. I'll try to take another
look soon. Is there any reason it shouldn't be in the AODVv2 draft
alongside hop count?
Kinds regards,
Vicky.
On 7 Apr 2016 12:31, "Charlie Perkins" <charles.perkins@xxxxxxxxxxxxx
<mailto:charles.perkins@xxxxxxxxxxxxx>> wrote:
Hello Vicky,
We need a table of metrics, and I don't agree to remove the citation
for it.
Do you disagree with having different types of metrics?
Did you have a look at the <very short> TDPB metric?
Regards,
Charlie P.
On 4/7/2016 8:28 AM, Victoria Mercieca wrote:
Hi Lotte,
In regards to the reference to the roll rfc, let's remove it if we
didn't already.
In regards to the OLSRv2 metric TLV, I just had a quick read, it seems
it uses 2 octets. 4 bits to represent whether it's an incoming/outgoing
link/neighbor metric, 4 bits to give exponent and 8 bits for mantissa,
allowing representation of minimum 1 and maximum 2^24-256. If we were to
use it, those 4 bits to indicate incoming or outgoing could be useful in
future, but can we interpret those bits as an accumulated route metric
(the
options define only link/neighbor) or will we get told off? Also <
http://www.iana.org/assignments/manet-parameters/manet-parameters.xhtml#link-metric-address-block-tlv-type-extension>
http://www.iana.org/assignments/manet-parameters/manet-parameters.xhtml#link-metric-address-block-tlv-type-extension
says about type extensions, looks like we could continue to use these to
identify MetricType (whether it's hop count/other).
I'd be in favour of reusing this. I don't remember discussing this
before....can anyone sum that up?
Also recent discussions have suggested a 32 bit metric value length as
a standard length for representing metrics. Or having the length dependent
on metric type. We need to agree (if we at least suggest something in the
draft and get told to change it that's ok too...if we use the OLSRv2 TLV
it
may be found more acceptable?)
Also just to mention Justin's comment from the metric section in this
email, should we define a maximum link cost allowable (as well as the
maximum allowable route cost we already define for each MetricType)? It
would allow exclusion of really poor links. But what if the only possible
route would need to use that link? Maybe it could be configurable whether
to enforce a maximum link cost... not sure where I stand on that one, I
think I would probably prefer not to have a max link cost.
Was there any other point to cover for metrics?
Kind regards,
Vicky.
On 7 Apr 2016 11:41, "Lotte Steenbrink" <lotte.steenbrink@xxxxxxxxxxxx
<mailto:lotte.steenbrink@xxxxxxxxxxxx>> wrote:
*bump*
anyone remember the metrics discussion? please? we’ve got to come up
with an answer, folks...
Am 19.03.2016 um 12:41 schrieb Lotte Steenbrink <
lotte.steenbrink@xxxxxxxxxxxx<mailto:lotte.steenbrink@xxxxxxxxxxxx>>:
Hi all,
I’ve replied to Thomas where I could, but some points need to be
addressed by someone else (or discussed here and then addressed).
I’m on his side regarding the Metrics thing because I’ve been a fan of
OLSRv2’s metric notation when I finally understood what it was all about
(thanks to Henning), but I think we had a discussion that brought up some
very good points why it’s just not that simple for AODVv2. Unfortunately I
can’t remember them! :( Does anyone else?
Regards,
Lotte
Anfang der weitergeleiteten Nachricht:
Von: Lotte Steenbrink <<mailto:lotte.steenbrink@xxxxxxxxxxxx>
lotte.steenbrink@xxxxxxxxxxxx<mailto:lotte.steenbrink@xxxxxxxxxxxx>>
Betreff: Aw: [manet] draft-ietf-manet-aodvv2-13 review - a couple of
big ticket Items
Datum: 19. März 2016 um 12:34:39 MEZ
An: Thomas Heide Clausen <<mailto:ietf@xxxxxxxxxxxxxxxxx>
ietf@xxxxxxxxxxxxxxxxx<mailto:ietf@xxxxxxxxxxxxxxxxx>>
Kopie: Mobile Ad Hoc Networks mailing list <manet@xxxxxxxx<mailto:
manet@xxxxxxxx>>
Hi Thomas,
thank you for reviewing AODVv2 yet again :) Some answers below:
Am 17.03.2016 um 17:00 schrieb <mailto:ietf@xxxxxxxxxxxxxxxxx>
ietf@xxxxxxxxxxxxxxxxx<mailto:ietf@xxxxxxxxxxxxxxxxx>:
Dear all,
Apologies for not having gotten this done sooner - day-job leaving few
spare cycles.
I’ve previously offered reviews and comments, and some of those have
been addressed in the latest I-D — others have not, but should be. I
recall
that there was some mail attempting to rebut parts of the review, and I
will dig it out and reply to that.
That wold be great.
With that being said, I have reviewed the latest version of the
document, and full details will be forthcoming. There’re a couple of
big-ticket/architectural items that I want to address up front, as I
believe that before we have those hammered out, it will be useless to go
into details. Note, I do not claim that this is an exhaustive list of “big
ticket items”, but that’s as far as I have gotten in thinking this
through.
I also bring these up as they are items that have been brought up
repeatedly over the past years, but not resolved nor discussed.
Loops
Just to bring this out: I share Chris’ worry about conflicting and
concurrent statements from the authors on “There are no loops possible”
and
“We need to fix two situations where loops can occur” and “we are still
investigating some loop conditions”
I particularly worry that this is not a discussion had in public, but
apparently in some other forum…
Intermediate Route Replies, and all of section 10
Section 10 contains a set of “vaguely specified extensions”, which is
incoherent with the intended status indicated for this document.
Specifically, and this is not unrelated to the point about loops
above, intermediate RREPs (section 10.3) are a potential source for loops.
Expanding Ring Multicast (section 10.1) is not documented in a way
that can be implemented (and also, see “Forwarding-vs-regeneration” below,
it is in the present form of this protocol impossible), etc.
Forwarding-vs-regeneration
Recent exchanges on the list made me understand that protocol control
messages are *not* forwarded, but are consumed at each hop, then a new
message with (almost-but-not-quite) the same content is generated and
transmitted.
That’s what we’ve been trying to say all along! I’m really glad we’re
having this conversation.
I have thought some more on this (& read some of the exchanges on the
list on this topic by Chris, Ulrich, and others), and I am convinced that
this is not the right way to go, at least for the following reasons:
o It renders the hop-limit/hop-count fields in the RFC5444 message
header useless.
This would not be bad if the functionality offered by those fields was
not useful
— sadly, it is. For example, for scope limited flooding (expanding
ring search, and
such) which may be of interest, and which require hop-limit.
A hop-count field may also provide a “cheap” (in terms of overhead)
additional piece
of information to use conjunctively with a “real” metric.
I agree on the usefulness, which is why we were puzzled when we were
told we weren’t allowed to use those fields (or, rather, that we were
using
them wrong, but that the right way to use them doesn’t work for AODvv2). I
believe Vicky has written about this in more detail in previous
discussions, and we were/are looking forward to reading your answers...
The only practical solution would be to re-introduce these functions
by way of inserting a
MessageTLV — which (i) is not specified in this document, and (ii)
which would just
serve to render messages bigger than strictly needed.
Exactly; we’d really like to avoid this as well.
Scope limited flooding does seem to be a necessary requirement, if
for no
other reason than to prevent information from “circulating forever in
the network”.
AODVv2’s duplicated detection hopefully should take care of that.
Iirc, We interpreted your earlier E-Mails to (implicitly) mean that you
think we should rely on that, since you said we can’t use the
hop-limit/hop-count fields.
o It makes end-to-end authentication unnecessarily hard.
I think Chris called this out already, but it bears repeating: S
generates a message
(say, a RREQ), and includes an ICV calculated over the content of the
message.
For any recipient to be able to validate the ICV, the message has to
be exactly
the same — not just in content, but in structure — as what was
generated.
“Regenerating” rather than “forwarding” messages means, that the
intermediate
router “regenerating” the RREQ may chose a different structure (e.g.,
include TLVs
in a different order).
The proposal from <
https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00>
https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00
is to add constraints on (i) the set of elements to include in a
signature and (ii) the
order of these elements.
One problem with that approach is (i): if an extension adds a message
TLV, or an
Address TLV, to a message, then that will not be “covered” by the
proposed e2esec TLV.
Rather for *each* extension developed, an “updates e2esec” clause
needs to be done.
I’d say that this approach would be prone to errors — and add entropy
to the process
of designing protocol extensions. The alternative, a message being
generated by the
source and *forwarded* (as we do in OLSRv2, for example) would allow
ICV TLVs
(even, allow reuse of those specified for OLSRv2) for covering a
message and
extensions.
“But what about the metrics value which will change on each hop”, you
may say?
Fortunately, that is relatively easy to handle: simply zero out the
value of that TLV when
generating or verifying the ICV MessageTLV. And use Packet-TLVs for
hop-by-hop
authentication, if needed (but, see below).
o It prevents the use of more clever/advanced signature schemes/ICVs
Aggregate signature algorithms ( <
https://crypto.stanford.edu/%7Edabo/papers/aggsurvey.pdf>
https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf)
exist, and an interesting use-case can be found in also reactive
protocols, allowing verifying
not “just” the end points, but also the intermediaries (again, with
the appropriate “zero out”
discussed above, or something smarter).
Regeneration of messages, rather than forwarding, renders that
impossible (or, if used,
updating to <
https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00>
https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00)
There are other reasons, but the above are those that jump at me as
immediate show-stoppers.
I do honestly not see what possible benefit there is from
“regeneration” — but I see very clear inconveniences, and security is not
the least of these. Insisting on “regeneration” requires development of
“non-general workarounds” as pointed out above.
The possible benefit is that we need to accumulate & transport metric
values somehow, and we can’t do that without regenerating at least parts
of
the message.
If we’re missing a solution here, please share it with us.
Security Considerations
Just for context’s sake, did you review the security considerations in
draft-ietf-manet-aodvv2-13 or the ones proposed in the thread „AODVv2:
Security considerations update“?
This is an always thorny subject. When OLSRv2 was going through the
process we got a thorough education in how little we knew about security
from the SEC-ADs, and had to spend about a year or so developing RFC7183.
The bottom line is, that this protocol needs its “RFC7183 equivalent”,
either as part of the main document, or as an independent document.
currently, that is not the case.
A minima, looking at BCP72 and BCP107 — taking inspiration from
RFC7183 might be aw good idea, as that was the most recent that went
through the SEC AD. Regardless of how, however, a “mandatory to implement”
security mechanism most be specified (I think the right term was “MUST
implement, SHOULD use”), in sufficient detail to ensure interoperable
implementations.
As an example, both [RFC6130] and [RFC7181] set out that that:
On receiving a ... message, a router MUST first check if the
message is invalid for processing by this router
and then proceed to give a number of conditions that, each, will lead
to a rejection of the message as "badly formed and therefore invalid for
processing” — a list which RFC7183 then amended. That gave a “hook” for
RFC7183 for inserting “rejection”. Idem for message generation.
If I was to do RFC7181/RFC6130 today, I would include that directly
into the protocol specifications. It turned out to be more overhead (and
slow down publication anyways) to do it as separate documents.
Secondly, we need to be a lot more rigid in terms of what ICVs,
Timestamps, etc. are added/removed, and what that brings.
For example (with the assumption that messages are *forwarded* and
*not* regenerated), this could be one option:
o When a RREQ, RREP message is generated, add an ICV Message TLV,
which is calculated <this way>
…(take inspiration from RFC7183 here)
o When a RREQ, RREP message is transmitted (by the source, or
forwarded by an intermediary)
in an RFC5444 packet, an ICV Packet TLV is added to the packet, which
is calculated <this way> …
o When an RFC5444 packet is received, validate the ICV Packet TLV
<this way> and if the ICV doesn’t validate,
discard the contained messages.
o When receiving a RREQ/RREP (either as destination, or as an
intermediary), validate the ICV Message TLV
<this way> and if the ICV doesn’t validate, discard the message, do
not process, do not forward.
This is a different (and more flexible?) model than “just” transitive
trust and “just” end-to-end trust discussed previously, and is enabled by
the “forwarding” bit described previously.
Metrics
I have asked this numerous times, but have not gotten any answer so I
am escalating this again. Why is this document having a normative
reference
to RFC6551?
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
and D. Barthel, "Routing Metrics Used for Path
Calculation
in Low-Power and Lossy Networks", RFC 6551<
https://tools.ietf.org/html/rfc6551>, DOI 10.17487/
RFC6551<https://tools.ietf.org/html/rfc6551>, March
2012,
<http://www.rfc-editor.org/info/rfc6551>.
Unless I am mistaken, this is not the ROLL WG. And the abstract to
RFC6551 explicitly reads:
Low-Power and Lossy Networks (LLNs) have unique characteristics
compared with traditional wired and ad hoc networks that require
the
specification of new routing metrics and constraints.
Which explicitly is disclaiming that these metrics are not applicable
in ad hoc networks — and, I am wondering, what has changed since the
publication of RFC6551 to suddenly make these applicable?
I am also wondering if looking at (and, perhaps, using?) the same
metric type TLV type as in OLSRv2 is not a possibility?
Either way, referencing RFC6551 here is wrong.
RFC6621 (SMF) usage
As late as earlier this month, RFC6621 reared its head again on the
mailing list. I understand that the authors are set on using flooding
reduction as part of RREQ distribution. If that is the case, then this
protocol MUST specify that flooding reduction.
Saying “Use RFC6621” won’t work, for reasons Chris point out in an
email earlier to the list:
The network does not and fundamentally cannot offer multicast
suppression to AODVv2. This isn't a hard concept, but seems to keep having
to be said. AODVv2 messages are carried in 5444 packets, and those only
travel one hop. That doesn't allow for suppression. Furthermore AODVv2 is
creating new messages each hop. That needs AODVv2 specific handling.
And quoting an email from myself:
If protocol X relies on using a flooding operation, then it certainly
is protocol X's responsibility to specify the flooding operation (or, at
least, the requirements to the flooding operation ) for correct
functioning
of protocol X.
I’ve previously pointed out that RFC6621 requires some degree of
configuration (can’t just, for example, pick two different relay set
selection algorithms, as that may produce a disconnected flooding domain).
In other words, what the authors propose in <
https://tools.ietf.org/html/draft-perkins-manet-using-rfc6621-00>
https://tools.ietf.org/html/draft-perkins-manet-using-rfc6621-00 is
insufficient.
Multiple interfaces configured with the same address(es) - & RFC6621
I think that it has been established that the ability to use the same
address on multiple interfaces is a requirement. It’s not clear to me that
a single way of doing so has been proposed, nor that the “operating
conditions” are called out (for example, will it work if router A and
router B both have two interfaces, and that all 4 interfaces use the same
IP address?)
This is not entirely unrelated to flooding reduction and RFC6621. One
of the complexities is to get that just right: OLSRv2 - for example -
calculates Flooding-MPRs per interface, and RFC6130 is careful in how it
detects bidirectionality of links.
I have not worked out all the details of how this impacts this
protocol — but, it requires attention. Especially when wanting to be able
to say “…use RFC6621”, then the interface configuration constraints when
faced with multiple interfaces must be worked out.
Prefixes & Gateways
A question to my mind, and I am not sure I know how to answer that
from reading the draft since it is not discussed in section 9 (at least),
is: “What happens if I send a RREQ to a prefix” (i.e., a /<128 in IPv6)?
o If the whole prefix is part of the attached network set of a single
router,
then I expect to get a single RREP back, is that the case?
o If "half the prefix" is part of the attached network set of a
single router,
and the other half is part of the attached network set of another
single router,
then I expect two RREPs, is that the case?
o More generally, will I get a tree build through the network here?
AODVv2 currently doesn’t support RREQs for prefixes. I’ve already
added „If RteMsg is a RREQ, RteMsg.TargPrefixLen SHOULD equal address
length.“ to RteMsg.TargPrefixLen in section 4.6<
https://tools.ietf.org/html/draft-ietf-manet-aodvv2-13#section-4.6>.
Multicast Route Message Table in response to Justin’s comments, but I’ll
go
through the draft again and see where we need to state this more clearly.
Best regards,
Lotte Steenbrink
Section 9 (or, the whole spec) is also not explicit enough about
multiple "default gateways" — i.e., the external network being “the rest
of the Internet”, and there being multiple gateways to the Internet. I
understand how the RREQ gets to the gateway, and how the gateway
determines
if it should respond (the destination is not part of “the MANET prefix,
with which it is configured”).
But, if A is close to GW1, and B is close to GW2, but A and B being
far far apart (according to the metric used) within the MANET, then it
would be preferential for the route from A to B to go via
GW1-“the-Internet”-GW2?
Is this a supported configuration?
o If yes, how is it (seq# wise, I would expect some complications)
handled?
o If not, where is it stated that this configuration is not possible
with this protocol?
The applicability statement says:
AODVv2 is designed for stub or disconnected mobile ad hoc networks,
i.e., non-transit networks or those not connected to the internet.
AODVv2 can, however, be configured to perform gateway functions
when
attached to external networks, as discussed in Section 9<
https://tools.ietf.org/html/draft-ietf-manet-aodvv2-13#section-9>.
I believe that the scenario I describe is indeed a stub network (and
not a transit network)?
— — —
As I indicated, these are the big-picture issues that I have gotten
around to thinking about enough to write up. I’m not through working
through the document, but those were the ones that came to mind, and which
seem imperative to resolve.
Best,
Thomas
_______________________________________________
manet mailing list
<mailto:manet@xxxxxxxx>manet@xxxxxxxx<mailto:manet@xxxxxxxx>
<https://www.ietf.org/mailman/listinfo/manet>
https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@xxxxxxxx<mailto:manet@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/manet
_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the
individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this
in error, please delete it and immediately notify the sender.
_____________________________________________________
_____________________________________________________
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________
