Subject: [icnrg] Review comments on draft-mendes-icnrg-dabber-04

From: "David R. Oran" <[email-masked]>
Date: Mon, 13 Apr 2020 11:04:57 -0400

Before getting to my review, one comment with **<Chair hat>**.

This seems novel and interesting ICN research deserving of more 
visibility, review, and hopefully publication through the IRTF. However, 
it’s gotten very little visibility and even less review in ICNRG, so 
as chair I need to ask - does this have enough interest to warrant 
adoption as an ICNRG draft, or should we encourage the authors to pursue 
other publication options (perhaps as an individual contribution). 
Unless we get more reviews and input encouraging adoption, it’s hard 
to ask the authors to continue to revise the work leaving it in limbo. 
PLEASE review this and send comments and indications of whether you 
support adopting this as ICNRG work.

**</Chair hat>**

The remainder of this review message is with **<Chair Hat Off>**

##General Comments##

- There are a lot of typos and English language usage problems, so the 
draft needs some editorial work. I’ve attached a marked up version 
with my suggested corrections, but I doubt I caught everything, and in 
particular was less rigorous about marking corrections later in the 
draft, since many of the usage problems are of the same general nature 
throughout.

- There needs to be a terminology section, and more care taken to define 
terms and acronyms either before or at their first usage. Some examples 
include:
	- data consumer ID (DID?)
	- custodian ID
	- neighbor (see detailed comment below)
	- NFD (also mis-spelled as NDF) on page 16
	- ICDTN on page 19

- This may be obvious, but you really do need to have Figure 1, not a 
TBD.

- I am not enough of an expert of the dynamics and optimization 
properties of DTNs to have a confident review of the material on 
node/social contact optimization (section 5.1-5.3). I therefore don’t 
have much to say on this material - it could of course be perfect.

##Detailed Technical Comments##

- Some of the assumptions in section 1.2 are not actually assumptions, 
as they are testable. For example, the statement “Selecting the best 
set of neighbors to replicate packets to, may not be efficient if based 
only on connectivity based information”. I also had a hard time 
figuring out why some things were considered assumptions and others 
requirements. It might be better to eliminate this distinction and 
instead articulate these as “design considerations”.

- Along the same line, why is it a requirement that “Routing 
information must be exchanged based on Interest / Data  messages”. 
That seems a design choice. It seems a good one, as it means you don’t 
have to resort to non NDN/CCNx machinery to create your routing 
protocol, but that doesn’t make it a requirement. A requirement would 
be something more like the statement further down that you can’t rely 
on the inverse path the Interest took to reach a producer/custodian to 
return data, as that path may no longer exist when you want to send the 
data back.

- The role of data consumer IDs and custodian IDs is not well explained 
at all in the introductory material. At least a forward reference to 
section 2.3 would help. I also had a hard time thinking clearly about 
their security properties, how easy they are to spoof (especially if 
interest messages are not signed), what the consequence of unintended 
value collisions were, etc. This whole part of the design needs to be 
explained in more detail, and early in the exposition. Where the terms 
are introduced (e.g. in section 1.2) a forward reference to the part of 
the spec that explains them would be particularly helpful.

