Subject: Re: [manet] Comments For AODVv2 (manet-dymo-22)

From: "Charles E. Perkins" <[email-masked]>
Date: Sun, 21 Oct 2012 21:14:44 -0700

Hello again Abdussalam,

Here are some responses to your suggestions from earlier this year.

On 5/3/2012 1:15 PM, Abdussalam Baryun wrote:
>
> AB>Overall> The dymo-22 draft is well organized and represents the
> protocol operations, operation location, and messages (when initiating
> its process, its conditions, and how processed) in section-by-section
> basis. However, it was difficult to read because I think the concept
> of version 2 and because the introduction and presentation was not
> representing the new issues added to the old version and even not seen
> the DSR-idea use in this version as mentioned.The draft lacks
> explanations of the relationship between AODV and AODVv2, because both
> protocols carry the similar name it is preferable to give more details
> to avoid misunderstanding. The similar name may indicate that both
> protocols can work together, or that AODVv2 router understands
> correctly AODV router, or they may be integrated in some network
> solutions.

I have added text to explain that AODVv2 is not interoperable with
DSR or with AODV.

>
> AB> Suggesting>  that section 3 put before section 2 to clarify the
> definition of some items of the protocol introduction presentation.

O.K.  I have done this, but there may be reasons why the Terminology should
precede the Applicability Statement.  Right now I am not aware of any such
reasons, though.

> AB>I read>In the manet discussion Chakeres to Baker (C2B), dated July
> 26 2010, sub:dymo-21:
> C2B>The nets do not have to be mobile, and DYMO may be applicable in low power
> C2B>lossy sensor networks. Without lots of details about a particular network
> C2B>deployment and application traffic, it is very hard to make
> C2B>generalizations in MANET.
>
> AB> suggest> Preferable to be mentioned in overview this discussion explanation.
> AB> suggest> If this protocol is able to be used in LLN nets as well
> as MANET, it is important to clarify it (LLN was only mentioned in
> acknowledgement section) and its relation with LLN information
> exchange requirements, because the protocol applicable to other nodes
> (e.g. LLN node) including MANET nodes.

I'm not sure about this.  We can make sure that the protocol is suitable 
for reactive
applications.  To precisely delineate the applicability to "low power 
lossy sensor networks"
make take the development of the protocol specification too far afield.  
Perhaps it
would be better to wait for additional comments before adding that to the
Applicability Statement.

> AB>thought and questions>The word “node” was used without indicating
> that it is MANET node, which its node may be a router. In addition,
> Originating Node (OrigNode) in the terminology is not defined to be a
> MANET node (e.g. if we compare with AODV RFC3561). So could it be a
> MANET node or it could not?

The intention is to allow nodes that are not AODVv2 routers to originate
traffic that will be routed by AODVv2 routers towards the destination.

> This makes the network architecture used
> not clear. Are all nodes in this network architecture, MANET nodes? If
> all messages/packets are MANET-units as RFC5444 therefore, all nodes
> are MANET. Moreover, the draft has some indirect indications that
> there MAY be more than one routing protocol (other than AODVv2) per
> net-interface in some nodes which is preferable to be mentioned.

Perhaps there is some terminology problem that needs to be resolved.  Right
now in the draft there is no occurrence of the term "MANET node". The word
"node" is used to include network nodes that are not AODVv2 routers.  And,
as always, there may be other protocols in use.  If there are places in the
specification where this introduces ambiguity, please let me know.

>
> AB>thought and questions>Is the protocol a specific purpose or general
> purpose or both, this should be specified. All MANET routing protocols
> need the purpose statement that specifies clearly its location in
> practical situation.

AODVv2 is "general purpose", but by no means universal.  The best ways to
use AODVv2 are intended to be described in the Applicability Statement.  
I am
not sure how to improve the description so that it resolves your comment.

>
> AB>thought and questions>The draft has not categorized the network’s
> devices/nodes (using only the word routing instead of nodes). The
> draft does not make explaination of the protocol’s interaction with ad
> hoc hosts (i.e. only ad hoc routers are mentioned as AODVv2 router).

