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 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 <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 <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 schriebietf@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
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/~dabo/papers/aggsurvey.pdf
<https://crypto.stanford.edu/%7Edabo/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)
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:
oWhen a RREQ, RREP message is generated, add an ICV Message
TLV, which is calculated <this way>
…(take inspiration from RFC7183 here)
oWhen 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> …
oWhen an RFC5444 packet is received, validate the ICV Packet
TLV <this way> and if the ICV doesn’t validate,
discard the contained messages.
oWhen 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 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)?
oIf 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?
oIf "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?
oMore 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?
oIf yes, how is it (seq# wise, I would expect some
complications) handled?
oIf 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 inSection 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
manet@xxxxxxxx <mailto:manet@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@xxxxxxxx <mailto:manet@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/manet