- The nonce based scheme you explicitly rely on  (page 8) for loop 
detection has been definitively demonstrated to not work, and to fail 
spectacularly if you allow any in-network retransmissions (which I 
assume for a DTN-like architecture you’d want to have). CCNx has 
eliminated nonce-based loop detection entirely in version 1.0, and NDN 
has added hop counts as a mandatory backup for the cases where nonces 
fail to detect a loop. I suggest finding a better loop detection scheme 
- if hop counts don’t cut it perhaps something based on Brent’s 
algorithm (e.g. https://arxiv.org/abs/1612.04430) might be worth 
considering? Also, I don’t see how disabling a face producing loops 
helps unless you are getting zero forwarding utility through that face. 
The topology is likely to be sparse and you want to use any working face 
if possible.

- in section 2.2, you talk about DABBER querying about “neighbor” 
nodes. In the world of DTN with nebulous and changing topology, what 
exactly is your definition of a neighbor? Any node the current node has 
ever talked to directly (i.e. over one radio hop), any node on a L2 mesh 
that hides the internal topology from L3? Something else?

- (p.9) How does “application category” relate to the metrics that 
DABBER would actually use? Is this some name mapping function where by 
application category you actually mean “part of the global 
namespace”?

- how do you compute node degree in a fluid topology? Is it the number 
of nodes contacted in some time window? Usually node degree measures the 
number of neighbor nodes that can be **simultaneously** reached, not the 
number reachable over time. This may or may not not affect your 
computation of centrality, The other parameters used to compute 
centrality seem intuitively the right ones though.

- The term “node similarity” doesn’t seem to capture the actual 
metrics mentioned in this category; perhaps a better term would be 
“node connectivity quality”?

- page 11 top - you are a bit sloppy in talking about an OPPface being 
“connected” - since in NDN and CCNx there is no real notion of a 
face being connected, only a neighbor being available over a face. It 
isn’t clear to me why you need a special face at all, since a regular 
face queue could get blocked for a long time due to link errors or 
long-baseline link scheduling like you’d see with LoRa or other 
low-bandwidth systems. There are other interactions I’m pretty unclear 
on as well, such was whether interactions with Interest Lifetime get 
modified for OPPfaces or not. It also seems a bit weird to have a single 
face that has two different MTU values - that seems implied by the 
discussion, however I think you mean that these two transmission modes 
(TCP or Mac-layer WiFi direct) would actually be different OPPface 
instances. The latter seems cleaner, no?

- top of page 12 - I don’t see how the selection heuristic minimizes 
the number of WiFi Direct groups in a certain area. I’m obviously 
missing something about the way WiFi direct works, since I thought the 
number of groups was essentially undefined since there’s no protocol 
to compute transitive closure of the nodes, hence you don’t know how 
many “groups” there are, or even if the notion of a WiFi direct 
“group” is even meaningful in the context of DABBER.

- at the end of section 2.4.1,  you say “DABBER would need to encode 
in the Interest packet information about the ID of the neighbors that 
should process the overheard Interest packet.” Why is this any 
different from normal multi-path forwarding in NDN/CCNx? Do you want to 
suppress duplicate upstream forwarding of Interests by somehow telling 
which neighbor is intended to be the forwarder? If so, this is normally 
done by L2/L3 demultiplexing and not something ”extra” in an L3 
packet.

- question: you seem to say DTNFaces only handle Data packets, not 
Interest packets? Seems right, but more explanation would be helpful. In 
particular you don’t explicitly say whether OPPfaces never handle data 
packets, only Interest packets; is this the case?

- section 2.4.3: you need to say a few words about CMFace rather than 
TBD. Using a special face type (actually any face at all) for 
communicating with the Context manager is actually an internal 
implementation design decision, right? One could have just as easily 
made the Context manger an application and used the NDN/CCNx APIs for it 
to talk to the forwarder, right? If not, and a face is needed 
semantically, this would be the place to explain the design, how the FIB 
directs things here and how the state passes as Interest/Data exchanges 
over this face.

- in the first paragraph of section 3, you claim that by using “data 
reachability cost” as the metric rather than than path cost, you 
magically reduce the impact of topological changes on routing stability. 
Well, that’s true only if the “data reachability cost” doesn’t 
change when the topology changes, right? And if it doesn’t change 
based on that, exactly what does it change based on? This doesn’t seem 
to map obviously to the availability, centrality, and similarity metrics 
mentioned earlier. You need to connect the concepts better. It would 
also help to better explain why having the data reachability cost avoids 
local flooding. Do you only forward to the next hop with the cheapest 
data reachability metric? Why would that be different from filtering on 
any other metric?

- It isn’t completely clear whether you are using the older Chronosync 
or just the newer PSync, since you reference both. It doesn’t seem you 
need the full overhead of chronosync, as is seems PSync (or something 
with even weaker semantics) would not suffice. In any event, it would be 
useful to cite some newer work, for example 
https://named-data.net/wp-content/uploads/2019/01/li2018sync-intro.pdf.

- Are LSA Interests sent on OPPfaces or regular faces? Are the Data 
replies sent back using DTNfaces? Seems like this would not be good, as 
they are one-hop protocols. The other problem could be a lot of 
duplicate interests since the OPPface queueing might have many redundant 
requests queued since nowhere does the face queue know about or try to 
suppress duplicate packets.

- At the top of page 18, you say “The higher the values of C, A and S, 
the most preferential a neighbor is.” But this isn’t well defined as 
you don’t specify a partial or total order among the metrics. Is this 
some sort of linear regression equation (ala what EIGRP does with 
multiple metrics?) Something else?

- What is the consequence of different Dabber nodes using different NFD 
RIB update policies (as described on p.19)? It seems that if all nodes 
don’t choose the same policy, even a local loop suppression policy 
like Downward Path won’t suppress loops if some other node selects 
Increased Diversity.

- I may have missed this, but another fairly deep fundamental property 
of NDN/CCNx forwarding is that Data packets which arrive without 
matching an existing PIT entry should be preferentially discarded, and 
certainly not opportunistically forwarded further. The DTN scheme you 
use for DABBER seems to quite dramatically violate this principle. The 
NDN/CCNx treatment of arriving data packets clearly has to be relaxed to 
accommodate DTNs. Part of my confusion is the statement “making usage 
of information stored in the PIT” since if you don’t use paths to 
nodes without an active PIT entry, you can in fact only use symmetric 
routes. There’s a lot of detail on page 23, which deals with the 
forwarding precedence, but not the (harder?) problem of how to manage 
the CS of one of these nodes opportunistically keeping Data packets for 
which there is no corresponding PIT entry.

- Section 8, beginning, you blithely state “ensuring the needed levels 
of confidentiality”. What in fact are the needed levels of 
confidentiality? I also suspect that a blanket statement like 
“Moreover, DABBER ensures the right level of privacy of the involved 
entities, who provide local information to support routing decisions.” 
might raise hackles. Local information distribution almost inevitably 
leaks, and you don’t really address the level of transitive trust that 
you are assuming for these local environments. Some of this is covered 
in section 8.1, so perhaps fewer words in the introduction, or explicit 
forward reference would keep the reader calm about the assertions.

- There seems to be a bit of circular logic in section 8.1 around the 
fetching of keys. You need a certain amount of routing information to 
support the fetching of keys from more than one hop away, yet the 
authenticity of the routing information in turn depends on your 
believing the keys. I suspect there is some invariant that ensures the 
scope of key storage is deterministically more localized than the 
routing information it secures, but it isn’t entirely clear that the 
key hierarchy by itself guarantees this.

##Nits##

- Need a reference for “Epidemic Routing” on p5
- in the first paragraph of section 2, I think OPPFace and DTNFace are 
face *types*, not faces. Also, forward reference to where these are 
actually defined and used would help.
- On page 9, in the paragraph on contextual awareness, you talk about a 
user’s “interests”, which is normally a fine term to use, but in 
this context, it has the obvious potential to be confusing. I suggest 
changing the sentence to “…the user configures any desired types of 
information or other types of personal preferences.”
- top of page 9, you say you only need one OPPface per device - but I 
don’t think this is true for a device with multiple radios, right? 
It’s one OPPface per radio operating in broadcast mode, plus one for 
each radio (or wired connection) operating in point-to-point mode. Yes?
- You don’t seem to specify the size/range of the LSA version. Is it 
modular or monotonic? Maximum value?
- I thought Chronosync and Psync use Bloom filters to find the diffs. 
The description on pp 14/15 seems to imply otherwise.
- Validity seems to be done via a separate Validity timer rather than 
relying on Data Expiry of the Itnerest/Data exchange. Is this because 
the individual LSAs are packaged together with multiple name prefixes to 
each prefix might be different expiry? In any event, the expire ought to 
be the MIN(LSA Data message expiry, Prefix expiry).
- You say “The routing table is then ordered by name prefix in 
decreased order of validity.” Why? This only matters when computing 
the FIB or deciding which LSAs (if any) to filter). Seems unnecessary 
overhead to keep the RIB sorted.
- In your example on page 20, you don’t say if the validity is in fact 
the Data Expiry value of the Data object in the Content store. I would 
hope it is, since if you make a separate validity value you can either 
continue to announce data that has expired, or black hole data that is 
still useful from the data producer’s standpoint. If the LSA covers a 
prefix with data objects of wildly different expirations, then I suspect 
the application needs to be rethought, or at least the structure of its 
namespace rethought.
- On page 21, you say “Independently of the used forwarding strategy, 
it has to respect the ranking of faces done by DABBER on the RIB.” 
This seems to imply that forwarding has to look at the RIB, which I 
don’t think is what you mean. I assume what you mean is that the FIB 
has to correctly reflect the ordering of the RIB with appropriate 
filters and face eligibility/precedence. In any event this doesn’t 
seem to be the right place in the exposition to be saying this.
- in section 7.1, you say “However, when DABBER is executing the LSA 
dissemination procedure over a Wi-Fi face, towards an edge router it 
will ignore all notifications that Chronosync will send related to 
Adjacency LSAs. Why? A few more words here would be helpful.