I believe the interaction between a general node in the network and the 
AODVv2
routers which have responsibility for that node is out of scope for AODVv2.
As I understand it, the network organization can be almost completely 
arbitrary
as long as the AODVv2 is explicitly able to discharge its responsibility 
for offering
reachability to the nodes for which it is responsible.
>
> AB> The draft had some paragraph that not followed the RFC2119, but
> some amended as (there may be other, that needs to be amended):
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> AB>page-10>required> A RteMsg REQUIRES the following information:

Fixed.

> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> AB>page-25>required> If no UnreachableNode addresses remain in the
> RERR, no other handling is REQUIRED and the RERR is discarded.

Fixed by using simpler rewording for clarity.

> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> AB>page-27>required> In table title: “REQUIRED Administratively
> Configured Parameters”

I'm not sure about this.  I don't think that all occurrences of 
"Required" have
to be capitalized.

> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> AB>page-27>should> Similarly, AODVv2 routers SHOULD subscribe to
> LL-MANET-Routers on all their AODVv2 interfaces.
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> AB>page-32>must> Note that if multicast is used, any confidentiality
> and integrity algorithms used MUST permit multiple receivers to handle
> the message.
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Fixed.

> #Abstract

....  deleted because I already discussed these in an earlier email...

>
> #In (Content)
>
>> 4.2.2. Routing Message (RteMsg) - RREQ and RREP . . . . . . . 10
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> AB>suggest amendments> Routing Messages.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

The information in this section has been reorganized.

>
> #In section (1. Overview)
>
>> Route discovery is performed when an AODVv2 router receives a packet from a
>> node under its responsibility to a destination for which it does not have a
>> route.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> AB>idea not clear> which kind of node under responsibility of another?
> An ad hoc node responsible for another ad hoc node, IMO may mean that
> the node gets its routing information from another! (dependent-node).

The sentence which you quote is worded incorrectly.  Nevertheless, I 
agree that there
may some confusion about what "responsibility" means.  I have changed 
all occurrences
of this to instead use language about advertising a network prefix 
containing the
address of a particular node.

>
> AB>Statements seen after, in section-2, page-5> “other nodes, attached
> via participating or non-participating interfaces”.
> This was not described well, and not sure if it has relation with the
> shared address among routers mentioned later in section-2, page-5.

The intention was indeed to describe how AODVv2 routers can use AODVv2 to
provide reachability to other neighboring hosts that do not use AODVv2.
After reading over the text several times, I determined that the term 
"participating"
does not add anything important to the description.  An AODVv2 router may
have some neighbors that don't run AODVv2, and it can route packets on
behalf of those neighbors.  Under some strict conditions, the AODVv2 router
can advertise a network prefix which is shorter than the length of a 
host address.

>
> AB> does it mean that it only performs discovery when . . . , as if
> the router itself cannot be a source of demand.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