[End of Comments]

DaveO

---

From: "Milheiro Mendes, Paulo Jorge" <[email-masked]>
Date: Mon, 20 Apr 2020 11:25:15 +0200

Hi David,

First of all, thank you for the extended review and valuable feedback. We
will take all your comments into consideration aiming to improve the draft.
We will also consider any other comments coming, in the meantime, from the
ICNRG community.

@ICNRG community: I would like to ask the ICNRG community to send comments
and indications about their support to adopt DABBER as an ICNRG work item.
Such comments will allow us to improve the protocol spec while preparing
its implementation. It is our opinion that the ICNRG would benefit by
having a working item that aims to support the development of ICN-based
wireless adhoc networks: this is the intention of DABBER.

Regards
Paulo

On Mon, Apr 13, 2020 at 5:05 PM David R. Oran <[email-masked]> wrote:

> Before getting to my review, one comment with *<Chair hat>*.
>
> it’s gotten very little visibility and even less review in ICNRG, so as
> chair I need to ask - does this have enough interest to warrant adoption as
> an ICNRG draft, or should we encourage the authors to pursue other
> publication options (perhaps as an individual contribution). Unless we get
> more reviews and input encouraging adoption, it’s hard to ask the authors
> to continue to revise the work leaving it in limbo. PLEASE review this and
> send comments and indications of whether you support adopting this as ICNRG
> work.
>
> *</Chair hat>*
>
> The remainder of this review message is with *<Chair Hat Off>*
> General Comments
>
>    -
>
>    There are a lot of typos and English language usage problems, so the
>    draft needs some editorial work. I’ve attached a marked up version with my
>    suggested corrections, but I doubt I caught everything, and in particular
>    was less rigorous about marking corrections later in the draft, since many
>    of the usage problems are of the same general nature throughout.
>    -
>
>    There needs to be a terminology section, and more care taken to define
>    -
>    This may be obvious, but you really do need to have Figure 1, not a
>    TBD.
>    -
>
>    I am not enough of an expert of the dynamics and optimization
>    node/social contact optimization (section 5.1-5.3). I therefore don’t have
>    much to say on this material - it could of course be perfect.
>
> Detailed Technical Comments
>
>    -
>
>    Some of the assumptions in section 1.2 are not actually assumptions,
>    as they are testable. For example, the statement “Selecting the best set of
>    neighbors to replicate packets to, may not be efficient if based only on
>    connectivity based information”. I also had a hard time figuring out why
>    some things were considered assumptions and others requirements. It might
>    be better to eliminate this distinction and instead articulate these as
>    “design considerations”.
>    -
>
>    Along the same line, why is it a requirement that “Routing information
>    must be exchanged based on Interest / Data messages”. That seems a design
>    choice. It seems a good one, as it means you don’t have to resort to non
>    NDN/CCNx machinery to create your routing protocol, but that doesn’t make
>    it a requirement. A requirement would be something more like the statement
>    further down that you can’t rely on the inverse path the Interest took to
>    reach a producer/custodian to return data, as that path may no longer exist
>    when you want to send the data back.
>    -
>
>    The role of data consumer IDs and custodian IDs is not well explained
>    section 2.3 would help. I also had a hard time thinking clearly about their
>    security properties, how easy they are to spoof (especially if interest
>    messages are not signed), what the consequence of unintended value
>    collisions were, etc. This whole part of the design needs to be explained
>    in more detail, and early in the exposition. Where the terms are introduced
>    (e.g. in section 1.2) a forward reference to the part of the spec that
>    explains them would be particularly helpful.
>    -
>
>    The nonce based scheme you explicitly rely on (page 8) for loop
>    spectacularly if you allow any in-network retransmissions (which I assume
>    for a DTN-like architecture you’d want to have). CCNx has eliminated
>    nonce-based loop detection entirely in version 1.0, and NDN has added hop
>    counts as a mandatory backup for the cases where nonces fail to detect a
>    loop. I suggest finding a better loop detection scheme - if hop counts
>    don’t cut it perhaps something based on Brent’s algorithm (e.g.
>    https://arxiv.org/abs/1612.04430) might be worth considering? Also, I
>    don’t see how disabling a face producing loops helps unless you are getting
>    zero forwarding utility through that face. The topology is likely to be
>    sparse and you want to use any working face if possible.
>    -
>
>    in section 2.2, you talk about DABBER querying about “neighbor” nodes.
>    In the world of DTN with nebulous and changing topology, what exactly is
>    your definition of a neighbor? Any node the current node has ever talked to
>    directly (i.e. over one radio hop), any node on a L2 mesh that hides the
>    internal topology from L3? Something else?
>    -
>
>    (p.9) How does “application category” relate to the metrics that
>    application category you actually mean “part of the global namespace”?
>    -
>
>    how do you compute node degree in a fluid topology? Is it the number
>    number of neighbor nodes that can be *simultaneously* reached, not the
>    number reachable over time. This may or may not not affect your computation
>    of centrality, The other parameters used to compute centrality seem
>    intuitively the right ones though.
>    -
>
>    The term “node similarity” doesn’t seem to capture the actual metrics
>    mentioned in this category; perhaps a better term would be “node
>    connectivity quality”?
>    -
>
>    page 11 top - you are a bit sloppy in talking about an OPPface being
>    “connected” - since in NDN and CCNx there is no real notion of a face being
>    connected, only a neighbor being available over a face. It isn’t clear to
>    me why you need a special face at all, since a regular face queue could get
>    blocked for a long time due to link errors or long-baseline link scheduling
>    like you’d see with LoRa or other low-bandwidth systems. There are other
>    interactions I’m pretty unclear on as well, such was whether interactions
>    with Interest Lifetime get modified for OPPfaces or not. It also seems a
>    bit weird to have a single face that has two different MTU values - that
>    seems implied by the discussion, however I think you mean that these two
>    transmission modes (TCP or Mac-layer WiFi direct) would actually be
>    different OPPface instances. The latter seems cleaner, no?
>    -
>
>    top of page 12 - I don’t see how the selection heuristic minimizes the
>    number of WiFi Direct groups in a certain area. I’m obviously missing
>    something about the way WiFi direct works, since I thought the number of
>    groups was essentially undefined since there’s no protocol to compute
>    transitive closure of the nodes, hence you don’t know how many “groups”
>    there are, or even if the notion of a WiFi direct “group” is even
>    meaningful in the context of DABBER.
>    -
>
>    at the end of section 2.4.1, you say “DABBER would need to encode in
>    the Interest packet information about the ID of the neighbors that should
>    process the overheard Interest packet.” Why is this any different from
>    normal multi-path forwarding in NDN/CCNx? Do you want to suppress duplicate
>    upstream forwarding of Interests by somehow telling which neighbor is
>    intended to be the forwarder? If so, this is normally done by L2/L3
>    demultiplexing and not something ”extra” in an L3 packet.
>    -
>
>    question: you seem to say DTNFaces only handle Data packets, not
>    -
>    section 2.4.3: you need to say a few words about CMFace rather than
>    TBD. Using a special face type (actually any face at all) for communicating
>    with the Context manager is actually an internal implementation design
>    decision, right? One could have just as easily made the Context manger an
>    application and used the NDN/CCNx APIs for it to talk to the forwarder,
>    right? If not, and a face is needed semantically, this would be the place
>    to explain the design, how the FIB directs things here and how the state
>    passes as Interest/Data exchanges over this face.
>    -
>
>    in the first paragraph of section 3, you claim that by using “data
>    reachability cost” as the metric rather than than path cost, you magically
>    reduce the impact of topological changes on routing stability. Well, that’s
>    true only if the “data reachability cost” doesn’t change when the topology
>    changes, right? And if it doesn’t change based on that, exactly what does
>    it change based on? This doesn’t seem to map obviously to the availability,
>    centrality, and similarity metrics mentioned earlier. You need to connect
>    the concepts better. It would also help to better explain why having the
>    data reachability cost avoids local flooding. Do you only forward to the
>    next hop with the cheapest data reachability metric? Why would that be
>    different from filtering on any other metric?
>    -
>
>    It isn’t completely clear whether you are using the older Chronosync
>    or just the newer PSync, since you reference both. It doesn’t seem you need
>    the full overhead of chronosync, as is seems PSync (or something with even
>    weaker semantics) would not suffice. In any event, it would be useful to
>    cite some newer work, for example
>    -
>    Are LSA Interests sent on OPPfaces or regular faces? Are the Data
>    they are one-hop protocols. The other problem could be a lot of duplicate
>    interests since the OPPface queueing might have many redundant requests
>    queued since nowhere does the face queue know about or try to suppress
>    duplicate packets.
>    -
>
>    At the top of page 18, you say “The higher the values of C, A and S,
>    the most preferential a neighbor is.” But this isn’t well defined as you
>    don’t specify a partial or total order among the metrics. Is this some sort
>    of linear regression equation (ala what EIGRP does with multiple metrics?)
>    Something else?
>    -
>
>    What is the consequence of different Dabber nodes using different NFD
>    don’t choose the same policy, even a local loop suppression policy like
>    Downward Path won’t suppress loops if some other node selects Increased
>    Diversity.
>    -
>
>    I may have missed this, but another fairly deep fundamental property
>    of NDN/CCNx forwarding is that Data packets which arrive without matching
>    an existing PIT entry should be preferentially discarded, and certainly not
>    opportunistically forwarded further. The DTN scheme you use for DABBER
>    seems to quite dramatically violate this principle. The NDN/CCNx treatment
>    of arriving data packets clearly has to be relaxed to accommodate DTNs.
>    Part of my confusion is the statement “making usage of information stored
>    in the PIT” since if you don’t use paths to nodes without an active PIT
>    entry, you can in fact only use symmetric routes. There’s a lot of detail
>    on page 23, which deals with the forwarding precedence, but not the
>    (harder?) problem of how to manage the CS of one of these nodes
>    opportunistically keeping Data packets for which there is no corresponding
>    PIT entry.
>    -
>
>    Section 8, beginning, you blithely state “ensuring the needed levels
>    of confidentiality”. What in fact are the needed levels of confidentiality?
>    I also suspect that a blanket statement like “Moreover, DABBER ensures the
>    right level of privacy of the involved entities, who provide local
>    information to support routing decisions.” might raise hackles. Local
>    information distribution almost inevitably leaks, and you don’t really
>    address the level of transitive trust that you are assuming for these local
>    environments. Some of this is covered in section 8.1, so perhaps fewer
>    words in the introduction, or explicit forward reference would keep the
>    reader calm about the assertions.
>    -
>
>    There seems to be a bit of circular logic in section 8.1 around the
>    authenticity of the routing information in turn depends on your believing
>    the keys. I suspect there is some invariant that ensures the scope of key
>    storage is deterministically more localized than the routing information it
>    secures, but it isn’t entirely clear that the key hierarchy by itself
>    guarantees this.
>
> Nits
>
>    - On page 9, in the paragraph on contextual awareness, you talk about
>    a user’s “interests”, which is normally a fine term to use, but in this
>    context, it has the obvious potential to be confusing. I suggest changing
>    the sentence to “…the user configures any desired types of information or
>    other types of personal preferences.”
>    don’t think this is true for a device with multiple radios, right? It’s one
>    OPPface per radio operating in broadcast mode, plus one for each radio (or
>    wired connection) operating in point-to-point mode. Yes?
>    relying on Data Expiry of the Itnerest/Data exchange. Is this because the
>    individual LSAs are packaged together with multiple name prefixes to each
>    prefix might be different expiry? In any event, the expire ought to be the
>    MIN(LSA Data message expiry, Prefix expiry).
>    decreased order of validity.” Why? This only matters when computing the FIB
>    or deciding which LSAs (if any) to filter). Seems unnecessary overhead to
>    keep the RIB sorted.
>    the Data Expiry value of the Data object in the Content store. I would hope
>    it is, since if you make a separate validity value you can either continue
>    to announce data that has expired, or black hole data that is still useful
>    from the data producer’s standpoint. If the LSA covers a prefix with data
>    objects of wildly different expirations, then I suspect the application
>    needs to be rethought, or at least the structure of its namespace rethought.
>    it has to respect the ranking of faces done by DABBER on the RIB.” This
>    seems to imply that forwarding has to look at the RIB, which I don’t think
>    is what you mean. I assume what you mean is that the FIB has to correctly
>    reflect the ordering of the RIB with appropriate filters and face
>    eligibility/precedence. In any event this doesn’t seem to be the right
>    place in the exposition to be saying this.
>    dissemination procedure over a Wi-Fi face, towards an edge router it will
>    ignore all notifications that Chronosync will send related to Adjacency
>    LSAs. Why? A few more words here would be helpful.
>
> [End of Comments]
>
> DaveO
>

-- 

*Paulo Mendes, Ph.D*

Senior Scientistic

Central Research and Technology, XRC

*Airbus*
The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.