I added some text to clarify that AODVv2 routers support routing 
operations for
their local processes as well as routing on behalf of their neighboring 
nodes.
>
>> During route discovery, the originator’s AODVv2 router initiates
>> dissemination of a Route Request (RREQ) throughout the network to
>> find a route to a particular destination, via the AODVv2 router
>> responsible for this destination.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> AB>not clear> originator; what did this node originate? Do we mean the
> router’s responsible for one, and it request for a connection to
> destination (as the responsibility is at destination or at source
> side.

This particular sentence is clearer if the word "originator’s" is simply 
deleted.
But to answer your question, the "originator" is the neighboring node which
transmitted a packet to the AODVv2 router, expecting the AODVv2 router to
forward the packet along the next hop to the packet's destination.

>
> AB>suggest adding words> “Route Request message (RREQ)”.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Done.

>
>> During this hop-by-hop dissemination process, each intermediate AODVv2
>> router records a route to the originator.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> AB>suggest amendments> During the hop-by-hop dissemination process,
> each intermediate AODVv2 router receiving the RREQ message records a
> route to the originator.
> AB> the target also should records a route to the originator..
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Done.

>
>> AODVv2 uses sequence numbers to ensure loop freedom [Perkins99].
>> Sequence numbers enable AODVv2 routers to determine the temporal
>> order of AODVv2 route discovery messages, thereby avoiding use of
>> stale routing information.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> AB>suggest amendments> “AODVv2 uses routers’ sequence numbers”.
> Or
> AB>suggest amendments> “AODVv2 uses routers’ AODVv2 sequence numbers (SeqNum)”.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Isn't that pretty much redundant?  It seems to me pretty clear in context.
AODVv2 sequence numbers are the only sequence numbers mentioned in
the entire document, so there seems to be little chance for confusion.

>
> #In section (2. Applicability Statement)
>
>> AODVv2 handles a wide variety of mobility patterns by dynamically
>> determining routes on-demand. AODVv2 also handles a wide variety of traffic
>> patterns. In networks with a large number of routers, AODVv2 is best suited
>> for sparse traffic scenarios where routers forward packets to only a small
>> portion of the other AODVv2 routers, due to the on-demand nature of route
>> discovery and route maintenance.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> AB>idea not clear> the word “other” confused, one side large and
> another side small of MANET network.

There was no intention to divide the network into "sides".  I have reworded
the sentence to eliminate this confusion.

>
> AB>maybe because> where the large number (portion) of AODVv2 routers
> forward packets to other small portion (number) of AODVv2 routers,
>
> AB>idea not clear> “due to the on-demand nature of route discovery and
> route maintenance”, what is the problem with both on-demand(discovery)
> or reactive(maintenance) nature? Do both create the different portion
> sides of routes?

Generally, if each MANET router has to maintain routes that pass through 
most
of the MANET routers in the MANET, then it's better to use proactive.  
If, on the
other hand, a MANET router typically has to maintain routes that only use a
smaller percentage of the MANET routers in the network, then reactive is 
likely
to be better.  The exact percentage has not to my knowledge been tabulated,
but it is known to depend on traffic patterns.

If anyone wants to discover the exact numbers and dependences,
I would be happy to collaborate.  I know how to go about getting the
answers.

>
> AB>discussion> Does the reason of the protocol suitability include
> traffic pattern and network density? Even though the paragraph claims
> AODVv2 handles them as mentioned. In the paragraph there is no clear
> relation between traffic and on-demand nature, even though on-demand
> is traffic oriented, so it seems positive to use an on-demand (the
> negative is not clear). Also for the route maintenance is related with
> route changes, which is positive.

See above.  As one trivial example, if the network has 1000 nodes, but the
entire traffic pattern is that communication is only needed between two of
the nodes which happen to be neighbors, then reactive is drastically better
than proactive.

>
> It is preferable to change the paragraph to describe both ideas; what
> AODVv2 cannot handle more suitable, with mentioning what it is best
> suitable. However, mentioning the reactive nature suitability will
> relate/reflect to all MANET Reactive Protocols not just AODVv2. This
> can be clear if using words like RECOMMENDED and/or NOT RECOMMENDED.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

If you can propose some clearer text after reviewing the above comments, 
that
would be appreciated.

>> AODVv2 is applicable to memory constrained devices, since little
>> routing state is maintained in each AODVv2 router. Only routing
>> information related to active sources and destinations is maintained,
>> in contrast to most proactive routing protocols that require routing
>> information to all routers within the routing region be maintained.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> AB>suggest amendments> “information related routes to active sources
> and to destinations is maintained”.

I used: "routing information related to routes between active sources and
       destinations"

> AB>suggest replace> “proactive routing protocols” with “MANET
> Proactive Routing protocols (MPRs)”
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

MPR is an acronym for something much different.  I did insert "MANET"
into the sentence, but to my understanding "proactive" already requires
the indicated behavior.

>
>> At any time within an AODVv2 routing region, only one AODVv2 router
>> SHOULD be responsible for, i.e. "own", any particular address.
>> Coordination among multiple AODVv2 routers to distribute routing
>> information correctly for a shared address (i.e. an address that is
>> advertised and can be reached via multiple AODVv2 routers) is not
>> described in this document. The router behavior for shifting
>> responsibility for an address from one AODVv2 router to another is
>> mentioned in Appendix C.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> AB>suggest amendments> At all times within an AODVv2 routing region,
> only one AODVv2 router SHOULD be responsible for (i.e. the
> routing-address region owner) any particular address. The coordination
> among multiple AODVv2 routers to distribute routing information
> correctly for a shared address (i.e. an address that is advertised and
> can be reached via multiple AODVv2 routers) is not described in this
> document. The AODVv2 router operation of shifting
> responsibility for an address from one AODVv2 router to another is
> mentioned in Appendix C.

Done.

>
> AB>not sure question> Is router behavior responsible for the address
> or for the address assignment? Not sure.

Address assignment is out of scope for AODVv2.

> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> AB>RFC2119> “Otherwise, persistent packet loss MAY occur”.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

This use of "may" is not one of the RFC 2119 meanings of the word.
I changed it to "could".

>
>> AODVv2 only utilizes bidirectional links. In the case of possible
>> unidirectional links, either blacklists (see Section 7.2) or other
>> means (e.g. adjacency establishment with only neighboring routers
>> that have bidirectional communication as indicated by NHDP
>> [I-D.ietf-manet-nhdp]) of ensuring and monitoring bi-directionality
>> is recommended. Otherwise, persistent packet loss may occur.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> AB>not clear> How does it not utilize unidirectional links, while
> mentioned, or who does this blacklisting, is it another protocol? Not
> sure why mention in this protocol draft while it is not clear what
> operates the blacklisting. This was not clear even in section 7.2.
> Usually some routing protocols operate the blacklisting, so does this
> mean that any/some AODVv2 router(s) in such situation may use
> blacklisting which does not affect the network’s routings.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

In AODV, this blacklisting was done using a flag on the RREP and a 
special RREP_ACK
message.  When DYMO was started, the working group discussion convinced Ian
(at that time, WG document editor) that RREP_ACK was simply not needed.  
Being
in favor of protocol simplification, Ian removed RREP_ACK and created 
the Message
TLV shown in Table 7 to serve the same purpose as the previous RREP 
flag.  I think
that this was considered to make DYMO more fully in compliance with RFC 
5444.

I agree that the blacklisting operation should be described more fully.  
I may not
be able to craft that text before the I-D submission deadline.

>
>> The routing algorithm in AODVv2 may be operated at layers other than
>> the network layer, using layer-appropriate addresses.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> AB>suggest amendments> The MANET routing algorithm of AODVv2 MAY be
> operated at another layer than the network layer, using the layer’s
> appropriate addresses.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

I'm not sure what improvement that adds.  Can you say a little more about
how it is better?  Presumably, AODVv2 is specifically a MANET routing 
protocol,
and its algorithms are properly considered as within the jurisdiction of the
[manet] WG.

>
> #In section (3. Terminology)
>
>> AODVv2 Sequence Number (SeqNum)
>> An AODVv2 Sequence Number is maintained by each AODVv2 router
>> process. This sequence number is used by other AODVv2 routers to
>> identify the temporal order of routing information generated and
>> ensure loop-free routes.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> AB>suggest amendments> An AODVv2 Sequence Number is maintained by each
> AODVv2 router process. The AODVv2 router’s sequence number is used by
> other AODVv2 routers to identify the temporal order of routing
> information generated and
> ensure loop-free routes.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

This is related to the above suggestion, and I am still not clear about how
the current text might be confusing.

>
>> Originating Node (OrigNode)
>> The originating node is the source, its AODVv2 router creates a
>> AODVv2 control message on its behalf in an effort to disseminate
>> some routing information. The originating node is also referred
>> to as a particular message’s originator.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> AB>suggest amendments> The originating node is the data source node.
> Its AODVv2 router or responsible AODVv2 router creates a AODVv2
> control message on its behalf in an effort to disseminate some routing
> information. The originating node is also referred to as a particular
> message’s originator.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

I used "the data source node" and reworded the rest of the sentence to
be more clear (I hope).

>
>> This Node (ThisNode)
>> ThisNode corresponds to the AODVv2 router process currently
>> performing a calculation or attending to a message.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> AB>confused!> the term ThisNode is not indicating to its definition
> (which makes the draft reading misunderstanding), maybe
> “RouterProcess” is more closer and clear. The word “node” is used in
> draft as a router is responsible for, therefore, the node may not
> perform route process, so it the term “ThisNode” may confuse while
> reading elsewhere.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

I think the source of confusion here is that an AODVv2 router may be also
called a "node" whenever convenient.  So, if part of the specification 
refers to
something about a "node", there is no implication that AODVv2 routers are
excluded from that part of the specification (unless that is explicitly 
stated).

If I find a good place to make that clarification, I will put in the
appropriate text.

>> Type-Length-Value structure (TLV)
>> A generic way to represent information, please see [RFC5444] for
>> additional information.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> AB>idea not clear> which kind of represent-information, does it only
> include routing or discovery information or other? Maybe say “routing
> information”.

TLVs are used to represent almost any kind of information.  There is no
restriction that they have to be used only for routing information.

> AB> add> the explanation of such types of information as:
> A generic way to represent information (add suitable types: routing,
> control, monitoring, Adjacency, etc.),

I think it would be problematic to attempt any such list, but I will await
other peoples' comments.

> AB>question> does the AODVv2 use RFC5444 if not, it will confuse.
> Refering to 5444 for more information may mean that 5444 is used in
> AODVv2 format.

Yes, AODVv2 uses RFC 5444.

> AB> suggested amendment> A generic way to represent information and as
> TLV is defined in RFC5444.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

I reworded this and cited RFC 5444 explicitly.

>
>> Unreachable Node (UnreachableNode)
>> An UnreachableNode is a node for which a forwarding route is unknown.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> AB>suggest amendments> Unreachable Node (UnreachableNode)
> An UnreachableNode is a node for which its forwarding route is unknown.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

To me, that doesn't sound right.  I'm not sure how to make it better.
As it is used elsewhere, the word "its" might even make the definition
more ambiguous.

>
> In addition to using this IP protocol number, AODVv2 may use the UDP
> port 269 (manet) [RFC5498] in conjunction with the IP Protocol Number
> 17 (UDP).
> AB> if it may use the 269 port I think only if it uses 5444. I don’t
> see statement that how will AODVv2 use 5444 info-format, and may not.

I put in an explicit statement to that effect.

>
> #In section 4.2.1. Generalized Packet and Message Structure:
>
>> For interoperability with other AODVv2 routers, all AODVv2 messages
>> specified in this document SHOULD sent using the IP protocol number
>> (138) reserved for manet protocols [RFC5498]; or the UDP destination
>> port (269) reserved for manet protocols [RFC5498] and IP protocol
>> number for UDP.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> AB>suggest> delete the “with other”, it seems like they are different
> routers, we may replace with “among all”.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

The sentence is even better if the entire first clause is deleted.

>
>> A packet is made up of messages. A message is made up of a
>> message header, message TLV block, and zero or more address blocks.
>> Each of the address blocks may also have an associated address TLV
>> block.
> AB> is it an IP packet made up of messages or it is another type of
> packets? The packet should be clarified. Maybe it is “5444 packet” or
> we have a name for it as MANET-Packet. Are the messages AODV messages
> or UDP encapsulating AODV messages? The answer is not clear her
> neither in RFC5444 that this document refers to. Messages can be
> AODVv2 messages, but what about addresses.
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

How about "AODVv2 messages are transmitted in packets that conform" ...
to RFC 5444  ?

>
>> Most AODVv2 messages are sent with the IP destination address set to
>> the link-local multicast address LL-MANET-Routers [RFC5498] unless
>> otherwise stated. Therefore, all AODVv2 routers SHOULD subscribe to
>> LL-MANET-Routers [RFC5498] for receiving control packets.
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> AB>not sure> what is control packet, is it routing control? Please amend.
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Done.

>
> #In section 5.3.3
>
>> For each of the additional addresses considered, ThisNode first
>> checks the that the address is a multihop-capable unicast address.
>> If the address is not a unicast address, the address and all related >information MUST be removed.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> AB>delete and add> delete “the” in “checks the that”
> Add “then” before “address and all related”.
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Done.

>
> # section 6
>> If, RESPONSIBLE_ADDRESSES is zero, this AODVv2 router is only responsible >for its own addresses.
> AB> does it have a list of its addresses that are its responsibility,

Yes.

> and does it have a list of its addresses that are not its
> responsibility (i.e. possibility some its addresses is other router
> responsibility).

No.

I'll put in some text to say this explicitly.

-- 
Regards,
Charlie P.

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Mon, 22 Oct 2012 06:21:18 +0000

Hi Charlie,

I made a first pass and found the document in GREAT shape, and I do agree with everything you said
below. One comment (more later) below:

On Oct 22, 2012, at 6:14 AM, Charles E. Perkins wrote:

Hello again Abdussalam,

I'm not sure about this.  We can make sure that the protocol is suitable for reactive
applications.  To precisely delineate the applicability to "low power lossy sensor networks"
make take the development of the protocol specification too far afield.  Perhaps it
would be better to wait for additional comments before adding that to the
Applicability Statement.

JP> I cannot agree more; I would really opposed to this; not only there would be issue with WG
charters,and this would re-open the doors to the number of LLNs such protocols do not apply to.

AODVv2 is "general purpose", but by no means universal.  The best ways to
use AODVv2 are intended to be described in the Applicability Statement.  I am
not sure how to improve the description so that it resolves your comment.

I believe the interaction between a general node in the network and the AODVv2
routers which have responsibility for that node is out of scope for AODVv2.
As I understand it, the network organization can be almost completely arbitrary
as long as the AODVv2 is explicitly able to discharge its responsibility for offering
reachability to the nodes for which it is responsible.

Fixed.

I'm not sure about this.  I don't think that all occurrences of "Required" have
to be capitalized.

Fixed.

#Abstract

#In (Content)

The sentence which you quote is worded incorrectly.  Nevertheless, I agree that there
may some confusion about what "responsibility" means.  I have changed all occurrences
of this to instead use language about advertising a network prefix containing the
address of a particular node.

The intention was indeed to describe how AODVv2 routers can use AODVv2 to
provide reachability to other neighboring hosts that do not use AODVv2.
After reading over the text several times, I determined that the term "participating"
does not add anything important to the description.  An AODVv2 router may
have some neighbors that don't run AODVv2, and it can route packets on
behalf of those neighbors.  Under some strict conditions, the AODVv2 router
can advertise a network prefix which is shorter than the length of a host address.

I added some text to clarify that AODVv2 routers support routing operations for
their local processes as well as routing on behalf of their neighboring nodes.

This particular sentence is clearer if the word "originator’s" is simply deleted.
But to answer your question, the "originator" is the neighboring node which
transmitted a packet to the AODVv2 router, expecting the AODVv2 router to
forward the packet along the next hop to the packet's destination.

Done.

Done.

Generally, if each MANET router has to maintain routes that pass through most
of the MANET routers in the MANET, then it's better to use proactive.  If, on the
other hand, a MANET router typically has to maintain routes that only use a
smaller percentage of the MANET routers in the network, then reactive is likely
to be better.  The exact percentage has not to my knowledge been tabulated,
but it is known to depend on traffic patterns.

If you can propose some clearer text after reviewing the above comments, that
would be appreciated.

Done.

In AODV, this blacklisting was done using a flag on the RREP and a special RREP_ACK
message.  When DYMO was started, the working group discussion convinced Ian
(at that time, WG document editor) that RREP_ACK was simply not needed.  Being
in favor of protocol simplification, Ian removed RREP_ACK and created the Message
TLV shown in Table 7 to serve the same purpose as the previous RREP flag.  I think
that this was considered to make DYMO more fully in compliance with RFC 5444.

I agree that the blacklisting operation should be described more fully.  I may not
be able to craft that text before the I-D submission deadline.

I'm not sure what improvement that adds.  Can you say a little more about
how it is better?  Presumably, AODVv2 is specifically a MANET routing protocol,
and its algorithms are properly considered as within the jurisdiction of the
[manet] WG.

This Node (ThisNode)

I think the source of confusion here is that an AODVv2 router may be also
called a "node" whenever convenient.  So, if part of the specification refers to
something about a "node", there is no implication that AODVv2 routers are
excluded from that part of the specification (unless that is explicitly stated).

Done.

#In section 5.3.3

Done.

# section 6

Yes.

No.

--
Regards,
Charlie P.

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 22 Oct 2012 13:38:20 +0200

Thanks Charlie,

I look forward to review the new WG draft,

All the best,

Abdussalam Baryun
University of Glamorgan, UK

On 10/22/12, Charles E. Perkins <[email-masked]> wrote:
>>> If the address is not a unicast address, the address and all related
>>> >information MUST be removed.
>>> If, RESPONSIBLE_ADDRESSES is zero, this AODVv2 router is only responsible
>>> >for its own addresses.